Ethan

• set up the rust environment for the pico
• rewrote the button abstraction into pure rust
• got a blink program working (just using pure embassy-rs for now, not written the abstraction for the sprig LEDs yet)
• started writing the hardware_checker program, which will display the current status of the buttons and also test all of the LEDs / screen / audio

Finally figured out how I want to do the systems in rust, since it becomes a lot harder when you need to deal with those memory safety design choices - for example, where do you construct the Input object needed within a Button class? Is it for the class to internalise or should it be handled by the constructor? If it needs to be referenced mutably in multiple places (eg. the debouncing task), how should it be handled? You cannot call the input.wait_for_high() without input being mutable, but you can poll for is_high() with an immutable input, which is what occurs internally in the wait_for_high() anyway…

The demo shown in the video is waiting for the button to be held (considered held when pressed down for >800ms) and then flashing the pico built in LED for 5ms. This isn’t a static demo, the logic for debouncing, detecting press vs hold, etc is encapsulated within a new Button class.

started writing into rust

• Switched the main C++ project with a Rust project which interacts with the C++ library
• Wrote the C-Rust bridge for the LEDs and Buttons
• Wrote the main Rust program which demonstrates using the LEDs and Buttons
• Wrote the CMakeLists.txt to build the library, the main Rust and then link the library into it

• Rewrote the system to have a centralised library “opensprig” that holds all of the logic for hardware interactions
• Wrote a loader that stores the programs on the sd card instead of on the pico flash (that is what the loading bar is doing - loading the program from the sd card ready to run)
• Added badapple!! example for the programs that can be run from the sd card (they need to be compiled with a custom memory mapping to get the .bin file which can be loaded by the main firmware).

NB. The firmware is displaying a hackclub logo immediately after the loading bar and before badapple!! plays, but it doesn’t show on the video very well. When viewed on the device, it looks just how you would expect.

• started moving the code into a library
• can display files in the bgr565 format for images/videos (12.2fps)
• add conversion script to convert normal images/videos into correct format

• Moved the font into a header since it is just the definitions now.
• Moved the set_backlight into the screen class, rather than just laying about.
• Modified my build script to flash with openocd and a pico probe. You may be able to see it attached to the back of the sprig if you look closely - it doesn’t add any functionality, just allows for quicker firmware uploads and debugging.
• Added a small script which uses ffmpeg to convert image files into the BGR565 format which is what is required for the sprig screen.
• Got the SD card interface built into the screen working with fat32 - the sprig can now read and write to any external storage connected here. This is what I spent most of my time working on, since it DID NOT want to cooperate.
• Added an interface for the speaker - just playing sine waves for now (like the spade implementation of the sprig, used for the games made on the website). This also took a larger amount of time, but nowhere near the time for the SD card.

In the video, you can see a demo of the audio beep and the SD card detection. Note that the hackclub logo is being read from the SD card, it is not stored on the device. This is why it requires that the user insert an SD card.

Since I received a PicoWH with my sprig (was that intended?), next I will add an option to automatically download and populate the SD card inserted if not already populated.

• Refactored basically all of the existing logic to use classes for each hardware type, and a master Hardware class that keeps track of all of the hardware on the sprig, instead of calling everything from main.cpp.
• The program is now using a screen buffer instead of writing directly to the screen. This allows us to have elements at different z-indexes and to have transparency between the elements.
• Added “fade_to” and “blink” methods to the LED class to handle smooth animations of the pwm enabled LEDs.
• Added the ability to render text to the screen buffer in a 4x6 font, which is stored in a font.cpp file as a hex representation of each character. This could be optimized, since I am using a uint8_t for each row of each character, when I only need half of that memory space.

Added functionality for interacting with the screen and added support for all buttons on the device. Also updated the demo to show how to interact with the screen and draw a gradient.

Got the pico environment set up and made a quick demo to check that I could interact with the sprig hardware. Also added some code so that the BOOTSEL button can be pressed while the program is running to immediately enter flashing mode.