Firmware Quandaries

Good evening, I have been getting back into the flashlight modding groove after not doing much with the hobby for about a year or so. I'm been editing the code ToyKeeper has published on her repository and it seems like whatever firmware I've tried I run into snags. I really like the Crescendo firmware and I've been tweaking it on a FET+7135 driver to how I like it. Unfortunately, I only have Attiny13A MCUs so I can't keep all the goodies on there but that's okay for now. On this particular firmware, I keep having issues with the changing modes. It seems that I have be extremely quick with the clicky switch to make it behave, otherwise it thinks I'm either making a bunch of clicks or just one long one. Not sure what line(s) of code to edit here to change that. Previously I was experimenting with the A6 firmware and couldn't get it to work on both channels (7135 and FET). For now though, can some of you software engineers give me a hand here with getting the mode switching to be more predictable. If it helps, I've tried adjusting this line from all the way from 250 to 1000 and nothing seems to change except at the end of the ramp the light stays on a bit longer.

// How long to wait at ramp ends, and
// how long the user has to continue multi-taps after the light comes on
// (higher makes it slower and easier to do double-taps / triple-taps,
// lower makes the UI faster)
// (recommended values 250 to 750)
#define HALF_SECOND 500
//#define HALF_SECOND 333

Do you have a spare switch to try, by any chance?

That sounds like switch bounce to me, i.e. the switch is oscillating rapidly between open and closed for an instant as it transitions from one state to the other.

Dirty or damaged contacts inside the switch, or just a switch that happens not to snap from open to closed (or vice versa) as quickly as it should can cause the effect.

Also check the source code for anything that mentions switch bounce, as I believe some firmwares take steps to mitigate it.

I changed the switch and it might be a bit better. I think the underlying problem is in the firmware though; I can't seem to be able to make the turbo mode work. The led just turns off or responds to a single or double click when I follow the UI diagram for accessing turbo mode.

Which driver do you use?
Do you set the correct fuses? Attiny13 and Attiny25 require different values.
http://www.engbedded.com/fusecalc/

I’m using a FET+7135 driver from Mountain Electronics. I’m using the Attiny 13 with the fuses recommended in the firmware: Low: 0x75 High: 0xff

Could you post a screenshot of the output of avrdude after uploading the program and setting the fuses?

Is this what you what you mean?

Yes, that’s what I meant. Looks good so far, I was still suspecting the fuse settings. Sorry, can’t help then, never used this firmware. You might find more help here:

One part of the firmware (or whatever else it might be) that bugs me is that a tap has to be super quick for it to count as one (tap). For instance, the when the ramping starts, one tap during the ramp sets the brightness at that level. If the tap is just a tiny bit too long however, it just starts over. The majority of the time the way I tap would be on the long side in the firmware’s logic. This makes it even harder to do an accurate double tap and nearly impossible to triple or quad.

This is a statement of crescendos creator regarding a similar problem:

Not sure if that’s related—it might be—but my driver does have an OTC. So apparently the problem doesn’t exist in my case? Yet it does. And it still doesn’t answer why turbo mode doesn’t work… :frowning: I wish I knew C and how the code translates to function on the driver and in real use; I really feel like a babe in the woods when it comes to this. I really want to get this to work, though! It also seems like almost any firmware I try I end up running into some snag or another, especially when using the Nanjg drivers.

If I can’t get crescendo to work, do any of you know of another ramping firmware similar to this that I could modify?

Your driver might have an OTC but crescendo does not use it.

Oh! Dumb question maybe but should I remove it in that case?

If it’s not used it shouldn’t harm.

I desoldered the OTC and tried it just to see. No apparent difference, so I put it back on.

I'm wondering if there's some kind of issue with the dual channel setup. I flashed the A6 firmware and as you likely know, there are two lines which specify the different outputs for each channel:

// PWM levels for the big circuit (FET or Nx7135)
#define MODESNx1 0,0,0,7,56,137,255
// PWM levels for the small circuit (1x7135)
#define MODES1x1 2,15,110,255,255,255,0

Could this be a problem with the driver circuitry itself, or is there still something plaguing my code? I'm guessing that whatever it is that is making the A6 firmware to not work is also making the crescendo firmware to not function either. Or maybe I should just give up on ToyKeeper's firmware and try something simpler :( I love the fact though that both the A6 firmware and the crescendo allow you to back up through the modes to do dimmer if you like.

Here is my code for the A6:

A6 firmware

Yep, I just flashed the A6 FW to another but identical driver and it works as it should. Crescendo still acts a little weird and is flickery now though. :person_facepalming: