Inaccurate delay and Blink doesn't work

LeafLabs Garden » Support » Maple Hardware Support

Inaccurate delay and Blink doesn't work

(10 posts) (3 voices)

Started 1 year ago by dbolgheroni
Latest reply from bobc

dbolgheroni
Member
Hi,

I'm using the CLI Unix toolchain on Linux to develop for a Maple Mini board I have. But I'm running into various strange problems.

1) using a toggleLED(), the delay is not accurate. For example, when set to 1000 ms, it take approximately 10x as much, or 10 seconds;
2) using Serial1.begin() or Serial2.begin(), even if after this I doesn't touch in code related to serial again, the LED doesn't blink. If I reset the board, it may or may not blink 2 or 3 times, but after this it stops.

I'm compiling with

$ BOARD=maple_mini make

and the code is the simpliest:
```
#include <wirish/wirish.h>

void setup() {
    // Set up the built-in LED pin as an output:
    pinMode(BOARD_LED_PIN, OUTPUT);

    Serial1.begin(9600);
}

void loop() {
    toggleLED();
    delay(100);
}

int main(void) {
    setup();

    while (true) {
        loop();
    }

    return 0;
}
```
Any hints?
Thank you.
Posted 1 year ago #
gbulmer
Moderator

Are you able to try the same program using the Maple IDE, and without your main()? If so, are the results all the same?

Have you access to an oscilloscope? You could try setting a PWM value for 50:50 mark space ratio with a cycle of 1ms, and see if that looks correct.

Posted 1 year ago #
dbolgheroni
Member

Are you able to try the same program using the Maple IDE, and without your main()? If so, are the results all the same?

I fail to see why the main() routine would cause the problem, but no. I can run the IDE, since it's where I got the Blink and added main(), but I have problems uploading to the board with it ("Reset via USB Serial Failed!", "Couldn't find the DFU device: [1EAF:0003]", etc.). It works without a problem via CLI, though, using the toolchain indicated in the LeafLabs site.

What about the Serial1.begin() problem? I think it's more critical. If I use somewhere in the code, the LED doesn't blink or it blinks 2 or 3 times after the program code is run (I know the difference between bootloader blinks and the program itself blinks). Doesn't blink even with the inaccurate delay I mentioned earlier. How this can be related to Serial is another thing that's bugging me now.

Have you access to an oscilloscope? You could try setting a PWM value for 50:50 mark space ratio with a cycle of 1ms, and see if that looks correct.

No.

Thank you very much.

Posted 1 year ago #
gbulmer
Moderator

The reason I asked you to upload without your main() is the traditional Maple main() has a call to an init function which initialised the peripherals. For example that initialisation uses the external crystal as a clock source, rather than the internal (on chip) RC oscillator. Also it initialises other peripherals, and sets the speeds and dividers for the clock signals. Hence using that is likely to fix your timing problem.

So all the symptoms may be corrected by using a different main().

If you look through the source of the libmaple library code, and especially the Maple mini main(), you should be able to track down the appropriate code.

Edit:
You could call init() directly form your main(), before calling setup().

Posted 1 year ago #

bobc
Member

gbulmer is right, you need to ensure init() is called.

Here is a sample from latest libmaple

// Blinks the built-in LED

#include <wirish/wirish.h>

void setup() {
    pinMode(BOARD_LED_PIN, OUTPUT);
}

void loop() {
    togglePin(BOARD_LED_PIN);
    delay(100);
}

__attribute__((constructor)) void premain() {
    init();
}

int main(void) {
    setup();

    while (true) {
        loop();
    }
    return 0;
}

Posted 1 year ago #

gbulmer
Moderator
If dbolgheroni is able to compile their program, it is probably better not to use:
```
__attribute__((constructor)) void premain() {
    init();
}
```
and just call init() directly at the start of main().
Posted 1 year ago #
bobc
Member

Hmm, not sure I would recommend that.

I've run into some problems with the libmaple startup code, the use of a constructor to initialise the hardware is not a reliable way to do it. The order of constructor execution is not defined (this is a general C++ problem).

It's possible that static constructors are called before the hardware is initialised, which is obviously bad. Really, standard practice is to explicitly call the hardware init function before __libc_init_array() is called.

Posted 1 year ago #
gbulmer
Moderator

"I've run into some problems with the libmaple startup code"
I haven't.

"the use of a constructor to initialise the hardware is not a reliable way to do it"
This is only an issue if there are dependencies between constructors which is not handled correctly in the code. When there is only one initialisation function it can't create a problem, unless the code itself contains a bug. If that were the case, it would be consistently wrong.

"The order of constructor execution is not defined (this is a general C++ problem)."
True, but in this specific case, only *one* initialisation function, that is irrelevant.

"It's possible that static constructors are called before the hardware is initialised"
What do you mean? I believe the init() function called by the static constructor *is doing* the hardware initialisation. How do you propose to call init() before __libc_init_array()?

(Full disclosure: I am not a member of LeafLabs staff.)

Posted 1 year ago #
dbolgheroni
Member

Apparently it's working OK with both solutions.

Thank you.

Posted 1 year ago #
bobc
Member

How do you propose to call init() before __libc_init_array()?

By changing start_c.c, obviously!

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.