search

emfcamp / TiDAL-Firmware

26 stars 14 forks source link

#5: PoC for uasyncio based app switching #17

Closed MatthewWilkes closed 2 years ago

MatthewWilkes commented 2 years ago

@tomsci What do you think of this app API?

tomsci commented 2 years ago

I wonder if the boot menu is the right thing to try and app-ify. I think it benefits from being kept as simple as possible, on the basis that it can act as the fallback option if there's a bug somewhere else that crashes the board.

I envisaged the boot menu as something that eventually sits below the level of apps and the app launcher (when we get round to having a proper one of those...) and by default the board would boot straight into the graphical app launcher, and you'd access the boot menu via holding down B during power on, or something like that. That way a bork in the graphical launcher would still allow the board to be recovered OTA (assuming "Update OTA" is something we add to the boot menu - @jbmorley and I plan to look at that soon).

So I'm hesitant for that reason to add what appears to be quite a bit of code to the critical boot path of the board. It's also because I'm not familiar with uasyncio nor async programming in Python in general :) That said, I think the task sharing stuff from uasyncio makes sense for the higher level apps to adopt, and to have a App base class. But I'll probably have to read up some more on exactly how uasyncio works to be able to have a worthwhile opinion on that.

Also, app.py appears to be absent from the PR?

MatthewWilkes commented 2 years ago

@tomsci Added app.py

Yeah, the boot menu description makes sense to me, maybe treat this as a view on how the graphical launcher would work, and we can keep a simple boot menu for emergencies.

MatthewWilkes commented 2 years ago

@tomsci I've extended the current apps to follow this pattern, created a distinction between boot menu and a new launcher, and added in switching out of the task. I also changed many things to class-based code rather than module globals, including buttons to reduce cross-app impact.

I know this is more complex an app interface than import-time side-effects or a single main() function, but I really like the idea of simplifying the interface especially around wake/sleep, given the desire to drop to sleep mode a lot.

MatthewWilkes commented 2 years ago

I've unmarked this as draft, I'd be happy for this to be merged if others agree.