I am testing some stuff on an LPC 1768 using mbed OS 5 and mbed-rtos library.

I find that all the non-blocking waits seem to run really slowly? To recreate, just run mbed os blinky LED hello world?

1. With Thread::wait(500) the blinky takes longer than 1 second to cycle more like 3-5x that? and Thread::wait gives deprecation warnings.

2. With ThisThread:;sleep_for(500) similar results but no deprecation warnings.

3. If I create uint64_t now; and try to do ThisThread::sleep_until(now+500) it gives similar results.

In general the deprecated Thread::wait() and usage for sleep_for and sleep_until appear to be undocumented for mbed OS 5???

Follow up: even wait(0.5) seems to run slow?

'''C

1. include "mbed.h"
2. include "rtos.h"

DigitalOut led1(LED1);

main() runs in its own thread in the OS int main() { while (true) { led1 = !led1; wait(0.5); Thread::wait(500); ThisThread::sleep_for(500); } } '''

Problem does NOT occur in OS 2. On the LPC1768 I am testing, when I run OS 2 blinky the light flashes with 1 second period using wait(0.5).

In mbed OS 5 all the waits seems to run slow? wait(0.5) Thread::wait(500) ThisThread::sleep_for(500) ThisThread::sleep_until(now+500)

Expected behavior: Should flash with 1 second period like OS 2 blinky. Observed behavior: Flashes with more like 3-5x longer period. Steps to replicate: Try mbed OS 2 blinky on LPC1768, then try OS 5 blinky using wait() or swap out for other non-blocking waits including deprecated Thread::wait() - it also throws many warnings during compilation at the line to #include "rtos.h"

Hello Dennis,

A firmware update might fix it.

I just had this same issue. Unfortunately, I lost quite a bit of time before finding this page. Of several LPC1768's I have, the one I just programmed was still running firmware rev 16457 instead of rev 141212 (the latest).

Timed in my head, the "mbed-os-example-blinky" wait(0.5) was acting like wait(5.0) - about 10 times slower. I'm not going to stand firm on my next statement - I think it was only slow when using mbed OS 5, and ran correctly under mbed OS 2.

I had thought the generated binaries were not dependent on the underlying interface chip that this firmware goes into, except where semi-hosting APIs were involved? Is there an explanation for what happens, and could you add a nice bright warning to the Firmware LPC1768 LPC11U24 page?