LeafLabs Garden » Topic: High-Speed GPIO Access?

LeafLabs Garden » Topic: High-Speed GPIO Access? http://forums.leaflabs.com/topic.php?id=774 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:08:14 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php hans leuthold on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=3#post-13733 Wed, 12 Sep 2012 12:06:28 +0000 hans leuthold 13733@http://forums.leaflabs.com/ ala42 - I guess you hit the nail right on the head, the while loop running exactly once up to exactly twice, I could not see the forest because of the trees..... thanks for the hint on SPI, I will check that out ala42 on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=3#post-13647 Tue, 11 Sep 2012 19:50:53 +0000 ala42 13647@http://forums.leaflabs.com/ The reaction time of the while loop is not constant, so you must get a jitter. If you have any doubt about this, just use some fixed calculations instead the while loops to be convinced :) Btw, you could read the data via SPI, so you do not need to follow the clock line in your code. Just read the SPI data when ready and evaluate it. This leaves you much more time for analyzing the data stream. crenn on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=3#post-13643 Tue, 11 Sep 2012 19:01:45 +0000 crenn 13643@http://forums.leaflabs.com/ You're also assuming that the 72MHz is exact. There will be jitter because of the design of the system. It's using a 8MHz reference into a clock multiplier to give a speed of 72MHz. hans leuthold on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=3#post-13639 Tue, 11 Sep 2012 18:01:54 +0000 hans leuthold 13639@http://forums.leaflabs.com/ the reduced code as suggested by gbulmer runs <pre><code>void loop() { while (!CHECK_SCK_PIN); // wait for raising edge of the input clock OCK_PIN_LOW; // send output shown on scope 290ns to 512ns after the rising edge while (CHECK_SCK_PIN); // wait for falling edge // in the real thing there will be some more code here OCK_PIN_HIGH; // send output shown on scope 235ns to 445ns after the falling edge }</code></pre> I read this result with a 72MHz cpu clock as 1st snippet is 21 to 37 cycles - this is a 16 cycles jitter 2nd snippet is 17 to 32 cycles - this is also a 16 cycles jitter in reality this would translate into about 4 cycles for loop() and 17 to 32 cycles while waiting for a transition and the output there are only 2 things that I can come up with as an explanation 1) interrupts that cannot be disabled 2) electrical noise on the input pin, board side any other ideas ? gbulmer on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=3#post-13636 Tue, 11 Sep 2012 16:03:29 +0000 gbulmer 13636@http://forums.leaflabs.com/ hans leuthold - have you reduced the loop() to: <pre><code>void loop() { while (!CHECK_SCK_PIN); // wait for raising edge of the input clock OCK_PIN_LOW; // send output shown on scope 560ns to 700ns after the rising edge while (CHECK_SCK_PIN); // wait for falling edge // in the real thing there will be some more code here OCK_PIN_HIGH; // send output shown on scope 552ns to 700ns after the falling edge }</code></pre> What is the jitter? I'd expect it to be better. I'd expect the path length, i.e. the number of instruction, to differ in loop(), because of the <code>if</code> tests. This would show up as jitter. 140ns is about 10 instructions. You might try 'decompiling' the program using <code>objdump</code>, which would let you see the number of ARM instructions See the GCC binutils documentation <a href="http://sourceware.org/binutils/docs-2.22/" rel="nofollow">http://sourceware.org/binutils/docs-2.22/</a> I was hacking with PDP-11's, and microprocessor development boards more than 30 years ago, but I don't think of myself as grandpa. hans leuthold on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=3#post-13631 Tue, 11 Sep 2012 14:11:46 +0000 hans leuthold 13631@http://forums.leaflabs.com/ - you are evidently right! - thanks after replacing all the digitalRead(xPIN) with a construct of the sort #define CHECK_SCK_PIN ((GPIOB_BASE)-IDR & BIT(y)) the test code is able to follow a 700kHz clock and the jitter is about 140ns. I supply my maple board with a 5V phone charger and wondered whether this remaining jitter is somehow related to noise from the power supply. However supplying it through USB does not change anything. At this stage the loop() looks as follows below. All times are measured on a digital scope at 100MS/s with a 1000 event envelop triggered by the rising input clock. The input clock is a 5V amplitude square wave signal at 700kHz <pre><code>#define ONEREV 31U #define MAXVAL 4095U uint16 erotable[ONEREV+1]; uint16 eroindex; const uint16 onerev = ONEREV; const uint16 maxval = MAXVAL; void setup() {..... /initializes the pins, variables & table } void loop() { while (!CHECK_SCK_PIN); // wait for raising edge of the input clock eroindex++; eroindex &= onerev; // in the real thing there will be some more code here OCK_PIN_LOW; // send output shown on scope 560ns to 700ns after the rising edge while (CHECK_SCK_PIN); // wait for falling edge if (CHECK_BS_PIN) { // bitstream is HIGH if(erotable[eroindex] < maxval) erotable[eroindex]++; } else { // bitstream is LOW if(erotable[eroindex] > 0) erotable[eroindex]--; // in the real thing there will be some more code here OCK_PIN_HIGH; // send output shown on scope 552ns to 700ns after the falling edge }</code></pre> I was hacking with PCs and single board computers 25 years ago and have not done a lot since (..so now you know, I am more like your grandpa..) I really appreciate all the hints I have gotten so far and wonder why the timing I see is what it is. I expected both code snippets including the wait for transition to be between 15 and 20 clock cycles which is roughly half of what I measure. ala42 on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=3#post-13519 Mon, 10 Sep 2012 19:50:35 +0000 ala42 13519@http://forums.leaflabs.com/ You have already noticed that digitalWrite is slow, but still use two digitalReads in your loop. hans leuthold on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=3#post-13517 Mon, 10 Sep 2012 19:08:49 +0000 hans leuthold 13517@http://forums.leaflabs.com/ - thanks: cutting interrupts reduced the jitter by over 80% now the test code is able to follow a 220kHz clock and the jitter is 680ns, this is still the equivalent of 49CPU clock cycles need to change over to programmable logic, I guess ala42 on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=3#post-13322 Fri, 07 Sep 2012 19:54:35 +0000 ala42 13322@http://forums.leaflabs.com/ #include "nvic.h" ... nvic_globalirq_disable(); hans leuthold on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=2#post-13321 Fri, 07 Sep 2012 19:15:43 +0000 hans leuthold 13321@http://forums.leaflabs.com/ hi gbulmer, I am scoping out a piece of code which should (once everything is ironed out) eliminate 2 stationary signals out of a bitstream, like a comb filter. The bitstream is clocked. The input clock SCK should in the end be around 500kHz. To test this out, a 80kHz digital signal is on pin 31, the main loop waits for the rising edge, executes some instructions, turns on the LED, then waits for the falling edge, executes some more instructions, turns off the LED, and exits. ' #define ONEREV 31U #define SCK_PIN 31 #define BS_PIN 30 #define OCK_PIN_HIGH (GPIOA_BASE)->BSRR = BIT(5) // simulate using LED #define OCK_PIN_LOW (GPIOA_BASE)->BRR = BIT(5) int clockState = LOW; uint16 erotable[ONEREV+1]; uint16 eroindex = 0; const uint16 onerev = ONEREV; void setup() // does all the pin initializations and some prep work on tables void loop() { while((clockState = digitalRead(SCK_PIN)) == LOW); eroindex++; eroindex&=onerev; // the real thing will have some more code here.. OCK_PIN_LOW; while((clockState = digitalRead(SCK_PIN)) == HIGH); if ((bsState = digitalRead(BS_PIN)) == HIGH) { if (erotable[eroindex] < MAXVAL) erotable[eroindex]++; } else { // bistream is LOW if (erotable[eroindex] > 0) erotable[eroindex]--; } // the real thing will have some more code here.. OCK_PIN_HIGH; }` I measure the timing with a scope that is triggered by the incoming clock signal. What I observed is that the time between a state change of the clock and the corresponding LED change is typically 0.6us for the rising edge and 1.5us for the falling edge. Either of these times may increase by as much as 3.9us sporadically. What I am trying to figure is whether there is a routine that would allow me to turn the interrupts you mention off. thanks Hans gbulmer on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=2#post-13320 Fri, 07 Sep 2012 17:41:58 +0000 gbulmer 13320@http://forums.leaflabs.com/ hans leuthold - how are you measuring the loop time variability? There should be no variability in loop time because the instructions are constant and a fixed duration, but there are interrupts happening 'in the background' which may be measured as variability. Specifically, there is a clock interrupt which provides the underlying event for delay() and millis(), and there is also the USB interrupt. Both of these will increase the apparent time of some iterations of loop(). (Full disclosure: I am not a member of LeafLabs staff.) hans leuthold on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=2#post-13319 Fri, 07 Sep 2012 16:22:19 +0000 hans leuthold 13319@http://forums.leaflabs.com/ I ran a test to compare digitalWrite(bitX) with (GPIOy_BASE)->BSRR = BIT(bitX). Using this more direct approach saves 0.3us or about 21 cpu clock cycles One question though - does anybody have some hints how to reduce the impact that the "Arduino/Maple OS" has on the execution time of loop()? My little test shows that loop times can vary by as much as 3.9us thanks Hans SDL on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=2#post-4930 Thu, 02 Jun 2011 01:41:15 +0000 SDL 4930@http://forums.leaflabs.com/ Hi robodude666 I don't know is it useful for you, but you may have a look and the stm's appnote: QVGA TFT-LCD direct drive using the STM32F10xx FSMC peripheral <a href="http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00278141.pdf" rel="nofollow">http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00278141.pdf</a> They're using 16 bit line though and they get 40 fps for the static image but their lcd does not have an onboard memory. gbulmer on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=2#post-4813 Thu, 26 May 2011 04:35:15 +0000 gbulmer 4813@http://forums.leaflabs.com/ <blockquote>I reviewed the ST documentation and they themselves say the GPIO cannot be toggled any faster than 18MHz. It is possible to get 36MHz, but that's for a single access. If you do two accesses back-to-back, the requests get buffered and are delayed by another instruction i.e.</blockquote> I think it is important that the speed quoted is for changing the pin state twice because the instruction timing might mislead folks to thinking it is 2 cycles for the first write, then 1 for subsequent writes, which isn't the case. I read toggling as two state changes. Oak would be a way to drive this LCD at maximum speed, assuming Oak's FPGA could completely take over all the address, data and control pins. I would expect an FPGA to be significantly faster than 10Mpixels/second for things like drawing lines, and for 'bitblit' with fast memory. poslathian on "High-Speed GPIO Access?" http://forums.leaflabs.com/topic.php?id=774&page=2#post-4771 Tue, 24 May 2011 19:56:44 +0000 poslathian 4771@http://forums.leaflabs.com/ good to know about single versus double transactions