Test data received by interruption

LeafLabs Garden » Support » Maple IDE Support

Test data received by interruption

(20 posts) (4 voices)

Started 3 years ago by Bernardo769
Latest reply from Bernardo769

12 Next »

Bernardo769
Member

Hi,

When I test this code:

#include "voieRC.h"
#define Serial SerialUSB

#define pinVoieGAZ 20
voieRC voieGAZ(pinVoieGAZ);

void setup() {
  attachInterrupt(pinVoieGAZ, interruptRC_GAZ, CHANGE);
}

void loop() {
  SerialUSB.println(voieGAZ.valeur());
  //delay(50);
}

void interruptRC_GAZ(void) {
  voieGAZ.etat();
}

voieRC::voieRC(int pin){
  pinRC = pin;
  pinMode(pin, INPUT_PULLUP);
}

unsigned int voieRC::valeur() const{
  return (lastValidValue);
}

class voieRC{
  public:
  voieRC(int);

  unsigned int valeur() const;
  void etat();

  private:
  int pinRC;
  unsigned int timeUP;
  unsigned int timeDOWN;
  unsigned int lastValidValue;
};

void voieRC::etat() {
  //noInterrupts();
  if (digitalRead(this->pinRC) == HIGH) {  // Front montant
    timeUP = micros();
    timeDOWN = timeUP;
  }
  else {  // Front descendant
    timeDOWN = micros();
    lastValidValue = timeDOWN - timeUP;
  }
  //interrupts();
}

I find that I have some data outliers.
Here is the data received through the USB port:
http://bernard.o.perso.neuf.fr/Electronic/MAPLE/BugRC/sansServo.txt
http://bernard.o.perso.neuf.fr/Electronic/MAPLE/BugRC/radioSansServo.txt
http://bernard.o.perso.neuf.fr/Electronic/MAPLE/BugRC/avecServo.txt

Here is the graph:
http://bernard.o.perso.neuf.fr/Electronic/MAPLE/BugRC/avecServo.jpg

Data are not usable as it stands.
You will find on this webpage for a video with the consequences of this problem:
http://bernard.o.perso.neuf.fr/Electronic/MAPLE/BugRC/BugRC.htm

My questions:
* Is there a programming error, is there any other way to avoid this?
* Is there an error in the wiring?
* How to eliminate these values?

thank you for your answers.

Posted 3 years ago #

bubulindo
Member

One thing I see is the variable type on timeUP and timeDOWN. They should be unsigned long.

Apart from that I don't see much more that can be wrong.

Actually, the interrupt function calling another function takes some extra time to read the pin.
Not sure if you can call a method on the interrupt, but that would be an optimization.

Posted 3 years ago #

Bernardo769
Member

Indeed, it was a mistake not to report these variables in unsigned long.
It does not solve the problem. I always inconsistent data.

To test, I changed my code :

void loop() {
  SerialUSB.println(voieGAZ.valeur());
  myservo.writeMicroseconds(constrain(voieGAZ.valeur(), SERVO_DEFAULT_MIN_PW, SERVO_DEFAULT_MAX_PW));  // OK
  //delay(50);
}
void interruptRC_GAZ(void) {
  //voieGAZ.etat();
  if (digitalRead(pinVoieGAZ) == HIGH) {  // Front montant
    voieGAZ.setTimeUP(micros());
    voieGAZ.setTimeDOWN(micros());
  }
  else {  // Front descendant
    voieGAZ.setTimeDOWN(micros());
  }
}

void voieRC::setTimeUP(unsigned long time){
  timeUP = time;
}

void voieRC::setTimeDOWN(unsigned long time){
  timeDOWN = time;
  lastValidValue = timeDOWN - timeUP;
}

The result is worse, servo controlled by pin 26 of the STM32 meets with 0.5 s delay!

Posted 3 years ago #

bubulindo
Member

Have you confirmed the input signal with an oscilloscope?
do you really need microseconds for the signal you're trying to measure?

Posted 3 years ago #
bubulindo
Member

Looking at the micros() function, I think I see what may be happening...

This is the function:

static inline uint32 micros(void) {
uint32 ms;
uint32 cycle_cnt;
uint32 res;

do {
cycle_cnt = systick_get_count();
ms = millis();
} while (ms != millis());

/* SYSTICK_RELOAD_VAL is 1 less than the number of cycles it
actually takes to complete a SysTick reload */
res = (ms * US_PER_MS) +
(SYSTICK_RELOAD_VAL + 1 - cycle_cnt) / CYCLES_PER_MICROSECOND;

return res;
}

Because the systick timer doesn't count microseconds, this is, as far as I can see something like millis() * 1000.

So if your signal is really fast, this may be the problem you're seeing.

Posted 3 years ago #
Bernardo769
Member

I have a handheld oscilloscope that gives me a correct signal to the output of the servo tester. The servo connected to the servo tester responds correctly.

The output signal of servo tester is like this:
http://robotpic.free.fr/tl_files/willy/images/servotime.gif

Posted 3 years ago #
gbulmer
Moderator
bubulindo - that version of micros() contains a bug.
See http://forums.leaflabs.com/topic.php?id=1098
```
do {
        cycle_cnt = systick_get_count();
        ms = millis();
    } while (ms != millis());
```
should be
```
do {
        ms = millis();
        cycle_cnt = systick_get_count();
    } while (ms != millis());
```
Sadly LeafLabs haven't updated the IDE download in the last year, so you need to patch it yourself, or go to github https://github.com/leaflabs/libmaple

That bug is enough to cause the value returned by micros() to jump backwards by almost 1000 microseconds, which might explain the results.

I don't think it is accurate to say

Because the systick timer doesn't count microseconds, this is, as far as I can see something like millis() * 1000.

systick counts at 72MHz, and counts down from 71999, i.e. 1 milisecond.

(ms * US_PER_MS) gives the number of complete milliseconds, measured in microseconds, the timer has been running.
(SYSTICK_RELOAD_VAL + 1 - cycle_cnt) gives the number of clock cycles (72MHz) into the current millisecond
(SYSTICK_RELOAD_VAL + 1 - cycle_cnt) / CYCLES_PER_MICROSECOND gives the number of microseconds into the current millisecond.

So the calculation is yielding a microsecond resolution timer, but with a range much bigger than 1 millisecond.
Posted 3 years ago #
Bernardo769
Member

Thank you for the information.
I downloaded the file libmaple-master.zip
I'm not used to these manipulations.
How to install its contents. I would not do anything stupid.

Posted 3 years ago #
gbulmer
Moderator
Bernardo769 - can you find the file wirish_time.h?

On my Mac, the path is MapleIDE.app/Contents/Resources/Java/hardware/leaflabs/cores/maple/
so it is likely something similar on other platforms.

Copy wirish_time.h to wirish_time.h.old (just in case you make a mistake)

Edit the file wirish_time.h, and replace
```
do {
        cycle_cnt = systick_get_count();
        ms = millis();
    } while (ms != millis());
```
with
```
do {
        ms = millis();
        cycle_cnt = systick_get_count();
    } while (ms != millis());
```
Unfortunately, the whole directory structure has changed, so it might be awkward to navigate.
Posted 3 years ago #
Bernardo769
Member

I still have the problem
I found the file wirish_time.h in the directory C:\Program Files\maple-ide-0.0.12-windowsxp32\hardware\leaflabs\cores\maple
When I look in the directory where the compilation is C:\Users\Olivier\AppData\Local\Temp\build7029581827160573567.tmp, how to verify that the change is taken into account

Posted 3 years ago #
gbulmer
Moderator

Bernardo769 - Good question. How about change the name of the file from wirish_time.h to xxx..xxx and see if your program compiles?

Posted 3 years ago #

Bernardo769
Member

good idea.
I renamed the file wirish_time.h in wirish_time.h.new
to compile, I get the message :
fatal error: wirish_time.h: No such file or directory
The change is well used.

/**
 * Returns time (in microseconds) since the beginning of program
 * execution.  On overflow, restarts at 0.
 * @see millis()
 */
static inline uint32 micros(void) {
    uint32 ms;
    uint32 cycle_cnt;
    uint32 res;

    do {
        ms = millis();
        cycle_cnt = systick_get_count();
    } while (ms != millis());

    /* SYSTICK_RELOAD_VAL is 1 less than the number of cycles it
       actually takes to complete a SysTick reload */
    res = (ms * US_PER_MS) +
        (SYSTICK_RELOAD_VAL + 1 - cycle_cnt) / CYCLES_PER_MICROSECOND;

    return res;
}

Posted 3 years ago #

ala42
Member

The systick IRQ has a low prio, lower that your IRQ handler, so the milli seconds counter is not updated, when the overflow occurs in your IRQ handler.
Add #include "nvic.h" and use this micros function:

static inline uint32 micros(void) {
    uint32 ms;
    uint32 cycle_cnt;
    uint32 res;

    do {
        ms = millis();
        cycle_cnt = systick_get_count();
    } while (ms != millis());

    if(systick_check_underflow()) {
    	ms++;
    	cycle_cnt = systick_get_count();
    }

    /* SYSTICK_RELOAD_VAL is 1 less than the number of cycles it
       actually takes to complete a SysTick reload */
    res = (ms * US_PER_MS) +
        (SYSTICK_RELOAD_VAL + 1 - cycle_cnt) / CYCLES_PER_MICROSECOND;

    return res;
}

Posted 3 years ago #

Bernardo769
Member

Despite all the proposed changes, I still worry.

In summary of the changes:

Sketch :

#include "voieRC.h"
#include <Servo.h>
#include "nvic.h"

#define Serial SerialUSB

#define pinVoieGAZ 20
voieRC voieGAZ(pinVoieGAZ);

#define PoloDigi4 26
Servo myservo;

void setup() {
  attachInterrupt(pinVoieGAZ, interruptRC_GAZ, CHANGE);
  // Servo :
  myservo.attach(PoloDigi4);
}

void loop() {
  //SerialUSB.println(voieGAZ.valeur());
  myservo.writeMicroseconds(constrain(voieGAZ.valeur(), SERVO_DEFAULT_MIN_PW, SERVO_DEFAULT_MAX_PW));  // OK
  //delay(50);
}

void interruptRC_GAZ(void) {
  voieGAZ.etat();
}

void voieRC::etat() {
  //noInterrupts();
  if (digitalRead(this->pinRC) == HIGH) {  // Front montant
    timeUP = micros();
    timeDOWN = timeUP;
  }
  else {  // Front descendant
    timeDOWN = micros();
    lastValidValue = timeDOWN - timeUP;
  }
  //interrupts();
}

wirish_time.h :

static inline uint32 micros(void) {
    uint32 ms;
    uint32 cycle_cnt;
    uint32 res;

    do {
        ms = millis();
        cycle_cnt = systick_get_count();
    } while (ms != millis());

    if(systick_check_underflow()) {
    	ms++;
    	cycle_cnt = systick_get_count();
    }

    /* SYSTICK_RELOAD_VAL is 1 less than the number of cycles it
       actually takes to complete a SysTick reload */
    res = (ms * US_PER_MS) +
        (SYSTICK_RELOAD_VAL + 1 - cycle_cnt) / CYCLES_PER_MICROSECOND;

    return res;
}

All ideas are property came...

Posted 3 years ago #

gbulmer
Moderator

ala42 - I think it is possible for SysTick to fire after the calculation of millis in while (ms != millis());, but before if(systick_check_underflow()) gets to check the value, so it is just possible that this will also give the wrong value very occasionally.

AFAIK, SysTick priority can be changed, though I have never tried to do that.

So it might be simpler to raise the SysTick priority above the interrupt service routine; simpler in the sense that micros() and millis() would work without extra checking.

Posted 3 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.