pbio/sys: Add Build HAT HMI that starts the status light animation. - #499
pbio/sys: Add Build HAT HMI that starts the status light animation.#499davelongdev wants to merge 1 commit into
Conversation
|
We probably want to save We can start with a copy of |
|
Sounds good. Thanks. |
|
FYI, you can just force-push to this same branch to update the PR instead of creating a new one when you are ready. ( |
The Build HAT used the "none" HMI, which requested the REPL without first starting the status light animation, so the LED stayed off after boot even though the platform enables state animations with a green hue. Rather than change hmi_none.c, which should stay the variant for hubs with no user interface at all, add hmi_buildhat.c selected by a new PBSYS_CONFIG_HMI_BUILDHAT. It is a copy of hmi_none.c that starts the breathe animation (or turns the light off when animations are disabled) before requesting the REPL, as hmi_pup.c does after program selection. The Build HAT has a status light but no buttons, display, Bluetooth or USB, so its user interface will need its own design later; this only starts the animation that is already configured. Verified on a Build HAT loaded from a Raspberry Pi 5: the LED breathes green as soon as the firmware is ready. Firmware size: 152188 -> 152316 bytes (+128). Fixes pybricks/support#2825
bcd2e16 to
53a8055
Compare
davelongdev
changed the title
|
Updated the PR. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
@BertLindeman, I see "City" in your log. Did you reply to the wrong PR? This one is about the Raspberry Pi Build HAT. |
Should have been in PR 500 |
|
I'm not opposed to adding this, but I guess it's worth doing some brainstorming about what the buildhat should eventually do. Would we want to run Pybricks programs on it, so the hat is semi-autonomous, sending relevant user-made data back and forth? Or would we rather have it become a remote i/o platform where the host (real Python, or any other app or language) would continuously receive sensor info, and send commands to drive the motors? Both are possible (and both have their unique merits), but this choice would roughly guide what the design would look like. |
Yes.
I think this would have too much latency. This is how RPi Foundation did it already and user feedback isn't great. |
|
Thanks Laurens, that's a helpful perspective. It seems like there are basically 3 options we might consider? I would ideally like to build something like all 3 for different purposes at least to try them out as prototypes. I say basically here because I think the boundaries are not totally clear cut: some aspects of what goes on the Pi vs. the BH might be shifted around within options 1 and 2. My thinking at this point is to start with option 2 below as David suggests because it seems like the best starting point (least work, the most practical, etc.), but I'm open to shifting gears if something else seems like a better option. 1. BH as smart I/O device: the Pi does most of the work, the BH does as little as possible. Look: User's program runs on the Pi. The BH handles I/O. Pybricks or some of its components could be built for Linux (like the virtual hub). Pros: One host program sees all BH ports, so two HATs on one Pi become one 8-port robot. Any host language could work, although options 2 and 3 could carry a different language on top of pbio too, since pbio itself is plain C. No program storage needed on the HAT. The BH firmware could be a slimmed-down option 2. Cons: This is the most similar to what the official Build HAT firmware already does, but we could probably do it better. As David noted, latency complaints on this existing approach have been voiced. I think some of this could likely be alleviated with better design choices and coding, but I think some things will probably run better / faster on the BH than on the Pi. 2. Pybricks on the HAT, Pi as loader and auxiliary. Look: User's program, Pybricks, and REPL run on the BH. Pi loads the firmware into BH's 264 KB RAM and runs some aux functionality. The BH's 2 MB flash is not used today, so nothing persists on it between power-ups. Flash could be used, but would add the bricking risk discussed below. Pros:
Cons: A two HAT setup would be more like two hubs, rather than one hub with 8 ports; coordination would go through the Pi like a multi-hub setup. Without using the 2 MB flash memory on BH, nothing would persist on BH after shutdown, and Pi would always need to be present. 3. Standalone HAT, no Pi. Look: Pybricks and programs run on HAT alone in some combination of BH's 2 MB flash and 264 KB RAM. Buttons possible with force sensor through LPF2 port or over UART. Bluetooth / wifi possible over UART with external hardware. Pros: Cheapest option / least hardware involved (at least w/o hardware beyond the BH). Saving across BH power down would be possible. Could access the full 2 MB flash memory on the BH. Cons: Bricking risk that can only be remedied through debugging probe - the BH bootloader (BHBL) lives in flash, so it could be overwritten once flash is touched. This limits this option to more advanced users. Startup would mean auto-run on power-up without extra hardware. |
That's not really a fair comparison though. Its implementation ran at 4Hz under some conditions. We should be able to do this much, much faster. And with the time critical control loops running in our firmware on the hat, we should be able to reach the right balance so that throughput is never the critical factor. For reference, even a ball balancing robot runs great at 40 hz when the sensor integration runs internally at maximum sensor speed. We might even be able to run the Pybricks API in real Python, async and all, with a lightweight link in between. All of this seems like it could work well for any hub connected to a computer, not just the build hat. Including daisy chained EV3 bricks. |
|
There really isn't a reason we couldn't do both either. Just run a special built-in remote I/O program if you want that (started just like we start the special REPL program now) or send your own Python programs directly to the hub. It isn't any more work either because the the latter is already done. |
|
We'll soon have both in the firmware, no special built in remote I/O program required 😉 So back to the original question on the HMI, which does need some redoing. The |
|
I'm in favor of merging this as-is for now so we an move on to getting motors and sensors working first and then come back to the "how are users going to use this" question later. |
|
Works for me! Might want to remove the part that waits for buttons though if there aren't any buttons. |
| return PBIO_ERROR_CANCELED; | ||
| } | ||
| pbio_os_run_processes_and_wait_for_event(); | ||
| } while (pbdrv_button_get_pressed()); |
There was a problem hiding this comment.
As Laurens said, we don't have a button on this hub, so we should be able to drop this loop.
4 participants
The Build HAT used the "none" HMI, which requested the REPL without first starting the status light animation, so the LED stayed off after boot even though the platform enables state animations with a green hue.
Rather than change hmi_none.c, which should stay the variant for hubs with no user interface at all, add hmi_buildhat.c selected by a new PBSYS_CONFIG_HMI_BUILDHAT. It is a copy of hmi_none.c that starts the breathe animation (or turns the light off when animations are disabled) before requesting the REPL, as hmi_pup.c does after program selection. The Build HAT has a status light but no buttons, display, Bluetooth or USB, so its user interface will need its own design later; this only starts the animation that is already configured.
Verified on a Build HAT loaded from a Raspberry Pi 5: the LED breathes green as soon as the firmware is ready.
Firmware size: 152188 -> 152316 bytes (+128).
Fixes pybricks/support#2825
Edited 2026-09-09: reworked after review. The first version changed hmi_none.c directly; this version adds hmi_buildhat.c instead, as suggested in the comments below.