thanks, that worked, well it doesn’t build, like you said it wants the DFP , but no file or directory error
edit: ah it gets the DFPs with
docker run --pull=always --rm -v E:\light_fw\tk\anduril-trunk:/src -e DEBUG=1 siterelenby/anduril-builder dfp
then it works for T85/T1634 builds, but not AVRDD nor T1616
/usr/lib/gcc/avr/10.3.0/../../../../avr/bin/ld: address 0x807038 of ui/anduril/anduril.elf section `.data' is not within region `data'
/usr/lib/gcc/avr/10.3.0/../../../../avr/bin/ld: address 0x8070cf of ui/anduril/anduril.elf section `.bss' is not within region `data'
/usr/lib/gcc/avr/10.3.0/../../../../avr/bin/ld: address 0x807038 of ui/anduril/anduril.elf section `.data' is not within region `data'
/usr/lib/gcc/avr/10.3.0/../../../../avr/bin/ld: address 0x8070cf of ui/anduril/anduril.elf section `.bss' is not within region `data'
collect2: error: ld returned 1 exit status
It kind of bombed, so they stopped trying to do bluetooth-configured flashlights. It sold poorly, was difficult to pair with a phone, and cost way too much to develop and maintain the app.
It probably didn’t help that the flashlight itself wasn’t great, and the configurable options were fairly limited.
Maybe it’ll happen someday… but that day isn’t here yet.
For now, a pogo pin USB dongle is a cheap, easy solution. Touch 3 spring-loaded pins to a driver, press a button, wait a few seconds, and it can give the flashlight a whole new personality.
But also very limited (and not maintained beyond initial release ?) I can’t help but notice the unusually large switch boot, maybe for better radio transmission.
Ah, I vaguely recall seeing that one at some point… I think they put the radio under the conspicuously large, raised switch on the side?
Anyway, phone OSes are a quickly moving target, and the light’s companion app might work today but there’s not much chance it’ll still work several phones down the line in 10 or 20 years. So I try to stick to standard programs that someone else is going to maintain long-term. It’s a lot of work to keep a phone app working over time, and I might get hit by a bus or something. Plus, I just don’t like phones very much. The phone ecosystem has been a corporate mess ever since Android arrived and pretty much ended all the community-based mobile OS projects.
Yeah, that makes sense - since the body tube is the battery negative, that makes it close to impossible to get a signal with an internal antenna contained within it. Having a coiled antenna under a switch boot makes sense (it might also be possible to integrate into the optics or bezel in some way, but that’s a lot harder and probably more expensive)/.
There is no need to worry about a companion app. If this functionality is really desired, a data model should be defined. If BLE is used, its as simple as creating the GATT model. Interoperability and open protocols / standards are just as important as open source.
On that note, lets hope 20 years from now we’ve figure out something better than C
I think we’re talking about fundamentally different layers of the software stack. BLE/GAP/GATT are basically a link / transport / protocol layer sort of thing, and I’m talking about stuff a few levels up in the application and content layers. Like, if I want to build a web site full of things people want to use, merely defining a standard for HTTP isn’t enough. That just takes care of one low-level prerequisite before work can begin on the bulk of the project.
We’re talking about two different things in this thread. My original Docker build environment and @wolfgirl42’s fork.
Recently I have updated my fork so that it works with the new repo format (but I haven’t released a build yet). It works only without the DFP and only for older MCUs, not the DD series! I “carefully” selected a version of avr-gcc together with the latest development version of avr-libc to create the smallest possible hex files (newer versions of avr-gcc have changed their optimization, which doesn’t work great with Anduril). The latest version of avr-libc supports tinyAVR 0/1 without the DFP (which would cause conflicts).
So if you want to build for DD, you can’t use the Docker versions right now. But the older MCUs are well supported with my new branch.
That’s what I’m interested in though, right now there’s just my devkit in the public repo but I’m developing several AVRDD drivers, and not just personal mods but for future commercially available lights.
Right now I’m using a Vmware ubuntu VM but it’s very annoying because the copy pasting (hex) out of the VM stops working after 5min and I have to reboot it constantly, shared folders also don’t work. I tried virtualbox but the VM just crashes for whatever reason. But even if it worked properly docker is just way more convenient.
I also tried WSL, very simple to setup but then when I add/edit folder/files from Windows I get permission denied on those in WSL …
No, it doesn’t work. Right now it’s completely incompatible with avr-gcc 10.3 that is used in my image.
===== anduril 2023-12-03+6 : thefreeman-avr32dd20-devkit =====
/usr/lib/gcc/avr/10.3.0/../../../../avr/bin/ld: address 0x807038 of ui/anduril/anduril.elf section `.data' is not within region `data'
/usr/lib/gcc/avr/10.3.0/../../../../avr/bin/ld: address 0x8070cf of ui/anduril/anduril.elf section `.bss' is not within region `data'
/usr/lib/gcc/avr/10.3.0/../../../../avr/bin/ld: address 0x807038 of ui/anduril/anduril.elf section `.data' is not within region `data'
/usr/lib/gcc/avr/10.3.0/../../../../avr/bin/ld: address 0x8070cf of ui/anduril/anduril.elf section `.bss' is not within region `data'
collect2: error: ld returned 1 exit status
ERROR: build failed
===== anduril 2023-12-03+6 : thefreeman-boost-fwaa-mp3432-hdr-dac-rgb =====
Device: attiny1616
Program: 10624 bytes (64.8% Full)
Data: 207 bytes (10.1% Full)
# 81a8d4069b95ff4449774236b5be1e7a
> hex/anduril.thefreeman-boost-fwaa-mp3432-hdr-dac-rgb.hex
I now tried Alpine 3.19 which uses avr-gcc 12.2 and avr-libc 2.1 and it fails as well, not only for DD, but also for all other targets.
===== anduril 2023-12-03+6 : thefreeman-avr32dd20-devkit =====
In file included from ./arch/mcu.h:12,
from ui/anduril/anduril.c:38:
./arch/avr32dd20.c: In function 'mcu_adc_sleep_mode':
./arch/avr32dd20.c:114:5: error: 'MCUCR' undeclared (first use in this function); did you mean 'MCU'?
114 | set_sleep_mode(SLEEP_MODE_STANDBY);
| ^~~~~~~~~~~~~~
./arch/avr32dd20.c:114:5: note: each undeclared identifier is reported only once for each function it appears in
./arch/avr32dd20.c:114:5: error: 'SLEEP_SMODE0_bm' undeclared (first use in this function)
114 | set_sleep_mode(SLEEP_MODE_STANDBY);
| ^~~~~~~~~~~~~~
In file included from /usr/avr/include/avr/io.h:99,
from /usr/avr/include/avr/eeprom.h:38,
from ./arch/mcu.h:8:
./arch/avr32dd20.c: In function 'prevent_reboot_loop':
./arch/avr32dd20.c:262:5: error: 'RAMPD' undeclared (first use in this function); did you mean 'RAMEND'?
262 | wdt_disable(); // from avr/wdt.h
| ^~~~~~~~~~~
./arch/avr32dd20.c:262:5: error: 'WDT_CTRL' undeclared (first use in this function); did you mean 'WDT_CTRLA'?
262 | wdt_disable(); // from avr/wdt.h
| ^~~~~~~~~~~
In file included from ./arch/mcu.h:13:
./arch/avr32dd20.c:262:5: error: 'WDT_ENABLE_bm' undeclared (first use in this function); did you mean 'ADC_ENABLE_bm'?
262 | wdt_disable(); // from avr/wdt.h
| ^~~~~~~~~~~
./arch/avr32dd20.c:262:5: error: 'WDT_CEN_bm' undeclared (first use in this function)
262 | wdt_disable(); // from avr/wdt.h
| ^~~~~~~~~~~
./fsm/standby.c: In function 'sleep_until_eswitch_pressed':
./fsm/standby.c:48:9: error: 'MCUCR' undeclared (first use in this function); did you mean 'MCU'?
48 | set_sleep_mode(SLEEP_MODE_PWR_DOWN);
| ^~~~~~~~~~~~~~
./fsm/standby.c:48:9: error: 'SLEEP_SMODE0_bm' undeclared (first use in this function)
48 | set_sleep_mode(SLEEP_MODE_PWR_DOWN);
| ^~~~~~~~~~~~~~
./fsm/standby.c:50:9: error: 'SE' undeclared (first use in this function); did you mean 'SP'?
50 | sleep_enable();
| ^~~~~~~~~~~~
./fsm/standby.c: In function 'idle_mode':
./fsm/standby.c:96:5: error: 'MCUCR' undeclared (first use in this function); did you mean 'MCU'?
96 | set_sleep_mode(SLEEP_MODE_IDLE);
| ^~~~~~~~~~~~~~
./fsm/standby.c:96:5: error: 'SLEEP_SMODE0_bm' undeclared (first use in this function)
96 | set_sleep_mode(SLEEP_MODE_IDLE);
| ^~~~~~~~~~~~~~
./fsm/standby.c:98:5: error: 'SE' undeclared (first use in this function); did you mean 'SP'?
98 | sleep_enable();
| ^~~~~~~~~~~~
ERROR: build failed
===== anduril 2023-12-03+6 : thefreeman-boost-fwaa-mp3432-hdr-dac-rgb =====
In file included from ./arch/mcu.h:12,
from ui/anduril/anduril.c:38:
./arch/attiny1616.c: In function 'mcu_adc_sleep_mode':
./arch/attiny1616.c:66:5: error: 'MCUCR' undeclared (first use in this function); did you mean 'MCU'?
66 | set_sleep_mode(SLEEP_MODE_STANDBY);
| ^~~~~~~~~~~~~~
./arch/attiny1616.c:66:5: note: each undeclared identifier is reported only once for each function it appears in
./arch/attiny1616.c:66:5: error: 'SLEEP_SMODE0_bm' undeclared (first use in this function)
66 | set_sleep_mode(SLEEP_MODE_STANDBY);
| ^~~~~~~~~~~~~~
In file included from /usr/avr/include/avr/io.h:99,
from /usr/avr/include/avr/eeprom.h:38,
from ./arch/mcu.h:8:
./arch/attiny1616.c: In function 'prevent_reboot_loop':
./arch/attiny1616.c:223:5: error: 'RAMPD' undeclared (first use in this function); did you mean 'RAMEND'?
223 | wdt_disable(); // from avr/wdt.h
| ^~~~~~~~~~~
./arch/attiny1616.c:223:5: error: 'WDT_CTRL' undeclared (first use in this function); did you mean 'WDT_CTRLA'?
223 | wdt_disable(); // from avr/wdt.h
| ^~~~~~~~~~~
In file included from ./arch/mcu.h:13:
./arch/attiny1616.c:223:5: error: 'WDT_ENABLE_bm' undeclared (first use in this function); did you mean 'ADC_ENABLE_bm'?
223 | wdt_disable(); // from avr/wdt.h
| ^~~~~~~~~~~
./arch/attiny1616.c:223:5: error: 'WDT_CEN_bm' undeclared (first use in this function)
223 | wdt_disable(); // from avr/wdt.h
| ^~~~~~~~~~~
./fsm/standby.c: In function 'sleep_until_eswitch_pressed':
./fsm/standby.c:48:9: error: 'MCUCR' undeclared (first use in this function); did you mean 'MCU'?
48 | set_sleep_mode(SLEEP_MODE_PWR_DOWN);
| ^~~~~~~~~~~~~~
./fsm/standby.c:48:9: error: 'SLEEP_SMODE0_bm' undeclared (first use in this function)
48 | set_sleep_mode(SLEEP_MODE_PWR_DOWN);
| ^~~~~~~~~~~~~~
./fsm/standby.c:50:9: error: 'SE' undeclared (first use in this function); did you mean 'SP'?
50 | sleep_enable();
| ^~~~~~~~~~~~
./fsm/standby.c: In function 'idle_mode':
./fsm/standby.c:96:5: error: 'MCUCR' undeclared (first use in this function); did you mean 'MCU'?
96 | set_sleep_mode(SLEEP_MODE_IDLE);
| ^~~~~~~~~~~~~~
./fsm/standby.c:96:5: error: 'SLEEP_SMODE0_bm' undeclared (first use in this function)
96 | set_sleep_mode(SLEEP_MODE_IDLE);
| ^~~~~~~~~~~~~~
./fsm/standby.c:98:5: error: 'SE' undeclared (first use in this function); did you mean 'SP'?
98 | sleep_enable();
| ^~~~~~~~~~~~
ERROR: build failed
It seems like the old vs new gcc+libc has changed so much that I probably can’t support both at the same time, so I probably just have to pick a version and stick with it for now.
I’m using debian here, and github uses ubuntu LTS for CI purposes, and WSL uses the same packages, so it’s easy to use the version included in debian+ubuntu… unless, of course, there’s a meaningful benefit worth upgrading for.
Is there some reason why docker couldn’t just use some debian packages for its dependencies? I thought that was pretty common.
It is possible to use debian as a base image, but it is much larger. Alpine is less than 5 MB, Debian or Ubuntu at least 25-50 MB. Dependencies will add a lot, though.
AFAIK I tested all versions from 4.9 to 13.2 and decided that 10.3 was the best (hex size, optimization, supported features etc).
It can be done - I can certainly rearchitect the existing image to be based on Debian instead of Alpine, but it might be simpler just to install the matching versions on alpine too. In the absolute worst case it can be installed from source which won’t affect the performance of the Docker image by end users, just the time it takes for me to build (which is already slow anyway as I build multiarch images, but I have already automated the actual build/push).
In terms of the image size, it’s not something I often worry about - Debian’s versions are very stable, and when you update the image, it’s not going to be pulling new filesystem layers often for the base image; most likely updated layers will be for things like the entrypoint script, and occasional libc/gcc upgrades. All it really does to switch it to debian is slows down the very initial pull with my Docker hub version, while even if people are building the image themselves, if they allow the layers to be cached then it wouldn’t be much of a space penalty.
I’m going to have a go at updating my fork of the docker builder to match your package versions, because that’s definitely the easiest way, not to mention that size optimisation is generally just easier if everyone is using the same compiler versions… (Edit: Looks like Alpine doesn’t package 2.0.0 anyway, so it’s going to be from source on Alpine, but it should be entirely possible to get the same versions working there)
Pushed a Debian-based image now, using gcc-avr=1:5.4.0+Atmel3.6.2-3 and avr-libc=1:2.0.0+Atmel3.6.2-3.
docker pull siterelenby/anduril-builder:debian
Windows CMD: docker run --rm --pull=always -v "%cd%":/src -it siterelenby/anduril-builder:debian avr32dd20-devkit
Linux/WSL/MacOS: docker run --rm --pull=always -v "$(pwd -P)":/src -it siterelenby/anduril-builder:debian avr32dd20-devkit
It’s ~200MB larger, but worthwhile to have to build on a consistent version as TK, I think. Maybe going forward we should think about standardising which versions are used, would make maintenance a lot easier.
debian: Pulling from siterelenby/anduril-builder
bc0734b949dc: Pull complete
dda60c7cc308: Pull complete
6b802aa972cc: Pull complete
44724d8061df: Pull complete
4f4fb700ef54: Pull complete
Digest: sha256:fd552fe656a4a254bbb571b75484edb0d4b2ca981ad2807c760b61df91496a6c
Status: Downloaded newer image for siterelenby/anduril-builder:debian
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
===== anduril 0. : thefreeman-avr32dd20-devkit =====
avr-cpp: error: device-specs/specs-avr32dd20: No such file or directory
ERROR: build failed
===== 0 builds succeeded, 1 failed =====
FAIL: thefreeman-avr32dd20-devkit