Handling multichannel serial communication on FPGA

[Mads]

NI recently released cRIO modules for serial communication on RS232 and RS485/422.  We need multiple RS232 channels for our RIO systems and previously the solution would have been to use a serial port server and then communicate with that using raw TCP/IP. Having the serial communication handled by RIO modules seems a bit more elegant though so I'm looking into using the RS232 module NI9870 instead.

NI has supplied an example on how to use the 9870 - a serial loopback on port 0. I've successfully modified this to be a general driver for a selectable port (added port selection and initialization), however I really need to code a solution that handles ALL the 4 channels in parallell. I'm not sure what would be the best way to do that though. DMA FIFOs seem to be the best option for host-target communication, however in this case there are 4 channels....and I may have multiple modules so at most it could be that I need to handle as much as 32 ports. The example uses interrupts for synchronization....which off course is also a limited resource. All in all I'll probably figure out a way to do this, however if anyone else have done something similar already it would be great to hear your views on this.

Coming from the Windows-programming world (this is the first FPGA work I've done) I was also hoping to make this driver as general as possible, maybe even be able to write a wrapper containing both VISA based serial functions and the FPGA host code. That way it could be transparent how the port is accessed.

This would require 1 code that would be able to handle a variety of module configurations (well, 1 to 8 NI9870 modules in the chassis), however that does not seem to be feasible(?). When you read or write to a port you cannot just refer loosely to it with a number e.g. - the read and writes are referenced to a specific port...this means that unlike in a Windows application where you can let the user just configure that he wants to use COM port num XX and the serial functions will accept that number regardless of whether the port exists or not (returning an error if it does not exist or is in use) - the FPGA code has to have all the items it will call pre-defined. If the chassis can have 16 ports on 4 9870 modules it does not seem possible to use the same FPGA code if the chassis currently only has 1 module...Is this the reality, or is it possible to create a more flexible solution?

If it turns out that the FPGA has to be reprogrammed if another serial module is added (or one is removed) it would seem much better to drop the modules and use a port server and tcp/ip instead...that way using new ports will only be a question of configuration (IP and port), not reprogramming...That may not be possible always (if you need the compact size and roughness only a single RIO chassis would offer), but in our case it is - it' just not as elegant hardware-wise.

[DrewBob]

> NI has supplied an example on how to use the 9870 - a serial loopback on port 0.

I would be interested to see this example code. I couldn't find it on ni.com or similar. Can you point me towards it?

[Mads]

After installing the driver software from www.ni.com/987x  (the modules were released before they could make a distribution that included the software) you can find the single channel example from LabView this way: Help->Find Example->Hardware Input and Output->Compact RIO->Module Specific->Serial.

If only they had made a multichannel example right away, then we would be up and running in no time instead...

[bbean]

Hi Mads,

Have you chosen a certain path for this issue and had any luck?  I'm running into the same problem now.

[Mads]

I ended up using the single-channel example and modified it to handle up to 10 channels if I stripped off the baud rate setting feature I added to it at first (the 1M FPGA could not handle more, if I added an eleventh channel the code would be to large).

The ports are not available in parallell, however by requesting bytes at port and not read until all bytes have been received I avoid that parallell processes are held up much. It is not ideal, but in this case the performance was good enough.

I did make a rough parallell version as well and got it working in one direction, however it was never finished as I focused on getting the rest of the project done on time.

One thing I had some problems with (apart from the code size issue) was that the modules returned a buffer overflow error, not just if there was a message of more than 255 characters, but also if the reply comes to quick (no matter how short)). It seems that the modules are very slow to switch between tx and rx and that they hang if it happens. Flushing the buffer is necessary to be able to read any data after such an error, however you often have to do a series of flushes to get things back up and running (again even though the message received really is a short one).

[ophi]

Hi Mads,

Can you send in the code that you had done to read multiple channels from the 9870 module?  Would like to take a look at how you do it, thanks!

[Mads]

Well, the multichannel experiment only wrote data, it did not read...(see attached VIs) however the concept can be used in both directions: Add a header to the FIFO data where the header tells the recipient what port the data is going to or comes from...Then use e.g. a state machine to read the FIFO, split the header and data, and route the data to the loop handling the port.

If you are going to read data you will get into one of the downsides to this namely that you will need to have a central communications manager that reads the incoming data and distributes it to the requesting VI. This way you can have more parallell access to both read and write, however the reads will have to be routed through this handler. How big a performance gain this would give is unknown though. You still only have one DMA FIFO for each direction so there is a limit to how parallell things can get, but logically this might get you closer than the NI example...

[sharda]

Hi,

I am trying to use 9870 to collect GPS data, which is ina string format. I have 3 9221 AI modules. Is there a way i donot use the FIFO route and simple read the GPS string parse it and then send it to the host program.

Or if some one can suggest/send some tutorials to work it around.

Thanks,

Ajay

[RavensFan]

Your question seems to have nothing to do with the questions originally posted in this year old thread.  I recommend that you start a new message thread with your question to get a better response.