What’s a clean way to share state between screens on a small device?

For a project this size, a single state structure may be enough. Keep the timer settings and other shared data in it, then have update and display functions take a reference to that structure. It makes ownership and changes easy to see, without adding a class for every piece.

The screen choice can still be represented explicitly. A small enum and a switch may be simpler than a full State pattern if the screens mostly differ in what they display and which buttons they handle.

Your central object can work well, especially if it owns the hardware utilities and the current settings. I’d avoid giving every screen unrestricted access to everything, though. Pass only the dependencies each screen actually needs, or expose a smaller interface for the operations it should perform.

There isn’t one universally best structure here. If the State pattern makes transitions and screen-specific behavior clearer, it’s a reasonable choice. If it mostly adds indirection, a simpler state structure and functions are easier to maintain.

Since the hardware gets initialized once, keep those instances at the application level rather than recreating them when screens change. Settings can live alongside them in a shared application state. Then make screen transitions change the active screen, not the lifetime of the timer or button-reading utilities.

Pre-creating a fixed set of screens can be perfectly practical on a device with predictable memory use. If that starts to make dependencies or setup awkward, you can revisit how screens are constructed later.