AnthonyPaulO
Posts: 27
Joined: Fri Aug 11, 2017 1:07 pm

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Tue Sep 12, 2017 9:07 pm

Seriously though, I'm not being sarcastic... if anyone has any information on receiving or sending data at higher speeds please post it here; I'm looking to push the envelope as far as possible and I don't care if someone else has done it already, I just want to achieve as high a speed as possible.

piras77
Posts: 122
Joined: Mon Jun 13, 2016 11:39 am

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Tue Sep 12, 2017 9:34 pm

AnthonyPaulO wrote:
Tue Sep 12, 2017 8:59 pm
He can sample the Level register all he wants, but unless it actually contains data it's useless. I would love to see if he can achieve those rates with, say, a teensy feeding data to the Pi via GPIO at Mhz speeds.
I don't know what you mean. Are you implying that the sampling rate drops when the levels at the pins change? Are you implying that a changed value at the pin takes a 1us or beyond to be reflected in the level register. Can you back that up?

When I connected two 7 bit counters at a high clock speed, the sampling rate did not change and the sampled values did differ.
AnthonyPaulO wrote:
Tue Sep 12, 2017 8:59 pm
I'm not missing any bits, at least not in the tests I've done. I've captured the sampled data to my SD and it is exactly what I sent it.
How can you say this is the maximum sampling rate? What happened when you increased the transfer rate from the Arduino to 1.5 MHz?
AnthonyPaulO wrote:
Tue Sep 12, 2017 9:07 pm
Seriously though, I'm not being sarcastic... if anyone has any information on receiving or sending data at higher speeds please post it here;
The Pi simply hasn't the capabilities for a _reliable_ GPIO bank sampling at high rates. That would need (hardware) pacing or (hardware) trigger. This was made clear in the beginning of the thread.

So you have to explore what is possible with what you have got. I don't see the end of CPU polling at 1 MHz. You didn't explore DMA yet.

On the other hand, you had not yet to struggle with asynchronously arriving edges on a bus (e.g. due to different lengths in the PCB traces).

AnthonyPaulO
Posts: 27
Joined: Fri Aug 11, 2017 1:07 pm

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Wed Sep 13, 2017 2:18 am

I don't know what you mean. Are you implying that the sampling rate drops when the levels at the pins change? Are you implying that a changed value at the pin takes a 1us or beyond to be reflected in the level register. Can you back that up? When I connected two 7 bit counters at a high clock speed, the sampling rate did not change and the sampled values did differ.
Sorry, after thinking it through I realized that I'm using "samples" incorrectly. You're right, the sampling may not be changing at all; I meant to say that the amount of cpu cycles available to react to a transition changes (obviously). For example, here's some pseudo-code for reading a timing signal off an input pin :

Code: Select all

start := MyGetTimeFunc();

cycles := 0;
while (IsRunning())
   {
   low := 0;
   while (!RisingEdgeDetected())
      low++;

   high := 0;
   while (!FallingEdgeDetected())
      high++;

   cycles++;
   }

end := MyGetTimeFunc();

duration := end - start;
If you run this kind of loop for a certain period of time you can measure the frequency of the signal you're receiving. On the other end, the low and high variables indicate how many iterations the CPU took to detect an edge. The lower the frequency, the higher these numbers, the higher the frequency the lower these numbers. When I feed it a 1mhz signal the low and high numbers fall into the single digits, which means only a few cycles are left for any logic; any faster than that and I'm sure to miss something. This is all I meant to say and why I believe 1mhz to be the limit of what I can reliably read off a pin. If I'm reading this wrong please feel free to correct me.
How can you say this is the maximum sampling rate? What happened when you increased the transfer rate from the Arduino to 1.5 MHz?
I haven't tried due to the above.
The Pi simply hasn't the capabilities for a _reliable_ GPIO bank sampling at high rates. That would need (hardware) pacing or (hardware) trigger. This was made clear in the beginning of the thread.
I'm afraid I do not understand what this means. At the beginning of this thread I was led to believe I would not be able to transmit or receive data at the 1mhz speeds I was looking for. I have so far been able to transfer data into the Pi at 1mhz and the incoming and outgoing data seem to match, so it seems to be reliable. I am going to test this soon for 8 bits at a time which, based on my experiments, shouldn't result in any surprises, but would serve as a good test to confirm the reliability of the data. I believe if I xmit a pattern and detect that exact pattern for a long enough period of time without any glitches that should serve as a reliability indicator.
So you have to explore what is possible with what you have got. I don't see the end of CPU polling at 1 MHz. You didn't explore DMA yet.
I didn't bother exploring DMA due to this guys findings : https://github.com/hzeller/rpi-gpio-dma-demo
On the other hand, you had not yet to struggle with asynchronously arriving edges on a bus (e.g. due to different lengths in the PCB traces).
Is this something I should be worried about?

piras77
Posts: 122
Joined: Mon Jun 13, 2016 11:39 am

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Wed Sep 13, 2017 5:24 pm

Since I was curious, I ran a brief DMA test (I did that already several months ago, but didn't remember the exact results). I work in Raspbian userland, so CPU access is no option for steady sampling anyway.

The test runs on a Pi-0 with VC's 2nd Level cache enabled for the ARM core (default Kernel). A memory block of 32 bytes + 16 MiB is allocated via Mailbox interface (/dev/vcio) @ bus address 0xddaef000.

The first 32 bytes are used as DMA TI: 04000030 7e00b420 ddaef020 01000000 00000000...

This will sample 0x400000 times the ARM Counter @ bus address 0x7e00b420. The ARM Counter is set up to increment at the core-clock rate. The core-clock is fixed in /boot/config.txt at 250 MHz so we get 4 ns ticks. DMA channel 0 is used for the DMA transfer.

The result is as follows: The first sample is 186,953,912. The last sample is 238,041,594. So we got an average sample time of 12 ticks (48ns). The actual difference of two subsequent samples is between 11 and 21 ticks (for this test, other tests may result in other values!?). However, this is not as bad as I remember.

Let's assume we have a clocked input source. The clock is a 1:1 square wave. Data is set up with the LH edge and supposed to be available @ Low Level. If we get a guaranteed sample at least every 100ns (21 ticks), then we should be able to detect signals that come in @ 5 MHz clock.

This is obviously no GPIO sampling. It's just an estimate. -- I don't have a reliable signal / counter that I could connect to GPIO pins with the required resolution. However I was going to try an async counter at about 50 MHz (which is not that neat since you have to single out the bit "errors" due to propagation) but never finished.

piras77
Posts: 122
Joined: Mon Jun 13, 2016 11:39 am

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Wed Sep 13, 2017 5:44 pm

AnthonyPaulO wrote:
Wed Sep 13, 2017 2:18 am
When I feed it a 1mhz signal the low and high numbers fall into the single digits, which means only a few cycles are left for any logic; any faster than that and I'm sure to miss something.
Well, if I understand you correctly, you want to sample an incoming signal at one bus-cycle, process it, and put the resulting data on the bus in the next cycle? Is that what you want to do? I assumed you would process data in blocks. You never answered my question to sketch out a dialogue on the bus.
The Pi simply hasn't the capabilities for a _reliable_ GPIO bank sampling at high rates. That would need (hardware) pacing or (hardware) trigger. This was made clear in the beginning of the thread.
AnthonyPaulO wrote:
Wed Sep 13, 2017 2:18 am
I'm afraid I do not understand what this means.
Sampling is typically done at a fixed rate (for instance every 10 ns). Another way would be a trigger (e.g. a clock pulse) that is used to sample data (e.g. with each rising edge of the clock pulse). The Pi's hardware supports that for certain peripherals (e.g. PCM,SPI, I2C,UART) but not for arbitrary GPIO pins. Sampling by tight CPU loops or DMA don't guarantee a (minimum) distance between two samples. So you may miss some pieces of the incoming signal.
AnthonyPaulO wrote:
Wed Sep 13, 2017 2:18 am
Is this something I should be worried about?
Only if you don't have a window when your incoming data is valid.

To make this clear: connect a square wave to several pins and sample the pin values. You will see that the sampled values won't be always all zeros or all ones since the signal paths have different length.

AnthonyPaulO
Posts: 27
Joined: Fri Aug 11, 2017 1:07 pm

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Wed Sep 13, 2017 9:02 pm

Well, if I understand you correctly, you want to sample an incoming signal at one bus-cycle, process it, and put the resulting data on the bus in the next cycle? Is that what you want to do? I assumed you would process data in blocks. You never answered my question to sketch out a dialogue on the bus.
The problem I'm having is that the results from the timing test I posted previously seem to indicate that the Pi is only able to accomplish about 5 while-loop iterations containing only a single increment count instruction in its body before it detects the next transition. At two-transitions per period that makes for about 10 while-loop iterations per period, and since each period is 1us I am left to wonder... what the heck is the Pi spending all its cycles on? After all, at 1.1ghz the Pi can perform 1100 instructions each 1us; I should have plenty of bandwidth to spare but that doesn't seem to be the case here. I'm really scratching my head here... the only thing that would make sense if each interaction with the edge or level registers takes a HUGE amount of cycles, like perhaps 80 or 90. I need to measure this; any thoughts?

As for dialogue, the use-case you described covers everything I'm trying to achieve. I have an external octal flip-flop that I would like to interface with at 1mhz in both directions and the 1mhz timing must be based on an external 1mhz clock. For this I needed to test a couple of things : 1) is the 1.1ghz Pi able to reliably input data at 1mhz? and 2) do I have enough cycles left over to do something meaningful? To accomplish this a read dialogue would look somewhat like the following :

Setup : bare metal Pi 3 with GPIO interrupts disabled and disable_pvt=1

Code: Select all

// read byte scenario
void DoRead()
   {
   while (!risingEdgeDetected) // wait for clock rising edge
      ;

   clearRisingEdgeFlag();

   var reg = readLevelRegister0(); // read GPIO bank 0
   var data = assembleDataFromReg(reg); // assemble a valid byte out of the different GPIO input bits

   doSomeWork(data); // do some work here

   while (!fallingEdgeDetected)
      ;

   clearFallingEdgeFlag();
   }
Sampling by tight CPU loops or DMA don't guarantee a (minimum) distance between two samples. So you may miss some pieces of the incoming signal.
Right, I don't want to sample, I want to respond to the clock in real-time by waiting for an edge, and once detected I wait x nanoseconds for the level to settle and read the GPIO for a bytes worth of data.
To make this clear: connect a square wave to several pins and sample the pin values. You will see that the sampled values won't be always all zeros or all ones since the signal paths have different length.
Wow, I hadn't considered that at all! I did plan on putting in a small delay in order to wait for the data to settle, but what you described is very interesting...
Let's assume we have a clocked input source. The clock is a 1:1 square wave. Data is set up with the LH edge and supposed to be available @ Low Level. If we get a guaranteed sample at least every 100ns (21 ticks), then we should be able to detect signals that come in @ 5 MHz clock.

This is obviously no GPIO sampling. It's just an estimate. -- I don't have a reliable signal / counter that I could connect to GPIO pins with the required resolution. However I was going to try an async counter at about 50 MHz (which is not that neat since you have to single out the bit "errors" due to propagation) but never finished.
Yeah, I guess if you sample and do nothing else other than store it in memory then 5mhz is doable, but you'd have to test. 50 mhz though? I'd love to see your results!

AnthonyPaulO
Posts: 27
Joined: Fri Aug 11, 2017 1:07 pm

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Thu Sep 14, 2017 1:57 am

Wow... I just made some measurements.

84ns to read GPIO register
84ns to read async rising edge event
22ns to clear event flag

Those are some pretty big numbers!

User avatar
joan
Posts: 12738
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Thu Sep 14, 2017 4:27 am

My (userland) pigpio library uses DMA to sample the GPIO (the 32 in bank 0 which includes all those connected to the expansion header). The maximum rate supported is 1 MHz. At that rate system activity (in particular video) will perturb the timings because of memory bus contention (I think). Another reason to limit the sampling rate is that the accessible system clock only has a 1 microsecond resolution.

piras77
Posts: 122
Joined: Mon Jun 13, 2016 11:39 am

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Thu Sep 14, 2017 4:31 am

AnthonyPaulO wrote:
Wed Sep 13, 2017 9:02 pm
what the heck is the Pi spending all its cycles on? After all, at 1.1ghz the Pi can perform 1100 instructions each 1us; I should have plenty of bandwidth to spare but that doesn't seem to be the case here
I guess you confuse CPU clock and bus clock. It takes much (!) longer to query a peripheral than executing an instruction in a processor core.

piras77
Posts: 122
Joined: Mon Jun 13, 2016 11:39 am

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Thu Sep 14, 2017 4:37 am

joan wrote:
Thu Sep 14, 2017 4:27 am
At that rate system activity (in particular video) will perturb the timings because of memory bus contention (I think).
If I remember right, you use CB chains in order to record time stamps too. Such CB chains are quite memory intensive.
joan wrote:
Thu Sep 14, 2017 4:27 am
Another reason to limit the sampling rate is that the accessible system clock only has a 1 microsecond resolution.
Is there a reason not to use the ARM Counter?

User avatar
joan
Posts: 12738
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Thu Sep 14, 2017 4:59 am

I have never considered that CB chains were the problem. Can you suggest an alternative?

piras77
Posts: 122
Joined: Mon Jun 13, 2016 11:39 am

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Thu Sep 14, 2017 5:11 am

No, not really. However, I was thinking about a slow 2nd DMA transfer that records in turn the time and the present SOURCE_AD of the 1st DMA transfer. So the 1st DMA transfer (to sample data) could work at full speed (not interrupted by CB reloading). While the 2nd DMA transfer provides the data to get a rough estimate of the timing. I never tested it, though.

Edit: DEST_AD not SOURCE_AD since we transferring from the peripheral.

piras77
Posts: 122
Joined: Mon Jun 13, 2016 11:39 am

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Thu Sep 14, 2017 6:35 am

AnthonyPaulO wrote:
Wed Sep 13, 2017 9:02 pm
50 mhz though? I'd love to see your results!
The external counter would just serve as time reference with 20 ns increments (instead of the ARM Counter with 4 ns increments).

AnthonyPaulO
Posts: 27
Joined: Fri Aug 11, 2017 1:07 pm

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Thu Sep 14, 2017 2:02 pm

piras77 wrote:
Thu Sep 14, 2017 4:31 am
AnthonyPaulO wrote:
Wed Sep 13, 2017 9:02 pm
what the heck is the Pi spending all its cycles on? After all, at 1.1ghz the Pi can perform 1100 instructions each 1us; I should have plenty of bandwidth to spare but that doesn't seem to be the case here
I guess you confuse CPU clock and bus clock. It takes much (!) longer to query a peripheral than executing an instruction in a processor core.
Not confused, it's just that I didn't expect such huge access times... I tried researching the APB and its speed isn't documented anywhere, we're just guessing it's the same as core clock @ 250mhz; however, the access times I measured seems to indicate that this speed seems reasonable.

AnthonyPaulO
Posts: 27
Joined: Fri Aug 11, 2017 1:07 pm

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Thu Sep 14, 2017 2:11 pm

Regarding DMA, do you feel that hzeller was wrong in his analysis of DMA <-> GPIO performance? He's been at this for a while so I never considered he might be wrong.

https://github.com/hzeller/rpi-gpio-dma-demo

piras77
Posts: 122
Joined: Mon Jun 13, 2016 11:39 am

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Thu Sep 14, 2017 3:42 pm

There are two different peripheral registers to set/clear the output level. This is very unfortunate for DMA operations. AFAIK he tries to work around this by using strides and/or CB chains, which isn't that promising.

There is another way: writing to one of the Function Select register.

You would switch between Input and Output mode which gives you high-impedance and zero. This might be sufficient for many applications. As another restrictions, you have only access to 10 pins (6 banks with either pin 0-9, pin 10-19, ...). I did this a while ago. So I don't remember exactly the throughput (which was quite high I think). You would have to try yourself if the mentioned restrictions are ok with you.

AnthonyPaulO
Posts: 27
Joined: Fri Aug 11, 2017 1:07 pm

Re: SPI or BitBang via GPIO to 5v device and vice-versa

Thu Sep 14, 2017 4:08 pm

If the registers are next to each other then perhaps a 64-bit instruction could be used to access both at the same time; I believe the Armv8 allows this.

Return to “Interfacing (DSI, CSI, I2C, etc.)”

Who is online

Users browsing this forum: No registered users and 17 guests