LeafLabs Garden

A place to share, learn, and grow...

1. 

   josheeg
   Member

   delayMicroseconds(us) and delay has anyone used them and are they semi-acurate?
   I am looking to bitbang a spi like interface for the ads1298 the speed of the maple & that it is open source is great for my open source project.
   the delays has anyone had problems with them?

   Posted 5 years ago #
2. 

   poslathian
   LeafLabs

   These functions are as accurate as the crystal on maple. It is not a realtime crystal but its not bad. I dont have exact specs off the top of my head, but it should vary from board to board. You should be able to use the HardwareSpi object to avoid bitbanging. I think this little gem was quietly slipped in to 0.0.6 without being documented. Once its well tested well document it, but for now ill point you to:

   http://github.com/leaflabs/libmaple/blob/master/wirish/comm/HardwareSPI.h

   Posted 5 years ago #
3. 

   CarlO
   Member

   The crystals on my two Maple Boards were off by 4ppm and 13ppm, both on the low frequency side (longer period) as I recall. I tested with the PWM functions and found a small error in the library that should be fixed in the next release. See this thread:

   http://forums.leaflabs.com/topic.php?id=124

   I haven't tested the delay functions but they should be as accurate as the crystals, certainly good enough for SPI. There will be some overhead in the library code, but it should be consistent.

   CarlO

   Posted 5 years ago #
4. 

   CarlO
   Member

   So I did some testing on the accuracy of the delay and delayMicroseconds functions. Here are the results:

   Using this code I measured the width of the pulse

   void loop()
   {
     digitalWrite(Pin, HIGH);   // set the LED on
     delay(100);
     digitalWrite(Pin, LOW);    // set the LED off
     delay(1);
   }

   I measured the following pulse width for each value of delay
   

   Delay           Width
   100             101.002ms
   200             201.005ms
   300             301.007ms

   Then I used this code and again measured the width of the pulse
   

   void loop()
   {
     digitalWrite(Pin, HIGH);   // set the LED on
     delay(100);
     delay(100);
     delay(100);
     digitalWrite(Pin, LOW);    // set the LED off
     delay(1);
   }

   I measured a pulse width of 303.007ms

   So for the delay function it looks like you get a delay of 1ms greater than the value passed to the function. (within the accuracy of the crystal) Note that the overhead for the function call etc. is very small compared to the minimum delay value.

   Then I used this code and again measured the pulse width

   void loop()
   {
     digitalWrite(Pin, HIGH);   // set the LED on
     delayMicroseconds(1000);
     digitalWrite(Pin, LOW);    // set the LED off
     delay(1);
   }

   I measured the following pulse width for each value of delay
   

   Delay            Width
   1000             1000.72us
   2000             2000.77us
   3000             3000.74us

   And then again with this code

   void loop()
   {
     digitalWrite(Pin, HIGH);   // set the LED on
     delayMicroseconds(1000);
     delayMicroseconds(1000);
     delayMicroseconds(1000);
     digitalWrite(Pin, LOW);    // set the LED off
     delay(1);
   }

   And measured a pulse width of 3000.93us

   So for the delayMicroseconds function it looks like you get a the proper delay with an overhead of about 0.1us for the function call etc. and about 0.5us for the function call to turn the pin off.

   CarlO

   Posted 5 years ago #
5. 

   CarlO
   Member

   Update,

   I found a small bug in the version of time.c that was released with v0.0.6 that was causing the delay function to delay for an extra millisecond. Now I see that in the code repository the delay functions have already been re-written. I'll try to compile my code with the new delay functions and re-run the tests.

   CarlO.

   Posted 5 years ago #
6. 

   gbulmer
   Moderator

   CarlO - very nice piece of work! As the young folks say, "Respect" :-)

   How are you measuring the pulse width so precisely (6 significant figures)?

   Posted 5 years ago #
7. 

   CarlO
   Member

   gbulmer,

   I have a Racal model 1992, 9 digit counter that is stable down to 1ns. I also have a GPS Disciplined timebase that I use when I need high accuracy. I only recorded the digits that weren't dithering on the display. Due to the fact that the delay and delayMicroseconds functions are implemented in software, there is a tiny amount of jitter in the width of the pulse.

   Carl

   Posted 5 years ago #
8. 

   poslathian
   LeafLabs

   hmm, the off by 1 in delay is very interesting: See the implementation:

   void delay(unsigned long ms)
   {
      uint32 i;
      for (i = 0; i < ms; i++) {
         delayMicroseconds(1000);
      }
   }
   
   void delayMicroseconds(uint32 us) {
       us *= 12;
   
       /* 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");
   }
   

   If delayMicros works, then delay should work. Odd. Perhaps what we should be doing for delay isnt a over delayMicroseconds anyway but instead a delayMicroseconds(1000*ms). This would roll over delayMircroseconds for calls to delay longer than 72 minutes (~4200 seconds, ~4200000 ms), which I think is OK. Or we could bump everything up to long, and add a little more overhead to the microseconds loop.

   In general, I am a fan that there is so little overhead for delayMicroseconds, only ,72us! Good stat CarlO!

   Posted 5 years ago #
9. 

   CarlO
   Member

   poslathin,

   The code for delay and delayMicroseconds distributed with V0.6 is different. I have not been able to get the new delay code to compile, too many dependency changes. I assume the new code will work correctly, but I'll test it when released.

   CarlO.

   Posted 5 years ago #
10. 

    poslathian
    LeafLabs

    Ahh, yea I pulled this out of git. I suspect then that this was a known bug in 0.0.6 and someone (bnewbold? iperry? mbolivar?) fixed it - Good!

    Posted 5 years ago #
11. 

    crenn
    Moderator

    The most important question I'd ask is when is an alpha (or beta) of v0.0.7 going to be out!

    Posted 5 years ago #
12. 

    poslathian
    LeafLabs

    0.0.7 is just a regular incremental release. the "alpha" stuff was referring to our snazzy new IDE (completely redone) for 0.1.0. Well push the 0.0.7 as soon as the last straggling tickets are closed, which are very minor. For example "grep todo in codebase" is currently on the top of the stack ;)

    Posted 5 years ago #
13. 

    crenn
    Moderator

    So a couple of weeks away? And is some form of I2C included in that release?

    Posted 5 years ago #
14. 

    poslathian
    LeafLabs

    days, and yes - software i2c with single master mode only. the hardware i2c with slave and multimaster is weeks.

    Posted 5 years ago #
15. 

    crenn
    Moderator

    Currently only need single master mode (our robot is designed around a single micro, which at this stage I'm hoping to be a Maple although there is a little bit of debating behind the scenes) and a software implementation will work fine for what we need.

    Posted 5 years ago #

RSS feed for this topic

Reply »

You must log in to post.