Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document EventFlags wait function timeout units #8894

Closed
sarahmarshy opened this issue Nov 28, 2018 · 4 comments
Closed

Document EventFlags wait function timeout units #8894

sarahmarshy opened this issue Nov 28, 2018 · 4 comments

Comments

@sarahmarshy
Copy link
Contributor

sarahmarshy commented Nov 28, 2018

Description

The EventFlags class does not specify a unit of time for its timeout.

I tried to follow the callstack, but I didn't find the units for this timeout.

Issue request type

[ ] Question
[ X] Enhancement
[ ] Bug
@sarahmarshy sarahmarshy changed the title EventFlags wait timeout units Document EventFlags wait function timeout units Nov 28, 2018
@ciarmcom
Copy link
Member

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-203

@kjbracey
Copy link
Contributor

Possible that this carries through a lot of stuff - many descriptions in the rtos namespace including that are cut-and-paste from CMSIS-RTOS documentation following that form.

Basic rule is that every time specified in the rtos namespace is in CMSIS-RTOS "ticks", which CMSIS-RTOS never defines itself. But for Mbed OS we have specified that the RTOS tick is a millisecond (see Kernel::get_ms_count()).

I see some things like ThisThread::flags_wait_all_for have the same wording, but changed the variable name to millisec, which seems like it might do?

Also, the fact that it's "ticks" is also significant - waiting for 5 ticks will take 4.000 to 5.000 milliseconds, depending on phase relative to the next tick. It doesn't aim for precisely 5 millisecond duration (unlike wait_us(5000).

@0Grit
Copy link

0Grit commented Feb 12, 2019

#9077

@kegilbert
Copy link
Contributor

@sarahmarshy #9670

The above PR should have addressed this, let me know if you have remaining concerns for this issue! Otherwise it should be good to close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants