RS422 overflow debugging

I put as the category picture the nice (well, you judge) hack Guy
came up with while we were working last Thursday. We have a board talking
over RS422 to an FTDI chipset (H233 or close to that) that was giving us problems,
specifically we have dropped messages over our custom protocol (up at
https://github.com/alon/emolog). At a very late (or rather early) hour
Guy had the idea that we might be having problems with the chipset
itself, leading him to read about flow control and to connect the DSR
(again not sure - either that or CSR?) to the oscilloscope, and lo and
behold, our outages matched. So now we are on the lookout for a better
chipset on the PC side (cannot change the board unfortunately) or just
reducing the traffic.

And welcome to the electronics category!

there is an RS-485 module sitting in the green plastic boxes on the main electronics table.
i dont see the diff between this and the RS422 internet suggests PDF they are the same?

thanks. RS485 and RS422 are similar. the difference is that RS422 is point to point (only 2 devices communicating) and RS485 is multipoint (multiple devices all connected to the same bus). We use RS422 in our system.

Anyway (to Alon): I do think we have a good device right now, that FTDI RS422 converter has 4K Byte buffer in each direction, that’s considered plenty. On the other hand, even with that buffer, at 6 MBaud it gets full after ~7 ms if not being emptied by the PC. I think in the cases where we do see a problem, it starts somewhat full from the last run, and when the PC starves the FTDI too much, it gets completely full and we lose data.

solutions:

  • the proper one: HW flow control. will need patching my board, need to get the proper HW (maybe even that board Yair showed).
  • to reduce problem near the start, make sure the FTDI buffer starts empty. it’s not enough to do the flush (that I think) we currently do at the start. we probably have to read bytes until there’s no more to read (or otherwise find out how to tell the FTDI to flush it). that’s tricky since the embedded side may still be transmitting.
  • fiddle with the device driver settings - latency, USB transfer size. may cause less starving of the FTDI.
  • or… just live with it for now. throw away the first half-second or so where most of the problems are. a stopgap measure at the very least.

I found a cool TI paper on comparing all the different bus options, can’t recall the link atm.

Regarding 7ms - we can definitely check this / try to play with windows for this. But it seems a bit too low for windows / linux unless some realtime option is used. We could look for a RS422<->Ethernet bridge, that will be completely on the PC side (so no board change).

still, the buffer will be an issue in another RS422 converter (regardless
if it’s to USB or Ethernet). If we find a converter with a much larger
buffer, it will help. I doubt there is one.

Mybe of interest

thanks. we’re using a different chip at the moment, I do need to expand it
from 2 channels to 4 (to have proper HW flow control). I’ll look at it as
an option when revising the board.