Skip to content

Make wait_for_idle work for everyone, with busy loop or sleep loop#125

Merged
caemor merged 4 commits intorust-embedded-community:mainfrom
peckpeck:idle_loop
Dec 3, 2022
Merged

Make wait_for_idle work for everyone, with busy loop or sleep loop#125
caemor merged 4 commits intorust-embedded-community:mainfrom
peckpeck:idle_loop

Conversation

@peckpeck
Copy link
Copy Markdown
Contributor

@peckpeck peckpeck commented Nov 7, 2022

The delay structure is missing in many places where wait_until_idle is needed, so i added it everywhere.

Moreover, the default is to busy loop, but it can be very interesting on microcontrolers to sleep instead, either to save energy or to give time to another task. Especially with large displays where the refresh time can take several seconds. So I made the sleep time a parameter the user can control.

I also made wait_until_idle public, because, even if methods call it when it is mandatory, the user can still want to call it to make sure last data has been processed before going on.

@mangelajo
Copy link
Copy Markdown
Contributor

+1 to this change.

I am having issues under the esp32 platform with std, running the display inside a thread I get errors from the underlying FreeRTOS because of the busy loop:

I (317323) esp-x509-crt-bundle: Certificate validated
Display: 
Display: 31  PLAZA MAYOR     1m 29s
Display: 31  PLAZA MAYOR     1m 29s
Display: 39  PLAZA ESPAÑA    3m 42s
Display: 65  BENAVENTE       4m 50s
Display: 36  ATOCHA          10m 41s
Display: 39  PLAZA ESPAÑA    12m 08s
Display: 65  BENAVENTE       13m 41s
Display: 33  PRINCIPE PIO    17m 34s
Display: 36  ATOCHA          19m 53s
Display: 33  PRINCIPE PIO          
Display: *
E (325323) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (325323) task_wdt:  - IDLE (CPU 0)
E (325323) task_wdt: Tasks currently running:
E (325323) task_wdt: CPU 0: pthread
E (325323) task_wdt: CPU 1: IDLE
E (325323) task_wdt: Print CPU 0 (current core) backtrace


Backtrace: 0x42098712:0x3FC989A0 0x4037982D:0x3FC989C0 0x42015145:0x3FCEE0B0 0x4201516E:0x3FCEE0D0 0x42007B60:0x3FCEE0F0 0x4200AB32:0x3FCEE120 0x4200AC56:0x3FCEE140 0x4200749B:0x3FCEE160 0x4200863B:0x3FCEE250 0x420085FF:0x3FCEE290 0x4200B1AF:0x3FCEE2D0 0x4200A294:0x3FCEE310 0x4206127F:0x3FCEE350 0x420612A6:0x3FCEE370 0x4205A050:0x3FCEE390 0x42077B04:0x3FCEE3B0

E (325323) task_wdt: Print CPU 1 backtrace

I was looking into fixing it, but I see you handled it already, thanks.

// - it is faster to not have it
// - it is complicated to pass the delay everywhere all the time
// - busy waiting can consume more power that delaying
// - delay waiting enables task switching on realtime OS
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exactly what I need!, thanks

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Be careful, on esp32 you have to use delay::FreeRtos and not delay::Ets and a minimum delay_ms on 10, to make sure there is a task switch

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, thanks, I knew and tried delay::FreeRtos, but didn't know about the 10ms limitation.

Copy link
Copy Markdown
Collaborator

@caemor caemor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the new change, but currently a few displays define their own wait_until_idle without using the given delay_ms. It would great to use it there as well and the case delay_ms is None fall back to a sensible constant (the current delay)

Copy link
Copy Markdown
Collaborator

@caemor caemor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the great work.
Do you think it would make sense to include the DelayUS update in here as well?

@peckpeck
Copy link
Copy Markdown
Contributor Author

Fixing DelayUs touches a lot of files, I think it would be more readable in a separate PR.

PR updated

@caemor caemor merged commit d6c44d5 into rust-embedded-community:main Dec 3, 2022
@caemor caemor mentioned this pull request Dec 7, 2022
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

Successfully merging this pull request may close these issues.

3 participants