GNU MCU Eclipse - new RISC-V support

[Liviu Ionescu]

For those interested in using Eclipse for RISC-V devices: the good old GNU ARM Eclipse project was recently upgraded with support for RISC-V devices and is currently rebranding as GNU MCU Eclipse (https://github.com/gnu-mcu-eclipse).

## Downloads

Pre-release binaries are available from:

https://github.com/gnu-mcu-eclipse/org.eclipse.epp.packages/releases/tag/v4.6.3-gme-20170606-0936

Alternatively, the evaluation version of the plug-ins can be installed inside an existing Eclipse from:

from http://gnu-mcu-eclipse.sourceforge.io/v4-neon-updates-test

If the old GNU ARM Eclipse plug-ins are already installed, they must first be manually removed, since the GNU MCU Eclipse project provides newer versions (but with different IDs).

## Multiple toolchains

As for the previous GNU ARM Eclipse plug-ins, the build plug-ins are able to manage multiple toolchains and multiple versions of a single toolchain; for this to work, simply install each version in a separate folder and be sure none of these locations are in the system path.

## Windows Build Tools

For Windows users, a set of tools provide a version of GNU make (http://gnuarmeclipse.github.io/windows-build-tools/).

## Debugging

For debugging, the GNU MCU plug-ins provide support for SEGGER J-Link, OpenOCD and QEMU. A new version of GNU MCU Eclipse OpenOCD with RISC-V support is under tests and will be shortly released.

## Templates

This pre-release includes a template to generate the classical "Hello World" program.

Blinky templates are planned and will be available in the near future.

## Documentation

The documentation will be soon updated with RISC-V details; for the moment please use the GNU ARM Eclipse site (http://gnuarmeclipse.github.io).

## Feedback

Any feedback will be highly appreciated.


Best Regards,

Liviu Ionescu
GNU MCU Eclipse maintainer

p.s. Many thanks to SiFive Inc, who made this possible.

[Tommy Murphy]

Looks interesting Liviu.

Should feedback/issues be posted here or elsewhere?

Thanks

Tommy 

[Liviu Ionescu]

> On 6 Jun 2017, at 20:23, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> Looks interesting Liviu.
> Should feedback/issues be posted here or elsewhere?

I'm new to this group and I do not want to set any new rules, but if the feedback is related to the RISC-V plug-in, I think it would be more useful for the discussions to be in a place where most of the RISC-V users are.

Otherwise general rules apply, for bugs and feature requests the preferred contribution is via Pull Requests after discussing on the project Issues tracker (https://github.com/gnu-mcu-eclipse/eclipse-plugins/issues).

For general, non RISC-V specific issues, the preferred way is via the project forum (http://gnuarmeclipse.github.io/support/forum/).

Regards,

Liviu

[Tommy Murphy]

OK - tell me if I should be posting any of these elsewhere please:

1. Select a project in the Project Explorer then select the menu option Run > Debug Configurations, select GDB OpenOCD Debugging and try to create a new debug launch configuration. Every time I try this I get a message box "Problem Occurred ... And error has occurred. See error log for more details. named capturing group is missing trailing '}'". I've attached the partial log. If you need any more details let me know. In case it matters I'm on Windows 7 here.
   
   
2. Newlib nano option doesn't work in a RISC-V project - maybe it's there as a placeholder for when nano newlib IS built by the RISC-V GNU Toolchain?
   
   
3. Is there any way to override/set RISC-V project defaults (e.g. RISC-V target details such as architecture, ABI, extensions etc.) from a "plugin_customization.ini" file referenced by eclipse.ini or through some other mechanism. Or are the RISC-V project defaults hard coded into the plugin?

I'll pass on any additional feedback if/when I have it.

Thanks a lot

Regards

Tommy

[Tommy Murphy]

If there's no project selected in Project Explorer then I don't get that error when creating a new debug launch configuration but obviously then the project specific details (folder, executable etc.) are not filled out.

[Liviu Ionescu]

> On 7 Jun 2017, at 19:42, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> OK - tell me if I should be posting any of these elsewhere please:
> • Select a project in the Project Explorer then select the menu option Run > Debug Configurations, select GDB OpenOCD Debugging and try to create a new debug launch configuration. Every time I try this I get a message box "Problem Occurred ... And error has occurred. See error log for more details. named capturing group is missing trailing '}'". I've attached the partial log. If you need any more details let me know. In case it matters I'm on Windows 7 here.

this is a bug, I'll fix it shortly.

> • Newlib nano option doesn't work in a RISC-V project - maybe it's there as a placeholder for when nano newlib IS built by the RISC-V GNU Toolchain?

that's correct, currently it is not available but I think that having a nano version would be a nice addition for the small RISC-V devices too, so it can be considered a placeholder. would it be a better idea to temporarily disable it?

> • Is there any way to override/set RISC-V project defaults (e.g. RISC-V target details such as architecture, ABI, extensions etc.) from a "plugin_customization.ini" file referenced by eclipse.ini or through some other mechanism. Or are the RISC-V project defaults hard coded into the plugin?

currently the defaults are hardcoded in the plugin.xml file associated with the managed build plug-in. if really needed, to each GUI element we can associate a java class handler, that manages the behaviour dynamically. it can be done, but it is not a trivial change.

> If there's no project selected in Project Explorer then I don't get that error when creating a new debug launch configuration but obviously then the project specific details (folder, executable etc.) are not filled out.

I think this is a normal CDT behaviour, at least in theory it is perfectly legal to create project less debug configurations.

> I'll pass on any additional feedback if/when I have it.

sure, thank you.

regards,

Liviu

[Tommy Murphy]

Thanks for the quick reply Liviu.

For completeness I logged an issue/bug about the debug launch configuration problem: https://github.com/gnu-mcu-eclipse/eclipse-plugins/issues/207

Fair enough about including the newlib nano (and maybe other?) option(s) as placeholders. I agree that newlib nano would make a lot of sense especially for the smaller (32 bit?) RISC-V targets.

It would be nice to be able to tune the RISC-V project properties externally as different users/vendors may have different default targets but I appreciate that it's not a trivial change and maybe not a/the priority right now.

I understand that creating a "blank" debug launch configuration is valid and one can fill in the blanks manually - I didn't mean to imply that this was a bug but just mentioned it in case it was relevant to pinning down the problem when a project IS selected.

If/when I have any further feedback I'll post it.

Regards

Tommy

[Liviu Ionescu]

> On 8 Jun 2017, at 01:31, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> For completeness I logged an issue/bug about the debug launch configuration problem: https://github.com/gnu-mcu-eclipse/eclipse-plugins/issues/207

thank you, I already fixed the problem.

> Fair enough about including the newlib nano (and maybe other?) option(s) as placeholders. I agree that newlib nano would make a lot of sense especially for the smaller (32 bit?) RISC-V targets.

I plan to dedicate some time to the scripts to be used to generate the toolchain binaries, and, if possible, I'll also consider enabling newlib nano.

> It would be nice to be able to tune the RISC-V project properties externally as different users/vendors may have different default targets but I appreciate that it's not a trivial change and maybe not a/the priority right now.

yes, different users/vendors may have different default targets, but setting the architecture/abi is only part of the game; to get a functional project you need not only lots of other options, but macros, startup files, linker scripts, etc, and here come project templates into the play.

if you take a look at the ARM part of GNU MCU Eclipse, you'll find templates for most STM32 families, which all generate fully functional blinky projects, a good starting point for a project.

something similar is planned for RISC-V devices too; even more, I'm working on a package based mechanism to build projects from components.

> I understand that creating a "blank" debug launch configuration is valid and one can fill in the blanks manually - I didn't mean to imply that this was a bug but just mentioned it in case it was relevant to pinning down the problem when a project IS selected.

ok, no problem.

> If/when I have any further feedback I'll post it.

sure, all feedback will be appreciated.


regards,

Liviu

[Tommy Murphy]

One other thing that I noticed - I'm still getting this problem even with the latest Eclipse/CDT (Neon.3 + CDT 9.2.1) and the new GNU MCU Eclipse plugins:

https://github.com/gnu-mcu-eclipse/eclipse-plugins/issues/197

For example right now I'm getting this:

Description Resource Path Location Type
Invalid project path: Duplicate path entries found (/riscv-systick-blinky [Include path] base-path:riscv-systick-blinky isSystemInclude:true), path: [/riscv-systick-blinky]. riscv-systick-blinky pathentry Path Entry Problem

The problem is sporadic/unpredictable (i.e. not the same results every time) but happens very often.

It happens in both ARM and RISC-V projects.

Any ideas?

[Liviu Ionescu]

no, it never happened to me.

so, unless you identify a way to reproduce the problem, I doubt I can do anything to fix it.

regards,

Liviu

[Tommy Murphy]

I can reproduce it easily on Windows.

I haven't tried on Linux yet.

If it helps at all I can easily provide you with a Windows installer that installs all of the relevant tools and shows the problem.

Alternatively if I can collect any logs that might help let me know.

Let me know if that is of any use.

[Liviu Ionescu]

> On 8 Jun 2017, at 02:17, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> I can reproduce it easily on Windows.
> I haven't tried on Linux yet.
> If it helps at all I can easily provide you with a Windows installer that installs all of the relevant tools and shows the problem.
> Alternatively if I can collect any logs that might help let me know.
> Let me know if that is of any use.

since this is not a RISC-V specific issue, I suggest you provide the details you have in the issue tracker, not in this forum.

regards,

Liviu