ChibiOS Free Embedded RTOS

It's just a shame that Em::Blocks does still lack the ability to handle external Makefile targets. It's such an amazing IDE!


~ Tectu

I wish Em:Blocks could support Makefile projects like Eclipse does. Maintaining lots of projects on custom builders is hell for a project like this (or like uGFX I imagine).

Giovanni

Chudik

- boards directory includes the board description files (.c & .h)

Undestand. And what about board.chcfg file? What is it? I think it's for eclipse board file generator plug in, right?

- os->hal->platforms includes all required drivers. Note, that if in Linker settings you check "Remove unused sectors" item, they actually won't be used in the project and will not increase code size either.

Understand. It was not clear for me. Thanks!

If you need I can attach here my project, where you will need to make changes, related to your board (including LED and serial port) and your processor.

It would be good

Another questions :
How I can turn off/ turn on hardware FPU support in EnBlock? I configured it with make file too earlier.

Giovanni wrote:I wish Em:Blocks could support Makefile projects like Eclipse does. Maintaining lots of projects on custom builders is hell for a project like this (or like uGFX I imagine).

What I have started doing on firmware projects at work recently, is to use CMake for the build system. I started doing this about a year ago, and the rest of the team has found it to work fantastically and others are converting their firmware projects to use CMake as well.

There are several benefits to using CMake in this case, when compared to other options including Makefiles, IDE projects, etc.:

1. CMake supports using GNU make, Ninja, NMake, Eclipse, Visual Studio, Code::Blocks, CodeLite and others as the build system backend. It generates the requested output project files dynamically and you can then open the IDE project or run the make system.

2. CMake handles complex build dependencies intelligently, and ultimately the build scripts are cleaner and simpler to write than makefiles.

3. CMake makes developer projects across different host platforms easy. Whether developing using Windows or Linux, you don't have to worry about the file/directory separator, whether there is an 'rm' or 'del' command in the OS to delete files, etc. since CMake has built-in support for this stuff in a simple and platform-independent way. You don't even need GNU make -- you can use the simple and clean and fast Ninja build system instead.

The main difficulty was creating a custom toolchain description, which probably was more difficult because the compiler is an oddball proprietary compiler that CMake doesn't know about. And it wasn't all that hard either -- just creating a few CMake scripts that find the compiler location and set up the right arguments for compiling and linking.

This sounds very interesting, I will give it a look, could solve a real problem.

Giovanni

colin wrote:2. ... and ultimately the build scripts are cleaner and simpler to write than makefiles.

What? You mean that this is not clean? https://bitbucket.org/Tectu/ugfx/src/60 ... ?at=master

Giovanni wrote:This sounds very interesting, I will give it a look, could solve a real problem.

I think the same. Probably we could help each other converting ChibiOS/RT and uGFX to cmake?


~ Tectu

Sure but I need to assess the effort first, a change of build system would impact all platforms, something like 200 distinct demo/test applications and a lot of end users. I would need a damn good reason and just supporting some IDEs probably is not a sufficient one.

I could evaluate its use in addition to regular makefiles but it is not exactly high priority, it will not happen in 3.0 anyway.

Giovanni

Same here, although for other reasons, I guess. uGFX has become huge as well but unlike you I can still "afford" to change major stuff.
My main reason (beside the obvious time issue) is that uGFX has a ToDo list that goes from here to the moon and back. There's just more important stuff to implement and fix first.


~ Tectu

Dvor_nik

And what about board.chcfg file? What is it?

Some kind of XML file. I don't care for now.

I have attached my project file that I was talking about early.

[img]How%20I%20can%20turn%20off/%20turn%20on%20hardware%20FPU%20support%20in%20EnBlock?%20I%20configured%20it%20with%20make%20file%20too%20earlier[/img]
I believe so. In the original project for F429 it was there. I just deleted this line.
Here is my project build option


===============
colin
Your CMake seems very promising. I hope I will be able to test it for you. At least for EM::Blocks and for the chips we're going to use in our projects.

==============
Giovanni

I would need a damn good reason and just supporting some IDEs probably is not a sufficient one.

EM::Blocks written in C/C++ with native Windows support, that means faster and more comfortable user interface. From my perspective it is more convenient than Eclipse.
For ARM it can use some kind of bare-metal GCC. Don't know what that means, but sounds cool Just speculation - I would think it might use some special features related to ARM.

Would it be a good enough reason for you?

Chudik wrote:Giovanni

I would need a damn good reason and just supporting some IDEs probably is not a sufficient one.

EM::Blocks written in C/C++ with native Windows support, that means faster and more comfortable user interface. From my perspective it is more convenient than Eclipse.
For ARM it can use some kind of bare-metal GCC. Don't know what that means, but sounds cool Just speculation - I would think it might use some special features related to ARM.

Would it be a good enough reason for you?

No doubt is very nice, I just wish it supported also a makefile-mode like Eclipse does, that would make adoption easier. You cannot just assume that new users just switch to a different way to work immediately.

Giovanni