I see you mentioned it in the previous post yeah, but i mean regarding this :
It makes sense that it’s installed within the FSM/Anduril folders and not elsewhere.
1 Thank
Thanks for the clarification. I’m not sure about that – what would be the point of installing something that’s definitely not part of Anduril, inside Anduril’s source tree? Not just because it’s “automatic” – it could be installed somewhere else writable by the user (like ~/.dfp or wherever), and even better would be if it first checked whether $ATTINY_DFP is already defined and then used it from there.
Anyway, just my $0.02…
Real programmers don’t wait for stability, they do it onto alpha-level code! 
Seriously(ish), just beat you to it:
Just waiting for TK to have a look and finding them worthy! 
Now, who is this Gretel person who beat me to #1?! 
[1] for those that never saw that joke: Real Programmers — Don't ...
I’m not currently taking suggestions for another migration, considering the last one was just a couple days ago. I did look into GitLab quite a bit though, and it has great features… but the hosting and user base aren’t really there. If I ever need to self-host a GitHub-like service, it’d be the top pick… but I’d prefer to host where people already are.
Long-term, the plan is to use whatever the developer and user community collectively decides is the most agreeable. At the moment, that’s GitHub.
It’s pretty common practice to install versioned external dependencies into a subdir in the project tree. That’s a big part of why git-submodule exists… and it’s what python-virtualenv is for. Most languages and most VCSes have a feature for this – automatically get the supported version of each dependency, drop them somewhere which has no effect on the rest of the user’s computer, and use it as a project-specific library.
The Atmel DFPs aren’t accessible as a git submodule though; they’re just .zip files on Atmel’s site. So I made a minimal system for installing those in a way which is easy for the user. It required a manual install before, but that’s unnecessary hassle for the user.
Yeah, I wasn’t sure about that one. If you’ve got a better idea, it can be renamed. The goal is to use a name which:
- Can be typed with just a dot, a slash, one letter, and a tab… with no ambiguity or collision with other files in the repo. So the first letter should be unique, and not typed with the same finger as ‘/’ or ‘Tab’ in any of the major keyboard layouts.
- Communicates its purpose pretty clearly with just its name.
- Is ideally a verb which makes sense when used before the script’s sub-commands… or a word which relates to the project somehow.
- Is short.
Traditionally, the command for these tasks is “make”. So I started out using a Makefile, but it’s not really designed for the type of usage I want, so it made things quite a bit more complicated. Like, a simple “make clean” can get pretty complex for a project with lots of nested directories, and it really doesn’t like sub-commands with multiple arguments like “make hank boost”. So instead of using “make” as a poor imitation of a shell script, I made it an actual shell script.
Edit: Some ideas for words…
- cast
- cook
- do
- eject
- elicit
- emit
- engage
- evoke
- excrete
- exert
- existify
- generate
- illuminate
- imagine
- incant
- induce
- inflict
- invoke
- let-me-cook
- make
- manufacture
- materialize
- melodramatize
- necromance
- perform
- prestidigitate
- produce
- realize
- render
- roll
- spew
- summon
- visualize
- vomit
- weave
- yield
Some are practical, some are silly. Some don’t meet the desired qualifications.
1 Thank
This is an awesome resource thank you.
1 Thank
Fantastic news. As a dumb user, Github is so much less convoluted to navigate and use.
The Open source philosophy and customizing a consumer product you own is what drew me to this hobby. There’s a lot of past users that contributed in big ways that have come and gone I won’t be the only one to say I appreciate all the work you’ve done. Thank you Toykeeper for sticking with this hobby for all these years.
2 Thanks
I suggest you keep along the lines of the current nomenclature: you already have bin/build.sh for building individual lights, then bin/build-all.sh to build all the lights, so instead of make I would call it ./build-it.sh (or something similar) for the top-level build script. I would also have it with the .sh extension, like the other aforementioned scripts. But actually just about anything would be better than make for the reasons already mentioned.
Of course, I wouldn’t either. That’s why I ended my suggestion with the clause:
when Github finally becomes unbearable.
Sorry it that wasn’t clear.
Well, not the systems I’m used to, like golang dependencies, PERL modules and C libraries: they all install dependencies outside of the current project, in system-wide or user-specific separate subtrees depending on the case. But different strokes for different folks, as they say, and if placing outside dependencies inside the Anduril tree works for you, more power to it I say,
And BTW. thanks for responding and making your views clear.
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.