efficiently getting data into RPi

[Harvs]

I've got an application where I'm using a two STM32M4F's to do some real time control work, then was going to datalog back to a single RPi (or similar linux SBC) that can provide a network facing interface to view the data and issue basic commands back to the uCs.  There'll be about 4kB/s of data going back to the RPi for each of the M4F's, then recorded onto USB HDD.

As the M4F's have pretty much every interface available on them, I've been doing some research on the RPi as to what interface going to be best.  I've been quite surprised to see that there's no DMA support available on either the UART or SPI interfaces and only an 8-byte FIFO.  Combined with the servicing of the UART and SPI as a routine task, it seems people are having quite a bit of trouble with it dropping bytes even at reasonably modest continuous data rates (as the CPU gets bothered with other tasks.)

I doubt that it's going to have real issues at 2x 4kB/s, and probably just need to setup a test rig to see how this is going to work.  However, any better ideas?

[ve7xen]

I'd just use USB. Either with quick and dirty USB UART chips or using the M4's built in USB interface. Should cope with the data rate just fine and will be well supported at kernel mode in Linux on the Pi. It's the only reasonable bandwidth interface on the Pi board anyway (aside from the camera and display interfaces).

Could also look at using a BeagleBone Black which has much better hardware for not a lot more money.

[FrankBuss]

I would use SPI master from the Raspberry Pi. Up to some MB/s is no problem at all, with just a few percent CPU usage, and no way that bytes get lost if the RPi is the master. See the RPi SPI driver authors webpage (and the comments) for code examples:

http://www.bootc.net/archives/2012/05/19/spi-on-the-raspberry-pi-again/

Maybe set manually some GPIO pins to select the two chipselects of your external chips before each SPI transfer.

[notsob]

Probably time to toss the Pi and get a beaglebone black , I think they are roughly half the price of the original beaglebone

[Harvs]

I would use SPI master from the Raspberry Pi. Up to some MB/s is no problem at all, with just a few percent CPU usage, and no way that bytes get lost if the RPi is the master. See the RPi SPI driver authors webpage (and the comments) for code examples:

http://www.bootc.net/archives/2012/05/19/spi-on-the-raspberry-pi-again/

Maybe set manually some GPIO pins to select the two chipselects of your external chips before each SPI transfer.

Of course, easy solution.  I can use some GPIO to indicate buffer level in the M4's as well.

M4's built in USB interface

I thought about it, but I didn't want the overhead of the usb framework at this stage as I'm not yet sure how much processing time the control algorithms are going to take. 

Beaglebone black looks nice.  Thank god they've put mounting holes in unlike RPi! But I've got a couple of pi's sitting around so I'll start with that. whatever code is on the Pi will be easily ported I'm sure.

Thanks 

[ve7xen]

USB overhead should be very minimal. The controller is in hardware. All the software has to do is put bytes into the hardware peripheral and do the initial enumeration. You can probably do it with DMA, if you want.

[FrankBuss]

USB overhead should be very minimal. The controller is in hardware. All the software has to do is put bytes into the hardware peripheral and do the initial enumeration. You can probably do it with DMA, if you want.

USB overhead could be a problem. Broadcom messed up the implementation. It needs 8,000 interrupts per second and up to 20% of CPU usage, even when idle (at least with the driver from last year, don't know if they improved it) :

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=7866

[Harvs]

USB overhead should be very minimal. The controller is in hardware. All the software has to do is put bytes into the hardware peripheral and do the initial enumeration. You can probably do it with DMA, if you want.

I haven't used the STM framework, but the PIC32 USB wasn't that simple.  You still needed to give it processing time every ms so it could respond to any requests from the host.  I'm sure this wont be anything significant for a 168MHz M4, but it's also no where near as easy as the UART or SPI which is just filling a memory location with bytes and telling the DMA to let you know when it's finished.

[ve7xen]

USB overhead could be a problem. Broadcom messed up the implementation. It needs 8,000 interrupts per second and up to 20% of CPU usage, even when idle (at least with the driver from last year, don't know if they improved it) :

Ah, I don't know much about the RaspberryPi. I kinda shunned the project because of the Broadcom affiliation, to be honest. If that's idle though, wouldn't it be a problem regardless of the interface used for the project?

No it won't be as simple as a UART, which is why I suggested you just use a ready-made USB UART chip. USB shouldn't require 1ms polling to the application though; if the FIFO is empty the peripheral should be intelligent enough to respond on its own, I believe this is the case with the M3's USB peripheral (though I've only used that for Audio Class which does require 1ms updates), and seems to be for the F4 as well.

[ovnr]

If cost is less of a concern, you could set up another micro with a decent slab of SRAM (you can buy a 128 kByte SPI SRAM (giving 2x16 sec of buffer time) for <$3), which accepts the data from your workhorse micros and buffers it, then spits out packets of data at the request of the host, whether that's a RPi or anything else.

Of course, you could do the same on the STM32M4F's if you have enough free RAM and if servicing requests from the host won't get in the way of your main program. I do agree that you shouldn't expect a RPi or anything else running Linux/etc to never drop bytes when operating as a slave (with minimal FIFOs and no DMA).


Also, if cost is a concern, consider using a TL-WR703N router ($22 on eBay) with OpenWRT instead - it's got wifi, LAN, a USB port, a single serial port and probably enough grunt to serve the data over the network, store it on a USB disk, etc. Swapping the flash on it for a 16MB chip (up from 4 MB, $3) is generally a necessity. If you do, build a new binary from the bleeding edge source or you'll have a headache. Been there, done that.

[HeyTom]

I created something that might fill this need.  It's a single chip that connects to an RPi through i2c and can be configured to provide digital in/out, analog in/out, pwm, pulse counting, and sets of pulses.

http://www.alleypress.com

I have some videos showing it in action.  Basically you can use any language you want, or type commands at the command line and have it configure and drive the ins/outs.

You can change the i2c address, so you can run many at a time.

I would like your input about this thing.

[Harvs]

I created something that might fill this need.  It's a single chip that connects to an RPi through i2c and can be configured to provide digital in/out, analog in/out, pwm, pulse counting, and sets of pulses.

http://www.alleypress.com

I have some videos showing it in action.  Basically you can use any language you want, or type commands at the command line and have it configure and drive the ins/outs.

You can change the i2c address, so you can run many at a time.

I would like your input about this thing.

Hi Tom,

Looks like a neat project you've done there, and if you are after a general discussion on it you'd be better off starting a thread for it specifically.

However, I don't see it being any benefit for this application of mine.  I already have two ARM M4F's doing the data processing and they have pretty much every interface on them free with the full support of a DMA.  My original question related to the issue of the RPi not having DMA support for the more basic interfaces (UART, SPI etc,) and would therefore require regular software servicing to carry out the transfers.  So the solutions offered earlier of the UART-USB bridge or using the RPi SPI as the bus master have provided solutions to the problem.