LeafLabs Garden » Topic: Low Level pin manipulation

LeafLabs Garden » Topic: Low Level pin manipulation http://forums.leaflabs.com/topic.php?id=860 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:12:51 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php mbolivar on "Low Level pin manipulation" http://forums.leaflabs.com/topic.php?id=860#post-5214 Tue, 14 Jun 2011 15:05:11 +0000 mbolivar 5214@http://forums.leaflabs.com/ update: done: <a href="https://github.com/leaflabs/leaflabs-docs/commit/fd7edc29d79bbba098fdab621a56205740599a4f" rel="nofollow">https://github.com/leaflabs/leaflabs-docs/commit/fd7edc29d79bbba098fdab621a56205740599a4f</a> includes a link to this thread. i also included a link to thread referenced by robodude666 above, with the very informative conversation between gbulmer, trevden, and robodude666. hm. i wonder what other FAQs should be added in. perhaps that's a topic for another thread. robodude666 on "Low Level pin manipulation" http://forums.leaflabs.com/topic.php?id=860#post-5212 Tue, 14 Jun 2011 14:56:48 +0000 robodude666 5212@http://forums.leaflabs.com/ I love good puns on a Tuesday afternoon :D. mbolivar on "Low Level pin manipulation" http://forums.leaflabs.com/topic.php?id=860#post-5211 Tue, 14 Jun 2011 14:25:26 +0000 mbolivar 5211@http://forums.leaflabs.com/ i think this should be included in the official docs (which recently moved to <a href="https://github.com/leaflabs/leaflabs-docs)" rel="nofollow">https://github.com/leaflabs/leaflabs-docs)</a>. i added an FAQ page to those the other day, and i think i'll fold this information into it. thanks to snigelen and robodude666 for all the good bits! poslathian on "Low Level pin manipulation" http://forums.leaflabs.com/topic.php?id=860#post-5210 Tue, 14 Jun 2011 13:47:16 +0000 poslathian 5210@http://forums.leaflabs.com/ So weve re-verified the official max square wave is 36MHz using PWM at 50% duty cycle and 18MHz using direct GPIO writes. Awesome! Thanks for all the great experiments. Definitely wiki material! robodude666 on "Low Level pin manipulation" http://forums.leaflabs.com/topic.php?id=860#post-5207 Tue, 14 Jun 2011 12:45:35 +0000 robodude666 5207@http://forums.leaflabs.com/ Well then, my previous <code>uint16_t bit9 = BIT(9);</code> statements can be ignored. snigelen on "Low Level pin manipulation" http://forums.leaflabs.com/topic.php?id=860#post-5206 Tue, 14 Jun 2011 11:57:30 +0000 snigelen 5206@http://forums.leaflabs.com/ <blockquote>Does the compiler optimize (i.e. pre-calculate) 1<<9 for you? I've never checked.</blockquote> Yes, all expressions that's constant at compile time will be evaluated by the compiler. robodude666 on "Low Level pin manipulation" http://forums.leaflabs.com/topic.php?id=860#post-5203 Tue, 14 Jun 2011 11:13:43 +0000 robodude666 5203@http://forums.leaflabs.com/ Does the compiler optimize (i.e. pre-calculate) <code>1<<9</code> for you? I've never checked. While experimenting with this before I noticed very interesting things as well. For example, with the following: <pre><code>GPIOB_BASE->BSRR = 1<<9; GPIOB_BASE->BRR = 1<<9;</code></pre> You'll see the Set occuring very quickly, then the Clear taking twice as long as the set. If you look at this next: <pre><code>GPIOB_BASE->BSRR = 1<<9; GPIOB_BASE->BRR = 1<<9; GPIOB_BASE->BSRR = 1<<9; GPIOB_BASE->BRR = 1<<9;</code></pre> all four operations take the exact same amount of time (as fast as the BSRR of the previous example). However, if you do something like: <pre><code>GPIOA_BASE->ODR = 0xAA; GPIOB_BASE->BSRR = 1<<9; GPIOB_BASE->BRR = 1<<9; GPIOA_BASE->ODR = 0xAA; GPIOB_BASE->BSRR = 1<<9; GPIOB_BASE->BRR = 1<<9;</code></pre> we return to the original model: the Set is quick, the clear takes a little longer. There is a really great thread on the official ST forums related to performance: <a href="https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FTrue%20performance%20of%20STM32&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=14129">True performance of STM32</a>, as I mentioned in my thread. The most interesting post is <a href="https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/DispForm.aspx?ID=639&RootFolder=%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fTrue%20performance%20of%20STM32&Source=https%3A%2F%2Fmy%2Est%2Ecom%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FFlat%2Easpx%3FRootFolder%3D%252Fpublic%252FSTe2ecommunities%252Fmcu%252FLists%252Fcortex_mx_stm32%252FTrue%2520performance%2520of%2520STM32%26FolderCTID%3D0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B%26currentviews%3D14129">this one</a> by an official ST employee. He writes: <pre><code>The reason is that stores can complete in the background on STM32. This means that the STR generally takes two cycle or more (depending on what precedes it and depneding on APB prescalers - wait states). So, if two STRs are back-to-back, then the second one must wait for the first to complete. If other activity precedes the STR, it will not stall, as a store buffer will drain the operation out. However this is not the case for Loads ;-( and Unlike the STR case, the Cortex-M3 has to wait for the load to complete no matter what. So, back-to-back LDRs (and an LDM) optimize the time by pipelining the address generation. So, it is better to keep loads together when possible.</code></pre> Quite interesting =]. snigelen on "Low Level pin manipulation" http://forums.leaflabs.com/topic.php?id=860#post-5201 Tue, 14 Jun 2011 10:41:45 +0000 snigelen 5201@http://forums.leaflabs.com/ I did some tests while robodude666 answered. First test. <pre><code>void setup() { pinMode(24, OUTPUT); } // 2.57MHz void loop() { GPIOB_BASE->BSRR = 1<<9; GPIOB_BASE->BRR = 1<<9; }</code></pre> It's short pulses at about 2.75MHz. Some of the time between pulses seems to be for the call to loop, which surprised me. I thought the compiler optimized that away. Test two. Same setup(). <pre><code>// 4.26 MHz void loop() { while(1) { GPIOB_BASE->BSRR = 1<<9; GPIOB_BASE->BRR = 1<<9; } }</code></pre> Still pulses. Time between them comes from the loop. Test 3. <pre><code>// 4 18 MHz pulses void loop() { GPIOB_BASE->BSRR = 1<<9; GPIOB_BASE->BRR = 1<<9; GPIOB_BASE->BSRR = 1<<9; GPIOB_BASE->BRR = 1<<9; GPIOB_BASE->BSRR = 1<<9; GPIOB_BASE->BRR = 1<<9; GPIOB_BASE->BSRR = 1<<9; GPIOB_BASE->BRR = 1<<9; }</code></pre> 4 18 MHz pulses with some time between. The fastest is to let the hardware take care of it. <pre><code>HardwareTimer timer(4); void setup() { pinMode(24,PWM); timer.setPrescaleFactor(1); timer.setOverflow(1); timer.setMode(4, TIMER_PWM); timer.setCompare(4,1); } void loop() { }</code></pre> 36 MHz. (which is about the highest I can see with my oscilloscope). robodude666 on "Low Level pin manipulation" http://forums.leaflabs.com/topic.php?id=860#post-5188 Tue, 14 Jun 2011 09:57:11 +0000 robodude666 5188@http://forums.leaflabs.com/ There sure is! The STM32 is capable of ~18MHz GPIO toggle speeds. Check out my <a href="http://forums.leaflabs.com/topic.php?id=774">"High-Speed GPIO Access?"</a> thread where we discuss it in much more detail. The short answer would be: Access the GPIO's registers directly instead of going through the overhead created by the <code>digitalWrite</code> function: <pre><code>// D24 corresponds to PB9. uint16_t bit9 = BIT(9); GPIOB->regs->BSRR = bit9; // Set PB9 GPIOB->regs->BRR = bit9; // Clear PB9</code></pre> It may be difficult to memorize the registers so libmaple has a built in lower-level gpio function: <pre><code>gpio_write_bit(GPIOB, 9, 1); // Set PB9 gpio_write_bit(GPIOB, 9, 0); // Clear PB9</code></pre> The only overhead of the <code>gpio_write_bit</code> function is a single if-statement and a <code>BIT</code> calculation. I created the following macros for my needs to remove the if-statement overhead: <pre><code>#define sbit(port, pin) port->regs->BSRR = BIT(pin) #define cbit(port, pin) port->regs->BRR = BIT(pin)</code></pre> You can remove the <code>BIT</code>.. bit, and pre-calculate the values ahead of time for slightly better performance. Note that you won't get 18MHz out of the GPIO, but get very close to it. There are some quirks related to how fast you can toggle. If you do two GPIO accesses in a row you'll get lower performance than just doing a single one.. and a bunch of other little things. If you need to get faster performance you can unroll loops: <pre><code>uint16_t bit9 = BIT(9); for(int i = 0; i < 4; i++) { GPIOB->regs->BSRR = bit9; // Set PB9 GPIOB->regs->BRR = bit9; // Clear PB9 }</code></pre> can be written as: <pre><code>uint16_t bit9 = BIT(9); GPIOB->regs->BSRR = bit9; // Set PB9 GPIOB->regs->BRR = bit9; // Clear PB9 GPIOB->regs->BSRR = bit9; // Set PB9 GPIOB->regs->BRR = bit9; // Clear PB9 GPIOB->regs->BSRR = bit9; // Set PB9 GPIOB->regs->BRR = bit9; // Clear PB9 GPIOB->regs->BSRR = bit9; // Set PB9 GPIOB->regs->BRR = bit9; // Clear PB9</code></pre> removing the small "overhead" of executing the for-loop. -robodude666 TRC on "Low Level pin manipulation" http://forums.leaflabs.com/topic.php?id=860#post-5187 Tue, 14 Jun 2011 09:23:26 +0000 TRC 5187@http://forums.leaflabs.com/ Hello all, I'm a new Maple R5 user with some Arduino experience. I was wondering if it is possible to do direct pin manipulation in the Maple ide. I tried an simple code to see how fast I could get a pulse going: ----------------------------------------- void setup() { pinMode (24, OUTPUT); } void loop() { digitalWrite(24, HIGH); digitalWrite(24, LOW); } ----------------------------------------- This gave me a 713KHZ signal. Now this is already much faster than Arduino. But there is a custom Arduino library which adds the "digitalWriteFast" and "digitalReadFast" functionality. And on the Ardunio this gives me a 2.2MHZ signal. Now I wonder if such a thing is also possible for Maple. Or at least the possibility for custom direct port manipulation within the Maple ide. Thanks in advance! TRC