Brian Marshall

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

5 years, 1 month ago.

What's going on in the "background?"

I'd like to learn more about what is going on in the background. Is this documented anywhere?

I know mbed covers many boards and microcontrollers so it wouldn't be the same for every single one. For example if I take the delay out of the blink program on my STM32F303K8 it switches at about 2MHZ while the processor is running at 64MHZ.

I want to detect an audio range frequency at a digital input and have a digital output for a multiple of that frequency. I run into trouble when the output frequency gets above 5Khz. It works, kind of but becomes non-symmetrical and falls behind. I assume this is because there are interrupts running in the background.

1 Answer

Andy A
5 years, 1 month ago.

MBed 2 or MBed 5 (mbed-os) ?

mbed 2 will have less happening in the background.

The main thing will be a timer interrupt running at 1 MHz (on most platforms on some low end ones it's slower) that is used for all of the Timers/Tickers/Timeouts to give 1 us resolution.

GPIO can be slow, there are several layers of software translating the user friendly DigitalOut commands into hardware accesses. There is a library called FastIO https://os.mbed.com/users/Sissors/code/FastIO/ that bypasses a lot of this and gives significant speedups on the supported platforms.

If you don't mind throwing away all portability and digging through the CPU user manual then generally setting an IO pin high or low should only take 1 or 2 cpu cycles if you hit the correct registers directly.

Forgive my ignorance. Is this FastIO still relevant compared to newer mbed-os? I note the last commits were a 2014 and the page refers to mbeds 85-86. It also refers to debugs being the cause of the slowdown in the online compiler - so can they be turned off (now) or via mbed-cli? my HW is unsupported, so I can't really explore it

posted by Brad S 27 Feb 2019

In that case it's probably easier to go with the direct register access.

The libraries for your part define things such that you should be able to do: 

GPIOA->BSRR = 1<<3; // set GPIO A_3 high, leave all other port A pins unchanged.
GPIOA->BSRR = 1<<(3+16); // set GPIO A_3 low, leave all other port A pins unchanged.
bool pinB_4_high = GPIOB->IDR & 1<<4; //  check the status of GPIO B pin 4

All of the other GPIO registers described in the user manual are accessible in a similar manner.

You could do all the setup manually using those registers but it's also OK and probably easier to use the mbed libraries to configure the pin with the direction, pullup/down etc... that you want and only use these direct calls to set/reset the pin.

posted by Andy A 27 Feb 2019