Allow a build with CMake and avr-gcc #3

ian-arkver · 2023-02-07T12:18:24Z

This series adds a basic CMakeLists.txt to compile the code using avr-gcc. It fixes some multiply defined symbols due to static variables in header files. It generates the elf output, but has not been tested on real hardware. More work is probably needed to add things like hex file generation.

The compiler and target selection is hard coded into the main CMakeLists file. Ideally this would be a separate toolchain file, but only the specific TinyG SoC is needed.

The line endings in the codebase seem to be mixed within each file. The editors I tried like to unify them, so the second commit has unintentional whitespace changes unfortunately. It might be better to fix these all at once, but that's an upstream task I think.

Usage instructions:

Install a version of GCC for AVR on your development machine.

For example on Manjaro use sudo pacman -S avr-gcc or on a Ubuntu flavour something like sudo apt install gcc-avr avr-libc might work. For Windows and Mac perhaps look at Microchip's site. Ensure the compiler is on your PATH. Also ensure CMake is installed and a build system like make or Ninja.

Clone the TinyG repo and cd into the source
cd TinyG/firmware/tinyg

Make a work dir to build in, change into it

mkdir build
cd build

Make the Makefiles or Ninja files. Build.
One of the following. Change Release to Debug if you want debug symbols in the elf and less optimisation.
Using Ninja:

cmake -GNinja -DCMAKE_BUILD_TYPE=Release ..
ninja

or using make and assuming an 8 thread CPU:

cmake -DCMAKE_BUILD_TYPE=Release ..
make -j8

Result is in tinyg.elf with a hex dump file in tinyg.hex

brainstorm · 2023-02-08T23:22:06Z

Well done @ian-arkver! I guess the .hex could be generated with AVR's objcopy -O ihex input.elf output.hex?

ian-arkver · 2023-02-08T23:29:19Z

Yeah, that would be the next step. I just now generated some hex as you suggest...

avr-objcopy -O ihex tinyg.elf tinyg.hex

but I've not added it as a custom command to the cmake file.

brainstorm · 2023-02-08T23:33:48Z

Yeah, that would be the next step. I just now generated some hex as you suggest...

avr-objcopy -O ihex tinyg.elf tinyg.hex

but I've not added it as a custom command to the cmake file.

Thanks! Please do add it to the build infrastructure, I'll use your changes, add mine and give that .hex a go next Tuesday ;)

Include min pagesize workaround for avr-gcc version 12 bug, see here: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=105523

ian-arkver · 2023-02-09T00:06:55Z

I added the other compile flags to match the ones in Debug/Makefile. If you're going to try this on hardware these might be necessary. The F_CPU one is probably critical.

These flags included -Wall and avr-gcc version 12 has a bug.
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=105523
Added the workaround.

Not that it seems to make any difference.

brainstorm · 2023-02-13T11:25:08Z

Thanks Ian!

Just getting ready for tomorrow, I'm hitting some snags with this branch:

brainstorm@braingate:~/dev/TinyG/firmware/tinyg/build$ cmake ..
-- The C compiler identification is GNU 11.3.0
-- The CXX compiler identification is GNU 11.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/brainstorm/dev/TinyG/firmware/tinyg/build


brainstorm@braingate:~/dev/TinyG/firmware/tinyg/build$ make -j8
[  4%] Building C object CMakeFiles/tinyg.elf.dir/config.c.o
[  4%] Building C object CMakeFiles/tinyg.elf.dir/canonical_machine.c.o
[  6%] Building C object CMakeFiles/tinyg.elf.dir/cycle_probing.c.o
[ 11%] Building C object CMakeFiles/tinyg.elf.dir/cycle_homing.c.o
[ 11%] Building C object CMakeFiles/tinyg.elf.dir/cycle_jogging.c.o
[ 13%] Building C object CMakeFiles/tinyg.elf.dir/encoder.c.o
cc1: error: invalid parameter ‘min-pagesize’
cc1: error: invalid parameter ‘min-pagesize’
cc1: error: invalid parameter ‘min-pagesize’
cc1: error: invalid parameter ‘min-pagesize’
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:90: CMakeFiles/tinyg.elf.dir/config.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:132: CMakeFiles/tinyg.elf.dir/cycle_homing.c.o] Error 1
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:160: CMakeFiles/tinyg.elf.dir/cycle_probing.c.o] Error 1
[ 16%] Building C object CMakeFiles/tinyg.elf.dir/config_app.c.o
cc1: error: invalid parameter ‘min-pagesize’
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:174: CMakeFiles/tinyg.elf.dir/encoder.c.o] Error 1
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:76: CMakeFiles/tinyg.elf.dir/canonical_machine.c.o] Error 1
cc1: error: invalid parameter ‘min-pagesize’
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:146: CMakeFiles/tinyg.elf.dir/cycle_jogging.c.o] Error 1
cc1: error: invalid parameter ‘min-pagesize’
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:104: CMakeFiles/tinyg.elf.dir/config_app.c.o] Error 1
[ 18%] Building C object CMakeFiles/tinyg.elf.dir/controller.c.o
cc1: error: invalid parameter ‘min-pagesize’
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:118: CMakeFiles/tinyg.elf.dir/controller.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/tinyg.elf.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

What am I doing wrong?

ian-arkver · 2023-02-13T11:29:31Z

The min-pagesize workaround is for a bug in gcc 12. You're using 11 which doesn't have the option. You can just remove the "--param=min-pagesize=0" line from the compile options.

In theory cmake should be told to add the flag dependent on the compiler version, but again this should really be moved out to a toolchain file instead. Feel free to fix it up. :-)

brainstorm · 2023-02-13T22:54:52Z

Thanks for the flag suggestion, I'm no CMake expert (so it'd take a while for me to implement that compiler conditional), but I found more issues after removing that flag... in which OS did you build it, btw?:

brainstorm@braingate:~/dev/TinyG/firmware/tinyg/build$ cmake ..
-- Configuring done
-- Generating done
-- Build files have been written to: /home/brainstorm/dev/TinyG/firmware/tinyg/build
brainstorm@braingate:~/dev/TinyG/firmware/tinyg/build$ make -j8
[  2%] Building C object CMakeFiles/tinyg.elf.dir/canonical_machine.c.o
[  4%] Building C object CMakeFiles/tinyg.elf.dir/config.c.o
[  6%] Building C object CMakeFiles/tinyg.elf.dir/controller.c.o
[  9%] Building C object CMakeFiles/tinyg.elf.dir/config_app.c.o
[ 16%] Building C object CMakeFiles/tinyg.elf.dir/encoder.c.o
[ 16%] Building C object CMakeFiles/tinyg.elf.dir/cycle_jogging.c.o
[ 16%] Building C object CMakeFiles/tinyg.elf.dir/cycle_probing.c.o
[ 18%] Building C object CMakeFiles/tinyg.elf.dir/cycle_homing.c.o
In file included from /home/brainstorm/dev/TinyG/firmware/tinyg/cycle_jogging.c:27:0:
/home/brainstorm/dev/TinyG/firmware/tinyg/tinyg.h:35:19: fatal error: ctype.h: No such file or directory
In file included from /home/brainstorm/dev/TinyG/firmware/tinyg/controller.c:29:0:
/home/brainstorm/dev/TinyG/firmware/tinyg/tinyg.h:35:19: fatal error: ctype.h: No such file or directory
In file included from /home/brainstorm/dev/TinyG/firmware/tinyg/config.c:31:0:
/home/brainstorm/dev/TinyG/firmware/tinyg/tinyg.h:35:19: fatal error: ctype.h: No such file or directory
compilation terminated.
compilation terminated.
compilation terminated.
In file included from /home/brainstorm/dev/TinyG/firmware/tinyg/config_app.c:28:0:
/home/brainstorm/dev/TinyG/firmware/tinyg/tinyg.h:35:19: fatal error: ctype.h: No such file or directory
In file included from /home/brainstorm/dev/TinyG/firmware/tinyg/encoder.c:28:0:
/home/brainstorm/dev/TinyG/firmware/tinyg/tinyg.h:35:19: fatal error: ctype.h: No such file or directory
In file included from /home/brainstorm/dev/TinyG/firmware/tinyg/canonical_machine.c:89:0:
/home/brainstorm/dev/TinyG/firmware/tinyg/tinyg.h:35:19: fatal error: ctype.h: No such file or directory
In file included from /home/brainstorm/dev/TinyG/firmware/tinyg/cycle_homing.c:28:0:
/home/brainstorm/dev/TinyG/firmware/tinyg/tinyg.h:35:19: fatal error: ctype.h: No such file or directory
In file included from /home/brainstorm/dev/TinyG/firmware/tinyg/cycle_probing.c:27:0:
/home/brainstorm/dev/TinyG/firmware/tinyg/tinyg.h:35:19: fatal error: ctype.h: No such file or directory
compilation terminated.
compilation terminated.
compilation terminated.
compilation terminated.
compilation terminated.
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:160: CMakeFiles/tinyg.elf.dir/cycle_probing.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:146: CMakeFiles/tinyg.elf.dir/cycle_jogging.c.o] Error 1
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:76: CMakeFiles/tinyg.elf.dir/canonical_machine.c.o] Error 1
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:118: CMakeFiles/tinyg.elf.dir/controller.c.o] Error 1
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:90: CMakeFiles/tinyg.elf.dir/config.c.o] Error 1
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:174: CMakeFiles/tinyg.elf.dir/encoder.c.o] Error 1
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:132: CMakeFiles/tinyg.elf.dir/cycle_homing.c.o] Error 1
make[2]: *** [CMakeFiles/tinyg.elf.dir/build.make:104: CMakeFiles/tinyg.elf.dir/config_app.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/tinyg.elf.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

ian-arkver · 2023-02-14T09:13:58Z

Hi Roman,

I use the avr-gcc package for the compiler and avr-libc for the runtime. Both these are official packages on my distro, Manjaro, which is an Arch derivative.

In particular ctype.h is a standard include from the runtime and in my system is found here:

[ian@devbox3 TinyG]$ pacman -Fx /usr/avr/include/ctype.h
usr/avr/include/ctype.h is owned by community/avr-libc 2.1.0-1

From the error I'd guess you have the compiler but not the runtime library installed, or else the default compiler include path doesn't search wherever the runtime is installed, which would be a bug in your distro's packaging. You can check the paths with:

[ian@devbox3 TinyG]$ echo | avr-gcc -E -Wp,-v -
ignoring nonexistent directory "/usr/lib/gcc/avr/12.2.0/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/avr/12.2.0/include
 /usr/lib/gcc/avr/12.2.0/include-fixed
 /usr/lib/gcc/avr/12.2.0/../../../../avr/include
End of search list.
# 0 "<stdin>"
# 0 "<built-in>"
# 0 "<command-line>"
# 1 "<stdin>"

Hope this helps.

ian-arkver · 2023-02-14T13:52:16Z

Fixed the warnings but again those files had inconsistent line endings, so vscode has unified them causing spurious whitespace diffs.

brainstorm · 2023-02-16T08:57:42Z

Hi Roman,

I use the avr-gcc package for the compiler and avr-libc for the runtime. Both these are official packages on my distro, Manjaro, which is an Arch derivative.
(...)
Hope this helps.

Indeed, silly me, for some reason I thought that apt-get install avr-gcc did pull avr-libc as a dependency, but obviously it did not (and shouldn't), so I just had to install the latter explicitly and everything compiles fine! :)

Now, comparing the resulting objects from Atmel Studio vs yours, there's a few (big) differences:

This branch's object sizes:

-rwxr-xr-x  1 brainstorm brainstorm 493K Feb 16 18:51 tinyg.elf
-rw-r--r--  1 brainstorm brainstorm 342K Feb 16 18:51 tinyg.hex

Atmel studio's sizes:

-rwxrwxrwx 1 brainstorm brainstorm 830K Feb 14 20:22 /mnt/c/Users/brain/dev/TinyG/firmware/tinyg/Debug/tinyg.elf
-rwxrwxrwx 1 brainstorm brainstorm 324K Feb 14 20:22 /mnt/c/Users/brain/dev/TinyG/firmware/tinyg/Debug/tinyg.hex

So the target .hex delta is around 20KB, so I'll assume that the differences are due to Debug -g-related flags not present on this branch.

So checking out the function count of the target hexes and comparing:

$ r2 ihex:///mnt/c/Users/brain/dev/TinyG/firmware/tinyg/Debug/
tinyg.hex
 -- The more 'a' you add after 'aa' the more analysis steps are executed.
[0x000092a4]> aaaa
INFO: Analyze all flags starting with sym. and entry0 (aa)
INFO: Analyze all functions arguments/locals (afva@@@F)
INFO: Analyze function calls (aac)
INFO: find and analyze function preludes (aap)
INFO: Analyze len bytes of instructions for references (aar)
INFO: Finding and parsing C++ vtables (avrr)
INFO: Finding xrefs in noncode section (e anal.in=io.maps.x)
INFO: Analyze value pointers (aav)
INFO: aav: 0x00000000-0x0001cc2c in 0x0-0x1cc2c
INFO: Emulate functions to find computed references (aaef)
INFO: Type matching analysis for all functions (aaft)
INFO: Propagate noreturn information (aanr)
INFO: Scanning for strings constructed in code (/azs)
INFO: Enable anal.types.constraint for experimental type propagation
[0x000092a4]> afl | wc -l
466

There are indeed 38 functions missing (or at least those that radare2 can detect side by side):

(...)
[0x00009856]> afl | wc -l
428

I'll check further what you meant by F_CPU being critical and the other flags and see if I can get those counts a bit closer, thanks for the help in any case! And let's see if we can get this ready for next Tuesday without risking bricking things in the process ;)

ian-arkver · 2023-02-16T09:04:46Z

Hi Roman,

I guess function count differences could be due to compiler/libc version too. Maybe the LTO in gcc 12 is better at inlining stuff. Radare2 looks interesting - hadn't come across that before.

F_CPU is used in (among other things) software delay loops. If it's wrong (or unset and defaults to something wrong) then those loops will delay for the wrong time. I haven't looked at TinyG code to see if it uses SW delays or what the effects of them being wrong would be. I copied the F_CPU setting from the original Makefile so it should hopefully be ok.

I noticed comments on the OpenPnP group recently that flashing the TinyG will scrub any settings you have stored. Just a heads-up.

Good Luck!

brainstorm · 2023-02-16T09:35:11Z

Radare2 looks interesting - hadn't come across that before.

It's awesome, been using it for a few years now on and off, totally recommended.

I noticed comments on the OpenPnP group recently that flashing the TinyG will scrub any settings you have stored. Just a heads-up.

Yeah, I'm aware of that since it bit me in the past and reported it to Mark, he kindly included the recommendation of backing up $$'s output in his original blogpost, point 15 of his flashing procedure explanation... thanks for reminding, I'll be more diligent in upcoming re-flashes, but so far the machine still works as it was (fingers crossed).

ian-arkver · 2023-02-18T09:56:05Z

Just noticed the edit - so... You flashed the cmake built hex and it worked ok?

brainstorm · 2023-02-18T10:11:55Z

Just noticed the edit - so... You flashed the cmake built hex and it worked ok?

Not yet, next Tuesday is my next window of opportunity, I only go to CCHS on Tuesdays ;)

ian-arkver · 2023-02-18T10:13:41Z

Ah right, ok. Good luck, bring a backup. :-)

markmaker · 2023-02-22T18:14:03Z

Cool stuff guys, appreciate a lot!

markmaker · 2023-02-22T19:19:31Z

@ian-arkver you're a

`🦸‍♂️`

@brainstorm, looking forward to your test!

I noticed comments on the OpenPnP group recently that flashing the TinyG will scrub any settings you have stored. Just a heads-up.

I suspect the EEPROM did only get corrupted because the TinyG authors were not diligent to keep the same layout across versions, and they did not increment the version number, so I got fooled twice. In my own tests, the settings were stable through flashing many times.

@brainstorm, unless I missed something, you need to cherry pick the ADC changes over, before you test on your hardware (this branch does not have them yet).

@ian-arkver, please increment the version number in the firmware, and possibly the M115 response FIRMWARE_URL, so we know that this is now definitely the PnP version with the ADC present etc., and that this is the avr-gcc build.

@ian-arkver, I did not know settings/settings_openpnp.h, and I'm not sure it is actually any good. Unless you positively know it is better, I suggest to go back to settings_default.h, i.e. change as little as possible.

Then, am I doing this right?

As discussed above, I had to remove the --param=min-pagesize=0 from the firmware/tinyg/CMakeLists.txt

sudo apt-get install -y gcc-avr avr-libc cmake
cmake -S firmware/tinyg/ -B build/
cmake --build build/

And it built flawlessly! 🏆 🏆 🏆

Compare that to setting up AtmelStudio 🤮

Side note: on my Kubuntu the package is gcc-avr instead of avr-gcc.

This is so great!

_Mark

markmaker · 2023-02-22T19:24:13Z

possibly the M115 response FIRMWARE_URL

Forgot the link

TinyG/firmware/tinyg/canonical_machine.c

Line 853 in a61772d

    
           static const char m115_response[] PROGMEM = "FIRMWARE_NAME:TinyG, FIRMWARE_URL:https%%3A//github.com/synthetos/TinyG, FIRMWARE_VERSION:%0.2f, FIRMWARE_BUILD:%0.2f, HARDWARE_PLATFORM:%0.2f, HARDWARE_VERSION:%0.2f\n";

_Mark

at Mark's suggestion since settings_openpnp.h is of unknown quality.

brainstorm · 2023-02-22T22:58:20Z

@markmaker We were focused on getting the ADC to work wit Atmel Studio branch first in #2 , but we hit some problems with the capacitor value in combination and the Mikroe Vacuum Sensor... here's the last checkpoint in our investigation by Anthony:

We are getting this nasty 2-4Mhz signal on the scope and the ADC just doesn't work when the TinyG board is fully initialized:

funnily enough it works when is still booting and we see the sensor reporting the right vacuum level through the voltage on the oscilloscope.

So the recommendation from TheReza on the Liteplacer forum might interfere with our needs with our particular sensor... we'll test more about this soon.

We wanted to flash @ian-arkver's .hex whenever we got those Vacuum issues fully figured out to not introduce more confounding variables in our investigation. After that's cleared, I'd be happy to PR our changes to Ian once we get the Vacuum working, we've been testing a lot of things at CCHS in the last 3 Tuesday sessions, hang in there ;)

@markmaker If you still have a TinyG board, go ahead and flash Ian's .hex? Otherwise you'll have to wait until the next window of opportunity (Tuesdays).

ian-arkver · 2023-02-22T23:43:10Z

I've reverted the settings_openpnp.h change and fixed up the cmake file so it only uses the gcc 12 fix if the gcc version is greater than 12.0 This might need revisited if/when Gnu fix the bug.

I've added an invented FEATURE_TAGS section to the M115 response with a '/' separated list of tags which are currently OPENPNP and CMAKE.

I've not cherry-picked the ADC change so I haven't added an ADC feature tag.

I also haven't bumped the firmware version since it seems that's what causes the settings to be scrubbed...

	read_persistent_value(nv);
	if (nv->value != cs.fw_build) {				// case (1) NVM is not setup or not in revision
		_set_defa(nv);

ian-arkver · 2023-02-23T00:00:48Z

@markmaker I don't have a TinyG so I've no idea whether settings_openpnp.h is better or worse so just undid the change as you suggested.

And yeah, your build runes look fine. Personally I like to use VSCode with CMakeTools extension so building is a one-click operation, but using cmake from the command line is also easy.

ian-arkver · 2023-02-28T14:15:42Z

It would be nice if someone who has an Atmel Studio setup and a TinyG can confirm that this series doesn't break that build chain. It shouldn't. In that case I think this could be merged as the other changes are specific to building with CMake. Once merged then perhaps the ADC-enabling branch can be rebased/merged to include this.

brainstorm · 2023-02-28T19:30:54Z

@brainstorm, some questions about the schematic...
* You got an MCP3221 I2C ADC on the board, is this a fall-back in case the TinyG ADC implementation fails?

I wish it was! Unfortunately our TinyG board (and xmega) does not seem to have I2C bus, so it'd have to be bit-banged, which is not good IMO.

Instead we are using the AN (analog) signal of that schematic/board.

* Might wanna add some bypassing on all the ICs' VDD/VCC, especially the MCP3221, as it also serves as reference (see data sheet 6.4).

The board is fairly well decoupled/tested I reckon and we found the culprit anyway as mentioned on the OpenPnP ML.

* You jumper-select the raw VS_OUT vs. divided VS_DIV, but why? You have a dual op-amp, why not just buffer (and break out) both, like [in my design](https://makr.zone/wp-content/uploads/2018/06/Vacuum-Sensor-Simulation-Circuit.png)?

I think that the board is built to accommodate different target voltages and target applications, haven't looked deeper into that either.

_Mark

brainstorm · 2023-03-07T12:11:11Z

Well, finally we managed to tame the ADC situation with our current firmware (sans 100Hz) today and tidied/low-pass-filtered it all up with a custom board. It got pretty late and I was about to test this branch on our PnP...

But I forgot to bring my Linux machine (🤦🏻 ) so I only had my mac with me and unfortunately it fails to compile on OSX:

(base) rvalls@m1 tinyg % mkdir build
(base) rvalls@m1 tinyg % cd build
(base) rvalls@m1 build % ls
(base) rvalls@m1 build % cmake ..
-- The C compiler identification is AppleClang 14.0.0.14000029
-- The CXX compiler identification is AppleClang 14.0.0.14000029
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/rvalls/dev/personal/TinyG/firmware/tinyg/build
(base) rvalls@m1 build % make -j8
[  4%] Building C object CMakeFiles/tinyg.elf.dir/config.c.o
[  4%] Building C object CMakeFiles/tinyg.elf.dir/controller.c.o
[  6%] Building C object CMakeFiles/tinyg.elf.dir/canonical_machine.c.o
[  9%] Building C object CMakeFiles/tinyg.elf.dir/cycle_probing.c.o
[ 13%] Building C object CMakeFiles/tinyg.elf.dir/cycle_homing.c.o
[ 13%] Building C object CMakeFiles/tinyg.elf.dir/encoder.c.o
[ 16%] Building C object CMakeFiles/tinyg.elf.dir/cycle_jogging.c.o
[ 18%] Building C object CMakeFiles/tinyg.elf.dir/config_app.c.o
avr-gcc: error: unrecognized command-line option '-arch'
avr-gcc: error: unrecognized command-line option '-arch'
avr-gcc: error: unrecognized command-line option '-arch'
make[2]: *** [CMakeFiles/tinyg.elf.dir/encoder.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/tinyg.elf.dir/config.c.o] Error 1
avr-gcc: error: unrecognized command-line option '-arch'
make[2]: *** [CMakeFiles/tinyg.elf.dir/cycle_jogging.c.o] Error 1
avr-gcc: error: unrecognized command-line option '-arch'
avr-gcc: error: unrecognized command-line option '-arch'
make[2]: *** [CMakeFiles/tinyg.elf.dir/cycle_homing.c.o] Error 1
avr-gcc: error: unrecognized command-line option '-arch'
make[2]: *** [CMakeFiles/tinyg.elf.dir/cycle_probing.c.o] Error 1
make[2]: *** [CMakeFiles/tinyg.elf.dir/controller.c.o] Error 1
make[2]: *** [CMakeFiles/tinyg.elf.dir/canonical_machine.c.o] Error 1
avr-gcc: error: unrecognized command-line option '-arch'
make[2]: *** [CMakeFiles/tinyg.elf.dir/config_app.c.o] Error 1
make[1]: *** [CMakeFiles/tinyg.elf.dir/all] Error 2
make: *** [all] Error 2

I was about to go through the rabbit hole and fix it, but I'm afraid it'll have to be another day next week :_/

brainstorm · 2024-03-25T22:00:22Z

Thanks for the PR merge @ian-arkver!

@markmaker I reckon this can be merged, actually? :)

markmaker · 2024-03-26T11:05:27Z

Thank a lot @brainstorm and @ian-arkver !

It has been a long time and I would like to be current with the status of this. Could any of you elaborate a bit? Some stuff is in the Description, but it seems a bit terse.

How to build, ideally with a short description how to get packages on different platforms (I know on Linux, but how on macOS, Windows?)
What the status is, with the ADC (I seem to remember it was a corrupted EEPROM $-setting, but I'm unsure)

The intention is to get "Instructions for Use" for posterity. Best revise the Description to reflect the latest state.

Thanks again! 💯 🥇

ian-arkver · 2024-03-26T20:34:28Z

@markmaker Added some runes. It's far from exhaustive but hopefully enough to get started. This changeset is unrelated to the ADC changes afaik.

brainstorm · 2024-03-26T23:58:58Z

Agreed, please ignore the ADC stuff Mark. Those changes were made by my initial motivation with a previous PR but those are closed and the problem with the EEPROM is resolved as well.

I haven't tried to compile this on windows, I don't even know how devs would like to work with this on windows: cygwin and WSL2 should work out of the box, though, other than that, no idea.

brainstorm · 2024-03-27T00:02:06Z

The description should point out that there's a resulting .hex file, not just .elf as the former is what's actually flashed via avrdude on the TinyG board.

markmaker · 2024-03-27T07:01:44Z

Thanks, @ian-arkver, that's brilliant.

I wonder if we should throw out all the AtmelStudio and .xcodeproj stuff, so nobody tries to still use them (I'm assuming those no longer work, or at least we don't want to give the impression they are supported anymore).

There were also build artifacts checked in. I think we should at least check-in the .hex as before, so users can directly install it without having to build. But probably not in the tinyg/Debug folder as before.

Btw. the cmake build is a release build, right?

_Mark

ian-arkver · 2024-03-27T09:14:39Z

Default cmake build is debug I think. I'll add -DCMAKE_BUILD_TYPE=Release to the instructions, and also add the custom_command for the hex dump. We can make that put the output wherever you prefer.

Will look at these this evening hopefully.

ian-arkver · 2024-03-27T09:16:35Z

Though actually my CMake file is a bit hacky and overrides the default optimisation: -O2 -g2 -Wall

ian-arkver · 2024-03-29T15:00:41Z

@markmaker I pushed one more commit to make the optimisation flags depend on build mode and added more details to the comment section on that.

The custom command to generate the hex was already there, I just changed the comment above to mention that the hex file was also created. It's in the same build dir.

ps. Re cleaning out the old build system - that's not really my call, it's yours for your fork of tinyg and synthetos's for upstream. Personally I'd wait a while after merging this for people to migrate and test the flow in windows/mac/other-linuxii and then maybe add a "Old buildsystem deprecated, will be removed" note to the README or something, then maybe a year from now... pull the rug.

markmaker · 2024-03-30T13:00:28Z

I agree about removing the other build systems.

But I still think you should check-in the build/tingy.hex artifact, so users can test the new build without having to compile themselves. I believe it is small enough to go against pure "no artifacts" policy.

This also helps with future features / PRs and their community testing.

ian-arkver · 2024-03-30T16:26:13Z

Hi @markmaker .

Hex files are explicitly ignored in the .gitignore in the firmware dir. Also tinyg.hex is ignored at the dir level above. Are you sure you want me to remove these so tinyg.hex can be tracked?

markmaker · 2024-03-31T10:44:50Z

yes, you can override gitignore with the -f flag. On 30 Mar 2024, at 17:26, ian-arkver ***@***.***> wrote: Hi @markmaker . Hex files are explicitly ignored in the .gitignore in the firmware dir. Also tinyg.hex is ignored at the dir level above. Are you sure you want me to remove these so tinyg.hex can be tracked? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

ian-arkver · 2024-03-31T13:14:39Z

@markmaker OK, added with -f as you suggested, pushed.

markmaker · 2024-04-01T12:03:41Z

Great, many thanks! 💯

ian-arkver · 2024-04-01T15:57:13Z

Thanks Mark.

ian-arkver · 2024-04-01T15:58:24Z

btw, as I mentioned earlier in this thread, I don't have a TinyG board, so this is completely untested by me.

markmaker · 2024-04-02T06:07:55Z

All the more thanks for your self-less work! 🥇

I do have a board but I don't think I'll find time to test it anytime soon... but this is is not pressing either.

Ian Jamison added 2 commits February 7, 2023 10:53

Add CMakeLists.txt and ignore built artifacts

b98f3bd

Move static data structs from headers to code

63f24e6

Ian Jamison added 2 commits February 9, 2023 00:03

Add compile flags matching Debug Makefile.

7d9d740

Include min pagesize workaround for avr-gcc version 12 bug, see here: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=105523

Add custom command to generate Intel hex

f534ec2

Use avr-objcopy instead of default objcopy

6a3a690

Not that it seems to make any difference.

Fix GCC string format and buffer overflow warnings

040cc50

Ian Jamison added 2 commits February 22, 2023 22:34

Revert back to default settings

b157592

at Mark's suggestion since settings_openpnp.h is of unknown quality.

Make avr-gcc 12 fix version dependant

66280ca

Add feature tags to firmware response string

792b580

Only include CMake M115 tag in CMake builds

f31ddac

brainstorm mentioned this pull request May 8, 2023

Atmel studio 7.x migration #1

Closed

Successfully compile on OSX

da00c7b

This was referenced Mar 4, 2024

CMake OSX compatibility ian-arkver/TinyG#1

Merged

Add AS5600 (hardware) encoder #4

Draft

brainstorm added 2 commits March 6, 2024 22:54

Add fix for 'cc1: error: invalid parameter ‘min-pagesize’'

890772d

Remove unnecessary comments, as suggested by Ian

56dfe5d

Make optimisation flags depend on build type

30b2428

Add release build hex file from cmake build

95ab47e

markmaker merged commit 0b7a174 into markmaker:feature/best-for-pnp Apr 1, 2024

Allow a build with CMake and avr-gcc #3

Allow a build with CMake and avr-gcc #3

Uh oh!

Conversation

ian-arkver commented Feb 7, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Usage instructions:

Uh oh!

brainstorm commented Feb 8, 2023

Uh oh!

ian-arkver commented Feb 8, 2023

Uh oh!

brainstorm commented Feb 8, 2023

Uh oh!

ian-arkver commented Feb 9, 2023

Uh oh!

brainstorm commented Feb 13, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ian-arkver commented Feb 13, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brainstorm commented Feb 13, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ian-arkver commented Feb 14, 2023

Uh oh!

ian-arkver commented Feb 14, 2023

Uh oh!

brainstorm commented Feb 16, 2023

Uh oh!

ian-arkver commented Feb 16, 2023

Uh oh!

brainstorm commented Feb 16, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ian-arkver commented Feb 18, 2023

Uh oh!

brainstorm commented Feb 18, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ian-arkver commented Feb 18, 2023

Uh oh!

markmaker commented Feb 22, 2023

Uh oh!

markmaker commented Feb 22, 2023

🦸‍♂️

Uh oh!

markmaker commented Feb 22, 2023

Uh oh!

brainstorm commented Feb 22, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ian-arkver commented Feb 22, 2023

Uh oh!

ian-arkver commented Feb 23, 2023

Uh oh!

ian-arkver commented Feb 28, 2023

Uh oh!

brainstorm commented Feb 28, 2023

Uh oh!

brainstorm commented Mar 7, 2023

Uh oh!

brainstorm commented Mar 25, 2024

Uh oh!

markmaker commented Mar 26, 2024

Uh oh!

ian-arkver commented Mar 26, 2024

Uh oh!

brainstorm commented Mar 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brainstorm commented Mar 27, 2024

Uh oh!

markmaker commented Mar 27, 2024

Uh oh!

ian-arkver commented Mar 27, 2024

Uh oh!

ian-arkver commented Mar 27, 2024

Uh oh!

ian-arkver commented Feb 7, 2023 •

edited

Loading

brainstorm commented Feb 13, 2023 •

edited

Loading

ian-arkver commented Feb 13, 2023 •

edited

Loading

brainstorm commented Feb 13, 2023 •

edited

Loading

brainstorm commented Feb 16, 2023 •

edited

Loading

brainstorm commented Feb 18, 2023 •

edited

Loading

`🦸‍♂️`

brainstorm commented Feb 22, 2023 •

edited

Loading

brainstorm commented Mar 26, 2024 •

edited

Loading

ian-arkver commented Mar 29, 2024 •

edited

Loading