LeafLabs Garden

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

1. 

   ala42
   Member

   #include "nvic.h"
   ...
   nvic_globalirq_disable();

   Posted 3 years ago #
2. 

   hans leuthold
   Member

   - thanks: cutting interrupts reduced the jitter by over 80%

   now the test code is able to follow a 220kHz clock and the jitter is 680ns, this is still the equivalent of 49CPU clock cycles

   need to change over to programmable logic, I guess

   Posted 3 years ago #
3. 

   ala42
   Member

   You have already noticed that digitalWrite is slow, but still use two digitalReads in your loop.

   Posted 3 years ago #
4. 

   hans leuthold
   Member

   - you are evidently right! - thanks

   after replacing all the digitalRead(xPIN) with a construct of the sort
   #define CHECK_SCK_PIN ((GPIOB_BASE)-IDR & BIT(y))
   the test code is able to follow a 700kHz clock and the jitter is about 140ns.

   I supply my maple board with a 5V phone charger and wondered whether this remaining jitter is somehow related to noise from the power supply. However supplying it through USB does not change anything.

   At this stage the loop() looks as follows below. All times are measured on a digital scope at 100MS/s with a 1000 event envelop triggered by the rising input clock. The input clock is a 5V amplitude square wave signal at 700kHz

   #define ONEREV 31U
   #define MAXVAL 4095U
   
   uint16 erotable[ONEREV+1];
   uint16 eroindex;
   const uint16 onerev = ONEREV;
   const uint16 maxval = MAXVAL;
   
   void setup() {..... /initializes the pins, variables & table
   }
   
   void loop() {
     while (!CHECK_SCK_PIN); // wait for raising edge of the input clock
     eroindex++;
     eroindex &= onerev;
     // in the real thing there will be some more code here
     OCK_PIN_LOW; // send output shown on scope 560ns to 700ns after the rising edge
   
     while (CHECK_SCK_PIN); // wait for falling edge
     if (CHECK_BS_PIN) {  // bitstream is HIGH
       if(erotable[eroindex] < maxval)
         erotable[eroindex]++;
     }
     else { // bitstream is LOW
       if(erotable[eroindex] > 0)
         erotable[eroindex]--;
   
     // in the real thing there will be some more code here
     OCK_PIN_HIGH; // send output shown on scope 552ns to 700ns after the falling edge
   }

   I was hacking with PCs and single board computers 25 years ago and have not done a lot since (..so now you know, I am more like your grandpa..) I really appreciate all the hints I have gotten so far and wonder why the timing I see is what it is. I expected both code snippets including the wait for transition to be between 15 and 20 clock cycles which is roughly half of what I measure.

   Posted 3 years ago #
5. 

   gbulmer
   Moderator

   hans leuthold - have you reduced the loop() to:

   void loop() {
     while (!CHECK_SCK_PIN); // wait for raising edge of the input clock
     OCK_PIN_LOW; // send output shown on scope 560ns to 700ns after the rising edge
   
     while (CHECK_SCK_PIN); // wait for falling edge
     // in the real thing there will be some more code here
     OCK_PIN_HIGH; // send output shown on scope 552ns to 700ns after the falling edge
   }

   What is the jitter? I'd expect it to be better.

   I'd expect the path length, i.e. the number of instruction, to differ in loop(), because of the if tests.
   This would show up as jitter. 140ns is about 10 instructions.

   You might try 'decompiling' the program using objdump, which would let you see the number of ARM instructions
   See the GCC binutils documentation http://sourceware.org/binutils/docs-2.22/

   I was hacking with PDP-11's, and microprocessor development boards more than 30 years ago, but I don't think of myself as grandpa.

   Posted 3 years ago #
6. 

   hans leuthold
   Member

   the reduced code as suggested by gbulmer runs

   void loop() {
     while (!CHECK_SCK_PIN); // wait for raising edge of the input clock
     OCK_PIN_LOW; // send output shown on scope 290ns to 512ns after the rising edge
   
     while (CHECK_SCK_PIN); // wait for falling edge
     // in the real thing there will be some more code here
     OCK_PIN_HIGH; // send output shown on scope 235ns to 445ns after the falling edge
   }

   I read this result with a 72MHz cpu clock as
   1st snippet is 21 to 37 cycles - this is a 16 cycles jitter
   2nd snippet is 17 to 32 cycles - this is also a 16 cycles jitter

   in reality this would translate into about 4 cycles for loop() and 17 to 32 cycles while waiting for a transition and the output

   there are only 2 things that I can come up with as an explanation
   1) interrupts that cannot be disabled
   2) electrical noise on the input pin, board side

   any other ideas ?

   Posted 3 years ago #
7. 

   crenn
   Moderator

   You're also assuming that the 72MHz is exact. There will be jitter because of the design of the system. It's using a 8MHz reference into a clock multiplier to give a speed of 72MHz.

   Posted 3 years ago #
8. 

   ala42
   Member

   The reaction time of the while loop is not constant, so you must get a jitter. If you have any doubt about this, just use some fixed calculations instead the while loops to be convinced :)

   Btw, you could read the data via SPI, so you do not need to follow the clock line in your code. Just read the SPI data when ready and evaluate it. This leaves you much more time for analyzing the data stream.

   Posted 3 years ago #
9. 

   hans leuthold
   Member

   ala42 - I guess you hit the nail right on the head, the while loop running exactly once up to exactly twice, I could not see the forest because of the trees.....

   thanks for the hint on SPI, I will check that out

   Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.