Arduino read/write funtions "slow"?

On the Wiki, it is mentioned that the basic Arduino digitalread/write() and the analog equivalents are “slow”, but what exactly is meant by that?

Are they slow when compared to the performance baseline of an ATMega328 with the same functions, or “slow” relative to directly addressing the hardware on the STM MCU?

Would it ever be an issue when using common Arduino example sketches and typical tasks?

It just occurs to me that without proper context, the observation is really not very helpful, and may lead to unnecessary churn when coding…

digitalWrite () you might achieve ~700kHz

while (1) {
digitalWrite(LED, 1);
digitalWrite(LED, 0);
}


Rick Kimball wrote:digitalWrite () you might achieve ~700kHz
…

STMdude wrote:Cool, but how does that compare to a 16MHz Uno (or ARM-Due) with the same code?

Rick Kimball wrote:STMdude wrote:Cool, but how does that compare to a 16MHz Uno (or ARM-Due) with the same code?

It seems that if you optimize the alignment of that code, you can get about ~12MHz out of the toggle

const uint8_t LED = PA2;

void setup() {

pinMode(LED, OUTPUT);

static volatile uint32_t * const reg = (volatile uint32 * const)&GPIOA->regs->BSRR;

__asm (
".align 4\n" // align code on a 16 bit boundary
);

while (1) {
*reg = 0b1 << 2 << 16 | 0b0 << 2;
*reg = 0b1 << 2 << 16 | 0b1 << 2;
}
}

void loop() {
}

I did some benchmarking then and the avr Arduino is 100x slower at GPIO vs. Native avr.

The stm32 Arduino is 20x slower.

I can post a link to my benchmarking later.

edit:

1. this is the benchmarking of STM32F103-based arduino: https://dannyelectronics.wordpress.com/ … 2-arduino/
2. here is the benchmarking of the AVR arduino: https://dannyelectronics.wordpress.com/ … r-arduino/

I’m porting Arduino to stm and so far the Arduino-stm32f10x GPIO is 2.5x slower than that of a native stm32.

So they aren’t the best if you are looking for raw performance.

dannyf wrote:

So they aren’t the best if you are looking for raw performance.

i doubt it is literally ‘slow’ but if you use dma or spi + dma it could be *much faster* reaching 10s of mhz for the switching speeds
one of the forum members did a logic analyzer and it achieved 1 msps just reading gpio pins in a loop
http://www.stm32duino.com/viewtopic.php?f=19&t=1973

and another member achieved 7mhz pushing the limits dma etc
http://www.stm32duino.com/viewtopic.php … =10#p27238
https://github.com/ddrown/stm32-sump

I’ve also made some benchmark some time ago witch also tests the ADC-speed.
As far as I remember the analogRead-Speed was about 30kSampels/Sec on the BluePill which seems a little bit slow to me.

ChrisMicro wrote:I’ve also made some benchmark some time ago witch also tests the ADC-speed.
As far as I remember the analogRead-Speed was about 30kSampels/Sec on the BluePill which seems a little bit slow to me.

RogerClark wrote:I don’t know if the AVR chipset has the equivalent of the BSSR (I didnt think so, but I could be wrong)

As far as I remember the analogRead-Speed was about 30kSampels/Sec on the BluePill which seems a little bit slow to me.

I did a benchmarking on my own brew of analogRead() on a 24Mhz 100RB.

25us/12-bit sample at the slowest sample time setting, and 5us/12-bit sample at the fastest sample time setting. Code optimization isn’t a big driver of speed here, so I would expect the numbers for 103 to be similar.

I don’t know if the AVR chipset has the equivalent of the BSSR (I didnt think so, but I could be wrong)

it does: https://dannyelectronics.wordpress.com/ … datasheet/

Just a short comment, this benchmark does not test the ADC speed, but the analogRead() function alone.
The ADC is capable of mega sample(s) per second in dual simultaneous mode.

That’s totally clear to me. But because I use the Arduino-Framework this is the relevant benchmark for me.
If I would use bare metal IDE programming, other benchmarks would be relevant.

I did some quick testing on stm8s105 at 16MHz. Under the slowest adv clock (fmaster / 18) each adc conversions takes just over 22us. Fairly comparable to that of a stm32f100.

edit: with the adc clock at the fastest in-spec speed (fmaster / 4 = 4Mhz – max for 3v supply which I’m running the stm8s at), each adc conversion takes just shy of 8us – of that, 1.75us is for the actual conversion.

U didn’t try the fastest setting (fmaster / 2).

stm8s ! i almost misread it as stm32
but then stm32 is 12 bits vs 10 bits on stm8s i think, even then that’s pretty fast for an 8bit mcu

The conversion time is 14 clock cycles (max 4 to 6 Mhz)

So at 16Mhz/18, the conversion time is 16us. Or 2.3us at 6Mhz.

So the chip can actually do much better than the benchmark numbers above would suggest.

It is not uncommon for today’s mcus to have 100ksps or faster adc and 1Msps adcs aren’t rare either.

One lpc4xxx chip has a blazingly fast adc.