Flashlight Firmware Repository

Thanks for the reference :slight_smile:
It’s an interesting implementation, ill test on my diving light soon

TK
I wanted to flash Anduril in my D4 with xpl-hi. But what does the lower muggle ceiling mean? I found it here

That was a one-off special build because someone requested a version with muggle mode limited to ~150 lm.

Thanks for this. This is exactly what I needed after I enabled some additional code in Anduril for dual switch support. I ran out of space and couldn’t make sense of the compile options I was missing in Atmel Studio. Now it compiles without issue!

Texas_Ace, were you ever able to suss out those problems with the GT70 style driver and Anduril? I’ve been researching a lot, and trying to find a way to get Anduril onto my GT70, but am not coming up with much information unfortunately.

Are Anduril inputs and outputs assigned to the same ports as Narsil and bistroHD?
Narsil:

bistroHD:

And Anduril?

Yes

Check the individual hwdef files to see how the pins are mapped for different types of hardware:

https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/fsm/files/head:/ToyKeeper/

/* BLF GT driver layout
* ----
* Reset -|1 8|- VCC (unused)
* eswitch -|2 7|- Voltage divider
* AUX LED -|3 6|- Current control (buck level)
* GND -|4 5|- PWM (buck output on/off)

/* Emisar D4 driver layout
* ----
* Reset -|1 8|- VCC
* eswitch -|2 7|-
* AUX LED -|3 6|- PWM (FET)
* GND -|4 5|- PWM (1x7135)

/* Fireflies ROT66 driver layout
* ----
* Reset -|1 8|- VCC
* eswitch -|2 7|- optic nerve
* FET -|3 6|- 7x7135
* GND -|4 5|- 1x7135

As always very helpful. Thanks a lot!

I actually do have some experience in programming Arduinos but I am quite lost in the repository.
Could somebody point me out which files I would need to compile the code for the FW3A?

Sorry, it’s kinda buried. The top level of the code organization at Launchpad is branches. Normally everything is in the trunk branch, but that’s treated as a place for stable code to land. Development is done elsewhere. In this case, development happens in the fsm branch, and in other branches off of that one. So the fsm branch is a better place to check for the latest updates.

Within a copy of the repository though, the top-level directories are authors, and then the next level is projects. Anduril is part of the FSM project, also known as Spaghetti Monster… so the full path is ToyKeeper/spaghetti-monster/anduril .

It’d be a good idea to branch a local copy of the whole repository, in order to get all the files and preserve the directory structure. It’d also be a good idea to use the included build scripts, like typing “make” in the Anduril directory. Grabbing individual files tends to lead to problems, and building it with other tools works but isn’t really supported.

Sometime soon I really should merge everything back into trunk. It has been a while. I’m just waiting on some projects to finish first, because there are a bunch of changes which haven’t quite landed yet.

Thank You! I got it.
Next step ist to try to compile the code. Should not be to complicated on Linux, I think.

Compiling works now, but the code is much more complicated than I thought :weary:

Help with Launchpad and Bazaar in Windows?

If you feel that this post doesn’t belong here or is a repeat, politely let me know and I will move or remove it.

Scanning this thread indicates that getting the code has not been a problem for anyone else; troubles only seem to arise when trying to build or flash. Though not an expert, I can RTFM, build/compile from examples, and have a handful of programmers on hand when/if needed. Those tasks are not (yet) a problem, but getting the repo has been anything but simple for me.

I installed Bazaar standalone in Windows and added bzr to PATH.
I tried bzr branch lp:flashlight-firmware and got error saying I needed to authenticate. Thus, I went down a rabbit hole for hours…

I cannot accurately list all of the steps I’ve taken to get this working as I’ve forgotten the exact sequence (I did this in 2018-11), but at the very least I:

  • Signed up with Launchpad/UbuntuOne (OpenID)
  • Created/shared OpenPGP key
  • Signed Ubuntu Code of Conduct
  • Established Launchpad/UbuntuOne SSH key
  • Opened Windows command prompt:
    $ cd
    $ bzr whoami

    $ bzr launchpad-login

    $ bzr branch lp:flashlight-firmware
    Connected (version 2.0, client Twisted)
    bzr: ERROR: Connection error: Unable to authenticate to SSH host as
    @bazaar.launchpad.net
    supported auth types: [‘publickey’]
    $ bzr help stupidity
    bzr: ERROR: No help could be found for ‘stupidity’. Please use ‘bzr help topics’
    to obtain a list of topics.
  • Read LaunchPad documentation
  • Read Bazaar documentation
  • Pulled out my 3 remaining hairs.

I accept that I don’t understand Bazaar’s paradigm and grok Launchpad’s unique implementation even less, but even this idiot should be able to download a repo…

I’ve done some searching and scanned dozens of pages of this thread looking for help, but so far come up short. Is there a post that I’ve missed regarding the use of launchpad? I’ve been using git for a long time, but only locally so I’m not an expert. I’ve never before needed authentication just to get a repository. I assumed that repos were freely available as read-only. I don’t even understand why I need an authenticated SSH key to pull a repo :person_facepalming: .

TK put this on launchpad to make it easy to get. What am a missing?

I went through the same thing, and as far as I can remember, the crucial step was to run pageant (which is part of PuTTY) and load the generated private key into it. Then you can run the SSH session (in PuTTY, never tried it in a cmd prompt).

Yes, frustrating as hell, and it feels like a big FU to the windows plebs.

Because you might as well run Linux in a VM (which is a useful thing, by the way) and not be bothered with any of that when you pull a bzr branch. Just install the bzr package and it works. (Could be that *ubuntu has SSH set up by default, but still.)

Which is what I ended up doing anyways.

Thanks so much! It makes me feel a lot better knowing that other people have done this as I’ve been worried that none of this was necessary. Even TK has said that bzr branch flashlight-firmware is the easiest way to get the firmware. I’m sure she’s right if you type it from Linux :person_facepalming: .

I installed the key into PuTTY, but am then confused about how to run Bazaar from PuTTY. I did manage to do so once back in January, but no longer remember how I did it and I seem recall that I still had problems :blush: . I won’t ask for help with that as that’s surely something I can look up on my own. It seems odd to me that BZR knows my identity on the command-prompt, but does not negotiate the SSH session. I don’t understand the system and understanding is key.

[sigh] I’ve got Linux VM’s lying around, but I’m a fool that has always coded and flashed with Windows, so that’s what I wanted to do here. I’ve used Linux since first installing Red Hat in 1998 (and Unix since college in 1994), but have never truly moved; I’ve learned the hard way that dipping your toes into Posix from the comfort of Windows does not lead to mastery.

I thought that I was going about this entirely wrong, so your reply at least let’s me know that I’m not crazy. I will try to come at this from a Linux VM and see what happens. Thanks again!

It has gotten a bit complicated in structure, in order to make things portable and keep the actual UI code relatively simple.

There are a few different layers or components…

  • There’s the hardware-specific stuff, the hwdef-*.h files and the attiny abstraction header. This helps convert hardware-specific code into a more abstract API for portability.
  • There’s the UI toolkit, called FSM or “spaghetti monster”. It’s sort of a cross between a GUI toolkit and an OS kernel. It talks to the hardware, handles hardware events, does task scheduling, and exports a much friendlier API for applications to use.
  • There’s the application itself, Anduril. It’s written in the abstract UI language of FSM. It defines states (modes), event handlers, transitions between states, and an idle processing loop.
  • … and there are config files for Anduril. These set different options for different build targets. Mostly the build targets are one per supported hardware device. The config files set things like the ramp shape, the thermal response details, the aux LED settings, which modes to include, and other app-specific options.

The main thing you probably need to edit to make UI changes is anduril.c. And to better understand the FSM API it’s written in, there’s a thread about how FSM works.

Or… To add support for a new type of hardware, it may be as simple as adding an Anduril config file for a new build target. It may also require a new hwdef file to map the pins and such. And depending on how different the hardware is, it could also require changing FSM itself, which I wouldn’t generally recommend for anyone who hasn’t spent a lot of time with it. Normally, people just hire me to do that because it’s not a very straightforward task. It’s called a “spaghetti monster” because all the complicated “spaghetti code” is under the hood where UI developers don’t have to care about it.

That’s odd. It’s not supposed to require authentication.

If the “lp:” prefix makes it try to use ssh, it should be able to bypass that by using a different URL. For example:

bzr branch ~toykeeper/flashlight-firmware/trunk : changes

However, I just tried this and it’s giving me HTTP errors. As far as I’m aware, Launchpad has only had one or two people maintaining it for the past several years, and bzr itself hasn’t really been updated at all in a year or two. The company has basically ended most development on both.

So it may be a good idea to look into moving things to GitHub. I don’t like Git as much, especially how it handles branches and merges… but at least it’s actively maintained and doesn’t completely lack any critical features. The hardest parts of a move are the people-related parts, not the tech underneath. Overall, GitHub would probably be easier for everyone except me.

I don’t suppose there is a cheat sheet for which firmware will work on which drivers?