true/000000widow-hackspacecon
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fix not sending last frame to LEDs

Browse Source 
also, clarified comments a bit
This commit is contained in:
true 2025-04-23 19:53:59 -07:00
parent d8d2677f54
commit 8a0430f137
1 changed files with 23 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
fw/HackSpaceCon_AS7/HSC_Wand/wand_program.cpp
View File

@ -10,6 +10,9 @@
the resulting binary at time of porting takes an additional
531 bytes of flash and 8 bytes of SRAM. I do not know why.
but I suspect it is due to the inability to get -flto working
properly on libraries. oh well; can figure it out later.
operation workflow:
@ -17,21 +20,21 @@
- at initial reset (battery inserted), set up GPIO and peripherals. this
includes setting up button wake interrupt. sleep MCU into standby mode.
- when button state changes, MCU will wake up and process the interrupt.
if button is pushed (btn gpio is low), prepare to run next RGB program.
- when button is pushed (pin goes low), MCU will wake up and process the
button interrupt. prepare to run next RGB program.
- rgb program setup involves turning on power to the LEDs and enabling
TCB0 periodic timer to interrupt every ~61Hz. this timer interrupt
does not handle the rgb program, but will wake the CPU which resumes
processing in the loop() function.
TCB0 periodic timer to interrupt every ~61Hz. (this timer interrupt
does not handle the rgb program directly, but will wake the CPU which
resumes processing in the loop() function.
- call the rgb program with the `init` parameter set to 1. idle the CPU.
- rgb prog timer will interrupt every ~61Hz. this will wake the CPU and
send the previously rendered LED data, then call the rgb prog function.
afterward, the CPU idles. process repeats until the rgb prog fn returns 0.
afterward, the CPU idles. process repeats until the rgb program returns 0.
- every time the rgb program is run, the rgb data to send is updated.
- every time the rgb program is run, the rgb data to send can be updated.
the data is not actually sent until next wakeup in less than 16.4ms.
this allows the functions to have variable processing time, but the
output to have a consistent ~61Hz (~16.4ms) timing.
@ -62,7 +65,8 @@
enum {
RGB_IDLE,
RGB_INIT,
RGB_RUNNING
RGB_RUNNING,
RGB_STOPPING
};
enum {
@ -140,7 +144,7 @@ void loop() {
rgb.show(); // send updates to the led
// then process the next program frame
if (!rgb_program[rgbprog_idx](PROG_RUN)) {
run_rgbprog = RGB_IDLE; // until the program says it's done
run_rgbprog = RGB_STOPPING; // until the program says it's done
break;
}
@ -148,8 +152,17 @@ void loop() {
break;
}
case RGB_STOPPING: {
rgb.show(); // send final updates to the led
run_rgbprog = RGB_IDLE;
idle_cpu(); // we can idle CPU after running the program
break;
}
default: { // no longer running a program
default: { // no longer running a program
disable_rgb_timer(); // disable RGB program timer,
digitalWrite(PIN_LED_PWRENA, LOW); // disable LED power supply,
run_rgbprog = RGB_IDLE; // and clear run_rgbprog.