Need some basic firmware

Can somebody point me to some basic mode changing flashlight firmware for the ATtiny85 or comparable microprocessor? Low/bright/Strobe etc via PWM output is fine.

I’ve found a bit of code, but it doesn’t want to work on my breadboard. It does operate and change modes, but not through the on/off switch. The flashlight only has an on/off switch, so changing modes will be done through the traditional half-presses. I have the button pin pulled up via 10K resistor.

Here’s what I have, can anybody spot the issue or am I just using entirely incorrect firmware for this?

https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/fsm/files/head:/ToyKeeper/bistro/biscotti/

There are other examples in the repository, just browse other firmwares.

Here is the index with short descriptions: ~toykeeper/flashlight-firmware/fsm : contents of INDEX at revision 490

Thanks for that link. I spent about 30 minutes digging through that and they all seem quite similar, like a derivative of some main code (perhaps by toykeeper).

I’m looking for something super basic, and that would be super cool if there was a schematic to see what components are used for the voltage divider and residual power cap.

Thanks!

Sounds like your breadboard and firmware doesn’t match the flashlight.

You say the flashlight has a single on/off switch which I assume is a clicky switch. But the firmware looks like it’s for a tactile switch and you specify using a pull up resistor which also implies a tactile switch.

Can you describe what you’re trying to do in a bit more detail?

Gchart,
Perhaps this is the case. I’m trying to get the Attiny85 to control a driver via PWM. It’s a flashlight with 3 modes, and I’d like to have the clicky on/off switch change the modes (each mode is a different PWM duty cycle).

Simple as that.

I was guessing that the clicky switch would pull down the pulled-up pin, to trigger the mode a few miliseconds before the microprocessor turns off. That should explain why I was using a pull up resistor.

Any suggestions to try?

Thank you!

In a non-eSwitch flashlight, the switch interrupts the power. There are various ways the light determines how long it was off during that interruption. In some versions, the MCU reads a capacitor; in others, a RAM location.

In an eSwitch flashlight, there is a switch for power, but the eSwitch is used to signal the MCU.

Here is a schematic and discussion of a typical driver.

Sorry, this got lost:

So the simplest version of your software would just store the mode, and change to the next mode each time the MCU restarted. Much of the complexity in the linked software is because the UI uses multiple signals, and must implement double-clicks, triple-clicks, long presses, and other signals.

With a clicky, "noinit" is your friend. It tells the program not to initialize that area of SRAM when booting up (so it won't overwrite any values stored in those variables). Due to SRAM decay, the values would normally become trash in a 1/2 second or so after power loss. So if when booting up, if those values contain an expected value, you know the circuit was powered down for a very short time (a short press). An easy way to do something like this is...

uint32_t boot_status __attribute__ ((section (".noinit")));
uint8_t current_mode __attribute__ ((section (".noinit")));
#define NUM_MODES 3

int main() {
// if it's our expected value, it must have been a short press
if (boot_status == 0xDEADBEEF) {
current_mode++;
if (current_mode >= NUM_MODES) { current_mode = 0; }
}
// not our expected value, long press… start with the first mode
else { current_mode = 0; }
// reset our variable so we can check it at next boot
boot_status = 0xDEADBEEF;

if (current_mode == 0) …
}