Skip to content

Linux ARM version of avr-gcc 5.4.0-atmel3.6.1-arduino2 doesn't support ATmega4809 #17

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
per1234 opened this issue Feb 3, 2019 · 14 comments

Comments

@per1234
Copy link
Contributor

per1234 commented Feb 3, 2019

Compilation for Arduino Uno WiFi Rev2 on Linux ARM system fails:

avr-g++: error: device-specs/specs-atmega4809: No such file or directory

Unlike the Windows, Linux 32/64-bit, and macOS versions of avr-gcc 5.4.0-atmel3.6.1-arduino2, the files specs-atmega4809 and iom4809.h are missing.

From examining the contents of the archive files, the same issue appears to exist for the Linux ARM64 version of avr-gcc 5.4.0-atmel3.6.1-arduino2 as well.


Originally reported at http://forum.arduino.cc/index.php?topic=594755

@facchinm
Copy link
Member

facchinm commented Feb 4, 2019

Just checked and confirmed; the interim avr-gcc 5.4.0-atmel3.6.1-arduino3 contained avr4809 support on ARM platforms but was never released.
Since 5.4.0 has so many bugs/regressions I'd try to push towards using avr-gcc-7.3.0-atmel3.6.1-arduino4 (based on https://github.com/arduino/toolchain-avr/tree/staging) for the next AVR core release; @cmaglie @sandeepmistry @matthijskooijman @PaulStoffregen any though on that?

@PaulStoffregen
Copy link
Contributor

My belief, as always, it keeping the AVR & ARM toolchains at the same version is best.

So far, I've not tried 7.3.0, on either platform.

@per1234
Copy link
Contributor Author

per1234 commented Feb 5, 2019

I've been exclusively using avr-gcc-7.3.0-atmel3.6.1-arduino* with Arduino AVR Boards for the last two months without encountering any problems.

@matthijskooijman
Copy link
Collaborator

Agreed with @PaulStoffregen, using same versions (at least same major versions) would be good. Also, I like using new versions, since they typically work better and faster. Unlike @per1234, I haven't actually used the new version yet, though :-p

@facchinm
Copy link
Member

facchinm commented Feb 7, 2019

We are indeed already shipping

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]

(not exactly the same version but similar) on the samd beta core (for the Vidor)

@MCUdude
Copy link
Contributor

MCUdude commented Feb 12, 2019

Does the 7.2.1 version support the new ATtinys, such as ATtiny417 and ATtiny817?

It would be great if most tinyAVR-0 micros were supported so we can work on an Arduino port for these. Register wise it seems like this repo will be quite easy to port over to the tinyAVR-0 family.

@facchinm
Copy link
Member

@MCUdude they should be supported as part of the Atmel patches over gcc (see here https://github.com/arduino/toolchain-avr/blob/staging/avr-gcc-patches/atmel-patches-gcc.7.3.0-arduino2.patch#L1043) . Testing it would greatly speedup the adoption of the new toolchain (instructions here 🙂 )

@MCUdude
Copy link
Contributor

MCUdude commented Feb 13, 2019

Great! We're currently having an interesting discussion about Arduino support for the entire lineup of tinyAVR-0, tinyAVR-1 and megaAVR-0 devices.

@WestfW
Copy link
Contributor

WestfW commented Feb 27, 2019

Atmel is adding new device info to their compiler via "packs", rather than complete re-issue of new compiler toolchains. Studio knows how to find the packs, but the CLI toolchains (for pretty much any OS that you used the toolchain installer) make it a pain to use them.
There does seem to be a way to copy the "pack" files into the toolchain dirs:

https://www.avrfreaks.net/comment/2526416#comment-2526416

Example:

****
**** Expected failure of non-existing device.
****
 avr-gcc foo.c -mmcu=attiny416
In file included from foo.c:1:0:
/usr/local/avr8-atmel-3.6.1.495/avr/include/avr/io.h:623:6: warning: #warning "device type not defined" [-Wcpp]
 #    warning "device type not defined"
      ^
/usr/local/avr8-atmel-3.6.1.495/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld: cannot find crtattiny416.o: No such file or directory
/usr/local/avr8-atmel-3.6.1.495/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld: cannot find -lattiny416
collect2: error: ld returned 1 exit status


****
**** Add Device space from Atmel Pack.
****
WWHackintosh<9977> sudo cp /Downloads/Atmel.ATtiny_DFP.1.3.229/gcc/dev/attiny416/device-specs/specs-attiny416 /usr/local/avr8-atmel-3.6.1.495/lib/gcc/avr/5.4.0/device-specs/
Password:


****
**** Add needed libraries and linker scripts and such
****
WWHackintosh<9979> sudo cp -R /Downloads/Atmel.ATtiny_DFP.1.3.229/gcc/dev/attiny416/avrxmega3/* /usr/local/avr8-atmel-3.6.1.495/lib/gcc/avr/5.4.0/avrxmega3/

****
**** Add devide .h file.
****
WWHackintosh<9980> sudo cp -R /Downloads/Atmel.ATtiny_DFP.1.3.229/include/avr/iotn416.h /usr/local/avr8-atmel-3.6.1.495/avr/include/avr/      


****
**** And now it works!
****
WWHackintosh<9981> avr-gcc foo.c -mmcu=attiny416
WWHackintosh<9982> 

@facchinm
Copy link
Member

facchinm commented Mar 4, 2019

@WestfW the problem with packs is that they must be merged with the toolchain and can't live externally (neither using -B flag as documented by Atmel/Microchip.
The toolchain build script does exactly that (see https://github.com/arduino/toolchain-avr/blob/staging/atpack.build.bash )

@facchinm
Copy link
Member

This should be fixed by core 1.8.1, can anyone check? Thx 😉

@per1234
Copy link
Contributor Author

per1234 commented May 24, 2019

@facchinm still the same problem for Linux ARM 32-bits. There is no avr/lib/gcc/avr/7.3.0/device-specs/specs-atmega4809 nor avr/avr/include/avr/iom4809.h in http://downloads.arduino.cc/tools/avr-gcc-7.3.0-atmel3.6.1-arduino5-arm-linux-gnueabihf.tar.bz2.

The files are present in http://downloads.arduino.cc/tools/avr-gcc-7.3.0-atmel3.6.1-arduino5-aarch64-pc-linux-gnu.tar.bz2, so that half of the issue appears to be fixed.

@facchinm
Copy link
Member

@per1234 I repushed the toolchain, should be fine now. It's also included in arduino/Arduino#8976 for testing convenience

@per1234
Copy link
Contributor Author

per1234 commented Jun 15, 2019

It's working fine on Raspberry Pi now. Thanks @facchinm!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants