cancel
Showing results for 
Search instead for 
Did you mean: 

Free Development Tools: GNU ARM Eclipse

Liviu Ionescu
Associate III
Posted on August 02, 2016 at 18:05

Please add GNU ARM Eclipse, with a reference to http://gnuarmeclipse.github.io, to the list of free, open source, development environments with strong support for STM32 devices.

Regards,

Liviu

#free-development-ide-gnu-arm
19 REPLIES 19
AvaTar
Lead
Posted on October 11, 2016 at 08:26

As said - I'm not surprised it doesn't work.

This is the most pathetic attempt of a ''forum webpage'' I ever came across.

> any other suggestions?

 

Aside from bumping this thread up, perhaps trying to contact ST engineers directly ?

I guess they are too busy to fix their Cube mess. Adding support for another toolchain (however good), seem lined up far behind fixing GUI bugs, fixing code generation bugs, and fixing support for newer MCUs.

Just my personal impression ...

Amel NASRI
ST Employee
Posted on October 11, 2016 at 10:51

Hi Liviu Ionescu,

Following your request, I updated [DEAD LINK /public/STe2ecommunities/mcu/Lists/STM32Java/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/STM32Java/Free%20Development%20Tools%20for%20STM32%20Microcontrollers&FolderCTID=0x01200200770978C69A1141439FE559EB459D758000F9A0E3A95BA69146A17C2E80209ADC21&TopicsView=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Java/AllItems.aspx&currentviews=4330]the sticky discussion to add GNU ARM Eclipse.

I reformulated your message to say ''supports STM32 devices'' instead of ''supports all STM32 devices'' as I don't see STM32Lx devices in the screenshots provided in http://gnuarmeclipse.github.io/.

Do you confirm that STM32Lx devices aren't yet supported?

-Mayla-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Amel NASRI
ST Employee
Posted on October 11, 2016 at 10:55

Hi Avatar,

When speaking about ''Cube mess'', are there any particular issues you are facing with this solution?

-Mayla-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

AvaTar
Lead
Posted on October 11, 2016 at 12:24

> When speaking about ''Cube mess'' ...

 

I spoke about my personal impressions, both with the package, and with other people's problems manifesting here.

I have the following points:

1. The ''Wizard'' approach. Letting inexperienced (ignorant ?) people create an application with a few mouse click seems o.k. at first glance.

But not only fails this approach (often miserably) when the desired goal deviates from the use cases imagined by the designer. (Do you remember the MS-Word/Excel 'Clip Wizards' ? Where did they go ?)

It also fosters an ignorance of the underlying subject. Patching an app together via a few click does not make one understand anything. It might even keep one from understanding it.

As another famous poster expressed it ''Monkey press button software''. I guess it not only incidentally correlates with the flood of semi-literate engineers on MCU fora.

2. The ''All embracing'' approach. Having used the SPL for many projects, I for sure tried Cube.

But where the SPL consists of quite autonomous modules, Cube is helplessly intermingled, and enforces all it's concepts on applications using it. Trying to remove Cube's use of timer, callbacks or just it's include file dependencies is a PITA. I resort to direct-register-access, or to MCUs for which a SPL is available.

3. Seems you cannot keep up. The cube developers are obviously overwhelmed by the amount of work to do for new MCUs.

And with more complex variants (like the M7 and high level M4), the possible inter-peripherals dependencies and use-cases grow exponentially.

Where are the LL (low-level) cube headers for most MCUs ?

I currently use STM32 products only for my private projects, so you can safely ignore my (very personal) opinions.

But I'm not sure if the Cube approach is heading toward the right direction.

Apart from that, I think Liviu did a great job, and I'm glad you finally managed to add it to the list ...

Amel NASRI
ST Employee
Posted on October 11, 2016 at 14:34

Hi again,

It is interesting for us to hear all opinions (not to ignore them), mainly if they are fact-based ones .

Various approaches are available in the STM32 ecosystem to be suitable for the variety of users working methods.

The aim is to make the MCU development easier. It takes time for sure to satisfy users. But work is ongoing to make expected solutions available (Cube, SPL maintenance, LL...).

LL drivers are currently available for F0, F3, L0, L1, L4.

Welcome again in the STM32 Community, and for any valuable feedback you share.

-Mayla-

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

AvaTar
Lead
Posted on October 11, 2016 at 15:03

> It is interesting for us to hear all opinions (not to ignore them), mainly if they are fact-based ones .

 

As said, my point of view is more based on personal observations, and my needs.

A company, pursuing business with STM32-based MCUs, has different requirements.

There are two points I might to add in regard to Cube here, based on experience in the mass product business:

That niche hardly accepts any library, as it increases code size. Where every fraction of a cent counts, the game follows different rules. I've seen projects swapping vendors, architectures and toolchains for a few cent.

From observation, it seems as Cube does not yet fully separate (auto-generated) library code and user code. That usually wreaks havoc on version control systems. Or is this fixed at the meantime ?

 

> LL drivers are currently available for F0, F3, L0, L1, L4.

There wasn't so much the last time I checked - admittedly about 4 month ago.

And I especially looked for LL drivers for my M7 Nucleo board ...

> But work is ongoing to make expected solutions available (Cube, SPL maintenance, LL...).

 

I know it is a tremendous work, and I don't envy you for that.

But being for about two decades in this business, I know what this statement means.

Liviu Ionescu
Associate III
Posted on October 11, 2016 at 15:09

> Following your request, I updated the sticky discussion to add GNU ARM Eclipse.

Thank you, Mayla, I appreciate it.

> Do you confirm that STM32Lx devices aren't yet supported?

STM32Lx devices are supported via the generic template, and via a solution that integrates CubeMX into the GNU ARM Eclipse project, but otherwise, strictly speaking, you are right, there are no direct templates for the Lx devices.

marcello2
Associate
Posted on October 11, 2016 at 16:26

Happy to see that Liviu's work has received the visibility he deserves

Liviu Ionescu
Associate III
Posted on October 11, 2016 at 23:47

> Happy to see that Liviu's work has received the visibility he deserves

Thank you, Marcello.

I hope this is just the first step, and some day CubeMX will also generate GNU ARM Eclipse projects.

It is curios that although GNU ARM Eclipse supported from the very beginning ST devices, ST never considered the opportunity to use this open source project.

Freescale did this, and KDS is based on the GNU ARM Eclipse build and debugging plug-ins, Infineon did this and DAVE uses the GNU ARM Eclipse debugging plug-ins, Somnium, and many more used the GNU ARM Eclipse in various ways.

It is a pity that ST did not sense the opportunity...

According to SourceForge, the project accounted more than 4.200.000 files downloaded; perhaps this might help raise some attention to responsible ST guys.

0690X00000604vtQAA.png

Liviu Ionescu
Associate III
Posted on January 15, 2017 at 09:09

http://gnuarmeclipse.github.io/blog/2017/01/14/plugins-v3.2.1-201701141320-released/

Version 3.2.1-201701141320 is a new major release; the main change is adding support for Eclipse Neon.2 (CDT 9.2).