In some ways I want to try that, but I do kind of enjoy doing the initial setup with a new light.
I feel that. It helped me get familiar with the options and how to navigate the menus, but it gets old when you have about 20 lights with anduril, and you regularly update the firmware for access to new features.
3 Thanks
If you do this enough, it becomes clear that you need to be able to save your user options and re-flash them along with the new firmware…
That sounds remarkably involved for a secondary function, necessitating chips considerably more capable/complex than the core driver/UI components.
I’m not sure what you mean by this?
That’s exactly what I do. My settings are saved in config files on my desktop. I compile the new firmware with my config file, then flash it to my light.
The price difference between an esp32 and a avr32dd is surprisingly small… Firmware is ofc hugely more effort, and you need to squeeze an antenna in.
The light I am considering this for is not possible to open, and has no USB port, so some sort of wireless updates is necessary unless I want to remove bezel, TIRs and MCPCB for every update/flash, which I do not want to do.
BOM may well not be what I assumed, but WiFi represents a lot of moving parts in order to move relatively small amounts of data. Seems like something akin to IrDA would work better for this sort of application (although I expect hardware support isn’t as good as WiFi nor bluetooth).
That is what I meant. For a long time I was flashing the firmware, then manually entering all of my settings. Lots of clicks and too much wasted time.
Left me with the impression that this is what you are/were doing.
Doing what you already do is a great time saver…and it was pretty much what I was trying to suggest. Though I don’t compile anything. I just flash the firmware then flash the saved config file. Probably better to do it your way, but I am not set up to do any compiling. Sorry for the lack of clarity.
Wait, this is possible with Anduril2?
Didn’t know that A2 could read/access separate files outside of itself(the hex file)once its on the light… Interesting!
Would you be willing to share the format of such a config file?
Ah, gotcha. Yeah i mentioned the custom config in my post above that. Compiling actually isnt that hard. There are some instructions on the anduril github for compiling the firmware.
It’s not an Anduril thing. It’s an AVR thing. You can read and write the eeprom in much the same way as reading and writing the firmware. So if you save the eeprom, reflash the firmware, then write the saved eeprom back, it keeps the old settings.
However… the eeprom format makes no attempt to be stable, or portable. Different lights have different data there, and different versions have different data in a different order. So flashing saved eeprom isn’t guaranteed to work. It might give you really bizarre settings.
So it’s sort of a hidden option some people use, but isn’t recommended for general use because it’s almost guaranteed to break sometimes.
That’s my impression too. The onboard config menus may be too complicated for some, but adding a wifi host and web server doesn’t make it any simpler. That makes it quite a bit more complicated.
Like, imagine your flashlight got pwned and the battery drains really fast because it spends all its time crypto mining. That’s not a future I want to build.
Open-source is great, but somebody still has to do the work… and I have no interest in writing or maintaining phone apps unless I can get paid, like, a full living wage for it, in perpetuity.
However, there is already a project started to build a web site where you configure stuff in a browser and then it compiles custom firmware for the user to download and flash. It makes customization easier for people who aren’t accustomed to editing and building code locally.
As for reflashing firmware on devices where the MCU is physically difficult to access, it may be possible to build an optical dongle to communicate with the light through its LEDs, and use a bootloader with support for flashing firmware that way. It can be done on AVR devices with at least 16 KiB of ROM, and the only physical modification required on the torch is to connect the LEDs to an ADC pin on the MCU. The hard parts are building the dongle, writing the bootloader, and maybe modifying the firmware to let it work with a bootloader. It’s still a lot of work, but it’s very do-able.
1 Thank
That can be pretty handy, especially the wifi. If I’m not actively using the light, let it download some torrents in the background, then I can collect them later via usb.
A slot for micro-SD would be nice, too. Or let it be USB-OTG through the charging port…
Maybe it has worked for me because I have only done it on a TS10. And then saved the eeprom data separately for the V1 and V2 lights. Avrdude just saves the eeprom data as a hex file. I just started trying this recently, so I hesitate to recommend it to anyone until I know more and feel more comfortable with it. I may have just stumbled through it and have been lucky. In fact I have only done a couple of the lights this way. It would certainly be nice to be able to do it with more lights.
Btw, I am a bit confused about why this would be any different than what @Whezzel is doing by compiling a config file and using it to flash the eeprom. Just trying to learn here. Good to know the potential pitfalls.
I’m imagining an operational and maintenance overhead that dwarfs the actual UI by a good order of magnitude.
Flashlight as pentesting tool using stock inbuilt hardware is a future no one considered.
Whezzel is changing the source code to make the desired configuration default. The compile puts all the values in the right places regardless of which hardware model or software version is used. If something changes in eeprom, no big deal, the compiler knows about it and moves things around as necessary so it “just works”. It also goes back to the desired config after each factory reset.
What you’re doing is saving a few dozen bytes of binary data, and hoping the meaning of those bytes won’t change from one version to the next. If something moves in that file, or if it’s applied to hardware with different features, it’ll break. And if the user does a factory reset, it forgets and goes back to the stock firmware defaults instead of the customized values.
There are reasons to do both. Like, if you have a whole fleet of TS10 lights that you want to update, and you’re flashing them from a phone, it’s easier to do the eeprom method. But if you have a collection of many different lights and don’t mind compiling your own builds, the source code method is more effective.
3 Thanks
Hence my plan to go for wifi. Every phone/notebook has a web browser. This completely removes the app side development. Also, allows for fun things like adding MQTT and integrate it in a smart home as a smart lightbulb if you really want to (and charge frequently).
It is definitely not the route the average flashlight development should/will take, but it’s a fun thing to play around with that I will absolutely make when I find the time. The Bluetooth app features of the Lupine lights look pretty cool, I would like to recreate something similar, but without the need for an app, basically.
This is cool, and together with a USB port and DFU flashing probably the easiest and most user friendly way of doing flashlights, and what I expect most custom lights to develop into eventually. Flashing tool as a fallback for non-USB lights. Definitely more practical and reasonable than WiFi/Bluetooth, but few things I do in my hobbies are aimed at being reasonable 
Dongles are always a nuisance for me. I have 10 different flashing tools for different devices/MCUs, each needs different drivers, some refuse to work on modern Windows, some refuse to work on Linux because proprietary toolchains, finding the right one from some drawer takes time. For me personally the future is USB, or WiFi. So basically, things I do not need a dongle/special cable/tool for. I try to avoid products that can not do either, for anything I plan on tinkering with. Simple products where I know I will never touch the firmware anyway are ofc an exception.
For the developer no (at least if you wanna do it properly and efficiently, and not just slap some ready-made arduino sample codes together, in which case it’d probably be a few hour job to get a basic proof of concept firmware with few options even for me), but for the user yes. At least if it is not the only way of configuring it. More options are always fun, multiple ways of doing things for different users.
It does, but it has one big advantage - everyone already owns at least one device capable of interfacing with it, without the need of an app, or flashing hardware, or anything. Just open a web browser. A small, static html/css page can easily be stored on the internal storage of most esp32 and similar chips, and is plenty for this application. If it makes sense to fo for wireless comms is a whole different topic.
Only enable WiFi when a button sequence (let’s say 4 short presses from off) happen, and only for a limited time window. Security is the least issue I see there. Getting wifi signal through metal cases, the added PCB surface needed, the added firmware complexity, and the fact that most users do not want or need this feature is a different thing - and the reason why I never suggested you building Anduril around wireless chips. That will just be a fun project for myself.
The flashlight community is pretty well off with the current chips, the only thing I miss about them is a USB peripheral that would actually add QoL on USB equipped lights, and no drawback on others. But WiFi/Bluetooth outside of some weird niche projects that might actually benefit from it (Olight Obulb being a great example, sadly killed by atrocious apps that are incompatible between lights and get discontinued quickly) - nah.