Using AVR-GCC with MPLAB-X Ide on LINUX

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I am trying to import an Atmel Studio (AS7) Project based on AVR-GCC compiler on Linux Ubuntu18.04.3 LTS.

My toolchain on MPLAB X(v5.25) is AVR_GCC version 5.4.0 provided by Microchip Site. I would want to stick to AVR_GCC since my entire project has been maintained on this compiler. 

I have successfully performed this task of transition from AS7 to MPLAB-X on Windows 10.

My problem is transition from Windows to Linux where I am having this issue which states that AVR (v1.0.0) isn't supported.

 

I have tried using the default location at /usr/bin too which again prompts the same problem.

What do I do ?

PS: Thought of resurrecting this post since it seems to have mentioned as ANSWERED. I guess it must be solved solutions for Windows systems and not for Linux systems.

This topic has a solution.

Nelson Lobo
(Firmware DevOps)

Last Edited: Tue. Oct 22, 2019 - 03:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

MPLAB-X frequently complains about external toolchains, erroneously saying they are "version 1.00" whatever that is. However, you can fix that error by editing a configuration file directly.

Unfortunately, I only know the file location for Windows systems, but I'm sure it must be there somewhere on Linux too.

 

On Windows, the file is this one (for MPLAB-X 5.15): " {user_path}\AppData\Roaming\mplab_ide\dev\v5.15\config\Preferences\com\microchip\mplab\nbide\embedded.properties "

 

I posted instructions for Windows here: https://www.avrfreaks.net/forum/...

Last Edited: Tue. Oct 22, 2019 - 01:15 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Finally got the solution.

 

El Tangas your doubts about the PATH is absolutely correct. In my .bashrc file I had made a mistake of adding an addition path to opt/microchip/avr8/bin/ which seemed to be causing this issue.

Once I got rid of that line.

 

I did the following:

Extracted and copied the contents of this avr-gcc version from Microchip into /opt/avr8/ folder.

Provided the location details in Build Tools Options.

Also got rid of AVR (v1.00) which was available as one of the default options by hitting the Remove button.

 

Now that my project is primarily focussed at AVR I have set the default option to AVR (v5.4.0)

 

The only problem that remains is that i need to open this Application in Root mode else it pops up various JRE related message boxes.

 

 

 

Nelson Lobo
(Firmware DevOps)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been using xc8-avr, with the build tools option set to look at the avr/bin folder to give the full gui compiler options and the ability to use c++ (same files, without the xc8 indirection). The default xc8 compiler options is a limited set (in the gui anyway), and no c++ support.

 

I have been using it for a while just on the tiny416 and mega4809, and I would say its mostly ok but there has always been little problems that 'shouldn't be'. I have been attributing any problems to mostly myself, since I am using c++ and well, maybe I'm not that good. In my defense I have a pic32mm that I started with very little knowledge of c++ and worked my way to a full set of drivers including usb, and I have had very few problems along the way- everything just works on that thing (and with the SNAP, debugging is fast and easy).

 

Working with the tiny/mega today, I seem to have discovered that the linker doesn't always know what its doing. A static var was getting overwritten somehow, and eventually discovered that there was another static var given the same address. Nice. I saw this thread and decided to give the 'toolchains for avr' linked to above a try. I simply downloaded, extracted to a folder, pointed the build tools to the bin folder, compiled, and it worked (that took about 5 minutes to do). Now things are starting to act normal. I hope this was the primary cause of my little problems. Since code is continually changing, its a little hard to distinguish code problems from other problems- one minute it works fine, so code must be good, then make some minor changes and it goes strange again (and then thinking latest code was the cause). If the linker all along has been throwing little problems at me from time to time, then that would explain what has been going on.

 

They are making quite a few changes in their version of gcc/avr, and in their defense they are not claiming to support c++ in this version, but in any case lots of changes means lots of potential to make mistakes that will take time to work themselves out. I had previously thought that since all the latest work being done was on the 'xc8 version', that was the place to be. Now I'm thinking the gcc branch is probably the 'stable' branch, and stable is good.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Glad you found your solution. But now i have stumbled upon new issues.

Namely the skidding Breakpoints issue. Which I will be addressing soon in a newer post.

Nelson Lobo
(Firmware DevOps)