konsumer / konsumer/beatstep-cli

Firmware

Open
#6 2 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.