Possibly some confusion - there are 2 x 32-bit GPIO registers, however the 8 (to 21) avalable GPIO pins are all inside one of those registers, but not at consecutive bit locations.signal wrote:Based on the wiringPi speed test example (which tests 3 methods of accessing GPIO) it looks like you can get up to about 14Mhz reliably. Maybe a smidge faster with overclocking.
This would still be well under my 40Mhz need though.
Gordon at wiringPi pointed out that there are 32 GPIO lines to use though. Using something like a shift register to store x4 8bit samples would require 10Mhz to read. Well within the limits but unsure how to handle a read cycle to the RPi while we still have data coming in.
Digging into it a bit more.
What code did you use to read data? Or was this just a case of toggling gpios as fast as possible?ci.v.ic wrote:I was able to read and write a 5V SRAM with 25 MHz max. I used assembler code to maximize the bit banging method, however, 40 MHz seems not to be possible. Details here: http://d-fence.sytes.net/raspberry-pis-gpio-speed/
You may have more joy using SPI. If I get a chance I'll connect two Pi's and see how fast I can push data between them. Might also try the same experiment with bit bang gpios.ci.v.ic wrote:I'm sorry it was only bit banging (toggling pins). There is second memory interface but I'm trying to find a documentation about that interface for months. Probably it is only for sd cards but maybe it is really for a second memory chip.
I'm not sure that ci.v.ic had a particular task in mind, the tone seems to be more one of experiment.mikronauts wrote:How many consecutive samples must you read before you can have a break, and how long would the break be?
jdb wrote:At 40MHz your prime concern will not be one of data acquisition rate.
The GPIO pins and trace routing are not designed to carry signals that fast with acceptable integrity. 25MHz is about as good as you'll get on the GPIO header.
If you try to sample an 8-bit bus at 40 meg then don't be surprised when you get data glitches, bit flips and other such nasties. The pins were never meant to go that fast and still transmit/receive valid logic levels.
Code: Select all
__asm__( "mov r1,#1\n\t" "lsl r1,#17\n\t" "loop:\n\t" "str r1,[%0,#28]\n\t" "str r1,[%0,#40]\n\t" "b loop\n\t" : :"r"((uint32_t)gpio) : "r0", "r1" );
Hi Daniel,danjperron wrote: is 25Mhz the frequency you get from toggle on/off? if yes than you got 50M change per second.
Also you assembly will have been faster if you didn't recalculate the bit all the time.
ci.v.ic wrote: Hi mikronauts,
In fact I would like to add RAM that is shared with other components but doing this with bit banging is not the optimal way, so it was just an experiment. What do you mean by "break"?
The hardware constraint is likely to be around the 25MHz point, i.e. signals transmitted to GPIO inputs are likely to be corrupted if they are over 25MHz.sibiquin wrote:I am left a bit confused by this discussion. One line indicates about 1MHz sampling on GPIO is the best that can be expected, other lines talk about 25MHz. What am I missing?
In my application I want to read 4 bits at 3MHz continuously - data is real time and fixed rate (e.g. no pause or gaps). With a bit of external hardware I can read 8 bits at 1.5MHz or 16 bits at 750KHz. There needs to be enough CPU cycles to write this data to a file without falling behind.
So what is the best approach? I have a bit clock (3MHz), 4 data lines, and a word clock (identifies 32-bit word boundaries in the data streams). I understand the software approach of sampling the bit clock and reading the 4 data lines on a clock change. Seems like very high CPU overhead. Next best would be the bit clock causes an interrupt and the interrupt routine reads the 4 data lines (can the interrupt be serviced reliably in the bit-time?). Is there a DMA solution?... I have no idea what the software side of that would look like...
Thanks for any ideas.