Arduino Time functions

[asifsardar26]

Arduino Time Functions are not working in the Ell-i Runtime.

[felixcl]

Here is more information about the problem with the delayMicroseconds() function.

I found these problems testing the humidity sensor described in
https://github.com/Ell-i/Hackathon/wiki/Components%20DHT22%20Humidity%20sensor

The file related to time functions is wiring_time.h

The humidity and temperature sensor sends data on a very critical timing, doing
highs and lows in a few microseconds.The code needs to capture all the transitions to calculate the
values correctly, so it uses the function delayMicroseconds() from Arduino to read fast but not continuously, and this function is not completely tested in our environment.

I did some tests with the delayMicroseconds() function, and it works fine for values under 20 microseconds and over 1000 microseconds.

Under 20 microseconds, it does the following
asm volatile(
"L_%=delayMicroseconds:" "\n\t"
"sub %0, #1" "\n\t"
"bge L%=_delayMicroseconds" "\n"
: /* no outputs */ : "r" (cycles4)
);

doing 12 loops for each microsecond @48 Mhz and it works good.

The current implementation for delays equal or over 20 microsecond compares the current micros() with the micros() the function started. As I said, it works well for delays over 1000 microseconds, so the delay and delayMilisecond functions work fine for values. The problem is only with delayMicroseconds with between 20 and 1000 microseconds. In discussion with Pekka he thinks that for miliseconds it might also not be working well, but since the jitter is so small, it gets lost in the microseconds and therefore it seems to be fine at the milisecond level.

When using these values, the delays seem to be random, and sometimes are too small and sometimes too big, but it does not generate the expected delays. Might be because the call to micros() function and the while loop takes more time than the delay, and then there are problems.

The library for the DHT22 sensors uses a call to delayMicroseconds of 40
microseconds, so it was definitely not working.

Another issues is that if I change the call of 40 microseconds to:
delayMicroseconds(15);
delayMicroseconds(15);
delayMicroseconds(10);

It gives a 25 microsecond delay. After several tests, I noticed that
if I call twice the delayMicroseconds function with the same argument
in consecutive lines, the second calls gets ignored. So if I do:
delayMicroseconds(15);
delayMicroseconds(10);
delayMicroseconds(15);

It gives the 40 microseconds delay I expect. I don't know the internal
working of the compiler and/or optimizations, so if an explanation and solution to
this issue could be provided it would be great.

On the current implementation, the comments also state that sometimes the current implementation fails if the millisecond counter rolls over. This should happen only every few days, but needs to be fixed at some point.

An idea from Pekka Nikander is: In addition to changing the cutoff value of the asm loop, we could also explicitly compute timo - micros() (as the compiler needs to do that anyway), and compare that to the cutoff value. If the difference is less than the cutoff value, run only the assembler loop for the rest of the time. Something like the following:

remaining = us;
if (remaining > cutoff)
   timo = micros() + us;

do {
   if (remaining < cutoff) { do the asm loop); return; }
   yield();
   remaining = timo - micros();
while (remaining > 0);

You need to be careful with signed and unsigned values. But that should give you more accuracy.

And Pekka also commented that to make the sensor work better, he thinks that the right way is to use a counter/timer instead of a delay. Please note also that on STM32F it is possible to set the weak pulldown and pullup on an I/O even if it is an input. See Figure 15 on page 126 of RM0091. In that way you should be able to set the pin low and high without setting it as an output, and start receiving data as soon as it first transitions. The current implementation on the sensor changes the pin from output to input after sending the first transition that makes data to start coming in.

He would use a timer to read the high-pulse length (26-28 us vs 70 us) and trigger an interrupt at each high-to-low edge. Then, at the interrupt routine it is easy to determine from the counter value whether the previous bit was one or zero.

The timer could even be set up before pulling the line high after the long low. The first interrupt would then be triggered by the first high-to-low transition, at the beginning of the transmission, and you could then see the that the 20-40 ms waiting time.