Low Level pin manipulation « LeafLabs Garden

LeafLabs Garden » Community » The Garden

Low Level pin manipulation

(10 posts) (5 voices)

Started 4 years ago by TRC
Latest reply from mbolivar

TRC
Member

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

Posted 4 years ago #
robodude666
Member
There sure is! The STM32 is capable of ~18MHz GPIO toggle speeds. Check out my "High-Speed GPIO Access?" 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 digitalWrite function:
```
// D24 corresponds to PB9.

uint16_t bit9 = BIT(9);

GPIOB->regs->BSRR = bit9; // Set PB9
GPIOB->regs->BRR = bit9; // Clear PB9
```
It may be difficult to memorize the registers so libmaple has a built in lower-level gpio function:
```
gpio_write_bit(GPIOB, 9, 1); // Set PB9
gpio_write_bit(GPIOB, 9, 0); // Clear PB9
```
The only overhead of the gpio_write_bit function is a single if-statement and a BIT calculation. I created the following macros for my needs to remove the if-statement overhead:
```
#define sbit(port, pin) port->regs->BSRR = BIT(pin)
#define cbit(port, pin) port->regs->BRR = BIT(pin)
```
You can remove the BIT.. 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:
```
uint16_t bit9 = BIT(9);

for(int i = 0; i < 4; i++)
{
	GPIOB->regs->BSRR = bit9; // Set PB9
	GPIOB->regs->BRR = bit9; // Clear PB9
}
```
can be written as:
```
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
```
removing the small "overhead" of executing the for-loop.

-robodude666
Posted 4 years ago #

snigelen
Member

I did some tests while robodude666 answered.

First test.

void setup() {
  pinMode(24, OUTPUT);
}

// 2.57MHz
void loop() {
  GPIOB_BASE->BSRR = 1<<9;
  GPIOB_BASE->BRR = 1<<9;
}

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().

// 4.26 MHz
void loop() {
  while(1) {
    GPIOB_BASE->BSRR = 1<<9;
    GPIOB_BASE->BRR = 1<<9;
  }
}

Still pulses. Time between them comes from the loop.

Test 3.

// 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;
}

4 18 MHz pulses with some time between.

The fastest is to let the hardware take care of it.

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() {
}

36 MHz. (which is about the highest I can see with my oscilloscope).

Posted 4 years ago #

robodude666
Member

Does the compiler optimize (i.e. pre-calculate) 1<<9 for you? I've never checked.

While experimenting with this before I noticed very interesting things as well. For example, with the following:

GPIOB_BASE->BSRR = 1<<9;
GPIOB_BASE->BRR = 1<<9;

You'll see the Set occuring very quickly, then the Clear taking twice as long as the set. If you look at this next:

GPIOB_BASE->BSRR = 1<<9;
GPIOB_BASE->BRR = 1<<9;

GPIOB_BASE->BSRR = 1<<9;
GPIOB_BASE->BRR = 1<<9;

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:

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;

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: True performance of STM32, as I mentioned in my thread. The most interesting post is this one by an official ST employee. He writes:

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.

Quite interesting =].

Posted 4 years ago #

snigelen
Member

Does the compiler optimize (i.e. pre-calculate) 1<<9 for you? I've never checked.

Yes, all expressions that's constant at compile time will be evaluated by the compiler.

Posted 4 years ago #
robodude666
Member

Well then, my previous uint16_t bit9 = BIT(9); statements can be ignored.

Posted 4 years ago #
poslathian
LeafLabs

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!

Posted 4 years ago #
mbolivar
LeafLabs

i think this should be included in the official docs (which recently moved to https://github.com/leaflabs/leaflabs-docs). 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!

Posted 4 years ago #
robodude666
Member

I love good puns on a Tuesday afternoon :D.

Posted 4 years ago #
mbolivar
LeafLabs

update: done:
https://github.com/leaflabs/leaflabs-docs/commit/fd7edc29d79bbba098fdab621a56205740599a4f

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.

Posted 4 years ago #

RSS feed for this topic

Reply

You must log in to post.