konsumer / konsumer/beatstep-cli
Firmware
- Dominant language
- C++
- Stars
- 3
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
I have the basic code for "put device in firmware update mode" but it's commented out because I don't know how to send the actual led file (I couldn't find documentation on the format, and couldn't seem to record what the official program sends.)
I think a virtual-device emulator for recording firmware-update messages would need to do this:
- Identify as `Arturia BeatStep`
- return `version` [correctly when asked](https://github.com/konsumer/beatstep-cli/blob/main/src/BeatStep.hpp#L167-L201)
- Emulate the "firmware update mode" (sends a bunch of weird bytes)
- reply with correct messages: seems like it has a "ok to start", "that chunk was ok" and "all finished here is my version now"
- Using this, record the bytes that come from software with the LED file to determine the protocol
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the commented firmware-update code and the version-handling section in src/BeatStep.hpp at lines 167-201. The issue proposes a virtual Arturia BeatStep emulator to record firmware-update messages, including device identification, version responses, update-mode bytes, chunk acknowledgements, and the final version response. Done would mean the protocol is understood well enough to record and reproduce the LED firmware update exchange.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- cli, embedded-iot, reverse-engineering
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100