2011-08-27 01:53 AM
Dear STM32 users,
I am facing an issue not related to the micro, it seems to be a general topic when transmitting data over usart. In my application I have an STM32 micro that will transmitt and receive data to/from another device (let us say device X). The STM32 device is doing the following steps: 1- Receive 16-byte from the device X 2- Process the received 16-byte data : this process is a workload for the STM32 3- Receive a new buffer of 16-byte (I am using a time-out for error handling) The device X: 1- Transmit a 16-byte to STM32 device 2- Make an active delay 3- Transmit a new 16-byte to STM32 device I discovered that sometimes the device X transmit the new buffer while the STM32 is processing data (step 2). Using delay is not good especially that I have the two systems running @ different frequencies. I was thinking to use hardware flow control but the usart embedded in STM32 is doing flow control on a single byte and not on 16-byte buffer. Is there a solution how to synchronize the two devices and avoid this desynchro? Thank you in advance and have a nice week-end.Po.JackBlack2011-08-27 05:26 AM
Well if you use interrupts and buffering, you shouldn't lose or miss data from subsequent packets. Provided you can process the data units at least as fast as they are transmitted. If you are slow you will need to pace the sender so as not to be overwhelmed.
You could use hardware flow control, but a software protocol like XON/XOFF might be more effective, as would one that has synchronization characters, and acknowledgment. Using two way communication is helpful if you need to pace the data stream. Where integrity is an issue, use CRC or checksum byte(s). If you are just using a stream of data, and need to be able to resynchronize after lost or corrupt data, you could use a self-synchronizing format like SLIP. Basically the use of escape characters to identify the beginning/end of data packets. Can't afford to lose any data, a protocol like XMODEM, tailored to your packet size, would be more robust. There are lots of ways to do this, but get familiar with simple methods that already exist, and look at ways to apply those type of ideas to your problem.2011-08-27 01:04 PM
What to say after such post by Clive1? (loud/long applause)
Clear, detailed, justified - and applications/choice tied to purpose. Thanks Clive1 for your long unmatched (and unassuming) superb, thoughtful service to this forum community.2011-08-27 03:19 PM
Just 1 addition to clive1's post:
Note that the STM32 USARTs support 9-bit mode - which could possibly be used as a means of synchronisation...