Hi,
During my first tests of the Maple mini, I found that the speed of flashing did not match the delay. So I checked it with this program:
http://bernard.o.perso.neuf.fr/Electronic/MAPLE/testDelay/testDelay.htm
Is there an explanation for this difference?
Hi,
My board is a Maple-mini.
Here is my sketch :
#include <Wire.h>
#define Serial SerialUSB
unsigned int time = 0;
void setup() {
// Led :
pinMode(BOARD_LED_PIN, OUTPUT);
time = millis();
}
void loop() {
togglePin(BOARD_LED_PIN);
delay(1000);
Serial.print("millis = "); Serial.println((millis() - time));
time = millis();
}The result is different than expected: for a time 1s, 669ms only!
gbulmer
Moderator
Bernardo769 - thanks for posting the details.
OMG !
The core of delay() is a 'busy' loop:
void delay(unsigned long ms) {
uint32 i;
for (i = 0; i < ms; i++) {
delayMicroseconds(1000);
}
}
void delayMicroseconds(uint32 us) {
delay_us(us);
}Then delay_us() is just a loop which counts down:
static inline void delay_us(uint32 us) {
us *= STM32_DELAY_US_MULT;
/* fudge for function call overhead */
us--;
asm volatile(" mov r0, %[us] \n\t"
"1: subs r0, #1 \n\t"
" bhi 1b \n\t"
:
: [us] "r" (us)
: "r0");
}Which is clearly not accurate.
The easiest things would be to change the value of STM32_DELAY_US_MULT from 12 to 16-ish.
higwoshy
Member
OMG indeed. This is why my spaceships keeping flying into the Moon rather than flying on to Mars. Now I think about it, I've noticed this before but never given it much attention, assuming it was my imagination.
I wonder if this is why some Arduino hardware libraries fail to work when ported over to the Maple? Anything with delay(100) etc in it for timing (say, clock pin toggling or waiting for hardware) would be out by 3/10 of a second?
I thought I understood assembly but that bit of code looks like nonsense to me? [us] "r" (us) ??! "r0" !?
Anyway, what's the fix? Changing that define from 12 to 15,16 produced 836, 1337 (!) - not much use.
I changed the delayMicroseconds(1000); in wirish_time.cpp to delayMicroseconds(1496); which is clearly a fudge, but a fudge that works is better than a 1 second delay that only last .7 seconds!
This still leaves delayMicroseconds as being very inaccurate - according to the Arduino docs it's meant to be very accurate above 3ms. Clearly the maple one isn't (?)
Test program used (I also used the visual of clock hand to led flash, which clearly showed how bad delay(1000) actually was.
//#include <Wire.h>
#define Serial SerialUSB
void setup()
{
pinMode(BOARD_LED_PIN, OUTPUT);
}
void loop()
{
int millitest;
int time;
togglePin(BOARD_LED_PIN);
time = millis();
delay(1000);
millitest=millis()-time;
Serial.print("millis = "); Serial.println( millitest);
}I'm running on an Olimexino, which returned 669ms for 1 second. With code change above, returns 1000. Which'll do until a proper fix comes along.
Is the original delay_us() flawed because it does a multiplication which takes longer than 1us?
@higwoshy, what about using a hardware timer instead of the delay-software-hack to get accurate timing?
http://leaflabs.com/docs/lang/api/hardwaretimer.html#lang-hardwaretimer
higwoshy
Member
@ventosus : I thought it would have been done that way anyway, but I guess they didn't want to use a valuable hardware timer on something so trivial - something I'd go along with. I'm ok with a hard coded delay as long as long as it's accurate - the Maple is not a multi-tasking OS so if you perform a delay() chances are you code isn't doing anything anyway so what's the harm. Keep it simple.
I have no idea how to implement a delay_us() - which is the problem function - as I don't know enough about clock speeds vs speed of each assembly level instruction.
Maybe it's the compiler being clever and 'optimising' the delay_us() code? It's a trivial bit of code so I'm surprised it's broken (?). I've only got an Olimexino so maybe the Maple native etc is different? Maybe it's measurement errors in the test code above?
gbulmer
Moderator
There is a dedicated Cortex-M3 hardware timer (SysTick) which drives millis() and micros()
So a reasonable implementation would just use that timer, and those functions, e.g.:
void myDelay(unsigned long ms) {
unsigned long start_ms = millis();
while (millis() - start_ms < ms) ;
}The code is assembler, and marked as asm volatile:
asm volatile(" mov r0, %[us] \n\t"
"1: subs r0, #1 \n\t"
" bhi 1b \n\t"
:
: [us] "r" (us)
: "r0");So the compiler shouldn't mess with it.
I think their is a thread on the forum where LeafLabs agree the estimate of this codes run time is just wrong.
But using the systick hardware timer is better anyway because it would have greater immunity to timing inaccuracy due to interrupts.
higwoshy
Member
@gbulmer. Yes, agreed, unless systick is turned off - maybe two versions? Anyway, it's all simple enough to fix...
but... it's been discussed before...1 year ago by the looks of it. Is there a new version coming out whereby all the fixes scattered throughout this forum are implemented? Will there ever be a version 0.0.13. Or even 0.0.125?
You must log in to post.