Flashlight Firmware Repository

Anduril

Do we have some soft for red bicycle back light?

There is such a thing, but I don’t actually know how it works.
click - tail light

I am even too stupid to get that Bazaar to open your trunk, the plenty URLs I tried do not work
Anduril does not work properly with temp reading

the Wiki gets it for granted you know which link and how to add and don’t even give any examples

with https://

I downloaded every single file to my PC manually and replaced the old ones, its still reading garbage then it seems to read correctly after running it a while
but testing the driver with heat applied does not adjust output at all

You’re using a website that presents the repository rather than the repository.
The website shows that you should use “bzr branch lp:~toykeeper/flashlight-firmware/fsm” command.
With your UI you may try to enter “lp:~toykeeper/flashlight-firmware/fsm” URL.

Those people who write this bazaar wiki seem to think everyone is an expert programmer and know all the basics

with your link I get this error

Please
all I am asking is a zip or similar container with a working Anduril build for AS7

.

I am wasting again now almost 4 hours on this and can’t build drivers in that time for the community and I have not much time at all right now for weeks and its not looking better this year

I am close to quit Anduril with a March build like I did with NarsilM v1.2 and support no newer versions anymore

Now I seem to got it working but I run into serious code overflow problems using FW3A with Aux LED support

IMO, tell buyers they can have AUX support OR muggle mode but not both. Commenting out muggle saves a lot of space

Add -fwhole-program to the CFLAGS in build.sh, and comment out #define USE_VERSION_CHECK from anduril.c (or USE_BIKE_FLASHER_MODE or another mode if you really need the version check)

#ifdef USE_BIKE_FLASHER_MODE
#undef USE_BIKE_FLASHER_MODE
#endif
#ifdef USE_PARTY_STROBE_MODE
#undef USE_PARTY_STROBE_MODE
#endif

disable 2 strobe modes works as well 99.7% full now

I got absolutely no idea how to do that, that file is not even on the dependencies list in my project

This is the code when open in my Editor

I use a simple build “Anduril” project button with my mouse
I use no scripts or make file or other stuff the programmers are always talking of to build 20 versions at once with different settings in them

v

My bad, I should have realized using Atmel Studio doesn’t use that build.sh. You might be able to get back some space by adding the -fwhole-program flag to the miscellaneous flags here:

But I haven’t tried it. I’m not set up to compile for AVR.

I cant find even that menu you opened

then add “-fwhole-program” ?

PS seems to save 126 Bytes but are there any problems with firmware stability?

Right click on the project in the solution explorer at the right, and choose Properties, to find the menu I showed. Then add the -fwhole-program to that huge list of flags in Miscellaneous (or maybe to the shorter list in Optimization). The flags are separated by spaces, and are what get passed to the compiler I use on the command line instead.

If it still gives you trouble, and you’re willing to wait a few days, I can try to set up Atmel Studio for AVR myself and give it a try.

99.9% with that option with all features enabled


Compression from this flag:
strobe modes like crazy 148→ 6 Bytes for tactical strobe
lightning mode gets a good compression from this option

-fwhole-program wasn’t my idea, it was Agro’s from the FSM thread. It shouldn’t affect stability.

Oh, er, the “ramping-ui” firmware was never shipped on the D4. I think you’re probably looking for RampingIOS. V2 is under the Tom_E directory, and V3 is in the spaghetti-monster directory.

It’s configured in cfg-mateminco-mf01-mini.h, but it’s in the fsm branch along with all the other recent development. The trunk branch is only updated occasionally.

That’s really interesting. I’ve heard a couple other reports of similar things too. I didn’t make a D1 tiny1634 build target, so it’s probably using a D4 V2 driver.

That should work okay, I suppose. Not much is different between the two configurations. But the thermal regulation might act a little weird, pulling the output down faster than necessary. I haven’t tried a D4 V2 firmware build in a D1, so I’m not sure if the thermal response is okay.

Hi, sorry about that. I forgot to add the FETless FW3A build target…

… until you reminded me just now.

It’s now included in the repository as cfg-fw3a-nofet.h.

http://toykeeper.net/torches/fsm/anduril.2019-12-03.fw3a-nofet.hex

Pretty much, yes. It needs to be in its native build environment unless you really know what you’re doing.

To set that up in Windows, step 1 is to install WSL. Either the Debian flavor or Ubuntu flavor should work.

From there, it’s mostly a matter of following the README in the code repository. There are a few commands to run to install other tools, and then the “make” tool should work.

Technically, it can be compiled in Atmel Studio, but it’s not easy and, as shown earlier on this page, people run into a lot of problems trying to do it that way. It’s not supported or recommended, and is an easy way to get headaches or bugs.

Hi, sorry about the delay in responding. There has been a lot to do… any help with thermal regulation would be really appreciated though. :slight_smile:

It’s the part of the code I’ve struggled the most with, and a rewrite is definitely not a bad idea. The abstractions used make it a harder problem than it probably should be, but I haven’t found any good alternatives which still allow the UI and hardware abstractions the system is based on. In particular, keeping it portable across lots of different hardware. A fresh pair of eyes looking at it would be really helpful.

How do you feel about C? I know it’s controversial. constexpr math would allow the compiler to create ramps, so no external script would be needed. Also, templates would allow a more abstract PID to be adapted to specific hardware.

I’ve done C on embedded systems a couple times. It’s definitely possible. I don’t think it would help anything in this case though. Ramp creation and per-hardware code selection haven’t really been issues. Switching has costs though, at least in terms of time but also potentially in terms of code size. Some build targets are already at 99.8% full, and a change of language could easily push them over the limit.

There’s certainly an argument to be made for moving the ramp shape calculations from a table to an onboard formula, since working in units of linear power instead of perceptual brightness would probably make the thermal code a lot more reliable. But that’s unrelated to the language the code is written in.