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

Comments

Projects
None yet
5 participants
@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

This comment has been minimized.

Copy link
Member

ciarmcom commented Nov 28, 2018

@kjbracey-arm

This comment has been minimized.

Copy link
Contributor

kjbracey-arm commented Nov 29, 2018

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).

@loverdeg-ep

This comment has been minimized.

Copy link
Contributor

loverdeg-ep commented Feb 12, 2019

@kegilbert

This comment has been minimized.

Copy link
Contributor

kegilbert commented Feb 22, 2019

@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
You can’t perform that action at this time.