Instead of reusing the name of a well-known tool like make, how about switching back to the original and using a Makefile? Here’s a branch which does that:
Basically, instead of ./make foo bar baz, run make foo bar baz without the dot-slash.
Bravo!
I’ve glanced at the code previously but I feel inspired to dig in after this latest huge effort.
/ui/anduril looked like a good place to start as an Anduril user (plus maybe ui/baton to cover the basics?).
But I also started looking into hw/wurkkos/ts10 (ignoring /rgbaux) since that’s the model I own and use most. Maybe an obvious question, but just to help connect the dots, when you mention the development process of making specific configurations for each model, are the files here what you mean? Such as these tuned values in anduril.h. Thinking of step 2 as described here:
It seems like it but I didn’t want to miss something. Thanks!
I wouldn’t expect to make any changes to those files for my personal setup but I am looking forward to modifying ui/anduril /config-default.h with my preferences.
Yes, the hardware-specific code goes in hw/vendor/model/, which is where it defines the MCU pinouts and init, the LED control algorithms, and the per-model UI configuration.
The ui/anduril/ files are mostly hardware-agnostic and define how the user interface works. Other UIs worked at some point in the past, but haven’t been maintained so I need to fix them.
The fsm/ files are basically a little microkernel to handle all the hairy details of bootup, task scheduling, interrupt handling, input dispatch, event delivery, voltage and thermal measurement, and other low-level stuff.
The arch/ dir has code to abstract out details of the individual MCU type (architecture), and generally deal with things which are specific to the MCU or compiler.
It’s not implemented yet, but there should also be a users/ dir where people can customize things on a per-user basis.
2 Thanks
And just like that I’m now acutely aware that I own a bunch of small cylindrical computers that also emit light.
1 Thank
That’s amazing! It’s definitely a milestone evolve for Anduril. lol
1 Thank
Just perfect. Now its even harder to use it with Atmel studio. It was great move to add file subdirectory to all snippets. Why not just use official software for Atmel chips?
I’m guessing because Atmel Studio is Windows only …
Yea, and Windows so unpopular… only few nerds is using it.
I’m pretty sure it’s not just about using FOSS but also because Microchip studio produces larger binaries.
Edit : oh and Microchip Studio doesn’t even support AVR32DD20, how weird it is to not support your own new MCUs 
Ah, yeah that works, thanks, I’m pretty sure I checked this but indeed it wasn’t supported in the DFP I had installed, my bad then.
The compiling/building steps in the Anduril repo README work well to setup the build environment inside WSL (Windows Subsystem for Linux). Once configured you can then use Visual Studio Code with the WSL extension to edit the files and run the build commands inside the terminal of VS Code.
That’s not how software projects work. Each project has its own build system, its own instructions for turning the sources into an executable. If you don’t follow those instructions, you’re choosing to make things difficult for yourself.
I’m not going to de-organize the project and rewrite all its internal infrastructure just to make it easier to build with proprietary tools it was never intended to be built with.
In Windows, there are two easy ways to compile it: WSL or Docker. Pick one.
It already does. One of the first steps in setting up the build environment is to download and install DFPs directly from Atmel, which make dfp helpfully does for you.
Git doesn’t have revision numbers like r817. It has commit IDs, like bc0b4625a1618d9322ea6a5f0bb402f8ddc0aad6 (or bc0b462 for short). I’m not super happy about it either, but it’s what people use. Regardless, the repo currently has 1178 commits in it, and a lot has changed since the last bzr version.
To do things in a more git-like manner, the version string is instead derived from the most recent release tag… potentially with extra info at the end to indicate how many commits since the tag and whether the repository is in a clean or dirty state. Like, yesterday’s release was tagged r2023-12-03, but if I were to add 158 commits and build in a dirty repo with uncommitted changes, the git describe tool would report the version as r2023-12-03-158-g0abcdef-dirty. This is then shortened somewhat to produce the version string used by Version Check mode: 2023-12-03+158#1. I’m still undecided whether it should include the rev short-hash in builds like that, but at the moment it omits that part. Official releases have a tag though, so it’s just the date with no +N or #1.
Anyway, the short revision numbers are gone because Linus Torvalds was feeling spiteful and contrarian in 2006 when he created Git.
Compiling is one thing and another thing then trying to code. Before “r817” all we had to do to update Atmel project was to drop new version files on top of old… . Now in Github style You added directory patches inside files like “fsm/ramping.h” before was just “ramping.h” and then all files are in same directory … now I have to rewrite every f single files patches… and i did and it does not compile anyway :DD
I recall you putting everything into one directory and then updating individual files one at a time… but that was never a supported way to build the code and it’s not how most software projects work.
Weren’t you doing that just because Launchpad’s tarball feature was broken and bzr didn’t work very well in Windows? Git has much better Windows support. All you have to do to update your local copy is git pull origin trunk or click the “pull” button in an IDE. Most of them have Git support these days.
Regardless, it’s not going to work with everything in one directory. Half the files have the same file names but in different directories. The directory structure is a semantically important part of the build.
So… install the latest debian or ubuntu in WSL. Run a couple apt commands to get build dependencies. Git clone the repo. Run make dfp. Then run make. That’s how to build it in Windows. That’s also basically how GitHub’s Continuous Integration system builds the code after each commit, so you can be pretty confident it’ll actually work.
1 Thank
Will us computer illiterates still be able to use our android phones and Zflasher to download .hex files
You can.
The release file will include all the various hex files, unzip it on your phone and then use ZFlasher to select the one you want to flash to a particular light.
There may be a simpler way, but I’m not the dude who can tell you what it is!
Yes, when you download the ZIP file from the release page and extract it, you get the following files and a folder called ‘hex’.
As @eckyeckypikang mentioned, the hex files for every supported light are there – inside the ‘hex’ folder.
Oh… I hadn’t even noticed the other files!
Interesting - it’s like a combo meal at your favorite fast food joint. Everything you need.
Exactly. Manual and everything. 
I also just noticed ‘which-hex-file.md’ which explains how to find out which hex file to use for a particular light. The link to the file in source is here: https://github.com/ToyKeeper/anduril/blob/trunk/docs/which-hex-file.md
This would clarify another regular question on reddit, so the only challenge remaining is to try to get reddit to RTFM… (and stop posting links to out of date resources).