LeafLabs Garden » Topic: Faster DigitalRead ?

LeafLabs Garden » Topic: Faster DigitalRead ? http://forums.leaflabs.com/topic.php?id=1107 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:17:10 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php gbulmer on "Faster DigitalRead ?" http://forums.leaflabs.com/topic.php?id=1107#post-7068 Wed, 02 Nov 2011 13:14:22 +0000 gbulmer 7068@http://forums.leaflabs.com/ newyorkbrass - <blockquote>since counter is 32 bit - if you need to count up to 27 bits you can alway wait with the shift operator until you need of even do away completely and just use a constant that is shifted <<5 <pre><code>void interrupt_vector() { Counter += (GPIOB_BASE->IDR& BIT(5)); }</code></pre></blockquote> Nifty thinking! If bit-band addressing is used, there is no need for the binary 'and' (<code>&</code>). Also a bit-band-address value is one bit, the bottom bit, even though it is read or written as a 32 bit word. It is always 0 or 1 so no need for binary 'right shift' (<code>>></code>). i.e.: <pre><code>loop() { Counter += IOBitBand(&(GPIOB_BASE->IDR), 5); }</code></pre> In this case, implementing IOBitBand as a macro or inline function would make the bit band address a constant, which, once loaded into a register would be very quick. The overhead of <code>loop() { ... }</code> is slower than the time to read the port register, extract the bit and shift it right. So a faster solution would be: <pre><code>loop() { while (1) { Counter += IOBitBand(&(GPIOB_BASE->IDR), 5); } }</code></pre> (Edit: bb_peri_get_bit() is already implemented.) newyorkbrass on "Faster DigitalRead ?" http://forums.leaflabs.com/topic.php?id=1107#post-7067 Wed, 02 Nov 2011 12:01:47 +0000 newyorkbrass 7067@http://forums.leaflabs.com/ <blockquote> loop() { Counter += (GPIOB_BASE->IDR& BIT(5)) >> 5; } </blockquote> since counter is 32 bit - if you need to count up to 27 bits you can alway wait with the shift operator until you need of even do away completely and just use a constant that is shifted <<5 <blockquote> void interrupt_vector() { Counter += (GPIOB_BASE->IDR& BIT(5)); } loop() { . . some_lengthly_operation(); use_counter(Counter << 5); . . } </blockquote> TRC on "Faster DigitalRead ?" http://forums.leaflabs.com/topic.php?id=1107#post-6859 Thu, 13 Oct 2011 04:11:07 +0000 TRC 6859@http://forums.leaflabs.com/ Great thanks for the info! gbulmer on "Faster DigitalRead ?" http://forums.leaflabs.com/topic.php?id=1107#post-6830 Tue, 11 Oct 2011 20:00:36 +0000 gbulmer 6830@http://forums.leaflabs.com/ Each I/O pin is represented in a 16-bit 'port', a bunch of memory locations which: - control the pin direction (whether pins are inputs or outputs), - the value of the pins that are inputs, and - the state of output pins - a few other things ... This is described in the ST Micro manual RM0008, in section 9 "General-purpose and alternate-function I/Os (GPIOs and AFIOs)". e.g. <a href="http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf" rel="nofollow">http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf</a> To figure out which port digital pin 4 is on, go look at the Maple pinmap, e.g. <a href="http://leaflabs.com/docs/hardware/maple.html#master-pin-map" rel="nofollow">http://leaflabs.com/docs/hardware/maple.html#master-pin-map</a> You can see that D4 (data pin 4) is "PB5", that is port B, pin 5. So Port B is GPIOB hence the call is <code>gpio_read_bit(GPIOB, 5);</code> Or, you can 'do it yourself' and just write ... GPIOB_BASE->IDR & BIT(5) ... which has a similar effect. The part of the expression <code>& BIT(5)</code> is extracting the specific pin value. Then you might use a test for zero, e.g. <code>if (GPIOB_BASE->IDR & BIT(5)) { Counter ++; }</code> if you actually want to use the bit value, the code would have to shift the bit. As an example, the code could use the value as an integer value 0 or 1, either: <pre><code>loop() { Counter += GPIOB_BASE->IDR& BIT(5)? 1 : 0; }</code></pre> or <pre><code>loop() { Counter += (GPIOB_BASE->IDR& BIT(5)) >> 5; }</code></pre> The if test disappears, though the compiler might generate a better code sequence for an <code>if</code> compared to the <code>...? 1 : 0;</code> I'd have to go look. I think the second one (<code>GPIOB_BASE->IDR& BIT(5)) >> 5</code>) might be quickest because the Cortex-M3 has a fast shift or bit test which might do that in one cycle (the compiler will know what to do :-) Theoretically, that specific expression <code>GPIOB_BASE->IDR& BIT(5)) >> 5</code>, once set up, could run in 3 cycles (.e. 24MHz), but the address of GPIO_BASE->IDR will have to be loaded so you'll not see that unless you have a long piece of code to keep testing the pin. There is an even quicker way using 'bit banding'. Every I/O pin has a second 'shadow address' where a whole memory word is used to set or test the pin value, so the <code>& BIT(5)</code> becomes unnecessary. Pete Harrison has an article at: <a href="http://www.micromouseonline.com/2010/07/14/bit-banding-in-the-stm32/#axzz1aWWAbNQg" rel="nofollow">http://www.micromouseonline.com/2010/07/14/bit-banding-in-the-stm32/#axzz1aWWAbNQg</a> Instead of using the bit band region for memory: <pre><code>#define RAM_BASE 0x20000000 #define RAM_BB_BASE 0x22000000</code></pre> You would be using the bit band region for I/O registers: <pre><code>#define IO_BASE 0×40000000 #define IO_BB_BASE 0×42000000</code></pre> and change the macros to match. Essentially, the code Pete shows converts a memory address, and the bit within the memory address to a memory address for a bit. You could modify the macros to convert the I/O port address and pin within that port to a bit-band memory address, and use that to test the pin (I've called that IOGetBit()). All of that can be calculated at compile time, so there is no need for the <code>& BIT(5)</code>, and the bit is always in bit position 0. So, it is possible to test a bit in two cycles once the bit-band address is loaded into a register. That is 36MHz. Again, you'll never see it go that fast unless it is in a long piece of code with all the addresses loaded into CPU registers. So your code: <pre><code>void loop() { if (digitalRead(4) == HIGH){ Counter ++; } }</code></pre> would become <pre><code>void loop() { Counter += IOGetBit(GPIO_BASE->IDR, 5); }</code></pre> which wouldn't do much useful (just count like crazy), but the overhead of calling <code>loop()</code> would be humungous by comparison with the time needed to test a pin. The time spent doing: <pre><code>int start_time = millis(); for (int i=0; i<6000000; ++i) { // 6 million Counter += IOGetBit(GPIO_BASE->IDR, 5); } int end_time = millis();</code></pre> would be slightly more <code>for</code> loop than the pin test. I guess that is less than 1 second, but it's late and I'm sleepy. Hence 'unrolling` the for loop: <pre><code>int start_time = millis(); for (int i=0; i<1000000; ++i) { // 1 million Counter += IOGetBit(GPIO_BASE->IDR, 5); Counter += IOGetBit(GPIO_BASE->IDR, 5); Counter += IOGetBit(GPIO_BASE->IDR, 5); Counter += IOGetBit(GPIO_BASE->IDR, 5); Counter += IOGetBit(GPIO_BASE->IDR, 5); Counter += IOGetBit(GPIO_BASE->IDR, 5); } int end_time = millis();</code></pre> should be noticeably faster. [WARNING: I have not compiled and tested the code] (Note to self: I think Pete's macros and the gpio.h header don't declare GPIOB_BASE as the address of a <code>volatile</code> so GPIOB->regs->IDR might be better because <code>regs</code> is <code>volatile</code>) (full disclosure: I am not a member of LeafLabs staff) poslathian on "Faster DigitalRead ?" http://forums.leaflabs.com/topic.php?id=1107#post-6827 Tue, 11 Oct 2011 17:34:40 +0000 poslathian 6827@http://forums.leaflabs.com/ digging into libmaple here: <a href="https://github.com/leaflabs/libmaple/blob/master/libmaple/gpio.h" rel="nofollow">https://github.com/leaflabs/libmaple/blob/master/libmaple/gpio.h</a> you can see that the read-bit function gets inlined (for faster digitalRead downstream) and is defined here: static inline uint32 gpio_read_bit(gpio_dev *dev, uint8 pin) { return dev->regs->IDR & BIT(pin); } you can figure out exactly what "dev" and "regs" are by looking up their type definitions in the same file. the long and short of it is that dev is a struct of type gpio_dev and regs is of type gpio_regmap which are also defined in that file. You could re-create what gpio.h does for you in your test, but since gpio_read_bit is inlined ANYWAY, calling that function inside a loop is about as fast as you are going to get without being very clever or dropping into asm. TRC on "Faster DigitalRead ?" http://forums.leaflabs.com/topic.php?id=1107#post-6814 Tue, 11 Oct 2011 09:09:51 +0000 TRC 6814@http://forums.leaflabs.com/ Hello all I was wondering if someone could tell me how to make the process of reading the High or Low state of a pin 'faster'? The DigitalRead command probably has 'a lot' of overhead and I am sure there must be some low level direct excess code to read the High or Low state of a pin directly and bypass the speed limitations of the DigitalRead command. So far example, using this simple code: ///////////////////////////////////////////// int Counter = 0; void setup() { } void loop() { if (digitalRead(4) == HIGH){ Counter ++; } } ///////////////////////////////////////////// Only then with direct pin readout, bypassing the DigitalRead commands overhead. So that it responds as fast as possible when pin 4 goes high. Now I have done some speed measurements of the DigitalRead command on the: - Arduino - Maple - Uno32 And although the Uno32 has the most mhz of them all, Maple's DigitalRead overhead was the lowest. But hey, we always want more speed. Thanks for the help in advance! Regards, TRC