Yup, you’re correct! I didn’t type that “Set”.
apparently I didn’t pay enough attention when I was doing it on the laptop. now I’m away from my laptop and typing on my phone and read and read again,
yup, the “Set” was left out 
1 Thank
that will be great, thank you very much,
to know for sure if my files & directories for the attiny1616 support is OK, and that missing the “Set” is the only problem.
take it easy, I’m at work too , I’m in a trip out of town actually, my coworker is driving.
it’ll be good to find the solution sooner but I won’t be able to apply the correction because I left my laptop at home.
The docker image has t1616 support working, which is probably the easiest way.
I recently added a new idea to my projects list that should make building anduril simpler for people who can’t install/configure Docker or compilers, but it’s going to be very dependent on when I find enough time.
2 Thanks
Hi @BLF-L,
I did the following on my WSL2 Ubuntu:
- I didn’t change build-all.sh
- create file spaghetti-monster/anduril/Atmel368.sh with content:
export ATTINY_DFP=/anduril2/Atmel.ATtiny_DFP.2.0.368
(I inserted your path) - make file executable (chmod 777 Atmel368.sh)
- before build I do: source Atmel368.sh
- then build-all.sh (whatever 1616 version you want to build)
Hope this helps
2 Thanks
yes, a method with Docker and SammysHP’s anduril-builder image is easy. all builds succeeded except 3.
I’ve built hex files for my SC21 Pro, SP10 Pro, TS10 with this method
Building Anduril with Docker
Building your own version of Anduril, the simple way.
…
I want to learn the alternative method with WSL.
1 Thank
Thank you for your explanation.
But I still have some confusions (as usual, I’m a rookie)
- how to do the “source” ?
how did you do that? what exactly did you type on the Ubuntu shell?
type:
“source Atmel368.sh”
(w/o the quote marks of course) ?
- “build-all.sh” instead of “make” ?
so, instead of:
“make”
(step #7 in ToyKeeper’s guidance), you type something like :
“build-all.sh wurkkos-ts10”
to build hex file for Wurkkos TS10 ?
I remember the first time I typed “make” (step #7 in ToyKeeper’s guidance), I was like Wow! it builds!
Then typed “explorer.exe .” (step #8 by @elendur),
and Windows Explorer pops up.
And I got a lot of hex files (I got all of them, except the t1616’s).
1 Thank
Yes, that’s correct
Yes, that’s true as well.
For the Wurkkos TS10 build, it is sufficient to do “build-all.sh ts10” …
In order to be sure that we are on the same track, I’ll shortly describe the steps from the scratch:
- Switch to su: “sudo su”
- install compiler and bzr: “apt install build-essential gcc-avr avr-libc binutils-avr avrdude brz make”
- exit from su: “exit”
- In my $HOME do a “bzr branch lp:~toykeeper/flashlight-firmware/multi-channel” to get the current sources of the multi-channel branch.
- The steps, I described here. The path I’m in is ~/multi-channel/ToyKeeper/spaghetti-monster/anduril
That’s it!
3 Thanks
Thanks so much for your detailed explanation,
now everything has become clearer to me.
The devil’s in the details
Without t1616 support I’ve got hex files for all flashlights except the t1616 models.
It is the additional steps for integrating t1616 suport (with Atmel DFP) that has given me some headache.
So, basically, this is my understanding in a kinda laymen style:
-
To integrate the t1616 support we create a file “Atmel368.sh”
-
Then tell the compiler (with a command “source Atmel368.sh”) to “do something” with that file.
-
Upon checking that “Atmel368.sh” file the compiler finding the order to export the “ATTINY_DFP” to wherever is appropriate…
-
Now support for t1616 is available.
-
We type “make” to build all hex files.
-
Alternatively we type “buil-all.sh TS10” to build hex file for Wurkkos TS10.
2 Thanks
I’ll try this solution as soon as I can, maybe next weekend when get get home from this trip.
Now I’m more confident that the build for t1616 flashlights will be successful.
btw my machine is a Windows 10 Laptop, with WSL2, Ubuntu 22.04
A rather trivial question: how dees it work?
It makes sense that typing
“build-all.sh”
will build all the hex files. There’s a “build-all.sh” file inside that /anduril directory.
But,
“make”
also builds all the hex files.
There’s no file with the name of “make” in the /anduril directory. There’s a “makefile” file (w/o extension) though. How does it work?
I hope I can explain this correctly…
make starts gcc and gcc reads the Makefile … And in Makefile there is a reference to build-all.sh …
2 Thanks
yup, I’m sure you’re correct.
inside the “makefile” :
all:
./build-all.sh
I like when things work, and when things work I want to know how things work.
I often have to figure out what’s wrong when things don’t work (troubleshooting hydraulic system and/or electric system problems on a heavy equipment).
1 Thank
Much appreciation for @BLF-L asking questions, and @Owenm03 et-al answers!
I haven’t gotten that far yet, but I’m sure it all helps, and it jogs my memory grom using such software before(a good 20 years ago lol).
A quick(ish) question for you Anduril2 modders… How easy is it to get manual memory in the simple UI? Is it a feature I can turn on in a config file and compile, or will this be much more indepth?
Long winded explanation;
I use simple UI as my daily use UI, maily to avoid accidentally having anything flashy, and I can more trust handing the light to others, same reason.
I CAN currently set a manual memory mode, but it has to be done in Advanced, then carries over to simple.
Problem is, I set up 3 different floor/ceiling sets for the 3 ramps… None of which overlap each other. And 2 different step counts between Adv/Simple steppedramp.
So to set manual memory level in Simple, I have to set the stepped ramp exactly the same in Advanced, set the memory, and the re-setup the advanced ramp, ceiling, floor etc.
Definitely not an on the fly process, if for instance I need(ok want, who am I kidding) a specific output more than several times in say 10 minutes, in simple ui, it gets to be annoying to turn on and ramp up or down every time I turn it on and off. Especially if on and off is every minute or less in and out of crawl spaces, closets, etc. Being able to set manual memory would be great.
Also, as a side to the way it is now, the manual memory level, if set to what I generally want every day in Simple,
is outside the ramp ranges of both stepped and smooth in Advanced. Meaning it comes on way too bright in one, and too dim in the other. (Advanced smooth is on 1 to about 30, if that, and stepped is 2 levels around 90/130, plus turbo. Simple ui operates between around 40 and 90)
Sooo… how much learning C++ and moving code around is involved in this? Lol
1 Thank
I may not fully understand your situation, but, If I want my Anduril light to turn Off and back On at the same level, I just use automatic memory, no manual memory, and no hybrid memory… only automatic memory.
Could that strategy work for you?
There is no custom Anduril Hex file needed to use automatic memory.
3 Thanks
Should be reasonably easy if my assumption here is correct.
Do I have it right that you just want a separate manual memory for simple UI vs advanced UI, and the shortcut to save the manual memory level to be available in simple (and only save the current level to simple’s memory, not advanced)? that’s fairly easy (edit: and if so, do you want memory save in advanced to save that level to simple UI’s memory as well, or only to advanced’s?).
But agreed with @jon_slider, this seems like the kind of use case hybrid memory was designed with in mind - set your manual memory to the level you like, then your automatic memory timeout to 10 mins. When switched off less than 10 mins ago, the light will resume at the last used level, then after 10 mins, it resets to the manual memory. No problem implementing the above though, probably <30mins of work, just want to make sure I have it right first.
2 Thanks
I’ve been using the light in automatic memory mode for 9 months. Only recently did I figure out that manual, at least partially, does what I wanted.
Automatic is great but I wanted manual control to always have a specific start up level, and to not have to ramp back to it before turning off.
The hybrid memory does in fact fix the issue, for some instances… the problem is that 95% of the time I want it to come on at a specific output and Never ever remember any changes I make, always come on at the same place.
Hybrid kills that.
Basically, I want to be able to manually set it IF I need to or not; IF I find myself ramping a lot in a short time frame, simply set it to the new place and forget it till the task is done, then set it back to my middle level later.
@wolfgirl42
The way you said it is exactly what I had in mind; the manual memory shortcut available in Simple UI, to only set the memory in simpleUI.
Then the shortcut in advanced, would only set it in advanced.
Ideally I’d want to be able to separate setting memory for all 3 ramps;
10c (or even a lower number? )in simple to set simple memory
10c in advanced stepped ramp to set only that ramps’ memory
10c in advanced smooth to set only that ramps’ memory
But I figure I’m probably asking a lot there… trying not to get greedy here lol. Along with other things. I have a list of changes I’d like to make. Some things I’d like to turn off completely… and others, like this, kinda blends advanced and simple modes. But I dont want to bother yall with all of that, its my incentive to learn to do this myself.
Thats why I’m trying to get a computer I can compile on set up… Given that, I’m pretty sure I can learn enough of the code to change things. I just haven’t bothered looking at the code till I can be sure to be able to compile it after.
1 Thank
Having said that, this is all somewhat academic right now, since my SC31 Pro is now residing at the bottom of a local river… had an incident while magnetic fishing Friday night. 
Be a couple weeks at least before the replacement arrives.
And oddly, tonight while setting up my SP10 Pro to the config I had on the 31, the manual memory seems to turn off in advanced mode when I change the floor/ceiling/steps, but atvthe same time stay active in simpleUi.
Like it’s partially separating simple and advanced as faf as manual memory goes.
If that makes any sense.
I set up my floor/ceiling in Simple, then set the level in AdvUI, set it to manual memory, and it set to Simple UI too. Normal.
On the 31 no matter where I set the floor/ceiling on advanced ramps after that, it still used the manual memory level allready set for them, even if it was outside the floor to ceiling ranges.
But here, as soon as I went back and reset the floor/ceilings in advanced, its like it turned off manual memory for advanced only, and is using automatic memory!! While still using the manual memory level in the simple UI.
Thats part of what I wanted to do for the 31… do I have a glitch, or is this normal for the sp10Pro build?
1 Thank
That’s no problem to do (and something I’d like to write to apply for other custom builds as well) - don’t mind doing other stuff especially like setting up defaults which I have semi-automated, but if you want it to learn I completely understand :), I’ll post the diffs of what I changed when done.
Edit: Here you go. Just had a thought, I built it on the multichannel branch, but if you want support for a light that that version doesn’t support yet I can backport these changes to the old branch as well, but that will need some refactoring of how the config is saved (which I should do anyway at some point, I guess…). I also added 8C to save manual memory in simple UI, but 10C will still work there too.
Possibly it’s running a newer version? There were a few bugfixes around manual memory with the initial multichannel changes. Also, the SP10 Pro’s config has a memory timer enabled by default as well. I’m not sure exactly what causes that result as I basically never use simple UI (all my lights start from reset in advanced, simple is only there for me for if I was to hand the light to someone else so it’s a very basic low-power mode).
2 Thanks
The t1616 support thingy…
it works, eventually.
I had to manually copy the contents of Atmel.ATtiny_DFP.2.0.368 directory to the location pointed by the README:
export ATTINY_DFP=$HOME/src/torches/atmel/attiny-dfp
This location:
$HOME/src/torches/atmel/attiny-dfp
On the Ubuntu shell:
-
cd /home/wsl2ubuntu003/ -
export ATTINY_DFP=$HOME/src/torches/atmel/attiny-dfp -
mkdir -p ./src/torches/atmel/attiny-dfp/ -
explorer.exe .
Windows Explorer
Copy the contents of Atmel.ATtiny_DFP.2.0.368 (it’s in my Windows 10, Drive D) into
the /attiny-dfp.
My /wsl2ubuntu003/ is the parent directory where the /anduril2/ is located.
The /src/ directory is in the same location as
/anduril2/ (same level).
Directory structure kinda like this:
/wsl2ubuntu003/
¦
¦-->/anduril2/ToyKeeper/spaghetti-monster/anduril
¦
¦-->/src/torches/atmel/attiny-dfp
That’s it, t1616 support works. I can build t1616 Anduril hex files using WSL Ubuntu.
I hope it makes sense.
It makes sense to me today, hopefully still makes sense to me next year or next next year, when/if I have become unfamiliar with this thing, but somehow need to build t1616 Anduril hex files
Edit: corrected some typo’s
2 Thanks
@BLF-L, thanks for that heads up. I ran into the same issue on my Linux box. I had extracted the contents to $HOME/src/torches/atmel/ and got all errors. However, just creating the $HOME/src/torches/atmel/attiny-dfp folder and moving the contents of the atmel folder into it and I was able to compile without errors.
2 Thanks