konan
Member
Hi all, i'm porting to Maple the IRremote library by Ken Shiriff (http://www.arcfn.com/2009/08/multi-protocol-infrared-remote-library.html), and spent last 2 hours trying to find the hang-up point in the IR sending routine. It was the call delayMicroseconds(0), which calls the delay_us function in the delay.h, and in the delay_us there is a line "us--;". So, if I want delay 0 microseconds, I get delay more than hour :)
Maybe it would better to make zero-test at the beginning of the delay_us?
konan
Member
And one more issue with delayMicroseconds(). I found that its actual delay time is very far from that I said to do. So, I tried instead of delayMicroseconds this routine:
uint32 a = micros();
while (micros() < a + time) {};
which works quite well. I think something really wrong with delayMicroseconds...
mbolivar
LeafLabs
konan,
Looks like you're right. I'm measuring delay times lower than we would expect. I'm reluctant to replace with a micros()-based impplementation, however, as that relies on SysTick. We want delay() and delayMicroseconds() to work even with SysTick disabled. I think we should stick with the delay loop, but it obviously needs to be fixed.
If you'd like to submit a patch to fix this, please do! See "contributing to libmaple":
konan
Member
mbolivar,
As for patch - I'd love to do my best to make the Maple project better, but now I have absolutely no spare time :(
I've ported (and reworked) IRremote library, so I can send you sources and brief description to include it in next IDE release, if you wish. I didn't touch the main routine - signal detection, although I strongly unlike that it use 50us interrupt (and occupies a timer) instead of tiying interrupt to the input pin. But it's a TODO item for the next release :)
gbulmer
Moderator
mbolivar
We want delay() and delayMicroseconds() to work even with SysTick disabled.
Why? What is the rationale?
I would prefer delay and delayMicroseconds to be:
a. accurate, and
b. deterministic, with no jitter.
Busy-wait loops will not give that.
I have no problem with the principle of busy-wait delays, just that they are harder to use and debug because they suffer jitter from interrupts, such as printing debugging messages.
As long as millis() and micros() are hardware-timer-based timing mechanisms, I am okay.
I would prefer delay(), and delayMicroseconds() to have comparable results to using millis() and micros() with a busy wait loop, but that is a question of taste. The fact that they jitter, which can make them somewhat tricky to use, could be mentioned in the documentation.
Maybe we could add low-jitter delay functions, with different names?
joet
Member
Konan,
Would you be willing to share your reworked IRremote library with me?
I'm getting tripped up right away with the #include <avr/interrupt.h> line...not sure what to do about this.
email: jtostenrude@hotmail.com
Thanks,
Joe
This is a known problem with the upstream Arduino implementation as well:
https://code.google.com/p/arduino/issues/detail?id=576
At a minimum, a note in the docs would be nice ;)
http://leaflabs.com/docs/lang/api/delaymicroseconds.html#caveats-and-known-issues
gbulmer
Moderator
bnewbold - as I understand LeafLabs plans http://leaflabs.com/2011/11/were-teaming-up-with-wiring/
the upstream reference will be Wiring. So I guess we need to get them to fix this :-)
mlundinse
Member
I have checked the timings for the delay_us loop and
measured the time for 1000 and 2000 us delays using a
simple oscilloscope.
With a Olimexino STM32, Maple clone, I get accurate delays
(as good as I can measure) using
# define STM32_DELAY_US_MULT 12 /* When running from flash. */
# define STM32_DELAY_US_MULT 18 /* When running from RAM. */
In Maple-IDE there is at the moment no clean way to switch between these alternatives.
When using the command line tools a compiler flag should work
-DSTM32_DELAY_US_MULT=18
Regards
Magnus
You must log in to post.
