AnthonyPaulO
Posts: 29
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: 148
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: 29
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: 148
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: 148
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: 29
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: 29
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: 12776
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: 148
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: 148
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: 12776
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: 148
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: 148
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: 29
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: 29
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: 148
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: 29
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.

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

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

Sat Oct 07, 2017 12:26 pm

I'm happy to report that I'm able to interface the Pi 3 with the Apple II at 1mhz via an 8-bit uni-directional GPIO bus via bit-banging. The test involved simulating an Apple II absolute LDA instruction to load data at an address (cycle accurate) and I was able to dump the ROM. Next step is to simulate a write to RAM which shouldn't be a problem. And people said it couldn't be done! :P

Things get pretty tight when syncing with a 1mhz bus so you need to make sure you're running bare metal without interrupts. For this I used ultibo, placing my logic on a dedicated core and polling the falling edge of the clock, performing each step of the instruction during the cycle's period, and then polling for the next cycle until instruction is complete. 1mhz seems to be the approximate limit for this type of real-time response though you should be able to go a bit faster if you're just sampling since that takes very few instruction cycles, though you have to worry about cache misses and sdram refresh.

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

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

Mon Oct 30, 2017 4:29 pm

Are there any news?

Since you use Ultibo (which appears to be a great one person show), what is your experience? There are a few bar metal approaches for the Pi, however, unlike them, Ultibo seems to provide some _real_ base to develop applications on bare metal.

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

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

Mon Oct 30, 2017 5:38 pm

piras77 wrote: Are there any news?

Since you use Ultibo (which appears to be a great one person show), what is your experience? There are a few bar metal approaches for the Pi, however, unlike them, Ultibo seems to provide some _real_ base to develop applications on bare metal.
Hi!

Well in my last post I described having success reading, and I've tested this to death and it's working flawlessly, no errors when left running overnight, reading from the 1mhz bus via the Pi 3 GPIO. I also got the write working but I was getting about 5 errors every 10 million writes and I believe this to be due to a timing issue since I only have a 25ns window to place the data on the data bus and try as I might I am unable to get the Pi meet those tight nanosecond requirements consistently (there must be some occasional jitter from something) so I'm going to add some additional chips to my circuit so that that particular timing is done in hardware; of course the Pi is still feeding at 1mhz but the exact timing as to when it needs to activate the control line on the databus is going to be done in hardware since the window during writes is too tight.

Ultibo has turned out to be a great environment to work in, I have no complaints, and they provide so much functionality... disk access, usb support, 2d and 3d video (via opengl es), etc... and they're actively adding more functionality; the video functionality I just mentioned was part of a major release this past month. The only reason I've been able to make this work at all is due to Ultibo as the overhead from the Linux OS (scheduler, interrupts, etc...) would make it impossible. In Ultibo I was able to move the runtime threads to the main core and run my logic on a dedicated core with interrupts disabled so nothing can interfere, and this has worked for me.

What are you working on that you're considering Ultibo?

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

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

Tue Oct 31, 2017 12:52 pm

Thanks for the update! :-) (I watched one of Ultibo videos and was just curious to hear about your experience.)

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

Who is online

Users browsing this forum: aymen and 11 guests