Anduril ... 2?

Yeah, out of all the changes in Anduril 2, reworking the diagram has ended up taking the longest. It’s tricky to arrange so much info in visual form and still keep the layout clean.

I’m not surprised the documentation is taking time.

Along with things like simple mode, documentation is a huge part of having an accessible UI. If the docs are good then manufacturers will be happier that their lights are targeting all users instead of just experts. It also makes it easier for us to lend or recommend lights with Anduril to others.

The state diagram is great and my brain grocks it. I wonder if a more task-oriented diagram (similar to the text manual doc) would be more helpful to others.

I’m imagining this taking the form of a more tutorial style set of images or maybe even GIFs and a bit of HTML holding them together.

As with the text manual, this would allow someone to have a useful flashlight even if they didn’t get to the end.

This would take even more work than the existing docs though.

I don’t think Launchpad allows previewing HTML but if it did then that’d be perfect.

Have you considered a website or even a domain that redirects to the readme?

(Opinions from a random internet stranger. Feel free to ignore)

I got 3 lights running Anduril2. About to dnld to a HK04. I did some light rev engineering on the HK04. They use a 3 leg part (FET?) with resistors preceding it to implement the single 7135 channel. Turns out they precisely reproduced 0.35 amps with the circuitry! I tested it simply by lots of measured ramping over the first flicker - seems pretty dead on averaged to 0.35 amps.

The HK04 driver uses 2 large/typical FET's in parallel for the main FET channel, and has switch LED's, and USB-C charging. The charging appears to share the one color switch LED, and uses another switch LED - I think they are green and red. I destroyed the switch PCB in getting it out so am replacing it, but don't have a 2 color (4 wire) switch PCB to use, so not supporting the 2nd color for charging. The one I'm suing though has 4 LED's but all wired together.

So even though it's a custom ATTiny85 based driver, it looks like a FET+1 with 1 color AUX/switch LED's to the firmware. Interesting...

I’m sorry if this has been covered already, but there is no downloadable hex file for Anduril 2 yet, correct? The firmware repository website layout has me on the verge of a stroke (there doesn’t seem to be a file associated with each “revision”?) and want to make sure I didn’t miss something :weary:

Correct, at the moment you have to compile it yourself.

The docs are taking a while mostly because I’ve hardly had any time to work on it. I have a lot of a tutorial written up, and mostly just need to make the diagrams to go along with it. The plan is to start with the simplest parts, then proceed in order of increasing complexity. People wouldn’t need to read the whole thing to use a light; just the beginning.

About short URLs, there is one which links to the latest revision in the repository, but I don’t have one specifically for the manual. I’m planning to put the tutorial up here on BLF as its own thread.

That seems to be a common issue. People don’t have bzr (or brz), which are the intended ways to access the repository… so they look for a way to download the whole thing, and can’t find it. It’s a pretty legit problem with Launchpad. However, there is a way to do it:

  1. Go to the code. Any part of the repository should be fine.
  2. Click “view revision”.
  3. Click “download tarball”.

Then extract the .tgz file.

However, if you’re going to be compiling it anyway, it’s probably easier to just use a Linux container. Compiling it can be a little tricky otherwise. So for that, the process would be a bit different…

  1. Install Debian or Ubuntu somehow (like inside of WSL, Windows Subsystem for Linux).
  2. Get root access with “sudo bash” or “su”, so you can install packages.
  3. apt install build-essential gcc-avr avr-libc binutils-avr avrdude brz make
  4. Exit the root shell with “exit” or Ctrl-D.
  5. brz branch lp:~toykeeper/flashlight-firmware/anduril2
  6. cd anduril2/ToyKeeper/spaghetti-monster/anduril
  7. make

Or something like that, anyway. Has been a long time since I set up a new host for this.

This should produce a full set of supported builds… one .hex file for each cfg-*.h file.

I’m not sure if avrdude actually works from inside of WSL. It may be necessary to flash using a Windows tool instead.

Thank you Sammy and TK! I’ve got some free time the next few days so maybe this is something I’ll mess around with. :slight_smile:

I'm compiling Anduril2 fine under Windows using AS 7.0, all source files combined in one folder

I haven’t compiled Anduril2 (yet), but that’s how I always compile the original.

:BEER:

One last question, I’ve downloaded the .tgz which seems to contain the entire repository but I’m still not sure what the actual file path and names are for Anduril 2. It just seems to be the latest revision (I assume?) of Anduril and the different model-specific files - is it just the ones under spaghetti-monster>anduril?

Yep - you trace it down under TK, under Spaghetti Monster, then Anduril -- that Anduril is Anduril 2 - check the manual, think there's another way too. Not on my home computer right now...

I am still changing Anduril.c to include the cfg file of choice.. I've made up 1 or 2 cfg files as well.

The hardware definitions are in ToyKeeper, fsm in ToyKeeper/spaghetti-monster and anduril (2) itself in ToyKeeper/spaghetti-monster/anduril. So these are the required files:

ToyKeeper/
├── hwdef-*
├── spaghetti-monster
│   ├── anduril
│   │   └── *
│   ├── fsm-*
│   ├── spaghetti-monster.h
└── tk-*

Yea, that looks correct. I simply re-used the solution and project files I had used on the old Anduril and it compiles/links. But if you want a complete proper project file for searching, etc., then you need to add all the new *.c files that Anduril.c includes, but specify to not compile them, just include them in the project -- this is what I did but not sure if I'm 100% accurate with it.

Awesome input everyone, thanks again!

If I had just “RTFM” I would have quickly realized it was v2 since it explains Simple UI, etc.

Edit: Getting two errors when trying to build (big surprise! - I’m in way over my head here haha)

First is “config-default.h: no such file or directory”
Then “recipe for target ‘main.o’ failed”

First thing I noticed was that in the atmel tutorial here the OP mentions that pasting in the Anduril.c code should rename main.c to that… that never occurred for me.

I did a quick search and there was some mention of user/file path names having spaces or weird characters causing issues. Even starting and saving with the project at the top directory of my D: drive didn’t eliminate either error though.

Second error has a log file but it seems there isn’t a compact code posting option on this forum and I don’t want to spam the whole page.

Using Atmel on W10 BTW

Yeah, that’s why I suggest using a Linux container, so you can use the project’s build system instead of rolling your own. The build is getting increasingly complicated with the way the files are organized, the compiler flags required to get everything to fit, and the multiple build targets. Building outside the included system requires finding solutions for all those things.

Updating to new versions is also much easier in a Linux container, since it only requires a “bzr pull” to grab the latest changes, or “bzr merge ; bzr commit” in the case that you’ve made your own local changes and want to integrate upstream changes too.

The more I thought about this, the more it made sense. So there were some updates today which completely reworked the menu system. Now it’s faster to navigate, and the build size is 150 bytes smaller, but only one menu item can be configured at a time.

The old way was:

  1. Click 7 (or sometimes 10) times to invoke the menu.
  2. Wait for the light to blink out each option one at a time, and then display a numeric entry prompt.
    • Click N times during the prompt to set a new value, or just wait to skip it.
  3. Wait for any remaining items to finish, and it falls back to the original state.

The new menu system is a bit different:

  1. Click 7 (or 10) times to invoke the menu, but keep holding the final press.
  2. The light should blink just once per menu item. Release the button after a blink if you want to configure that item, or otherwise just keep holding the button.
    • If you hold the button until all items have scrolled by, it exits the menu as soon as you let go.
    • Or, if you release the button to select an item, it then displays the blinking/buzzing numeric entry prompt.
      • Click a few times to enter a new value.
  3. Afterward, it exits the menu and goes back to the original state.

This “hold” style was requested a bunch of times because makes it harder for people to get into menus by accident. It may take a little while to get accustomed to, but it’s faster for the common case of wanting to change only one value.

It also introduces the ability to set a value of zero, which really simplifies some parts of the UI. Like, to turn autolock on or off, it requires only setting the timer value. Set it to zero to disable autolock, or non-zero to enable it and set the timer duration. However, some items (like ramp config) still follow the old style of “no clicks means no changes”.

With the changes so far, I’ve found I usually want to configure a few things right after flashing each light. These are the things I change from default:

  • Factory reset, to calibrate thermal sensor
  • Advanced UI
  • Lockout mode’s RGB aux LED style: low, disco
  • Ramp style: smooth (usually), with floor 1/150
  • Manual memory: On, at ramp step 2/7
  • Manual memory timer: 10 minutes
  • Voltage sensor calibrated per light

Otherwise, I generally like the defaults… though I also change other things sometimes on some lights. Like, if I’m going to be carrying a D4 without a raised button ring, it can be nice to use auto-lock. Or for an outdoor light like a thrower, I generally use the stepped ramp.

Don’t know if it was already talked about in this thread, but I might have a new suggestion: Multi-Chemistry Cell Support

Of course the voltage-ranges of the different chemistries have to have a gap in between them, but then it could be possible with multiple ADC*… tables, and then different PWM_LEVELS linked to the specific ADC*… tables.
MCU pin definitions have to be linked to the ADC_… tables as well (at least the LED_ENABLE_PIN should be changeable), a 14500 might have a different circuit that needs to be controlled compared to a AA.

The MCU could measure the voltage when inserting a cell, and then choose the correct table according to the measured voltage, then next cell insertion overwrites the old.
To save bytes, there could be a #define to enable or disable the whole “Multi-Chemistry Cell Support” (I hope it’s possible on tiny1634, it’s not needed on 85 since it has too few pins anyway).

Thank you ToyKeeper for your hard work. I am a embedded SW developer myself and I know how hard it can be to develop SW for platforms with limited resources and try to add all functions and options the users request.

I followed your steps for building and it works fine in Ubuntu on Windows, within 10 minutes I was able to build Anduril and Anduril 2. I didn’t change anything (yet) but just looked at the code and tried to understand how it works.

I tried one thing however and it reduced the file sizes a few bytes of multiple targets. I added “static const” in front of the variables seq, levels and animation in aux-leds.c. By adding this the variables can be accessed in ROM directly and are not copied from ROM to stack (RAM) every time a function is called.

A tip for others: if you cd to /mnt/c in the Linux prompt you can access your local Windows C: drive from within the Linux prompt. If you clone the anduril source code here you can still use your favorite Windows editor to read and/or modify the code (no need to use vi). The hex files will also be generated on the Windows drive so Windows tools can be used to flash.