Repository navigation
Button lights on the BlackBox: they follow the blocks (#8) - #17
Merged
Merged
Conversation
Owner
|
@steponme82 NICE JOB! please read #16 more info about my current work. thank you so much for you help |
Contributor
Author
|
Thanks! No rush, v37 first. 1: once v37 is pushed I'll rebase #17 on it myself, so you don't have to deal with the conflicts If a second pair of eyes helps with the NAM speed, I have JieLi's objdump running here and I can go through how 021 uses the vector unit and the second core. Tell me where to start. |
The BlackBox's button lights hang on a 74HC595 on port C (DS PC8, shift clock PC5, latch PC6), as the stock firmware drives it. PC7 is the lights' enable, low = on. OpenPocket held PC7 high as a screen line, so the lights stayed dark whatever the 595 held. - px_leds.h: the 595 driver. leds_init loads the all-off byte with the lights disabled, then drives PC7 low, in the stock order. - px_lights.h: what they show, once per main-loop pass. AMP, MOD, DLY, REV and CAB light while their block is on, FX while any block of its group is on (ui.h UI_FXB, shared with the FX button), HOME blinks in the tuner. The byte is written only when it changes. Off during an update (px_usb.h PX_LIGHTS_OFF). - led_probe.h (LED_PROBE 1): the LED map build that read the bit order on a BlackBox: 0 HOME, 1 FX, 2 AMP, 3 MOD, 4 DLY, 5 REV, 6 CAB. - tests/lpsim.c and tests/lightsim.c: a 595 model with its enable on PC7; both run from tests/run_tests.sh. Confirmed on a BlackBox. Not tried on a Pocket X yet: the same firmware runs there and the stock routine is the same, but its bit order may differ. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
steponme82
force-pushed
the
button-lights
branch
from
November 7, 2026 16:18
90d901b to
9e4f821
Compare
isod89
added a commit
that referenced
this pull request
Nov 8, 2026
Conflict in firmware/openpocket.c: the lights' update and v37's '2C' status line kept. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LFaxqW3CpFrLCvqoteTUv9
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@isod89
The button lights work on my BlackBox. This is the driver from #8.
What they show:
1: AMP, MOD, DLY, REV and CAB are lit while their block is on
2: FX is lit while any block of the FX group is on (drive, SFX, synth, pitch, comp, gate, EQ). It's the same list the FX button cycles through, now
UI_FXBin ui.h so both use it3: HOME blinks while the tuner is open
4: all dark during an update
How:
1:
px_leds.hdrives the 595 the way you read it (DS PC8, SHCP PC5, STCP PC6). At init it loads the all-off byte, then drives PC7 low, like stock. PC7 is the lights' enable, not a screen line.lcd_initandinput_initstill set it high at boot, only their comments changed2:
px_lights.hbuilds the byte once per main loop pass and writes it only when it changes. On the wire a 0 lights, so it goes out inverted like stock3:
led_probe.his the LED map build I used to read the bits (LED_PROBE 1, off by default). It can map a Pocket X too4:
tests/lpsim.candtests/lightsim.cmodel the 595 with its enable on PC7. Both run intests/run_tests.shTested:
1: on my BlackBox the lights follow the blocks, also when I change preset, and HOME blinks in the tuner
2: the host tests all pass, and the two new tests catch all 19 deliberate mistakes I tried in the code
3: the CI build on my fork compiles with no warnings
Not tested on a Pocket X. The same firmware runs there and you found the same routine, but the bit order may be different. If you can, install it and check that each light sits on the right button. If not,
LED_PROBE 1gives the map in a minute.Not in this PR: a setting to switch the lights off. It needs a place to save settings, and VinSpee's #10 adds the first one. I'll add it on top once #10 is in.
Heads up: #10 and #16 also add lines after the screen step in
tests/run_tests.sh, so whichever goes in second gets a small conflict there. Keep both blocks.🤖 Generated with Claude Code