SBC with large GPIO pin count

[theoldwizard1]

I am think of a project that I would like to build using one of the current day SBC (Raspberry Pi, etc) but I have a few requirement.

• At least 48 (64 would be better) GPIO pins, without using a I²C or SPI, that are easily accessible (i.e no soldering). I need to be able to "read" 48 pins as fast as possible.
  Multiple cores
  On chip RAM (off chip is just too slow) for at least some of the data.

Does such a SBC exist ?

[stj]

ST NUCLEO-144 series.

[LapTop006]

Look at the TI Sitara line (used in the BeagleBoard's), although often not by default (you switch the pinmux) they get up around what you're asking for, although probably not in any board that already exists.

Using an FPGA to mux the data is probably a more conventional method these days.

[theoldwizard1]

It turns out, if you use a genuine Raspberry Pi Compute Module (a daughter board in the same form factor as an SDIMM) with the Compute Module IO Board (the mother board with the SDIMM socket) you get access to ALL of the GPIO pins.  You do NOT get all of the functionality of the an RPi B or RPi B+, but you do get the GPIO pins !

[theoldwizard1]

Look at the TI Sitara line (used in the BeagleBoard's), although often not by default (you switch the pinmux) they get up around what you're asking for, although probably not in any board that already exists.

Using an FPGA to mux the data is probably a more conventional method these days.

The point is, I don't WANT the hassle of a FPGA !

The TI Sitata line is the only line used on a commonly supported SBC that has actual on-chip RAM, a useful feature for this application.

[james_s]

What's wrong with an I2C IO expander? This is exactly the sort of thing they're made for.

[Monkeh]

What's wrong with an I2C IO expander? This is exactly the sort of thing they're made for.

"as fast as possible"

[DaJMasta]

The point is, I don't WANT the hassle of a FPGA !

The TI Sitata line is the only line used on a commonly supported SBC that has actual on-chip RAM, a useful feature for this application.

What's the hassle?  There's learning to code one, if you haven't, but there are plenty flavors that don't have so many power rails or whatnot... and when I see lots of input needing to be fast, that's definitely the first programmable device I think of.


But I guess, how fast are we talking?  As fast as possible to what speed?  Just digital data?  Just input?  Reading a full register at a time and storing in memory can probably be done pretty quickly on one of these 100MHz+ arm chips, but if you really just want fast capture and storage, putting together a dedicated storage circuit or using an FPGA seems to generally be faster than sequential reading of the pins on a micro and just cranking the clock speed.  If we're talking 10s of MHz capture speed, then any chip with a DDR interface of some sort could probably handle all the data storage in external RAM, but if you're talking capture at 100MHz+, I don't think you're going to achieve that on a micro of almost any sort on a wide bus.


Figure out how fast it needs to be.  Figure out how much time skew is acceptable between reading the first input to reading the last (not every connection is going to be one port, so it's going to be at least a couple clock cycles in total on a micro unless you're using some DMA mode).  Figure out how much data bandwidth that is and how much data needs to be stored (will tell you what memory technologies are sufficient) and that should tell you if the memory needs to be on chip and how much needs to be there.


If you really just want raw performance using commercial parts and standard system architectures..... use an FPGA and whatever compatible fast memory it supports (DDR2 or 3 probably).  Otherwise if it's digital data, you could try looking at dual ported memory and then discrete bus drivers for gating the data in on a set clock, then connect that memory to whatever micro is fast enough to read it and do what you want with the data.

[Siwastaja]

What's wrong with an I2C IO expander? This is exactly the sort of thing they're made for.

"as fast as possible"

For some "high-level" bloat software guys, an IO poll or storage happening at 10Hz intervals and <100ms jitter may be overwhelmingly fast black magic.

For high-speed electronics guys, storing binary inputs at 10 gigasamples per second may be ordinary stuff.

The chances are, when someone asks something to be done with Raspberry Pi or similar "as fast as possible", without numerically knowing what speed they actually need, it's very likely it's closer to the first than the second extreme.

It's very improbable that an FPGA is needed. There are slow and fast IO expanding solutions available. If I need to guess, the OP's issue with an IO expander IC is not actually speed, but the "complexity" of connecting anything to the SBC. Complexity with a custom FPGA design for someone with no FPGA experience is quickly 5-6 orders of magnitude more. Why I think this is the case? "No soldering" was mentioned...

[technix]

I would suggest something like this: still a FPGA but a bit different: Myir Z-turn board with XC7Z010 and a breakout board. Implement that ultra-wide ultra-fast GPIO on the FPGA side, and put application code on the ARM side.

[SiliconWizard]

Well, not knowing what the op means by "sbc" and "fast", it's rather pointless to guess a solution.
A simple MCU-based board has nothing much to do with an RPi in terms of actual programming and real-time performance for instance. We don't know what the op is familiar with. Does it need to run a full-fledged OS? What programming languages?
As Siwastaja said, what is "fast" only commits whoever is mentioning the term.

[theoldwizard1]

Well, not knowing what the op means by "sbc" and "fast", it's rather pointless to guess a solution.
A simple MCU-based board has nothing much to do with an RPi in terms of actual programming and real-time performance for instance. We don't know what the op is familiar with. Does it need to run a full-fledged OS? What programming languages?
As Siwastaja said, what is "fast" only commits whoever is mentioning the term.

Touché !  "Bigger than a bread box and smaller than a box car" is a very poor description.

The project would be for data acquisition.  Multiple process would be required with one dedicated to gathering the data off the GPIO pins and written to a RAM shared by other processors.  The other processors would be doing various display and housekeeping.  I would like to be able to grab the "value" of the GPIO pins and store in in the shared RAM in a loop that would take about 100 nsec, 50 would be better.

RPi missing on several counts.  Can't access the pins that fast and there is no on chip shared RAM (off chip not fast enough nor deterministic) other than the L2 cache.

[DaJMasta]

So 10-20MHz polling?  That may be doable with a micro, but a lot of their pin frequencies (outside of the hardware specific high speed interfaces) are going to be lower than that.  As for the memory.... virtually any external decent speed memory should be fine.  You're talking up to 128Mbit per second (64 bits by 20MHz), which could even be done on a fairly narrow data bus.  You share RAM on the cycles you're not writing data to memory... and for any fast processor or fast external memory, that will be at least several cycles of other stuff that can happen on a single core.  Using external acquisition (like latching buffers triggered by your sample clock), you could set up a small counter to cycle through banks of latching buffers, so that you could acquire at full speed and then read at slower rates.  Two banks and a flip flop on the sample clock would halve the rate needed by the GPIO to read, but you'd need double the pins to read it.  That said, I've seen reports of RPi GPIO being read at over 10MHz (even over 20MHz), though I don't know if there would be gaps in acquisition timing for other tasks.



Still, the simplest way to be sure is an FPGA.  Tons of GPIO pins, plenty of RAM for small scale storage on chip and ready made interfaces for fast external RAM, good overall speed, and the ability to run entirely separate from your main program loop - with bigger ones, you can even make a software core in remaining FPGA fabric or get one with an integrated hardware core so you don't even need a different chip.  The strength of FPGAs is parallel data processing in a fully configurable manner..... and that really sounds like what you need unless you want to lay out a ton of discrete logic or spin your own ASIC.

[SiliconWizard]

I would like to be able to grab the "value" of the GPIO pins and store in in the shared RAM in a loop that would take about 100 nsec, 50 would be better.

Yeah, there's no way you can do that with an RPi unless you use an additional board dedicated to the GPIO acquisition and buffering. And even so, you would have to push the data back to the RPi at a throughput that you would probably fail to sustain if using USB for instance.

Even if using an MCU that will be quite a challenge if the MCU is busy doing other tasks in parallel. A fast MCU with an embedded "parallel port" peripheral feeding a DMA channel should do the trick though.