User forums > Embedded development

C::B for embedded development?

<< < (3/4) > >>


--- Quote from: mariocup on July 18, 2007, 08:00:59 am --- 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.

--- End quote ---

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.  :)


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.


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

WinARM, GNUARM, ours: sarm (, 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).



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.
[ -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.



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 :).


[0] Message Index

[#] Next page

[*] Previous page

Go to full version