Flashlight Firmware Repository

Flashlight Modding and DIY Parts
1661

Sounds like a bug. I’ll see what I can figure out.

…

Do you have the ability to compile the code? If so, could you try adding one line?

==@@== -406,6 +406,7 ==@@==
     if (my_reverse_modes) {
         // TODO: yuck, isn't there a better way to do this?
         int8_t i;
+        src = modegroups + (my_modegroup<<3);
         src += solid_modes;
         dest = modes;
         for(i=0; i<solid_modes; i++) {

I think this may have broken a long time ago and nobody noticed until now, because the hi-lo mode order doesn’t get tested much.

1662

Thank you ToyKeeper, that solved the problem.
Another problem regarding cypreus firmware, I flashed it to my driver with atttiny25 and 85. The medium press doesnt work and the battcheck always blinks 5x which means it is full even if it is 3v already. Also the beacon and strobe is 2x faster than normal. Does it mean that cypreus firmware don’t work well with attiny25?

1663

Awesome, I’ll get the fix published in the repository.

I’ve never attempted to use cypreus or cypreus2 on tiny25, so I don’t know what to expect from it. It’s mostly just a thing I made for my own personal use. Cypreus2 runs on the same hardware as blf-a6 (FET+1 w/ tiny13 and OTC). The older cypreus has only been tried on a single-channel FET driver.

For a while, I’ve been meaning to get some tiny25 FET+1 drivers and upgrade my Cypreus, using the extra space to add more stuff, and bump the version up to become cypreus3… but I haven’t yet.

1664

Hi TK, what in the BLF-A6 code controls which channel the hidden turbo is on? I can easily modify the channel of regular-mode-order turbo but it has no effect on hidden turbo and I’m unsure what controls that.

I’m building a white/UV dual emitter light and I’d like hidden turbo to only be 100% on the secondary channel (secondary channel 1x7135 will drive the UV emitter as it does in my white/red build but that one works different that I want this one to work). I’m sure I don’t need to tell you but for anyone else reading along the issue (which is NOT a problem for 99.9% of users) now is that hidden turbo is 100% on the main channel only.

1665

If I recall correctly, that’s in HIDDENMODES_ALT.

1666

Good morning TK, so that did work perfect to turn on the secondary output in hidden turbo, my remaining issue is I need the main channel to be off during that hidden turbo (but still 100% in regular rotation max)

Edit: Here’s how to do what I’ve been talking about my last 2 posts, in case anyone else needs it. So to recap, this will disable all output on the main channel during hidden turbo mode and enable the secondary channel to it’s max (but not effect the max mode in the normal rotation in any way).

#define HIDDENMODES_ALT 0,0,0,255 // Zeroes, same length as NUM_HIDDEN

#define TURBO 0 // Convenience code for turbo mode

1667

One additional question on the subject:does the same turbo timer setting effect both regular mode order turbo and hidden turbo?

1668

Some new patches on the way:

  • Add settings for USE_BATTCHECK, USE_GOODNIGHT, USE_BEACON, USE_STEPPED_RAMPING
  • Add sanity check for Battcheck modes (VpT vs. bars setting)

And I took a look which feature eats how much memory on the ATTiny85:

Baseline with every flag below enabled: ROM 8090 bytes (98.8% full), RAM 299 bytes (58.4% full) used

Memory saved by disabling each define alone:

USE_BIKE_FLASHER_MODE -
ROM 122 bytes (1.5), RAM 1 bytes (0.2)
USE_PARTY_STROBE_MODE -
ROM 26 bytes (0.4), RAM 0 bytes (0.0)
USE_TACTICAL_STROBE_MODE -
ROM 20 bytes (0.3), RAM 0 bytes (0.0)
USE_LIGHTNING_MODE -
ROM 228 bytes (2.8), RAM 0 bytes (0.0)
USE_CANDLE_MODE -
ROM 432 bytes (5.3), RAM 8 bytes (1.6)
USE_MUGGLE_MODE -
ROM 430 bytes (5.3), RAM 8 bytes (1.6)
USE_THERMAL_REGULATION -
ROM 1188 bytes (14.5), RAM 88 bytes (17.2)
USE_REVERSING -
ROM 86 bytes (1.1), RAM 0 bytes (0.0)
USE_BATTCHECK -
ROM 70 bytes (0.9), RAM 0 bytes (0.0)
USE_GOODNIGHT -
ROM 130 bytes (1.6), RAM 2 bytes (0.4)
USE_BEACON -
ROM 106 bytes (1.3), RAM 0 bytes (0.0)
BLINK_AT_CHANNEL_BOUNDARIES -
ROM 8 bytes (0.1), RAM 0 bytes (0.0)
BLINK_AT_RAMP_FLOOR -
ROM 8 bytes (0.1), RAM 0 bytes (0.0)
BLINK_AT_RAMP_CEILING -
ROM 30 bytes (0.4), RAM 0 bytes (0.0)
BLINK_AT_STEPS -
ROM 56 bytes (0.7), RAM 0 bytes (0.0)
USE_STEPPED_RAMPING -
ROM 440 bytes (5.4), RAM 8 bytes (1.6)
USE_IDLE_MODE -
ROM 36 bytes (0.5), RAM 0 bytes (0.0)

1669

Awesome. I’m not sure how often people actually customize the build, but I try to make it relatively easy to do so.

BTW, which hardware build is that based on? Here’s what I get when I build all supported targets:

  • BLF GT: 7994 bytes
  • BLF Q8: 8040
  • Emisar D1: 7674
  • Emisar D1S: 7674
  • Emisar D4: 7674
  • Emisar D4S: 8026
  • FW3A: 7900

That’s with default flags though. Some things, like blinking the smooth ramp at the stepped ramp’s steps, didn’t really work well and aren’t enabled by default. So I should maybe take that out.

I’ve been meaning to reduce RAM use by moving some things into ROM only, but it hasn’t really been an issue so I haven’t done it yet. For example, by moving event_sequences into ROM, it seems to save about 22 bytes of ROM and 38 bytes of RAM. And there are a bunch of little things like that which can be done. I just haven’t yet.

1670

There’s a pretty good chance that will break something. It’s not the cleanest code ever, and if I recall correctly it expects turbo to be exactly 255. To get the code small enough, I made some things a bit wonky… which worked fine for use in the BLF A6, but makes it a bit brittle when modified.

1671

D4S with some more flags set. All the ones mentioned above.
That was done by a script to automatically test if the build passes when each flag is switched on/off once.

1672

Sounds like you need more space, would switching to a 1634 help?

With Lexel switching to his programming key it might be a good time to switch to the 20 pin QFN style attinys.
Possibly an adapter board could be made use the new Attiny on older hardware.

1634 specs

• High Performance, Low Power AVR® 8-bit Microcontroller
• Advanced RISC Architecture
– 125 Powerful Instructions – Most Single Clock Cycle Execution
– 32 x 8 General Purpose Working Registers
– Fully Static Operation
• High Endurance, Non-volatile Memory Segments
– 16K Bytes of In-System, Self-Programmable Flash Program Memory
• Endurance: 10,000 Write/Erase Cycles
– 256 Bytes of In-System Programmable EEPROM
• Endurance: 100,000 Write/Erase Cycles
– 1K Byte of Internal SRAM

– One 8-bit and One 16-bit Timer/Counter with Two PWM Channels, Each
– 12-channel, 10-bit ADC
– Programmable Ultra Low Power Watchdog Timer
– On-chip Analog Comparator

1673

It’s not out of ROM or RAM yet, but I hope to keep things relatively space-optimized regardless.

As for the programming key, a large part of why that’s happening is to enable future drivers to use other MCUs, like the tiny1617, tiny1634, and tiny841, and to use smaller packages. It’s not just to make flashing convenient, it’s also to make MCU upgrades possible.

On a related note, a big part of why I made FSM is to make bigger MCUs and more complex firmwares possible. Things were getting unwieldy before, but with some of the tricky details abstracted out into a toolkit, it’s possible to do more complex interfaces.

1674

Is there a preferred way [i.e. Less likely to break something]?

It does actually function as expected but it’s still just a driver on a bench so I’ve got very little of any, and exactly zero real-world, testing.

1675

It seemed like you are spending a lot of time trying to gain back a little memory. People have been talking about more memory and more pins for a while now. Why not now?

The programming key allows the use of qfn packaging. The 85, 841 and 1634 are the same qfn package with varying amounts of unused pins. Switching to the 1634 in qfn package and getting rid of the programming clip gives Lexel more room for components on the board.

It also gives you more programming space. No more fighting for memory, just do what needs to be done without creating more problems for yourself trying to make it fit.

You spend a lot of time and energy on this stuff, I’d like it to be easier for you.

1676

I don’t make the drivers, just the firmware. When there are drivers with more-capable MCUs, I’ll use them. But I still want to make things space-optimized regardless, both to support older hardware and on general principle.

1677

Well I’m super confused. I ordered the BLF X6 driver (BLF X6 X5/Astrolux S2 S3 SS SC Taschenlampe Treiber Sale - Banggood Deutschland-arrival notice-arrival notice) to use in a host with a lighted tail cap, and the UI is doing some funky things. Long story short, I am now using a non-lighted switch and flashed the Bistro firmware onto the driver.

When going through modes and it wraps from the highest mode to low, it does some type of flash before going to the low mode. I can’t see anywhere in the code that this is intended. Also, when half press is enabled in the config, when it attempt to step back from low to the hidden modes, it just does a single flash and goes back to low mode. It did this both before and after I flashed Bistro, so is this a driver issue?

Thanks in advance!

1678

JonnyC My understanding is the X6 driver used a reverse clicky. I only say this in that I had a switch do that once. Changed sw and OK. Maybe hardware problem and not firmware.

1679

The hidden-modes-flash-then-moon thing is a known issue with Banggood’s X6 drivers. It can’t really handle more than about 5 Amps, because FET pulses cause voltage spikes which reboot the tiny25 MCU. Usually it happens on strobe though, not regular turbo. This issue is fixed in later designs, like RMM’s and TA’s FET+1 drivers. It also doesn’t happen on tiny13-based drivers, because the attiny13a is sort of a beast and can operate well outside its specified voltage range.

The initial flash on moon, when accessing it after turbo, is also a known hardware issue. I don’t really know if it’s fixed on newer drivers or not, but I think so.

The interaction between a lighted tailcap and the UI timing should be fixable by adding a bleeder resistor on the driver. Basically, the lighted tail keeps power flowing through the driver, which means the OTC can never really drain, so the driver can’t measure time while off. It’ll then think every button press is short. But a bleeder resistor between BAT+ and BAT- on the driver can allow a small amount of current to flow without keeping the rest of the driver charged up. The resistor values for the bleeder and the tailcap are known to be quite finicky though, and may take some trial and error to get working correctly. Also, it significantly decreases the efficiency of moon mode, since that extra power is always bleeding off.

1680

I wouldn’t go that far, I’ve personally had the exact blink-to-moon-glitch with rmm drivers and during my research of the issue came across plenty of others who had the issue manifest too.
Yes they’re much more stable than the BG version but imo it’s the tiny25, not the PCB which is the culprit.

I definitely concur that either board design is stable with BLF-A6 / other FW on a 13A. On my 17mm rmm board in my S41 I finally got sick of the crap, even after DEL’s “fix” and swapped to a 13A, alls well now!