Interface change to callback min_tx_byte
senilix opened this issue · 4 comments
Hi Ken,
I'm planning to use the min protocol on a device that runs a USB CDC, as I believe you did on the Arduino platform.
I know from experience that interface changes are a no-no. But, I hope it would be possible to perhaps add a compile options for a second version of the min_tx_byte where which allows for more bytes to be send on one call. Perhaps something like:
min_tx_byte(uint8_t port, uint8_t* data, uint8_t bytes_to_send, uint8_t* bytes_send)
You get the idea.
Apart from using a device with USB many devices also have DMA support making it possible to send a chunk of data with an UART.
I have had this thought too and that's why I added the min_tx_start() and min_tx_finished() callbacks. I'm currently using MIN on a Pyboard and calling the internal USB CDC API which is just as you say. The byte-by-byte callback is done that way because of the insertion of stuff bytes in the protocol but I didn't want to force all MIN users to pay for an internal buffer. So the way I addressed it in my Pyboard firmware was to buffer it into an static buffer in the min_tx_byte callback, then shoot the whole buffer into the USB driver when it's full or when the min_tx_finished() callback happens.
Hi Ken,
Sorry, I had missed those in the header file. They will do the trick.
Btw. off-topic. Since you are using micropython and have added your min protocol to the firmware, I wonder if you know mpy-utils and fusepy? Pretty neat.
I haven't offered my MIN changes back into the firmware yet: my wrappers are a bit scabby (I've hardwired in the USB CDC, for example).
I haven't come across fusepy: my focus to date has been on stopping the internal flash from appearing in the host file system! A sector erase on the Pyboard MCU (STM32F405) takes about 250ms and freezes the CPU while it happens, which causes mayhem if you're trying to stream sensor data in real-time. Linux just loves to index disks and drop little indexing files into file systems it finds, which was a nasty thing to discover the hard way.
Hi Ken,
Thanks! I will close this issue.
Mogens