this post was submitted on 17 Aug 2023
18 points (100.0% liked)
flashlight
2929 readers
1 users here now
Portable illumination
Rules:
- Be excellent to each other
- Don't be the reason we need to make more rules
Related:
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Speaking of testing locally - how do folks test code changes? Actually flash them to driver, or is there some kind of way of simulating the inputs and outputs? I’m guessing there isn’t an Anduril emulator.
Yes, you could (theoretically) use an emulator for the microcontroller. I tried it a few times. And it isn't fun. It takes a lot of effort to simulate all inputs, outputs are hard to interpret and all kind of effects of the real light aren't reproduced.
In reality we flash the build onto a flashlight and try it. Sometimes it's only a prototype, disassembled. And rarely it's an actual devboard which has all relevant parts of the flashlight nicely accessible (basically the microcontroller with required electronics, regulated power supply, low power LED to see the output, several LEDs for aux and button and the switch itself).
That makes sense that it’s easier to flash directly since there are so many different parts and variations to the actual destination hardware.
I read that one of Toykeeper’s original design decisions was to separate out the generic UI code from the specific code that interfaces with the hardware (being vague due to lack of knowledge). Maybe it would be possible to incorporate some testing code that only evaluates the user inputs compared to expected outputs within the Anduril layer? Such as a single state transition like “when multi-channel is enabled and user selects 4H, selected output level is equal to turbo”. Such a test could be indicate unexpected behavior when UI code is being customized.
Just adding to the imaginary backlog here!