Finite State Machine, or [F-word] Spaghetti Monster.
Why? Because it takes the mess of spaghetti code typically associated with low-level firmware and locks it away in a box where people don’t have to care about the monster inside. Instead it presents a more user-friendly interface in the form of a finite state machine, because that’s typically how people describe flashlight UIs. A finite state machine is basically a flowchart.
Yes, the one labelled R1, connected to pin 7, is along the path which allows current to leak. Removing it would stop the leak.
For BLF-A6 and Bistro, this is a good thing. The offtime measurement depends on current leaking out at a predictable and high enough rate. And for multi-cell serial lights it’s necessary to scale voltage down to a usable range. But for single cell e-switch lights it’s not desirable.
Those banggood drivers don’t have a tiny85 though, so they can’t run FSM.
Thanks TK for all the explanations. I have put Attiny 85’s on a couple of these drivers and run the eswitch between pin 2 and earth.
When I read through these posts I feel like a Friggin Scared Moose.
I figured that what else it could be while laying in bed thinking about this. Too far into this hobby where this ends up happening…
I would definitely need to test this on the bench with the PWM to see how it behaves. I have seen a test of these where at 120mA they start to go blue… Are there lower power 7135s?
Lots of code updates lately, though most of them aren’t UI changes. Most are to keep code cleaner and more manageable, splitting hardware-specific bits out into their own files and such. This way, new drivers can be added more easily with less clutter. Drop in a hardware layout definition and a UI config file, and it should be pretty much done.
Due to the way the C preprocessor works though, it does typically still require adding a couple lines to the main source files. But the changes there are a lot smaller than they used to be, and easier to read.
Anyway, I paid off some technical debt so I’m done for the evening.
I wonder how it even compiled like that. I’ve been using a script lately to build every supported version every time instead of doing just one, and the Q8 version built and worked normally under gcc 4.9.2. But it looks like it really shouldn’t have worked…
Since it’s a thing people might want, and since I think Lexel may have been requesting it, I took a moment to make a Werner-style momentary UI, side e-switch plus tail clicky-switch.
Nope, that is set entirely in hardware. It depends on the indicator LED Vf, the battery voltage, and the resistor(s) between them. Note that, in low mode, the attiny’s internal resistor is active, which is why low mode exists at all.
The code can’t change this, because the MCU is asleep and not executing any code. The PWM facility isn’t active.
Hey y'all i'm late to the party and i'm trying to figure this out. I want to run anduril on a TA board that i'm pretty sure is a tripledown layout. Do I just add in a line "#define TRIPLEDOWN_LAYOUT " ?
And what about the FET+1+20 part? Its just a FET+1+6. Any help will be much appreciated
I’d suggest copying the FW3A config, or even just using it directly, depending on the details of that driver. It’s a FET+7+1, so it should be pretty close.
I recently (in the fsm branch) reorganized how hardware definitions work… there’s a physical layout file, like hwdef-FW3A.h, showing which pins do what and a couple other things. There’s also a UI config file, like cfg-fw3a.h, which configures options specific to Anduril or FSM.
Then there’s a magic #define to tell it which hardware config files to use.
There is a Tripledown definition, but I think it’s designed for a clicky-switch type with OTC and a voltage divider. So I suspect the FW3A definition might be closer, if you’re using it with e-switch instead of OTC, and if you take the voltage divider off. (it’s not recommended to have or use a voltage divider for e-switch lights, since it increases parasitic drain)
If you’re doing multiple cells in series though, it’ll need the voltage divider, and some bits copied/tweaked from the BLF GT configuration. And the 7135 chips are likely to burn out.
Anyway, you can probably just remove a voltage divider resistor and flash the FW3A build directly. If my guesses are right, it should “just work”.
Oh, the FW3A doesn’t have a pin for an aux LED. The four main pins are used for 1x7135, Nx7135, FET, and e-switch. But you could probably attach the aux LED to pin 7 (PB2), and define something to make it use that. It should work, but will involve compiling your own version.
I’m also not entirely sure it’ll fit into ROM all at once. The third PWM channel uses extra space, and the aux LED uses extra space, and there may not be quite enough room for both unless you turn off something else.