I worked in the past with Helios and AVR Plugin for Eclipse 2.3.4 without big problems so far.
Now I decided to change to AVR Plugin 2.4.0 the latest tool chain from ATMEL and Indigo.
I started from scratch and loaded the last Eclipse Indigo Version (win32). I installed it and started with an empty workspace. Then I performed a update check to ensure Eclipse is on the latest version.
Then I loaded avreclipse.2.4.0.final.p2repository.zip unzipped it and stored it on the HDD.
After that I loaded the current ATMEL Tool chain and installed it.
Then I installed the AVR Plugin to Eclipse (Help/Install new Software).
That process worked fine so far.
After installing I restarted Eclipse as recommended.
Now I can see the typical buttons and so on are available and things are looking fine.
Under Window/Preferences/AVR/Paths I keyed in the path to th AVR Toolchain.
AVR-GCC ==> C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain\bin
GNU make ==> C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain\bin
AVR Header Files ==> C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain\avr\include
AVRDude ==> C:\Program Files (x86)\Atmel\AVR Tools\AVR Toolchain\bin
Atmel Part Description Files are not available and so far I know not necessary.
Finally I disabled search for system path at startup and click the button Apply
To be sure everything is correct I restarted Eclipse.
When I now start to create a new C project (File/New/C Project)
For Project name I key in "Test"
Project type:
AVR Cross Target Application
Empty Project
Toolchains:
AVR-GCC Toolchain
Click Button Next
I unselected Debug
Click Button Next
I see the dialogue AVR Target Hardware Properties
Here is the MCU Type: empty and the MCU Frequency (Hz): is 1000000
When I click to the MCU Type nothing is to select.
I'm on a Mac and using the CrossPack instead of the Atmel distribuition.
In the "Paths" panel I have introduced the path /usr/local/CrossPack-AVR-20130212/bin for everything except the AVR Header Files (/usr/local/CrossPack-AVR-20130212/avr/include)
Could this be the reason why it doesn't work?
If the usual (unmodified) avr-eclipse plug-in didn't worked with avr-gcc, I
don't think my mod will do the difference... I read also many posts
regarding to problems under Mac...
What can I say, maybe you can put together an used PC from someone who does
not need it any more? Linux will work for sure if you can't afford (or
simply don't need) a WIndows license.
I'm really sorry that it does not work for you!
Best regards!
On Sat, May 25, 2013 at 10:14 PM, xtal xtalxtal@users.sf.net wrote:
--
Vasi
Related
Support Requests: #25
Hi all. I encountered this issue about four months ago when I upgraded to the ATMEL toolchain from WinAVR. I had successfuly used this plugin with WinAVR for about 6 months compiling some simple experimental C programs for the ATtiny2313 device.
This issue of the devices drop down list not being populated meant that, to continue with my projects, I had to revert back to using command line instructions written in Windows batch files. (My system is a Windows7 PC). Having reached a suitable point in my experiments a couple of weeks ago I decided to investigate this 'bug' and by chance stumbled on this forum and found this bug report.
Several days ago I decided to carry out an experiment - deleting and re-installing Eclipse and this plugin. This has cured the fault!!!
I already had the ATMEL tolchain on my pc (having uninstalled the WinAVR toolchain) so I had already altered the path environment variable to add in the paths to the ATMEL toolchain. I deleted and reinstalled Eclipse(Keppler) and installed the plugin anew. It was necessary to manually edit the four directory locations (located in Windows > Preferences) for the ATMEL toolchain as the plugin had not 'found' this toolchain.
I created a new project with an existing C program that I knew would compile correctly. I went to set up the Project > Preferences to set CPU frequency as 20MHz and the device as ATtiny2313 and that is when I found the dropdown list fully populated with all the supported devices.
Perhaps others could carry out the same experiment and post the results here.
On the AVR Freaks forums there is an update to this plugin, so it works
with the new avrdude 6.x
But you can install it manually from my archive (because the plugin was
available only via internet, I made my own archive to be sure I won't lose
it).
On Thu, Feb 20, 2014 at 3:12 PM, semulum semulum@users.sf.net wrote:
--
Vasi
Related
Support Requests: #25
Hallo all,
a simple:
works for me on linux with eclipse luna.
Hi Vasi, Ivica,
What is the reason that this suddenly got revived?
Is there an update of GCC that changed the --target-help output? Which version of GCC are you using?
Please notice that the plugin executes the following command to find the supported CPU's:
The output has two sections with supported MCU's the first one starts with a line " Known MCU names:" and the second section starts with "Known MCU names:".
In other words, the second one matches. So what is the reason for the patch?
Hallo,
The reason is that the german language the output of avr-gcc -Wa,-mlist-devices --target-help is:
and
And the plugin not work corectly....
That's the reason.
the 2.4.0 eclipse-avr plugin doesn't work with the new avrdude 6.x - it
won't be able to retrieve the list of supported microcontrollers in the
avrdude column. It works OK with the old avrdude 5.11.1
The new 2.4.1 beta plugin (the archive I've sent) works ok with the latest
avrdude, not matter which gcc version (avr-gcc from 2.7.x to 2.8.x,
including the ones distributed by ATMEL).
The plugin works well on Windows and Linux.
On Sat, Nov 22, 2014 at 10:50 PM, Ivica Safranko ivisaf@users.sf.net
wrote:
--
Vasi
Related
Support Requests: #25
Hello Vasi,
You're probably talking about a different problem than Ivisaf is, because the string "Known MCU names" comes from GCC and BINUTILS.
The latest plugin (2.4.1) has indeed an issue with the German translated string in GCC 4.7 and higher. The same string in BINUTILS is not translated and also no leading white space on that line.
BTW. It looks like the translated string is from BINUTILS. That's puzzling, because GCC has that string translated since 4.7
Ivisaf, which version of AVR-GCC are you using?
Indeed, apologies! BTW, I'm romanian and I have no problems with the
english version of gcc...
On Sun, Nov 23, 2014 at 12:32 AM, Kees Bakker keesb@users.sf.net wrote:
--
Vasi
Related
Support Requests: #25
kees,
i use "gcc version 4.8.2 (GCC)".
Better solution is to search "avr1" string in stdout and then parsing whole MCU types.
MCU types are defined as constant in avr-devices.c:
That would be a long-term solution, regardless of GCC translation.
Yep, I was thinking something similar. Except that I would like to catch both lists from the GCC output. So, we may need some regex magic. Something like:
BTW. I'm the maintainer of avr-eclipse plugin, but I'm not much of a Java programmer. Plus I haven't done a release in more than a year, so I have to get myself familiar to all of this again.
In avrdude 6.x programmers list has too few informations.
To get all needed informations, execute avardude with the "-v -c?"(verbose mode).
In File: AVRDude.java
line no. 872:
Ah OK.
Strange. Why is only one of these lines translated? And, is this translated line a new thing in GCC? Of so, what must we do when they translate the other line as well?
BTW. How does this work on Windows? (The original bug report was for Windows.)
On windows they cann use two types of toolchain:
WinAVR(it works on my Laptop with Windows 7) or
Atmel AVR GNU Toolchain 3.4.5(uses gcc-4.8.1).
I supose that this new versions of Atmel Toolchains do not work.
There is an update of the plugin, 2.4.2. Please try it out.
Works fine for me on Win7/atmel avr8 toolchain and xubuntu/linux avr-* tools.
Also works last svn avrdude version.
I came up with this problem of missing MCU type on Linux distro and solved via terminal.
sudo apt-get install gcc-avr avr-libc binutils-avr avrdudeLast edit: Andy Irving 2016-02-14
English version below
Hallo,
Da das Problem nicht auf Englischen Systemen Auftritt schreibe ich in Deutsch und in Englisch :-)
Ivica Safranko hat recht das Problem ist das im Plugin nach dem Englischen String in der Hilfe Ausgabe gesucht wird.
Die Lösung ist, die Ausgabe von avr-gcc in Englisch Zu Verwenden, das lässt sich unter Linux ganz einfach durch die Entsprechenden Umgebungsvariablen Steuern.
Für Linux (die anderen Systeme kann ich derzeit nicht testen, und ich will ja nichts kaputt machen :-)) habe ich das ganze im Quellcode ergänzt (commit und Merge Request: b82f5a2b).
Bis zu Veröffentlichung dieser Version, hier einen Workaround:
Einen Ordner /usr/local/eclipse-toolchain erstellen.
Dort eine Datei Anlegen mit Folgenden Inhalt:
diese Datei Ausführbar machen (chmod +x)
und unter eclipse → Window → Preferences → AVR → Paths → als AVR-GCC Path /usr/local/eclipse-toolchain auswählen.
Zur Erklärung:
wir sagen eclipse es soll nicht den Original avr-gcc verwenden sonder ein von uns erstelltes Skript.
Unser Skript macht nichts anderes, als durch die entsprechende Umgebungsvariable auf Englisch umschalten und dann den Originalen avr-gcc Aufrufen.
Der Aufruf direkt in der Konsole, bzw. in Anderen Skripten bzw. Programmen bleibt davon unberührt.
Hello,
Since the problem does not appear on English systems I write in German and in English :-)
Ivica Safranko is right the problem is that the plugin looks for the English string in the help output.
The solution is to use the output of avr-gcc in English, which is easily controlled by the corresponding environment variables under Linux.
For Linux (I can not test the other systems at the moment, and I do not want to break anything :-)) I added the whole code in the source code (commit and merge request: b82f5a2b).
Until the release of this version, here's a workaround:
Create a folder / usr / local / eclipse-toolchain.
There create a file with the following content:
make this file executable (chmod + x)
and under eclipse → Window → Preferences → AVR → Paths → as AVR-GCC select Path /usr/local/eclipse-toolchain
For explanation:
we say eclipse it should not use the original avr-gcc but a script created by us.
Our script does nothing but switch to English through the appropriate environment variable and then call the originals avr-gcc.
The call directly in the console, or in other scripts or programs remains unaffected.
Hello! The same problem. In project properties not appear AVR menu. And select targed not accessed. In AVR Compiler options always setted atmega16 and I can't change this value, even create new project. If I select different MCU at start in options stay atmega16. How fix it?

Eclipse version 2019-09 R4.13.0.
System: Manjaro 5.2.21-1
Last edit: Tarletsky Andrey 2019-10-17