Flashlight Firmware Repository

My bigger question would be: Who, other that ToyKeeper and TomE is also doing firmware work? And what could be gained from switching to GitHub (or GitLab).

While bazaar works, it has a learning curve to it as it is not that common as git.

As for the issue of building it, that has to do with scripts and documentation. For now, setting up a build environment on Linux is easy. I haven’t tried Windows (without WSL) or OsX.

Otherwise, maybe a online configure-your-build service would be something of interest?

TK and TomE do 95% of the open source firmware work around here that I have seen (although I have not been paying close attention the last year).

I know in theory it is easy to get things to compile on Linux, and once all the dependency’s are installed and setup to compile it is easy to do it from there on out. The setting it up in the first place is the hard part.

It is the single reason I can’t move to linux, the darn obsession with the terminal. I have nothing against the terminal / command prompt to be clear, I started out using DOS 1.0, so I know it has uses. But dang does it have a learning curve something fierce.

Coming from 20+ years of what I think would qualify as advanced skills in Windows / DOS, I can’t even do the most basic things in Linux without having to google for 5 minutes to find the correct command to type in and then find out there are 10 more needed after that. All to forget all of it and have to look it all up again if I ever have to do it again in the future.

For those that use it daily, it truly is a more powerful interface once you have memorized the commands. But for those that do not need or want to memorize the commands, it is a dang nightmare. Why GUI options can’t be added for 90-95% of tasks like windows I will never understand, it does not effect the terminal commands but it allows new users to be able to fumble around for a little bit and figure it out in most cases instead of being up a creek without a paddle should they not have internet.

A position I was in recently that made me realize I was stuck with windows for a bit longer, much to my own dismay. :person_facepalming:

/End rant

In other news, here is a zip of the S43 and MT09R/GT70 drivers. This should include everything from the source code to the gerber files. It is not super organized as I just zipped up the working folder as it was but it should all be there.

S43 Driver + Charger + Firmware + Manual

46mm Texas_Avenger LDO Driver for MT09R or GT70

I combined the driver for both of these lights into a single driver, the firmware is split up but is very similar between them, just minor ramp, thermal and mode changes

Yeah, I understand that.

But if you have a recent update of Windows 10, you can install Ubuntu from the Microsoft store as you would with an app and launch an Ubuntu she’ll from Windows.

After that, you’re good to go.

The “biggest” change is that your C:\ now is called /mnt/c inside Ubuntu.

If you now manage to get into the Anduril folder, you’re ready to run the build script

I refuse to allow the windows store to be installed on my systems, or any other Microsoft spyware bloatware :wink:

I do make extensive use of virtual machines though with VMware and do have a linux install there that is setup to compile firmware and works ok if I can remember all the commands to actually compile it. Generally involves some googling if it has been awhile lol.

Warning: Long post is long.

The Microsoft acquisition certainly threw a bit of a wrench in the gears.

To be clear, Microsoft in 2018 is very different than Microsoft in 1998. Their efforts to destroy free software failed, and now the company relies on free software for quite a few things. But it’s still a bit worrisome seeing the most popular development platform acquired by a big company, especially one with such a problematic history.

Yeah, it gets pretty messy. There is a lot of gardening to do. That’s part of why I went with GPLv3, actually, instead of V2. V3 recognizes that life is messy, and is a lot more tolerant about these things.

Looking at the repository, the people who have contributed projects are (in asciibetical order):

  • DrJones
  • Flintrock
  • JonnyC
  • Mike_C
  • RMM
  • Tamagotchi
  • Tido
  • Tom_E
  • ToyKeeper
  • Werner
  • _the_
  • alexvh
  • dthoang
  • gchart
  • odd
  • pilotdog68
  • tterev3

The main benefit of Git / Github over Bzr / Launchpad is that Git is more popular, familiar to more people. In terms of technical features, either one is more than sufficient… and it pretty much comes down to what is most convenient for people.

I like Bzr more, so I used it. But the differences aren’t a huge deal.

If it helps, most of the setup is pretty quick if you know what to do. But if not, it can be confusing. The basic steps are:

  • Install a Debian-based distro, such as Debian, Devuan, Ubuntu, or Mint.
  • Open a terminal.
  • sudo apt install build-essential gcc-avr avr-libc binutils-avr avrdude bzr
  • bzr branch lp:flashlight-firmware

It may also be desirable to add some extra tools, like qbzr and meld and your favorite text editor or IDE, to make it easier to view changes and such. And it may be helpful to make avrdude always run as root, to make sure it can write data over USB: sudo chmod u+s $(which avrdude)

If I understand correctly, most or all of this can also be done inside an Ubuntu environment under Windows 10.

Afterward, basically just use the scripts provided in the bin/ directory and scattered among various projects. Like, in Anduril, there’s a build-all.sh script.

  • cd flashlight-firmware/ToyKeeper/spaghetti-monster/anduril
  • ./build-all.sh

To make things easier, long file names don’t need to be typed in. Just type the first letter or two, enough to uniquely identify the file, and then hit Tab to auto-complete the rest. And commands typed in the past can be recalled by pressing Up and Down.

I can respect that. I know there are GUI options available for most things, but I couldn’t really tell you what most of them are because I don’t use them. So it’s a bit foreign to me. My experience has been that, with command line tools, I can learn something once and then keep using it pretty much forever. I still use scripts I wrote decades ago. Meanwhile, GUI tools seem to be constantly changing, and the user must re-learn it every couple years. Frequently this means dumping any prior customization or enhancements and starting over with the defaults.

Generalizing quite a bit, GUI tools are typically easier to learn but less powerful, which makes them better for infrequent or casual use which aligns with the scenarios they were built for. CLI tools are typically slower to learn but more powerful, which makes them better for heavy or customized use. Both are important, but it can be unpleasant going from one to the other. Going from GUI to CLI, everything seems arcane and complicated. Going from CLI to GUI, everything seems slow and limited.

I’ve been trying to make this a bit easier for everyone by keeping everything in one place, but sometimes it takes me a while.

Thanks! I’ll get this merged in as soon as I can.

You have very valid points about the command line. Like I said I know the power of it and can appreciate it.

I would love to see Linux become a viable option for the masses though with windows now being basically pure spyware. Earlier this year I was actually going to switch over most of the systems in my house to Mint but after setting up the first few I quickly realized it was just not ready for the masses. When I have to search google and use a terminal for the most basic of functions, no way is a normal user going to figure it out.

So really it is more annoyance that there is not a viable alternative to windows then anything “wrong” with Linux. I truly want to move to linux in a bad way.

Someday I hope to see linux become a real option in the consumer PC market.

It depends on who you ask and what they want from their computer. Some people are still waiting for the Year of the Linux Desktop, while others insist it already happened a long time ago. Me, I think it happened in the mid 1990s. I’ve tried Windows every few years, waiting for it to catch up and become a viable desktop option, but it still hasn’t gotten there yet. Some things have been improving, like it finally got virtual desktops in Windows 10, but it still has a long way to go.

The main thing I can say for sure is that they’re different and they’re unlikely to ever converge. Choosing one depends mostly on the user’s values and expectations.

Switching will likely remain painful indefinitely. They overlap, like two circles in a Venn diagram, but they also have a lot of area which doesn’t overlap. While switching, people tend to see the entire circle of where they’re coming from, but only the overlapping portion of where they’re moving to, so it doesn’t look very good. But there’s a lot of new territory to explore too, and it may not be visible.

Has anyone here tested the BLF GT extensively with Anduril?
I swapped my TN42 driver (BLF GT driver) and got Anduril flashed on it. I probably took the light apart 5 times by now to check if there’s something wrong with my connections or the switch. The light works fine for a few hours and then the wierdest stuff starts to happen. Sometimes it starts to flicker, pressing the switch makes the flickering brighter or dimmer. Sometimes it would just switch off when I go into turbo. Sometimes activating muggle mode makes it strobe and there’s no way of switching the light off then.
If I break the battery connection it works fine again up to a certain point. Especially multiple short clicks seem “break” it.
Now I gave up on it and flashed Narsil back on it and so far everything works fine. I’ll test it out for a week now with Narsil and if there are no problems, I’ll give Anduril a new try.

Edit: Activating or leaving the muggle mode seems to be especially problematic. In 50% of the cases this “breaks” the light.

I have yet to use Anduril at all outside of a quick test I did on my Q8. The firmware showed promise, I just have never had time to dig into the code. Usually takes me a week or 2 to get used to a new firmware code (even to the minor extent I understand the technical side) and have not had nearly that much free time lol.

As a discrete mode user I might as well suffer with what I have so far and live with the quirks. I won’t get used to the Narsil UI in 100 years. :smiley:
I don’t know if it’s a hardware or software problem, that’s what’s bugging me the most.

I’m running Anduril on my GT, and haven’t seen any issues on it. Which exact file did you flash to it? I could try to reproduce the issues using the same file.

I have also Andúril on my GT. But I don’t use it very often.

I flashed anduril.2018-09-30.BLF_GT.hex yesterday, but had anduril.2018-09-07.BLF_GT.hex on before. The thing is, I can’t really reproduce the problem. But doing a lot of clicky actions (as opposed to single clicks or holds) seem to increase the chance of failing.
A problem with the e-switch seems be unlikely, if the light works again after I disconnected and reconnected the batteries, right?

If the switch acts weird and it helps to loosen / tighten the batteries, it could be a bad connection to ground or something. I get that on the FW3A prototypes sometimes, especially after it has been knocked around. If I hit it sideways sometimes it seems to move the inner tube just enough to cause problems, so I have to loosen/tighten it to reset things. The firmware seems fine though, because even if I do it fast enough that the MCU doesn’t reboot, all the symptoms go away after re-seating the physical connections.

Anyway, I downloaded the 09-30 build and flashed it to my GT. I’ll keep an eye out for anything weird, but I ran through all the modes and so far it hasn’t done anything it’s not supposed to.

Whats updated from Anduril 9/7 to 9/30?
Thanks!

In detail, this is what changed:

https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/fsm/changes

I have been looking at the Anduril firmware for a project light I am working on. Got it to compile now I am trying to understand it so I can design the driver.

The big hangup I am having right now is the LVP. The drivers that do not use a voltage divider still seem to use a pin for ADC measurements in the firmware. Where / What is the setting to switch between a voltage divider and internal voltage sensing?

Setting: ADMUX_VCC in tk-attiny.h, with a mix of the hardware-definitions (hwdef-BLF_GT.h vs hwdef-Emisar_D4.h, #define USE_VOLTAGE_DIVIDER)

Where it's done: fsm-adc.c

In fsm-adc.c, it switches between reading the temperature and VCC values.

Thanks, keep in mind I know just enough about C code to get my self in trouble and fully admit it.

So best I can understand, if the” #define VOLTAGE_PIN” is set to PB2 (maybe it ignores the pin completely when using the internal ref?) and “#define USE_VOLTAGE_DIVIDER” is not set, then it defaults to the internal voltage reference and there is nothing else I need to do.

If “#define USE_VOLTAGE_DIVIDER” is set then it uses an external voltage divider?

So basically adding or removing the “#define USE_VOLTAGE_DIVIDER” is all I need to do to switch between these options?

What about pin 7? What does it need to be connected to if using the internal voltage? Can it be used as an indicator LED output? Can I set the voltage sensing (internal or external) to another pin?