I have a very interesting problem. I am using an ethernet to serial port converter (ENET-RS485/4) to load the contents of flash memory on a remote microcontroller. This micro uses software handshaking (XON/XOFF) to allow itself to process data but not in the sense you would usually imagine.
A typical example of software handshaking might normally occur when data from a buffer is continually processed. When the buffer reaches, say 90% the micro would send an XOFF so that the host would turn it's transmitter off. When the micro processed it's data buffer until it was only, say about 30% full, it might send the XON character to let the host know it can continue to transmit information.
Unlike the example just cited, the micro I'm flashing has a 40k buffer that it fills to completely full before processing. It will send an XOFF character with about 5 bytes to spare, process the 40k you just sent it, send an XON character, then wait for the next 40k chunk of code.
Using a regular computer plugged directly into the micro, this has never been a problem. The terminal software receives the XOFF character and immediately quits sending. The problem arises using the network serial port converter. When sending segments of data (the code that will be loaded into flash) to the serial port, if the micro tries to send an XOFF, the serial port will continue to send data until it is finished with that segment. For example you can theoretically write 64k to the port although I usually do 1k segments of the file I am sending. If however, the micro sends an XOFF halfway through that segment, the converter continues sending the 1k of data it received over the network, until it is finished. This of courses causes a buffer overflow on the micro.
My next recourse was to send data one byte at a time. With a normal serial port this is not a problem. With a network to serial converter though, many packets are sent to the converter with one byte of data. The packets that can't be transmitted on the network immediately are buffered to allow the software to continue to operate, which creates a problem when the micro sends back an XOFF. The software receives the XOFF, but too many network packets are already buffered to be sent, so again, the micro has a buffer overflow.
The next thing I tried doing was putting a delay in between bytes. Needless to say, this agonizingly slow. The delay makes sure the network/driver keeps up and doesn't buffer packets, so when the micro sends an XOFF, we can receive and process it before more information is transmitted. I also had problems doing this though because a delay can make the micro timeout and exit it's download routine for the flash code.
So when doing this I found there to be two variables that affected performance. Packet size--how many bytes I sent at once--and delay time in between sending data packets. The magic combination for interfacing with my micro is 5 byte data sets with a 100ms delay. Maybe it's just me, but 50 bytes/sec is NOT acceptable for loading a 1mb file! The workaround is to send large packets like there's no tomorrow, count internally to a little less then 40k, then slow down when the micro is about to send an XOFF. This is still tedious and slow, and vulnerable to what results in a hang if there is no XON detected--we're stuck sending at 50 bytes/sec so you might as well call it a day and start over.
Finally to my questions. What does opening a serial port with software flow control enabled actually do? What are the internal mechanics of this? Since I was unaware of this option when I started coding, I made my own software flow control which checks for XON/XOFF characters. My question is though, is there way to tell the ethernet to serial converter to check for XON/XOFF and to respond accordingly? If this were the case I could send it a 1k segment over the network which it would send to the micro. If the micro sent an XOFF back during the middle of that segment, the network to serial converter would know to stop transmitting data until it received an XON character. As it is now it just keeps sending.
Is there any way to achieve this? I tried opening the port with flow control, input XON/XOFF enabled but it appeared not to work the way I thought it would (as described above). Can anyone give me insight into this matter? Even if you are unfamiliar with the network converters you might be able to help me out on the operations of a regular port and how it actually works when it is initialized with software flow control enabled--I'm guessing that the network to serial converter can be made to behave the same way as a normal serial port in almost all regards.
Thanks for any help.
