Can we add support for AVR microcontrollers

[ehoeks]

Can we add support for AVR microcontrollers

Atmel/Microchip provides toolchains for AVR MCU software development for boh Linux and Windows. Could we extend gnu-mcu-eclipse to be able to develop AVR projects with eclipse?

I'm not a java developer myself, but am willing to put in some effort, if someone could help me start this project.

[ilg-ul]

As with most software, it is possible to add support for AVR, but is if it is worth the effort?

Personally I do not think AVR microcontrollers represent the future.

Plus that there are some plug-ins for AVR, why not use them?

[ehoeks]

I think it is worth the effort, for me to be able to support vintage hardware using a modern IDE, and to allow beginners to migrate away from arduino (which are mostly avr mcu's) to a full-featured IDE.

Personally I don't care if the AVR represents the future, i still have to support multiple AVR based hardware products. And like to use the same IDE as for 'future' products.

The available avr-eclipse plugin 2.3.4 seems to be from 2011 (7 years old) so please do not tell me using that is a valid option.

---

I stand to be corrected, but I think adding AVR support should not be to difficult (although adding extra variability is always extra work) In essence the AVR tool-chain is just an other gcc based tool-chain, with potentially some different options to choose, all of which should be able to define in 'configuration' files.

I'm not asking anyone for adding this feature FOR me, but rather someone to help ME implement it.

[ilg-ul]

using a modern IDE

Eclipse itself is not exactly in peak condition.

allow beginners to migrate away from arduino

did you try the Eclipse Arduino plug-ins?

I think adding AVR support should not be to difficult

adding a build plug-in for AVR would not be very difficult, I already did a similar step when adding support for RISC-V.

however, full support would also include a multi-platform AVR toolchain, with the automated distribution mechanism similar to the one used for ARM and RISC-V toolchains.

I currently have no idea how difficult is to put together all the pieces required to build such a toolchain; to be clear, I have the scripts to build a multi-platform toolchain (see the ARM build script), I just don't know where to get the AVR pieces.

if you figure this out, and you are not happy with the Arduino plug-ins, we may consider the AVR build plug-ins.

[ehoeks]

I'll check out the arduino plugins, but my bias will work against me. I've found:

• sloeber.io (The Arduino Eclipse plugin named Sloeber)
• Eclipse C++ IDE for Arduino

About the tool-chain: atmel toolchain site contains pre-build tool-chains for linux (32/64) Windows and MacOsX Atmel-AVR-GNU-Toolchain src 3.6.1 is the latest released

I'll report back if the alternative plugins are sufficient for my use-case.

Thanks for the quick replies :)

[ilg-ul]

Atmel-AVR-GNU-Toolchain src 3.6.1 is the latest released

aha. based on GCC 5.x. not exactly new. I hope the files provided by Atmel are enough to rebuild the toolchain, since I saw references to other distributions, which might suggest the opposite.

[ehoeks]

AtmelStudio (the official IDE for AVR uses the 3.6.1 toolchain I linked to)

From an 'unofficial' source a potentially alternative newer compiler AVR-GCC 8.1.0 for Windows 32 and 64 bit

arduino IDE also seems to be using a very old gcc version.

The most important reason (for me) to have a newer version of the compiler is to be able to enable extra warnings.

[ilg-ul]

... a newer version of the compiler is to be able to enable extra warnings.

and use the new C++ features, assuming they are functional for AVR too.

[ehoeks]

After spending some time investigating the available plugins, my colleague and I aren't content with the available plugins.

Sloeber seems to be a 'wrapper'around the 2011 avr-eclipse for AVR and GNU-MCU-eclipse for arm based arduino's.

The arduino CDT plugin does not seem to allow the project portability and multiple toolchain support we need.

So we are still very eager to see AVR support integrated in GNU-MCU-eclipse.

[ilg-ul]

I see...

As I said, a build plug-in would probably not be very difficult to write, but I guess you'll also need to import projects from the old AVR plug-in, the tools to program flash, to run the simulator, the toolchain, and so on, and all those together might take some time.

I'll think on them, but for now I cannot commit any resources to this, and I doubt there will be someone willing to support the development, so it'll have low priority for a while.

[jantje]

Sloeber seams to be a 'wrapper'around the 2011 avr-eclipse for AVR and GNU-MCU-eclipse for arm based arduino's.

I do not understand what you mean by this. As I'm the Main Sloeber developer I'd like to understand. Can you elaborate on this statement?

[ehoeks]

@jantje I'm sorry if I misidentified sloeber as an extension to avr-eclipse and gnu-mcu-eclipse.

Are you of the opinion that eclipse+cdt+sloeber would be a good fit to continue the development of our existing AVR based products. Due to legacy we would need to be able to have multiple AVR tool-chains, and preferably select them on a project-build-target basis. Per project one main tool-chain could be used for auto-completion etc.

For debugging we currently use the atmel-ice, but I think that is pretty standard for AVR development.

[ilg-ul]

Are you of the opinion that eclipse+cdt+sloeber would be a good fit

This is a good question.

If the Arduino plug-ins can also be used for generic AVR projects, including flashing and debugging, a documentation page explaining how to do it would be very useful.

But when I say 'generic AVR projects' I mean it, i.e. no Arduino libraries or other specifics, plain C/C++ code.

[jantje]

Sloeber is build to "extend CDT" with the arduino framework. If you do not use the arduino framework (cores and arduino libraries) you are "dragging" these Sloeber core functionalities along. So from that point of view it does not make sense to use Sloeber. However to support Arduino IDE functionality Sloeber extends CDT in ways which are of interest to you. Such as: Sloeber supports easy installing of toolchains based on the "arduino framework" component called package. Sloeber supports multiple versions of the same package (as such supporting "versions of toolchains") Sloeber supports multiple configurations each with their own package (as such different toolchains per configuration)

Note that Sloeber -does not support "debugging". The Sloeber product includes some debugging components of gnu-mcu-eclipse of @ilg-ul for a nice user experience. As far as I'm aware you can run gnu-mcu-eclipse, avr-eclipse and Sloeber in the same eclipse instance without problems. -is completely agnostic to the toolchain. Sloeber gets the toolchain commands from the "platform.txt" and feeds them to CDT.

In short I think using Sloeber in your case might be like using a coin as a screw driver. The coin was never intended to be used that way but in some conditions it is a perfect fit. I think the main deciding factor for you will be "the of the shelf availability of toolchains in the current arduino framework ecosystem" and your willingness to learn part of the arduino framework (you will very likely need to modify platform.txt files).

PS Your usage of Sloeber is so specific that it is very unlikely you will succeed without me "guiding". So if you try it, give me a shout for some tips.

[ilg-ul]

-does not support "debugging".

then it is of little value for generic projects. :-(

[ehoeks]

The lack of debugging support makes it a non-candidate for me.

And I think working against the Arduino nature of Sloeber would create more problems than it solves. So I don't think we have to waste @jantje 's time any more. I'll have to either get my plain CDT to work with my AVR toolchains, or look for a way to extend the gnu-mcu-eclipse.

Luckily I seem to have found THE person to aid me in accomplishing that :)

@ilg-ul As a full-time embedded developer I know adding more configurations to a project has the risk of exponentially growing the complexity. So It's up to you to decide if the project is feasible.

[ilg-ul]

decide if the project is feasible

the project is definitely feasible, but... I currently cannot dedicate any resources to it. :-(

as a workaround, did you try to use the current ARM build plug-ins with a custom toolchain, and redefine the toolchain prefix to match the AVR one?

or continue to use the old AVR plug-ins, as long as they will run on newer Eclipses.

[jantje]

-does not support "debugging".

then it is of little value for generic projects. :-(

What I mean is that there is no specific code in Sloeber to support debugging. There is simply no need because mcu-plugin does a great job and it works with Sloeber build output.

So I don't think we have to waste @jantje 's time any more

thanks for thinking about my time.

[nexgenfs]

let us get down to basics. I love to write in C, and I hate the butchered code for AVR plug-in. It never seems to obey the C rules. and it scopes incorrectly.
In C I have a .h file for every function. and I also keep my structs and #defines up there and out the way. when I run the plugin it invariably tells me something is scoped wrong even when I use the preprocessor #include or 'file.h.' so I am forced to use the crappy Arduino IDE!! Even after transporting my code to the Arduino IDE things seem to go wrong.

[woodz-]

One question: why not to support renewing the old faithful avr eclipse plugin?

It had done its job very well until it has lack compatibility to newer eclipse versions. For what I understand the latest eclipse version supported is Photon.

The most challenging thing to do for further support would probably be to include debugging abilities. Would this plugin be a hit for you?

[ilg-ul]

You are right, it is a pity that the old plug-in is no longer functional, but it is a matter of resources, for me AVR is a thing of the past, and I simply cannot afford to allocate any resources for it, since there are many other things more important that need to be done.

[jantje]

The most challenging thing to do for further support would probably be to include debugging abilities.

I don't understand this remark. Soeber builds for avr and debugging is done with eclipse-embed-cdt. So this functionality exists in eclipse-embed-cdt. Also I can't remember avr eclipse plugin to have debugging capabilities.

The only functionality avr eclipse plugin had that I miss is "tell me which avr is connected o this com port. I know there were also maps which someone may miss but I don't ;-)

Don't get me wrong. IMHO avr eclipse plugin was a great tool dedicated to the avr community. However the avr community is small and functionality has moved to embedded tools. All open source communities struggle with way more people requesting things than supporting. As a consequence smaller communities can not keep up.

[woodz-]

@ilg-ul + @jantje, thanks for taking time to answer. Yes, avr eclipse plungin had lack debug ability for the first time it came up. And that's what I mean by challenge, if anybody decides to append it to the plugin plus renewing it.

@jantje, if I get you correct, you say everything what was possible by avr eclipse plugin shall still be possible by sloeber? I am relatively new to the sloeber ide or arduino, etc. What I understood till now is, sloeber does not separate microcontroller types. It just separates boards. Knowing the board, you know the controller. But not vice versa. You might be right, pointing to a huge community is the way to support tools. But for me as an electrician it's just awful to fix to a specific board all the time instead of selecting the suitable controller for a project and doing stuff around by my own. With avr eclipse plugin that all was possible.

You are always welcome to disabuse me. If you can tell my how to stick to the attiny861 and do development for this specific controller in sloeber and just use the avrmkII to download the hex and eep via isp, I would be glad to hear about.

[jantje]

if I get you correct, you say everything what was possible by avr eclipse plugin shall still be possible by sloeber?

no absolutely not. Sloeber is aiming at arduino. Arduino originally was AVR. Arduino allows debugging and the debugging functionality is from gnu mcu from @ilg-ul