Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
6 years, 4 months ago.
I'm dipping my toes into mbed-os-5
I've run the blinky demo for mbed-os-5.
Question1: the wait call is "wait(0.5)" but the led changes state every 5 seconds. If it change it to 0.1, it changes state every second. Looks like the delay amount is off by a factor of 10. What's up here?
Question 2: mbed-os-2 documentation says "wait()" is a simple hang whereas if you're running a thread "thread::wait can be used to allow other tasks to run while waiting. Which 'wait' is being invoked in the example?
Question 3: In the mbed-os-5 reference section, no mention is made of a wait that takes a float argument. Is there a 'float' version for mbed-os-5? I'm wondering since question 1 suggests that it isn't working properly.
1 Answer
6 years, 3 months ago.
1. I'm not sure why it would be 10x longer. Yes, it is supposed to be the time in seconds. You could try calling Thread::wait() directly instead. The time for that function is an integer and given in milliseconds rather than seconds. I did have trouble at one point with timing due to a sleep function the rtos was calling. The problem was in function hal_sleep() inside sleep.c, which is vendor specific. My target was an STM32 part and the problem was the attempt to suspend and resume the HAL tick.
Could be a clock issue. You could try printing the system clock to see if it is as expected.
printf("clock = %d",SystemCoreClock);
You could roll back the mbed-os source to an older version and try that. Maybe there was a timing bug introduced at some point.
2 and 3. Pretty sure that wait is mbed_wait_api.h
But the implementation is different depending on if you enable RTOS in the build. RTOS version tries to call Thread::wait to release control to scheduler but the no RTOS version seems to just spin in a while loop until the time expires.
Should I take my toes out of mbed-os-5 since something as fundamental as the wait function and perhaps the underlying system clock isn't working properly? I'm using the lpc1768.
In mbed-os-5, how do you enable RTOS? I thought mbed-os-5 had RTOS always running (the main program is run as a task). I'm using the online compiler, not CLI.
posted by 28 Dec 2017I use mbed-os 5 and it has been fine. But sometimes you do have to dig in and troubleshoot things. I believe the rtos is enabled by default. My comment was being directed at the mbed_wait_api_rtos.cpp which has this conditional compilation, #ifdef MBED_CONF_RTOS_PRESENT. As a debugging step you might want to check that your call is in fact hitting the wait function you expect. I would do this offline with a breakpoint. Online you could import the mbed-os source, add printfs to the wait calls and confirm you are hitting the one you think.
I would try rolling back mbed-os version as well just to check. Very easy to do. In your project, right click on mbed-os, select Revisions, pick an older revision and hit the switch button.
posted by 28 Dec 2017Did you notice that in wait_us in https://github.com/ARMmbed/mbed-os/blob/cd8e9e6aafeff800c0c33b452072fcbebdeb41a8/platform/mbed_wait_api_rtos.cpp, the " Use busy waiting " code is always executed. Seems to me an "else" is missing.
posted by 28 Dec 2017I have not studied this code in detail. But it looks like this is intentional. The delay time would be the same without the if block, that block just politely cedes control to the scheduler if the wait time is longer than 1 ms. When the scheduler returns here the us ticker should be close to expiring.
posted by 28 Dec 2017
Which board are you using? There are boards that actually do not have a user LED; but some LEDs that just live their own life (like the Realtek RTL8195AM).
posted by Janne Kiiskilä 28 Dec 2017