bzr branch lp:~toykeeper/flashlight-firmware/trunkWho knows why the author decided to use bzr rather than git, but it is a simple matter to install bzr on my linux system and deal with it.
cd hello_world make CC STAR_smaller.o avr-gcc -Wall -g -Os -mmcu=attiny13 -o STAR_smaller.o -c STAR_smaller.c STAR_smaller.c:100:10: fatal error: util/delay.h: No such file or directory 100 | #includeSo, I am involved in some kind of header file nightmare. It turns out this issue is solved by installing the avr-libc package. Then we try it again:| ^~~~~~~~~~~~~~ compilation terminated. make: *** [Makefile:25: STAR_smaller.o] Error 1
make CC STAR_smaller.o avr-gcc -Wall -g -Os -mmcu=attiny13 -o STAR_smaller.o -c STAR_smaller.c LD STAR_smaller.elf avr-gcc -Wall -g -Os -mmcu=attiny13 -o STAR_smaller.elf STAR_smaller.o /usr/lib/gcc/avr/9.2.0/../../../../avr/bin/ld: STAR_smaller.o: in function `main': /u1/Projects/Convoy/trunk/hello_world/STAR_smaller.c:(.text.startup+0x10): undefined reference to `ADC_on' /usr/lib/gcc/avr/9.2.0/../../../../avr/bin/ld: STAR_smaller.o: in function `__vector_8': /u1/Projects/Convoy/trunk/hello_world/STAR_smaller.c:213: undefined reference to `read_mode_idx' /usr/lib/gcc/avr/9.2.0/../../../../avr/bin/ld: /u1/Projects/Convoy/trunk/hello_world/STAR_smaller.c:213: undefined reference to `next_mode' /usr/lib/gcc/avr/9.2.0/../../../../avr/bin/ld: /u1/Projects/Convoy/trunk/hello_world/STAR_smaller.c:213: undefined reference to `WDT_on' /usr/lib/gcc/avr/9.2.0/../../../../avr/bin/ld: /u1/Projects/Convoy/trunk/hello_world/STAR_smaller.c:213: undefined reference to `WDT_off' collect2: error: ld returned 1 exit status make: *** [Makefile:15: STAR_smaller.elf] Error 1Apparently there are some issues with the gcc I am using (avr-gcc (Fedora 9.2.0-1.fc30) 9.2.0) related to inline functions. The things it is complaining about are clearly "inline void" functions declared in the source file. Apparently if these are made "static inline" everything works, which is odd, but something that would require diving into gcc arcania to understand what and why. The relevant section of the gcc document would seem to be this:
When an inline function is not static, then the compiler must assume that there may be calls from other source files; since a global symbol can be defined only once in any program, the function must not be defined in the other source files, so the calls therein cannot be integrated. Therefore, a non-static inline function is always compiled on its own in the usual fashion.This would explain why the inline function might not be handled in an inline way, but I still don't see how it got eliminated and thus yielded link errors. But I have better things to do than chase this issue and adding the "static" keyword seems to solve this problem.
Tom's Electronics pages / tom@mmto.org