v1.1 hardware changes about crow

[tehn]

let us not not not touch the bootloader. i've already flashed these all and want to just ^^b them with the final firmware. i'd also like to avoid spending too much time addressing edge cases which benefit only this newest version pcb

i do like 1+2. effectively indicates POWER and NOT-CRASHED

how can we make #2 lowest possible cpu use?

if 3 is the packet flash, let's just have it be an XOR so it's one line without any timers or anything, which i think is a cpu burden for a 99.9% unused feature

[dndrks]

re: LED, the primary support issues are:

• is crow receiving power?
• is crow successfully running a script / otherwise working fine (eg. not crashed / in some weird state + not in bootloader)?
• has my USB port failed?

microcontroller status also seems useful for us to be able to identify from an LED pattern.

DAC state seems easy to diagnose at home, as lots of folks write in with stuff like "I've got 10V on every output", so that seems less ambiguous.

hopefully that helps -- lmk if i can pull anything else from support emails!

[tehn]

@trentgill my preference (not strong) is for option A, default "on" (/strong) --- which covers the predominate use case of norns dongle driving JF. people w/ TT will be able to navigate this territory

[trentgill]

@tehn agreed that option A is better. doesn't change the API at all & simply provides a more reasonable amount of pullup current.

@dndrks ok i think we can do all 3. how about this:

1. is crow receiving power? turn on the LED at the very start of the stm program. So if the LED comes on, we know the stm has booted which means we have the power running successfully. even if the program quickly crashes, the LED should at least blink when turning on the case.
2. crow running normally: slow fade in/out (never turns all the way off). around 2seconds cycle time.
3. crow running & connected to a USB host: quick fade cycle (~500ms cycle time).
   3b) alternatively we could have the same as (2) but flash the LED fullbright whenever a message is sent/received over USB. Would this be helpful beyond "USB connected"? eg. for cases where druid isn't working, but crow hardware is working ok (is this a real-world problem case?)

@dndrks do we need to indicate that we're in bootloader mode? if so, i need to make a change to the bootloader project (which is separate from this repo).

---

i'll get the hardware stubs built in now, but i don't have new hardware to test. should be pretty basic though, and i'm confident i can get it working without hardware in hand. if we have issues getting things up, i'll have you send one of the new units over.

[dndrks]

@trentgill , those proposals all sound good!

1. yeah, having any indication that the module is on / able to turn on would help cast aside doubt when crow shows as disconnected in druid for other reasons (eg. weird path stuff, or maybe you told macOS not to trust crow, etc).
2. normal / standalone 2s cycling makes sense!
3. mirroring data sent/received over USB would be rad! even if just for non-druid situations (eg. Max or norns) where you want quick visual confirmation that the message you sent was received by crow, so then if you aren't getting the result you want it's likely a code issue.

i think indicating bootloader would be a nice-to-have, since druid announces that crow is disconnected when crow is fully functional but just happens to be in bootloader vs. when crow isn't actually connected.

lmk if there's anything else i can help with! <333

[trentgill]

ok i'll get working on this. already got the pullups done & ready to test.

re: 3) i note that the LED is not visible when the module is screwed into the case. i don't love the idea of telling people to remove the module from the case to check the status light when running, but i guess it's a nice to have for last-ditch-effort debugging before claiming a hardware issue?

i'll take a look at the bootloader - should really just be copying the same code into the bootloader. perhaps in BL mode it can just blink twice a second so it's a distinctly different visual.

@tehn i think it should be possible for druid to detect crow in bootloader mode. this would be a very helpful thing to communicate when entering bootloader mode i think! but it could be more of a burden than necessary. perhaps a better solution is to just match on ^^b and print a message saying "crow is now in bootloader mode, open another terminal and run druid firmware to update crow's firmware". would probably be a 10 minute change?

---

after @tehn's comments:
ok, noted re: CPU usage. it also drastically simplifies the code to just blink rather than worry about PWM. updated proposal:

1. turn on LED at boot (if LED is stuck on, it suggests some kind of uC setup failure)
2. without USB connection: toggle high/low once per second for a 2s duration squarewave
3. when USB is connected: toggle high/low 4x per second (for 500ms squarewave), and XOR the output state on USB tx/rx.

i think this effectively communicates the 2 working states, and should give some blinky / half-bright fuzziness when sending USB packets. it will also be super minimal CPU usage - simply adding a condition check in each background loop, then when it's time to toggle, it just sets variable & toggles the GPIO.

[dndrks]

the super minimal version sounds right to me!
also, having druid reflect bootloader state would be super super helpful, and would meet the need for any LED indication.

[trentgill]

There's a dev branch firmware zip over here: https://github.com/monome/crow/suites/11149257223/artifacts/568918905
It includes these v1.1HW changes & the timeline library.
Hope that helps @dndrks !