Electronics > Projects, Designs, and Technical Stuff
SBC with large GPIO pin count
<< < (3/3)
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:

--- Quote from: SiliconWizard on November 22, 2018, 06:31:16 pm ---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. :-//

--- End quote ---
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:

--- Quote from: theoldwizard1 on November 23, 2018, 02:48:52 am ---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.

--- End quote ---

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.

Navigation
Message Index
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod