Flashlight Firmware Repository

2251 posts / 0 new
Last post
trakcon
trakcon's picture
Offline
Last seen: 38 min 11 sec ago
Joined: 01/23/2019 - 15:50
Posts: 387
Agro wrote:
trakcon wrote:
These are the latest builds from the development (not always fully tested) branch. I haven’t had any issues with the newest build on my D4V2 Ti.
Thanks, that’s exactly what I was looking for. Thumbs Up
Big Smile
D'AVerk
Offline
Last seen: 1 week 23 hours ago
Joined: 09/05/2018 - 07:48
Posts: 127
Location: Russia

In this beautiful software there are one awful thing.
Every time, when i am going to check voltage, if i shutdown flashlight on high level, i get huge preflash during 3 short click. And because moonlight not remembered – even if i firstly switch on by hold on moonlight and off then – huge preflash would appear.

It would be essential, if software d’t turn immediatly on memory level after first click. Just moonlight for first 0.1-0.2 sec and only after – turn back to memorized level. So, if we do many clicks – as for voltage check, software would catch next click before turning power up to memorized level.

Agro
Agro's picture
Online
Last seen: 9 sec ago
Joined: 05/14/2017 - 11:16
Posts: 6421
Location: Ślōnsk

I use gentoo on my dev machine. I just got a notice that bzr will be removed from the package repo in 30 days because it requires Python 2. They recommend that I switch to breezy.

d_t_a
Offline
Last seen: 4 hours 16 min ago
Joined: 08/04/2017 - 23:58
Posts: 2190
Location: Manila, Philippines

D'AVerk wrote:
In this beautiful software there are one awful thing.
Every time, when i am going to check voltage, if i shutdown flashlight on high level, i get huge preflash during 3 short click. And because moonlight not remembered – even if i firstly switch on by hold on moonlight and off then – huge preflash would appear.

It would be essential, if software d’t turn immediatly on memory level after first click. Just moonlight for first 0.1-0.2 sec and only after – turn back to memorized level. So, if we do many clicks – as for voltage check, software would catch next click before turning power up to memorized level.

Seems to be a worthy change if possible. I usually don’t turn off from High, so maybe I don’t encounter it often, but I’ve encountered this (bright pre-flash) when doing the triple-click battery check.

SammysHP
SammysHP's picture
Online
Last seen: 4 min 36 sec ago
Joined: 06/25/2019 - 14:35
Posts: 652
Location: Germany

Agro wrote:
I use gentoo on my dev machine. I just got a notice that bzr will be removed from the package repo in 30 days because it requires Python 2. They recommend that I switch to breezy.

I use breezy for months already, works great. The multi backend support (bazaar and git) is nice. Much better than fast-export. But for me it’s still just a bridge between bazaar and git. Wink
Tom E
Tom E's picture
Offline
Last seen: 1 hour 26 min ago
Joined: 08/19/2012 - 08:23
Posts: 13805
Location: LI NY

d_t_a wrote:
D'AVerk wrote:
In this beautiful software there are one awful thing. Every time, when i am going to check voltage, if i shutdown flashlight on high level, i get huge preflash during 3 short click. And because moonlight not remembered - even if i firstly switch on by hold on moonlight and off then - huge preflash would appear. It would be essential, if software d't turn immediatly on memory level after first click. Just moonlight for first 0.1-0.2 sec and only after - turn back to memorized level. So, if we do many clicks - as for voltage check, software would catch next click before turning power up to memorized level.
Seems to be a worthy change if possible. I usually don't turn off from High, so maybe I don't encounter it often, but I've encountered this (bright pre-flash) when doing the triple-click battery check.

Not sure of the solution would be more painful than the problem. I do agree it's annoying - happens to me all the time, but adding the delay to the basic click ON - I dunno...

ChibiM
ChibiM's picture
Offline
Last seen: 21 hours 14 min ago
Joined: 05/09/2011 - 10:25
Posts: 6510
Location: Holland

Just a quick question: I assume all flashlights have slightly different coding? So I can't just adjust 1 code and upload it to several Anduril lights I own, for example: Noctigon D18, Lumintop FW3A etc. 

 

Actually I have a second question, when I go to this overview: https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper

I'm trying to download but get errors each time. 

Chatika vas Paus
Chatika vas Paus's picture
Offline
Last seen: 1 hour 28 min ago
Joined: 09/03/2017 - 13:46
Posts: 950
ChibiM wrote:
Just a quick question: I assume all flashlights have slightly different coding? So I can’t just adjust 1 code and upload it to several Anduril lights I own, for example: Noctigon D18, Lumintop FW3A etc.

Anduril has separate files for several more popular flashlights. They usually differ in the number of pwm outputs, auxes, button illumination, “maximum power” and temperature, or smaller “BLINK_AT_RAMP_MIDDLE” settings.
But if you are sure that the driver has the same structure and flashlights have the same functionality then one file should be enough.

ChibiM wrote:
Actually I have a second question, when I go to this overview: https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper I’m trying to download but get errors each time. 

TK seems to be trying to refresh the entire library. Check this thread.
At this link you will download (probably) the latest version (482). (Whole repository).

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 14 hours 26 min ago
Joined: 01/12/2013 - 14:40
Posts: 10623
Location: (469219) 2016 HO3
Agro wrote:
I use gentoo on my dev machine. I just got a notice that bzr will be removed from the package repo in 30 days because it requires Python 2. They recommend that I switch to breezy.

Long story short… bzr (bazaar) has become brz (breezy).

Longer version: Most of bzr’s development was funded by Canonical, and the company’s entire development process was built on bzr and Launchpad. Around 2010, the company changed priorities from a community-first approach to a profit-based approach. Lots of things changed over the years, and development for Launchpad and bzr was scaled back to just a few people. They also started adding support for Git, and some of the newer developers switched to GitHub instead of using the company’s own system. In 2017, after several failed attempts at profitable projects, the company laid off most of its developers. Soon after, some of the original bzr devs then continued to work on bzr in their own time, but renamed it to brz to signal a new direction… and they were much more free to do what they wanted with it. It was a labor of love again, not tied to a company. The original bzr is effectively dead, replaced by brz.

Tom E wrote:

d_t_a wrote:
D'AVerk wrote:
huge preflash during 3 short click. … Just moonlight for first 0.1-0.2 sec and only after – turn back to memorized level.

(bright pre-flash) when doing the triple-click battery check.

Not sure of the solution would be more painful than the problem. I do agree it’s annoying – happens to me all the time, but adding the delay to the basic click ON – I dunno…

Yeah, prioritizing the path to battcheck would mean adding a delay at each normal activation… so it seems like spending $20 to save $5.

However, there are two ways to solve it… the user could build a customized verison with “B_TIMING_ON” set to “B_TIMEOUT_T” to make it wait until inputs are fully resolved before responding. Or if a “soft start” is ever added, that might reduce the pre-flash too.

I tried adding a soft start once though, and it added a lot of complication and potential for bugs, since it didn’t react well to being interrupted. But perhaps I could try again after doing some refactoring.

ChibiM wrote:
all flashlights have slightly different coding? So I can’t just adjust 1 code and upload it to several Anduril lights I own, for example: Noctigon D18, Lumintop FW3A etc.

The code is structured to make the hardware details and UI details separate. If you change the UI, it generally should work on each supported device… and if you change the code for a supported device, it generally won’t affect the UI or any other devices.

For the most part, the code for each specific device is limited to only a hardware definition file (MCU pinouts, hardware features) and a UI config file (ramp shape, interface options). The rest is shared across all devices.

It’s very similar to how a regular computer works… there is an operating system and there are applications. But in this case, there’s a microkernel and a user interface… and they’re compiled into a single file to save space.

After making UI changes, it’s normally recommended to run “make”, which builds the firmware for every supported device. Then match up the .hex files with the devices you want to flash.

ChibiM wrote:
when I go to this overview:
https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/files/head:/ToyKeeper

I’m trying to download but get errors each time.

That should be resolved very soon. A bug popped up in Launchpad a couple days ago, I reported it yesterday, and a fix was committed today. So it should be in the next site update, and the updates happen frequently.

(edit: it’s fixed now)

Agro
Agro's picture
Online
Last seen: 9 sec ago
Joined: 05/14/2017 - 11:16
Posts: 6421
Location: Ślōnsk

Thank you for the story ToyKeeper. I’ll switch to brz then.

flucero28
Offline
Last seen: 4 months 3 weeks ago
Joined: 04/24/2012 - 11:24
Posts: 46
Location: New Mexico

Hoping someone can help me. Pulling my hair out.

I’m trying to make a small change to the dragon low color output. I want it lower.

So I change it from this:

// THESE VALUES ARE USED FOR EASY LEVEL CHANGING INSTEAD OF USING THE RAMP
#define RAMP_SIZE 8
#define RAMP_7135 *25*,255,0,0,0,0,0,0
#define RAMP_FET 0,0,1,15,40,90,140,255

To this: (25 to 10 for first value)

// THESE VALUES ARE USED FOR EASY LEVEL CHANGING INSTEAD OF USING THE RAMP
#define RAMP_SIZE 8
#define RAMP_7135 *10*,255,0,0,0,0,0,0
#define RAMP_FET 0,0,1,15,40,90,140,255

It builds fine in atmel studio. It flashes to the attiny25 on the board no problem.

However, the brightness level does not change. I have tried flashing many times, no affect. What am I doing wrong or not doing correctly?

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 14 hours 26 min ago
Joined: 01/12/2013 - 14:40
Posts: 10623
Location: (469219) 2016 HO3

flucero28 wrote:
I’m trying to make a small change to the dragon low color output. I want it lower.

So I change it from … 25 to 10 for first value …

However, the brightness level does not change. I have tried flashing many times, no affect. What am I doing wrong or not doing correctly?

I’m not sure, but I recall hearing about some issues with the Dragon boards having a leaky 7135 chip which stays on even during the white modes. If you’ve got one of those, it might not be possible to lower it below a certain point.

To test it, try changing the first white mode to 0, and check if the color channel stays on.

It’s possible the white LEDs could be on at level 0 too, but that usually means it’s using fast PWM instead of phase-correct. Might be worth checking that too.

flucero28
Offline
Last seen: 4 months 3 weeks ago
Joined: 04/24/2012 - 11:24
Posts: 46
Location: New Mexico

ToyKeeper wrote:
flucero28 wrote:
I’m trying to make a small change to the dragon low color output. I want it lower.

So I change it from … 25 to 10 for first value …

However, the brightness level does not change. I have tried flashing many times, no affect. What am I doing wrong or not doing correctly?

I’m not sure, but I recall hearing about some issues with the Dragon boards having a leaky 7135 chip which stays on even during the white modes. If you’ve got one of those, it might not be possible to lower it below a certain point.

To test it, try changing the first white mode to 0, and check if the color channel stays on.

It’s possible the white LEDs could be on at level 0 too, but that usually means it’s using fast PWM instead of phase-correct. Might be worth checking that too.

Thank you TK. I started all over from scratch in Atmel studio and it worked the first time. Must have been a glitch somewhere. Facepalm

Capital
Offline
Last seen: 3 months 2 days ago
Joined: 05/23/2018 - 16:21
Posts: 17
Location: SW Missouri

Can someone recommend an Anduril hex file for a D4V2 without the auxiliary lights?

I have a D4V2 that I’ve been swapping MCPCBs and I’m not reconnecting the aux light board. I assumed I could grab a hex file for another Anduril light without the aux lights but I’m not having any luck.

Any input would be greatly appreciated.

gchart
gchart's picture
Online
Last seen: 17 sec ago
Joined: 03/19/2016 - 11:57
Posts: 2787
Location: Central IL

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

Capital
Offline
Last seen: 3 months 2 days ago
Joined: 05/23/2018 - 16:21
Posts: 17
Location: SW Missouri

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

gchart
gchart's picture
Online
Last seen: 17 sec ago
Joined: 03/19/2016 - 11:57
Posts: 2787
Location: Central IL

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.

Capital
Offline
Last seen: 3 months 2 days ago
Joined: 05/23/2018 - 16:21
Posts: 17
Location: SW Missouri

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

Garik F
Offline
Last seen: 3 hours 13 min ago
Joined: 09/13/2020 - 12:17
Posts: 38
Location: Russia

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)?

Tom E
Tom E's picture
Offline
Last seen: 1 hour 26 min ago
Joined: 08/19/2012 - 08:23
Posts: 13805
Location: LI NY

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.

Garik F
Offline
Last seen: 3 hours 13 min ago
Joined: 09/13/2020 - 12:17
Posts: 38
Location: Russia
Tom E wrote:

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?

thebentern
Offline
Last seen: 1 month 1 week ago
Joined: 10/03/2017 - 08:36
Posts: 11
Location: Arkansas

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.

Tom E
Tom E's picture
Offline
Last seen: 1 hour 26 min ago
Joined: 08/19/2012 - 08:23
Posts: 13805
Location: LI NY

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 smile) 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.

 

thebentern
Offline
Last seen: 1 month 1 week ago
Joined: 10/03/2017 - 08:36
Posts: 11
Location: Arkansas

Tom E wrote:

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 smile) 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.
dave1010
dave1010's picture
Online
Last seen: 11 min 53 sec ago
Joined: 07/04/2017 - 02:38
Posts: 139
Location: Dorset, United Kingdom

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 https://docs.rs/avrd/0.1.2/avrd/index.html

https://davestechreviews.wordpress.com/ / Email: <my BLF username>@gmail.com

Agro
Agro's picture
Online
Last seen: 9 sec ago
Joined: 05/14/2017 - 11:16
Posts: 6421
Location: Ślōnsk

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…

dave1010
dave1010's picture
Online
Last seen: 11 min 53 sec ago
Joined: 07/04/2017 - 02:38
Posts: 139
Location: Dorset, United Kingdom

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 https://locka99.gitbooks.io/a-guide-to-porting-c-to-rust/content/porting... but it looks like they wouldn’t be as good as porting it manually.

https://davestechreviews.wordpress.com/ / Email: <my BLF username>@gmail.com

Agro
Agro's picture
Online
Last seen: 9 sec ago
Joined: 05/14/2017 - 11:16
Posts: 6421
Location: Ślōnsk

dave1010 wrote:
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++.

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.

Garik F
Offline
Last seen: 3 hours 13 min ago
Joined: 09/13/2020 - 12:17
Posts: 38
Location: Russia

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?

SammysHP
SammysHP's picture
Online
Last seen: 4 min 36 sec ago
Joined: 06/25/2019 - 14:35
Posts: 652
Location: Germany

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

Pages