Separate the open, close and xfer so an interface can be left open between transfers

[stephendpmurphy]

The current shost_xfer_begin function opens, transfers and then closes an interface. We would like to leave the interface open so transactions can be sent and received at will without constantly opening and closing the interface. This would mean expanding the API to

int shost_xfer_open(shost_xfer_t *xfer) { ... }
int shost_xfer_begin(shost_xfer_t *xfer) { ... }
int shost_xfer_close(shost_xfer_t *xfer) { ... }

This would mean the shost_xfer_t object now needs to store the Protocol context so it can be shared across function calls. The shost_xfer_open and shost_xfer_close would just call a virtual _open and a public close function. The open requires context and specific modes and params based on the interface. The close just generically closes the mpsse context which the Protocol class is storing.

[stephendpmurphy]

We could leave shost_xfer_begin as the current "All encompassing" function call which does it all and add another api like shost_xfer_execute which only executes a transfer (Meaning the open and close must be called on their own before and after the execute call.

[NoeelMoeskops]

I was considering this as well when designing the Protocol class. But as you stated the issue is that the base class needs to be protocol aware. It might be cleaner to leave the connection open, but I really don't see the benefit in doing so. And it comes with a huge downside that if you forget to open/close the connection then strange error would occur. Closing/opening the connection every time we use it, might seem like a cumbersome task, but it is less error-prone and ensures that the FT2232H is always in a zero (closed) state. This becomes especially handy when things like (for example) multithreading come into play. Otherwise, we would need to check if it is open every time we do a write command. Which will result in more logic (and more potential for errors) than just opening and closing it every time.

[stephendpmurphy]

Fair points! It's not necessary yet for our use case so I'll close this issue.