Report
2 years, 2 months ago.

Strange behavior

With this new release, I encountered strange behaviors below. Both can be compiled and behaved as expected by using previous releases.

1) wait(float s) statement it looks that this statement really waits for 10 times more time than expected "s" seconds. For example, wait(5.0) seems wait for 50 seconds.

"wait_ms" also behaves same as "wait".

2) const float PI = 3.14; This declaration causes compilation error. Below error message is output. Expected an identifier in "I = 3.14;"

Question relating to:

I'm using LPC1768 board.

For wait(5.0) I've got new results, though they are the same as before.

mbed OS 5.5.1 -> elapsed time = 50011300 mbed OS 5.4.7 -> elapsed time = 5001406

Is there anything wrong with my use of "wait"? I wonder we should not use wait function.

posted by Misao Miyata 08 Jul 2017
Comment on this question

2 Answers

2 years, 2 months ago.

I've tested that on mbed OS master:

    uint32_t start = us_ticker_read();

    wait(5.0);

    printf("Time: %u\n\r", us_ticker_read() - start);

I'm getting Time: 5000000 and it actually takes around 5 seconds using a stopwatch.

As to 2, that's because of arm_math.h which is included by default for mbed OS (due to IAR limitation and CLZ intrinsic), defining:

  1. define PI 3.14159265358979f so if you try defining variable of that name it's not going to work. I agree the name is unfortunet, it should use some sort of prefix (like M_PI is using). Hope that helps, Bartek

Thank you for your reply.

I think the essential problem is that "wait function" behaves differently under different OS releases. I've run below code under two OS releases.

pc.printf("mbed OS: %d.%d.%d Release\n", MBED_MAJOR_VERSION, MBED_MINOR_VERSION, MBED_PATCH_VERSION); uint32_t start = us_time.read_us(); wait_ms(5); pc.printf("Elapsed time = %u\n", us_time.read_us());

The results are: (1) mbed OS: 5.5.1 Release Elapsed time = 61293

(2) mbed OS: 5.4.7 Release Elapsed time = 6471

Under previous OS release, I can get expected result. But "wait function" seems to wait about ten times longer time than it should .

Also, as to "define PI = 3.14.....", it's OK under previous OS Release but not under latest release.

posted by Misao Miyata 01 Jul 2017

For wait(5.0):

[1499078932.42][CONN][RXD] mbed OS 5.4.7 -> Time: 5000001 [1499078824.06][CONN][RXD] mbed OS 5.5.1 -> Time: 5000001

I'm getting correct results for both mbed OS releases. Which board are you using?

posted by Bartosz Szatkowski 03 Jul 2017
2 years, 2 months ago.

I though it *was once* the case that the global wait performed a spinning wait (running state) and that Thread::wait became the recommended API.

Looking at the source, then it seems sub ms delays are spinning and larger delays use Thread::wait

https://github.com/ARMmbed/mbed-os/blob/master/platform/mbed_wait_api_rtos.cpp

Have you tried waiting for less than 1ms?

Thank you for your comment.

I've tried 50 us wait under two different os releases( 5.5.1 and 5.4.7). Both results are almost same, 1465 us and 1458 us respectively.

I know that we should not expect excess resolution for wait function.

posted by Misao Miyata 01 Jul 2017

You need to log in to post a question