Currently the request is cleared while state is either generating start or generated start. That means it's not really clear when queuing next request is possible. There is no output for that. Currently it would be probably necessary to just wait for some cycles, or in case of transmission wait for waiting output. One possible use case could be to wait for dev busy and then send another start when ie. one byte is transmitted as a command, and then there is a switch to read. For that it would be necessary to change the clear of the request from "in generating start" to "going to generating start".
Another thing is whether to somehow signal that a request has been processed - ie. after start is generated, output a pulse that request has been processed. That could allow a use case where the user would wait on the pulse, and then put in another start request to switch to receive.
Currently the request is cleared while state is either generating start or generated start. That means it's not really clear when queuing next request is possible. There is no output for that. Currently it would be probably necessary to just wait for some cycles, or in case of transmission wait for waiting output. One possible use case could be to wait for dev busy and then send another start when ie. one byte is transmitted as a command, and then there is a switch to read. For that it would be necessary to change the clear of the request from "in generating start" to "going to generating start".
Another thing is whether to somehow signal that a request has been processed - ie. after start is generated, output a pulse that request has been processed. That could allow a use case where the user would wait on the pulse, and then put in another start request to switch to receive.