Install a QMK-compatible Open Source controller on my keyboard by danishprakash

Replace the proprietary keyboard controller(buggy) on my Kinesis Advantage2 and install the open source KinT controller and flash QMK on it.

Here's a short write-up - https://danishpraka.sh/posts/kinesis-advantage2/

---

Adding individual key RGB to the keychron k17 pro by ldragon

Description

I recently acquired a k17 pro and was disheartened to learn instead of a way to set individual key RGB values we were given a set of preset "animations" and didn't have individual key RGB. The keychron k17 pro in hardware does support individual key RGB addressing as shown in many of the animations it ships with.

However this functionality is not provided to the firmware/via to set individual key RGB back light. Other keychron keyboard with similar issues seem to have this resolved by following a method similar to the one described here this aim is to replicate this one the k17 and attempt to over come the shortcomings of the original(save+load does not work).

Goals

1. Port the original RGB to the wls_2025q1 branch of keychrons fork of qmk
2. Fix the capslock and numlock state light not changing state after being pressed once.
3. Fix the save+load issue that is present in the fork by Sasuchisama

Resources

• keychron's fork
• community fork

---

Smart lighting with Pico 2 by jmodak

Description

I am trying to create a smart-lighting project with a Raspberry Pi Pico that reacts to a movie's visuals and audio that involves combining two distinct functions: ambient screen lighting(visual response) and sound-reactive lighting(audio response)

Goals

• Visuals: Capturing the screen's colour requires an external device to analyse screen content and send colour data to the MCU via serial communication.
• Audio: A sound sensor module connected directly to the Pico that can detect sound volume.
• Pico 2W: The MCU receives data fro, both inputs and controls an LED strip.

Resources

• Raspberry Pi Pico 2 W
• RGB LED strip
• Sound detecting sensor
• Power supply
• breadboard and wires

---

Learn a bit of embedded programming with Rust in a micro:bit v2 by aplanas

Description

micro:bit is a small single board computer with a ARM Cortex-M4 with the FPU extension, with a very constrain amount of memory and a bunch of sensors and leds.

The board is very well documented, with schematics and code for all the features available, so is an excellent platform for learning embedded programming.

Rust is a system programming language that can generate ARM code, and has crates (libraries) to access the micro:bit hardware. There is plenty documentation about how to make small programs that will run in the micro:bit.

Goals

Start learning about embedded programming in Rust, and maybe make some code to the small KS4036F Robot car from keyestudio.

Resources

• micro:bit
• KS4036F
• microbit technical documentation
• schematic
• impl Rust for micro:bit
• Rust Embedded MB2 Discovery Book
• nRF-HAL
• nRF Microbit-v2 BSP (blocking)
• knurling-rs
• C++ microbit codal
• microbit-bsp for Embassy
• Embassy

Diary

Day 1

• Start reading https://mb2.implrust.com/abstraction-layers.html
• Prepare the dev environment (cross compiler, probe-rs)
• Flash first code in the board (blinky led)
• Checking differences between BSP and HAL
• Compile and install a more complex example, with stack protection
• Reading about the simplicity of xtask, as alias for workspace execution
• Reading the CPP code of the official micro:bit libraries. They have a font!

Day 2

• There are multiple BSP for the microbit. One is using async code for non-blocking operations
• Download and study a bit the API for microbit-v2, the nRF official crate
• Take a look of the KS4036F programming, seems that the communication is multiplexed via I2C
• The motor speed can be selected via PWM (pulse with modulation): power it longer (high frequency), and it will increase the speed
• Scrolling some text
• Debug by printing! defmt is a crate that can be used with probe-rs to emit logs
• Start reading input from the board: buttons
• The logo can be touched and detected as a floating point value

Day 3

• A bit confused how to read the float value from a pin

---

Creating test suite using LLM on existing codebase of a solar router by fcrozat

Description

Two years ago, I evaluated solar routers as part of hackweek24, I've assembled one and it is running almost smoothly.

However, its code quality is not perfect and the codebase doesn't have any testcase (which is tricky, since it is embedded code and rely on getting external data to react).

Before improving the code itself, a testsuite should be created to ensure code additional don't cause regression.

Goals

Create a testsuite, allowing to test solar router code in a virtual environment. Using LLM to help to create this test suite.

If succesful, try to improve the codebase itself by having it reviewed by LLM.

Resources

Solar router github project

---

OSHW USB token for Passkeys (FIDO2, U2F, WebAuthn) and PGP by duwe

Description

The idea to carry your precious key material along in a specially secured hardware item is almost as old as public keys themselves, starting with the OpenPGP card. Nowadays, an USB plug or NFC are the hardware interfaces of choice, and password-less log-ins are fortunately becoming more popular and standardised.

Meanwhile there are a few products available in that field, for example

• yubikey - the "market leader", who continues to sell off buggy, allegedly unfixable firmware ROMs from old stock. Needless to say, it's all but open source, so assume backdoors.

• nitrokey - the "start" variant is open source, but the hardware was found to leak its flash ROM content via the SWD debugging interface (even when the flash is read protected !) Compute power is barely enough for Curve25519, Flash memory leaves room for only 3 keys.

• solokey(2) - quite neat hardware, with a secure enclave called "TrustZone-M". Unfortunately, the OSS firmware development is stuck in a rusty dead end and cannot use it. Besides, NXP's support for open source toolchains for its devboards is extremely limited.

I plan to base this project on the not-so-tiny USB stack, which is extremely easy to retarget, and to rewrite / refactor the crypto protocols to use the keys only via handles, so the actual key material can be stored securely. Best OSS support seems to be for STM32-based products.

Goals

Create a proof-of-concept item that can provide a second factor for logins and/or decrypt a PGP mail with your private key without disclosing the key itself. Implement or at least show a migration path to store the private key in a location with elevated hardware security.

Resources

STM32 Nucleo, blackmagic probe, tropicsquare tropic01, arm-none cross toolchain

---