Data Corruption with rs232 module

The SD write is slow.

Hi,
I think, if you need a high data rate that using the event handler of the serial port class is not the best choice. I think this event handler gives a very fast reaction time for short messages but not a higher data rate for longer messages as a new event will occur when new data arrived and the data chunks will be rather short. In my modification of the Bluetooth module driver (Class bluetooth.cs in FEZ/PC Bluetooth File Transfer Server/Client) I read the data from the serial port in a circular buffer, from there read them back in a byte array and sent this byte array over a delegate to the main program. I reached a data rate of around 30 kbits/sec. The program also shows how the data can be written to the SD-Card. I saw no data corruption if I took care that the sender did not send to much data without a gap

That’s where you need flow control on the link. (RTS/CTS)

@ Cowboy -

I think that usually on our NETMF devices the transport of data from the serial port is so slow that the time it needs to write the data on the SD-Card is not the limiting factor.

Yes you are right, but additionally on sender side you need some mechanism to avoid writing to the write buffer of the sender serial port if this buffers is not emptied over the serial connection. If the data arise continiously fast on Sender side flow control alone does not solve the problem. Each part in the transmission chain must be able to transmit at the average datarate or sooner or later you will have a buffer overflow or inacceptable latency between arising of data an arriving at the final receiver.

@ RoSchmi - “Each part in the transmission chain must be able to transmit at the average data rate or sooner or later you will have a buffer overflow or inacceptable latency between arising of data an arriving at the final receiver.”

That’s exactly what hardware flow control is about.

Hey guys,

I took Roland’s code and just ran a test.

I sent 5, 14 byte arrays into my Cerberus at 57600.

I repeated it 5,000 times with zero delays.

I reduced the sleep param in the runWriter thread from 100ms down to 10ms and ran it concurrently.

Both sides ran flat out and never missed a beat.

This was driving me crazy.

The only downside is that I’ll have to start talking to my wife again. :wink:

THANK YOU.