Arduino for STM32

If you really wanted to print the result of the digitalReadFast(), but exclude the time taken for the Serial.print() from your measurement, then you could assign the return value from digitalReadFast() to an int variable, and then print that together with the timecnt value.

Based on the code I saw ...

leonardo wrote: Thu Mar 11, 2021 6:03 am but the loop is still 1100 microseconds after using this function

Maybe show us your code as it is now. I'm not sure what you are measuring.

I looked at what the compiler does for statements like these:

if ( GPIOB->IDR & 1 << 10 ) ...;
if ( GPIOB->IDR >> 10 & 1 ) ...;

I thought that potentially the first of those might execute a tad faster than the second, but no, it turns out the compiler is smart enough to generate exactly the ...

...
Also you're ISR isn't as fast as it can be. This 10 bit shift needs time.
You can use

digitalReadFast(digitalPinToPinName(pin));

and set optimization to fastest (-O3)



if ( GPIOB->IDR & GPIO_IDR_ID10 ) receiver_input1_previous = no

Would obviate 10 bit shift (at execution time ...

I don't know what you expect timecnt to be. If you are trying to determine how long the Serial.println(receiver_input1) takes, then you should have just set timecnt = micros(), not timecnt = micros()-timecnt initially.

You probably should have declared receiver_input1 as volatile too, but that ...

I'm not familiar with the internals of this. Maybe there is some clue in the actual values in XFerOptions or Mode when it fails, or perhaps there is some subtle difference between what you do in your code compared to the example.

If it is somehow related to the rate, or just the number of times ...

You're way ahead of me. What makes you think this has anything to do with I2C getting stuck in busy state? When I had that problem, the busy state caused a HAL error code to be generated (after some timeout). I don't remember the details now, and I also don't know how that would surface when using ...

I have done some reading around and have found that some people have had problems with the HAL I2C library and the I2C BUSY state in particular, it looks as though it is present in some STM32 erattas too. I found these results by searching "hal i2c busy eratta" into google.

https://electronics ...

In my travels through RM008 and AN2604 yesterday, I noticed that you can get it to output RTC clock divided by 64 on the "TAMPER" pin (PC13?). If that pin is available, you would not need a very accurate counter to see if the frequency is out by as much as it appears to be.

...
You say I can compensate for an LSE error in software, but I can't find that in the datasheet. it's a bit hard to find this info if you don't know exactly what to look for. Do you have any clues as to what function or register(s) I need to use?


I have never tried to use the RTC on any STM32 ...