I would like to know if the flush() function available for the UART is a blocking function (ie will it block the single imp processing thread until all bytes are flushed out of the UART) ? More in particular, will it prevent reception of serial data (processing of the data received in th FIFO) on one of the other UARTS as long as it’s not finished ?
I assume so, given that it doesn’t cater for an async callback, just to make sure…
If it is blocking, an async version would be nice … Now I plan on estimating the time it will take to flush and program an event for it using imp.wakeup
Hi vedecoid, have a look at my post from a few weeks ago. The Imp team are considering callback option. I don’t believe reception of serial data is affected by flush(), but your callback won’t be called until the imp device is idle.
Thanks. Hadn’t spotted that one.
You’re probably right about the reception of bytes (which I assume is under interrupt control under the hood) and the delay of the callback execution. That’s what I need the non-blocking flush for. When sending a large stream, I could overflow the incoming fifo (80 bytes only)…
For now I’ll simulate async with a calculated imp.wakeup delayed event to pull the TxEnable back up and not use flush() at all.
I hope they’re looking at providing various async operations for the peripherals. SPI Readblob and Write of large blobs could benefit from it too…
UART async stuff has been implemented, will be in the release after next. SPI currently doesn’t use a buffer (it’s synchronous so uses your squirrel buffer) hence that’s a bit different.