Closed 8bitbunny closed 6 years ago
If frit as wants to implement there may be a better way. In the new teensduino there is the a event api that has a hook for threads. Was looking at trying but got lost on how to link the two libs. This is just info.
Mike
It's an interesting approach. You could try something simpler: call the ARM instruction "WFI", which puts the system into a basic sleep until the next interrupt. So when you are done with your computing in a thread, instead of calling 'yield();' and giving your time to the next thread, you can call '__asm volatile("wfi");' and the system will sleep until the next interrupt wakes it.
The wfi rubs at every millis() interrupt, thus wakes every 1ms, giving higher power draw in idle, as it sleeps 1ms max each time
Typo correct: Rubs = runs
Think using the event api would allow u ou to essentially suspend the thread till the next event. Know it sound counterintuitive but it allows you to do other things while waiting for the next interrupt or timer. Avoids putting the teensy to sleep and avoids the wfi interrupt from triggering ever ms.
right now i have a example programmed in, and it works rather good, uploading a video of it in combination with Snooze, i'll post a link to it in here, and will create a pull request asap do you want the changelog in here for evaluation, or in the pull request itself?
ramonschepers, i've been following this thread and I'm interested in the results. Waiting on the video 👍
thnx, it wasn't that hard to accomplish to be honest, no api stuff has changed, just 2 public api functions added, as well as an example in combination with the snooze library.
only limitation is that you do need a
extern void enter_sleep(int ms)
in your ino file,
int ms is sleeping time requested, and you need to shape this function to your sleep mode yourself.
i got the idea from the freertos port with low power features, and wanted something similar ready to use with teensy threads (preferably on a T3.6) without losing arduino ide compability.
video is at around 80%, and when completed i will post again and do the pull request.
https://www.youtube.com/watch?v=aJeI3Zm7V_A silly youtube put the video upside down :(
will close this issue now and put up a pull request
i don't know if i actually suggested it earlier (at least i dreamt of a possible solution!)
sleep the mcu by your own function till next task calls (for example: using the Snooze lib) though this might look like a rtos feature, it turns out it isn't hard to implement at all if done right.
needed info: a struct for each thread containing: next execution time
on a delay call, the next execution time is stored and state is set to suspended, followed by a yield (instead of calling yield multiple times in a loop)
the the main loop: there is a function call which simply checks next execution times, and sleeps till the next one occurs, after sleep, the remaining time on each thread is reduced by sleep time, if a thread has hit 0, then set it's state to run followed by another yield.
noe that i have only dreamt of this, and i don't foresee much issues implementing this, though this can increase one's battery life on a teensy by alot. :D
what do you think?