Ideas for redesign of badge software for next year

[smcameron]

Here are some ideas for redesigning the badge software for next year to perhaps escape some of the pain of the current system (or at least exchange it for a different pain.)

The current badge-main/menu system IMHO tries to do to much (has slowly evolved over time to do too much.) It does at least the following:

1. Acts as a menu system.
2. Acts as kind of "init" process controlling execution of various apps
3. Acts as device driver for USB, infrared, etc.
4. Acts as screen saver (the current code suffers greatly from complexity in this area.)
5. Is pressed into service as the "schedule" app.
6. Is pressed into service as the "settings" app.

I propose the new system should have the following properties:

1. There should be an "init" process (roughly speaking) that controls execution of the "apps" and handles USB, infrared, etc. (much as the current system.) This part should be kept as simple as possible.
2. The main menu should be just an app, not a part of this "init" process.
3. The schedule should be just an app.
4. The screen saver should be just an app.
5. "Settings" should just be an app.
6. There should be a mechanism for a "stack" of apps, with the topmost app running. The would allow, e.g. the "init" system to "push" the screensaver "on top of" a running app, and on exiting, the screensaver could be popped off, restoring the previously running app. The menu app could work by pushing apps on top of itself, and when apps "exit", they pop off, leaving the menu app running.

[warasilapm]

There are some good ideas here. I especially like the "stack" of apps idea for it's simplicity, though it may make background behavior more challenging. The menu system should probably be kept as a generic tool that can be used to build apps, but I agree that it shouldn't be as directly tied to the main menu as it has been before.

There's lots to look at architecturally going forwards into a future badge.

[smcameron]

The menu system should probably be kept as a generic tool that can be used to build apps

I might kinda sorta disagree with this, depending on what you mean.

I say the main menu should be "just an app", so that it would be possible to have two or more, completely different menu apps and any of them could be chosen at run time as "the main menu". So there should be nothing special about the main menu app, and it should be free to use whatever weirdo ideas it wants to present its idea of a menu to the user.

Now, it could be possible that these menu apps use some kind of generic menu library that other apps could also use -- that'd be fine.

[smcameron]

Or, another way to put it, we should be free to completely change the look/implementation of the main menu every year without breaking any apps.

This year is an example of that failing to be true. The new menu style needed to also preserve the old menu behavior, because too many "apps" relied on it (e.g. schedule).

[warasilapm]

I think we're on the same page; I'd imagine that apps may want to use a "menu" and having a generic/extensible menu system has clearly let it see a lot of reuse (even if it maybe should not have been). Then the apps can be built on top of that and perhaps have a "renderer" that can be swapped out for different looks, animations, etc.

[paulbruggeman]

Its time to change to FreeTOS or similar if these will be real 'apps'. Margan got it working in 2017(??), but it just added complexity to the main loop ProcessIO system without any real benefits so we ditched it the next year.

…

On Fri, May 31, 2024 10:03:18AM -0700, smcameron wrote: Or, another way to put it, we should be free to completely change the look/implementation of the main menu every year *without breaking any apps*. This year is an example of that failing to be true. The new menu style needed to also preserve the old menu behavior, because too many "apps" relied on it (e.g. schedule). -- Reply to this email directly or view it on GitHub: #13 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[warasilapm]

An RTOS isn't strictly necessary, and at least for the apps themselves adds a lot of complexity and understanding about mutual exclusion etc. that currently we currently sidestep by only allowing one thing to run at a time. An approach like the app stack Steve proposed may be sufficient.

On the other hand, an RTOS provides a much more powerful toolset that can be very helpful in managing the hardware drivers. It's not something I'm strictly opposed to. I've just been hesitant to increase the barrier to entry, add more complexity for Steve, and and up needing to trash a good portion of our code base. That said, if we're going to start over anyways... maybe it's not such a big deal after all.

I've used FreeRTOS and ZephyrOS at work and I'm familiar with embassy-rs (though I have yet to use it on one of my own projects at work or personally. FreeRTOS is a glorified scheduler and takes a lot of work to integrate your application into, but that's sort of its power. ZephyrOS is a much more involved tool, but provides a very good driver model, tons of out of the box platform support (at least across arm's product stack), and borrows heavily from the linux kernel code style and build tool set so it may be more familiar to work with. embassy-rs is rust and has much more limited platform support (though the RP2040 is supported out of the box). Rust is a big adjustment for us, but it is shaping up to be an embedded language of the future. It may be a good way to attract the younger generation of programmers who are scared off by C.

If we needed to commit to a platform change today, I'd say ZephyrOS. It's main upside is that it's so portable we can probably build the "simulator" as QEMU with peripheral mocking; the main downside is that the learning curve is very steep and it will frustrate the old guard especially.

[smcameron]

Its time to change to FreeTOS or similar if these will be real 'apps'.

FWIW, I was not suggesting anything that drastic. They would not be "real" apps (whatever that means). I was merely suggesting decoupling the screensaver, the schedule, and the menu system and simplifying the main loop code by cramming more stuff into the so-called "apps".

The current system is actually pretty nice, for the most part. Esp. the simulator makes app development easy (some rough edges, esp. around audio and new sensors, etc., but for buttons and the display, it's pretty nice, and not something to toss away without a thought, which such a drastic change would entail.) There are a few pain points with the current system, and this proposal is only meant to address one of them.

I'm not against moving to FreeRTOS, (or zephyr, or whatever), but realize doing so means ditching the simulator (or writing a new one, or Frankensteining a new one from the corpse of the current one.) Adding a proper OS to the system makes the simulator a lot harder, or perhaps we move back to something like the simulator used to be -- only emulating the app API, simulating one app at a time, not the whole badge firmware, which is a pretty big step backwards.

OTOH, despite the simulator making app development easy, still, nobody does it but me and Peter, so maybe it doesn't even matter. But maybe that's just a failure on our part to produce badge development propaganda to get people onboard like Hal's hotdog roller propaganda.

[smcameron]

Rust is a big adjustment for us, but it is shaping up to be an embedded language of the future. It may be a good way to attract the younger generation of programmers who are scared off by C.

Get your army of young'uns lined up first, because I'm out.

Edit: Also, isn't it the case that the main problem that Rust sets out to solve has to do with object lifetimes and management of dynamic memory allocations? We don't even do dynamic memory allocation at all. We already don't have the main class of bugs that Rust tries to eliminate. I might be wrong, but I don't think Rust programmers are especially common, just especially noisy.

[warasilapm]

Get your army of young'uns lined up first, because I'm out.

Edit: Also, isn't it the case that the main problem that Rust sets out to solve has to do with object lifetimes and management of dynamic memory allocations? We don't even do dynamic memory allocation at all. We already don't have the main class of bugs that Rust tries to eliminate. I might be wrong, but I don't think Rust programmers are especially common, just especially noisy.

Well it's good to know where you stand on that. :)

Rust programmers aren't all that common, but I do know that most of the "programmers" at hack I've spoken to have dabbled in it at least once. It's something new to learn, and it can be hard to find a project to use to learn a new language. I just think it might be more motivating to attract people than C which people seem equally intimidated by but less interested/willing to learn.

The original big marketing point of Rust was memory safety but I think that may have been a marketing misstep that overshadows some of it's more nuanced points - but those are much harder to persuade a manager or bean counter with. Rust has a large number of language features that are more advanced than C without being quite as fraught with danger as C++. Some of these stem from the increased information that the compiler has about the code to better guard against memory safety but others are just the result of another 20+ years of computer science research and compiler development over those languages. I think my top favorite features are probably tagged unions and the match statements that are a grown up version of manually doing that switch statements with enums in C as well as the trait system.

None of this is to persuade you that Rust is the right choice for badge. I think it'd be much easier for us to move to Zephyr than re-do everything in Rust, personally.

[paulbruggeman]

When we switched before the main reason was the peripherals it supported- flash disk, WIFI, ETH etc. The PICO lib supports this so... meh. The killer was memory management weirdness. There is so much more ram and flash now these reasons don't really exist. One big plus was gdb chip support, though I never got to use it.

…

On Sun, Jun 02, 2024 08:41:59PM -0700, smcameron wrote: > Its time to change to FreeTOS or similar if these will be real 'apps'. FWIW, I was not suggesting anything that drastic. They would not be "real" apps (whatever that means). I was merely suggesting decoupling the screensaver, the schedule, and the menu system and simplifying the main loop code by cramming more stuff into the so-called "apps". The current system is actually pretty nice, for the most part. Esp. the simulator makes app development easy (some rough edges, esp. around audio and new sensors, etc., but for buttons and the display, it's pretty nice, and not something to toss away without a thought, which such a drastic change would entail.) There are a few pain points with the current system, and this proposal is only meant to address one of them. I'm not against moving to FreeRTOS, (or zephyr, or whatever), but realize doing so means ditching the simulator (or writing a new one, or Frankensteining a new one from the corpse of the current one.) OTOH, despite the simulator making app development easy, still, nobody does it but me and Peter, so maybe it doesn't even matter. -- Reply to this email directly or view it on GitHub: #13 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[smcameron]

FWIW, I spent the day playing around with my idea for a stack of apps...

I pushed my attempt to the branch "grand-simplification-theory-POC"

The horror of menu.c is dead, replaced with apps/default_menu_app.c.

badge.c is quite a bit simpler now.

Pretty much everything works... maybe some breakage around "dormant" power saving stuff though.

$ git diff main grand-simplification-theory-POC | diffstat
 apps/CMakeLists.txt                          |    2 
 apps/aagunner.c                              |    5 
 apps/aagunner.h                              |    3 
 apps/about_badge.c                           |    4 
 apps/about_badge.h                           |    2 
 apps/asteroids.c                             |    4 
 apps/asteroids.h                             |    2 
 apps/badge-app-template.c                    |    6 
 apps/badge-app-template.h                    |    2 
 apps/badgey.c                                |    4 
 apps/badgey.h                                |    2 
 apps/battlezone.c                            |    4 
 apps/battlezone.h                            |    2 
 apps/clue.c                                  |    4 
 apps/clue.h                                  |    2 
 apps/cube.c                                  |    2 
 apps/default_menu_app.c                      |  263 +++
 apps/default_menu_app.h                      |   20 
 apps/etch-a-sketch.c                         |    4 
 apps/etch-a-sketch.h                         |    2 
 apps/game_of_life.c                          |    4 
 apps/game_of_life.h                          |    2 
 apps/ghost-detector.c                        |    2 
 apps/gulag.c                                 |    4 
 apps/gulag.h                                 |    2 
 apps/hacking_simulator.c                     |    4 
 apps/hacking_simulator.h                     |    2 
 apps/image-test.c                            |    4 
 apps/image-test.h                            |    2 
 apps/lunarlander.c                           |    4 
 apps/lunarlander.h                           |    2 
 apps/magic-8-ball.c                          |    4 
 apps/magic-8-ball.h                          |    2 
 apps/maze.c                                  |    2 
 apps/moon-patrol.c                           |    4 
 apps/moon-patrol.h                           |    2 
 apps/new_badge_monsters/new_badge_monsters.c |    4 
 apps/new_badge_monsters/new_badge_monsters.h |    2 
 apps/pong.c                                  |    5 
 apps/pong.h                                  |    2 
 apps/qc.c                                    |    4 
 apps/qc.h                                    |    2 
 apps/rover_adventure.c                       |    4 
 apps/rover_adventure.h                       |    2 
 apps/rvasec_splash.c                         |    5 
 apps/rvasec_splash.h                         |    2 
 apps/sample_app.c                            |    2 
 apps/screensaver_app.c                       |   95 +
 apps/screensaver_app.h                       |    6 
 apps/slot_machine.c                          |    4 
 apps/slot_machine.h                          |    2 
 apps/smashout.c                              |    4 
 apps/smashout.h                              |    2 
 apps/spacetripper.c                          |    2 
 apps/tank-vs-tank.c                          |    5 
 apps/tank-vs-tank.h                          |    2 
 apps/test-screensavers.c                     |   11 
 apps/test-screensavers.h                     |    2 
 apps/test_flair_led.c                        |    2 
 apps/username.c                              |    4 
 apps/username.h                              |    2 
 core/badge.c                                 |  230 +--
 core/badge.h                                 |   16 
 core/dynmenu.c                               |   19 
 core/dynmenu.h                               |    1 
 core/menu.c                                  | 1014 ---------------
 core/menu.h                                  |   13 
 core/settings.c                              |  118 -
 core/settings.h                              |    2 
 69 files changed, 630 insertions(+), 1345 deletions(-)

Not to suggest we have to go down this path, I just couldn't resist trying it out.