Flashlight Firmware Repository

Honest question: what’s the harm with leaving the firmware as-is?

I snipped the leads and just wanted to make sure they weren’t powered. Maybe I’m being too OCD?

Ohhhh. If you unsoldered them, there shouldn’t be any risk. Being snipped, there is a small risk yeah.

I don’t think a pre-built file would help honestly. My biggest fear would be if a wire touched the body of the flashlight (ground) causing a short. To avoid a “short” situation you’d need the aux wires to be driven low (ground) by the MCU. I’m not sure if Anduril/FSM is like this, but it’s common to set unused MCU pins to input-pullup (positive with a ~25000 Ohm internal series resistor).

When you have the aux LEDs enabled but in the “dim” setting, that is actually being used to power the LEDs: the MCU’s internal ~25000 Ohm resistors. So if you know that aux is set to “dim” and you have a loose wire touch, it wouldn’t be a true short… it’d only source about 0.17 mA (very very little).

But I think your best bet would be to unsolder the wires if you can.

Great information thank you. I’ll go a step further and just unsolder the leads.

Maybe this is the topic for the questions I got

1) I got D4V2 with KR4 CC 5A driver (LED - Nichia 219c) and have noticed that it seems like main channel and FET are active together when FET is active (config file - cfg-noctigon-kr4-219.h) - why it is like that? I may be wrong, but shouldn't it be like FET only?

// don't turn off first channel at turbo level
#undef PWM1_LEVELS
#define PWM1_LEVELS 0, ... ,1023


2) I have compared config files for kr4 (cfg-noctigon-kr4.h) and original driver d4v2 (cfg-emisar-d4sv2.h) and found those difference, which makes me question why it's like this (exept differences in configs that I can undestand, like AUX LED in button, soft reset with button and so on - wich root cause are hosts possibilities)

D4V2:
// stop panicking at ~30% power or ~1200 lm
#define THERM_FASTER_LEVEL 105

KR4:
// stop panicking at ~25% power or ~1000 lm
#define THERM_FASTER_LEVEL 100
#define MIN_THERM_STEPDOWN DEFAULT_LEVEL
#define THERM_NEXT_WARNING_THRESHOLD 16 // accumulate less error before adjusting
#define THERM_RESPONSE_MAGNITUDE 128 // bigger adjustments

So, I see different thermal settings and the question is - this difference due to bigger kr4 thermal mass, or the driver itself? In other words, should I change them for my light like in original d4 config (remove them, so ones from fsm will be taken)?

For 1), for FET+1 designs we turn off the 7135(s) channel because giving all the amps to the FET is more efficient, meaning is higher amps. Since TK probably was the one who wrote the config files, she probably found out having both channels on results in more amps rather than less amps, but that's my interpretation

For 2), the difference is a combo of things - but comes down to mass and amps (heat) the driver and light can produce. More mass may mean nothing if you have more amps, for example.

Than you for your answer, it’s really making things more clear to me.

I got another question about branches: I’m really not familiar with launchpad. What is the difference between lp:flashlight-firmware and lp:~toykeeper/flashlight-firmware/fsm. Second one seems newer, so I assume I should use this branch to get latest Andruil?

I debated posting this as a separate thread, but has anyone used Platform IO (https://platformio.org/) to modify and flash firmware to Atmel based boards?
It appears to support most of the AVR boards we deal with, and in fact I’m pretty sure it’s wrapping the standard AVRdude tools up. I haven’t personally tried it yet in the tiny MCU space, but I find it to be fantastic for Arduino and ESP32/8266 board development and flashing. It’s much superior to the clunky interfaced Arduino IDE and uses Visual Studio Code as the host.

I'm not familiar with it but I can see advantages if you regularly deal with various MCU and board/computer designs, or at least want that flexibility. We've been extremely tight on code space, so not sure if it would work for us, unless we go with the 32 KB MCU's like the 1-series 3216. We (well I mean gchart ) have Anduril support basically working for this MCU. I think right now, the 1-series 1616 and 3216 are our best options with 3 pin flashing, small footprint, calibrated temp sensor, and advanced features.

If I could write firmware for ATTiny's in C#, that would be outrageous! Not sure if this platform supports that though - it looks like C/C++ but gives a wink to C#. I've been spoiled rotten working in C# over the last few years.

Funny enough, I write C# based applications in the .NET framework (mostly web apps) as well! There’s a lot of developer ergonomics I miss when I’m outside of that space.
As to Platform IO, at least in my experience, you’re still sticking to the same C / C code, but you get some additional conveniences such as pulling code libraries in from their package repository or referencing a Github url. And having the command palette abstract all of the cmd line stuff for flashing and monitoring your boards. And of course, VS Code is a fantastic editor to work with. I pretty much exclusively work in it for the front-end Javascript editing.

The Rust language now has AVR support baked in. Rust isn’t quite C# but it has lots of developer experience things that are missing in C, supposedly without any performance trade offs.

https://book.avr-rust.com/

It looks like it supports loads of ATTiny at ATMega CPUs avrd - Rust

Do you have any information about how size-efficient are AVR binaries written in Rust compared to C ones? Because it’s a major limitation…

I can’t find any information on it and I haven’t tried myself. On x86 CPUs Rust binaries are often bigger than C or C.

Would be interesting to try porting FSM to Rust, just to see. There’s automated tools like Porting Code · A Guide to Porting C and C++ code to Rust but it looks like they wouldn’t be as good as porting it manually.

This is a different case. Rust binaries are statically linked which makes them comparatively very large.
But in the embedded space everything is statically linked, so no difference here.
On the other hand is LLVM as good as gcc in optimizing for size? I played with that years ago on a different target and it was not. But this experience may not be relevant now.
Also, how does the higher level nature of rust lend itself to space optimizations? It works well for performance which is a good sign. But it is not a certainty.

BTW, modern MCUs tend to have much more flash. So dropping compatibility with older lights (as well as many modern ones that still use older MCUs) would make things much easier. I don’t expect our greatest firmware developers to go this way any time soon but I wouldn’t surprised to see someone else experimenting with Rust either.

Please help me make things clear with branches. I’m really not familiar with launchpad. What is the difference between lp:flashlight-firmware and lp:~toykeeper/flashlight-firmware/fsm. Second one seems newer, so I assume I should use this branch to get latest Andruil?

Yes, fsm is the main development branch. You can also try anduril2, the next version of Anduril.

Is there an Anduril version that uses only the FET and no 7135’s? I would need one for 6V and 12V drivers.

You can use any single channel config (often “nofet”) and use the corresponding pin.

Please help. I tried to flash an fw3a driver with narsil and got this error… “Event not declared”

Cannot see the picture. Have you modified narsil to run on the driver?