C::B for embedded development?

[mandrav]

Slowly but steadily, Code::Blocks' infiltration in the embedded development field is growing. This forum aims to bring all the embedded developers together to share their knowledge regarding the use of Code::Blocks as an embedded development tool.

So, do you use Code::Blocks for embedded development? Have any tips for other members? Faced any problems?
You can use this forum if you answered "yes" to any of the above questions .

[pass86]

UP

[pass86]

I say yes to you.

[pauliusz]

I started using CB as IDE for WinAVR toolchain. For this purpose I made WinAVR compiler support you can see in CB. Currently I am not working with AVR processors. It would be nice if someone could merge my last patch "[ Patch #2071 ] GNUAVR: mcu list update".

I have also made support for Tasking C166 compiler and I am using it a lot. Actually after I did it now our whole company (~30 in R&D) are using CB with my patches. Since C166 architecture microprocessors are not very popular I haven't made my patches available, but if someone needs it I can do this.

In near future we will start using ARM processors in our company... so you can expect some patches in this area also.

[rickg22]

Yiannis, I think pauliusz should become an official dev, with access to the compiler plugin (just to maintain the ARM compilers). What do you think?

[pauliusz]

Yiannis, I think pauliusz should become an official dev, with access to the compiler plugin (just to maintain the ARM compilers). What do you think?

I would be glad to maintain ARM compilers... actually I already have some patches for ARM, but they need some tuning before going to public I could maintain AVR compiler also (since I started it...).

P.S. I really respect your trust in me Rick. Thanks.

[rickg22]

Actually a better idea would be to implement compiler support using dll's, one for each compiler. But that'd be after 1.0...

[chikigai]

I currently use ARM (RealView Developer Suite v2.1 ) for development.
I mentioned in a previous post (several months back) the main difficulties I face using the ARM package:

1) Different compilers for ASM, C, CPP source files
2) Different linkers for libraries and binaries
3) Different options/switches for the above

The Compiler plugin requires serious tweaking to integrate the environment.

There were talks of redesigning the Compiler plugin based on XML configuration files a while back.
If I remember correctly, Mandrav replied that this was still considered as future development.
Separate DLLs for each Compiler, as Rick mentioned, is also an idea, but I can't really say which would work best.


Dan

[mariocup]

Hi pauliusz,

we are working also with ARM compiler, PowerPC, MSP430 and made an own gcc port for C16x (deprecated) and TriCore. For these compilers we add support in the compiler.dll (not commited yet) and some wizards: See the attached file (can not attach all files because of file size limitation).

Which debugger are you using (integrated debugger or external)?

We made also a plugin to support the start of external tools (e.g. Jtag-Server, Simulator, Insight Debugger). This plugin checks the compiler ID and will modify the menu dynamically.

We would be glad to help you to enhance the support for embedded compilers and are interested in the changes, so the work will not be done twice . We are still in the beginning of codeblocks development, but we want to help to bring the great IDE also to embedded users.

[attachment deleted by admin]

[killerbot]

Actually a better idea would be to implement compiler support using dll's, one for each compiler. But that'd be after 1.0...

or .... xml file and maybe with some scripting ;-)

[Joerg]

For these compilers we add support in the compiler.dll (not commited yet) and some wizards: See the attached file (can not attach all files because of file size limitation).
We made also a plugin to support the start of external tools (e.g. Jtag-Server, Simulator, Insight Debugger). This plugin checks the compiler ID and will modify the menu dynamically.

Hi mariocup,

I also use C::B for embedded development.
The problem for me lies in debugging.
I need support for gdb remote debugging (gdb JTAG server openocd).
That's why I switched back to Eclipse temporarily, because they have built in
'hardware debugging' in the Europa distribution.
If I understand you and others correctly there is already much effort made
to integrate support for this in CodeBlocks.
So I would like to encourage the core team to make these features
available as soon as possible.
Maybe even in the nightly builds. 

Greets,
Joerg

[mariocup]

Hi rekisum,

as far as I know mandrav started support for remote debugging (WinAVR), but I do not know the current status. I agree that there are a lot of embedded users and they need more debugging features in CB .  So we should discuss also new ideas and features for the debugger to see the needs of all users.

[martind]

Hi,

Have been using codeblocks to work with ARM processors. Using these toolchains:

WinARM, GNUARM, ours: sarm (www.st-angliamicro.com/software.asp), and now started to use code-sourcery for cortex M3 support.

Project management and compiling works fantastic, however I am using the Insight debugger as there some issues with arm-elf-gdb under codeblocks.
These are mainly to do with some differences with mingw gdb, and arm-elf-gdb.
For instance, arm-elf-gdb seems to output breakpoint information slightly differently, so I have added some simple regex expressions in the source, and added support code in debugger_gdb.cpp
Also, there are some other options which are not recognised that need minor tweaks.

I am currently hacking at the debugger plugin source to get arm-elf-gdb working.

A couple of questions though...

Before I go much further, codeblocks has a parseoutput() function in gdb_driver.cpp that regex's the console output of GDB, to set the cursor position.

Is it worth adding support for GDB/MI format? Any technical or emotional issues here?

I have code blocks setting the cursor at the correct place upon a breakpoint stop, however I still have some way to go.

What I was planning to add:

1) Finish support for arm-elf-gdb.
2) Add some sort of ProcessorFactory class to store localized information for specific CPU/architecture target. Or would this information be better stored in compiler options, would probably make sense?
3) Add support for OpenOCD JTAG engine on the debugger panel. (Remote debugging).
4) Startup wizard to select processor and target settings, default build options, relevant linker and OpenOCD scripts.
5) Flash programming plugin.


Appreciate and feedback or comments, as I am fairly new to the source code and architecture (few weeks in).

Cheers,


Martin.

[mariocup]

Hi martind,

nice to see that embedded development for codeblocks is going on. We are working also with embedded target an insight-debugger. What we did until now is:

1) We made a plugin that checks the compiler-id and modifies the debugger plugin dynamically. So if you have active project for ARM then the menu will display entries like:
Start ARM-Insight, JTAG Server etc. So you can add to each compiler-id a specific tool menu. Before sending the code to CB we want to do some clean-up, but if you like I can attach the source code.

2) Wizards for ARM, PowerPC, TriCore, MSP430

I agree that the remote debugging is one of the most important feature for embedded and should be added as soon as possible. It should also be possible to add a gdb-ini file to the project settings.

Since gdb 6.1 you can use both modes GDB/MI simutaneously (section: gdb/mi Data Manipulation). The advantage of MI-interface is that  you can use it to make a mixed mode of source and assembler code in a assembly view.
Synopsis
-data-disassemble
[ -s start-addr -e end-addr ]
| [ -f filename -l linenum [ -n lines ] ]
-- mode
The next step would be to add support for breakpoints in the assembly view.

5) Are you going to make a GUI in a flash programming plugin.

Bye,

Mario

[mandrav]

This is kinda funny: we created an entire forum dedicated to embedded development and you 're all posting under the sticky announcement topic :lol:.

I 'm locking this now, just start a new topic for whatever you want .

[mariocup]

Hi mandrav,

you are so right.

We will start new topics to discuss these things.