code::blocks::embedded

[oBFusCATed]

Does code::blocks use the GDB mi interface in the debugger branch?  This would probably be better than the current stdin/stdout redirection method since it let's you interact with GDB while the debugee is running and you can stop individual threads.

No, it uses the normal interface. I've a plugin that uses the MI interface but it is not very usable at the moment.
Also the MI interface is using the same stdin/out redirection.

[etg]

I will provide the C::B::E + DEBUGGER PLUGIN for ARM NXP CORTEX M3 family development for download at right time when will be sure it is stable for user. The C::B::E (SRC+BIN) will of course free for everyone and about DEBUGGER PLUGIN not decided at this moment. The demonstration package will run DEBUG TARGET - ARM V7 SIMULATOR (not included in neither official GDB distribution). Other target requires real ARM V7 hardware debugger available via ETG site.
Significant difference of DEBUGGER PLUGIN is that allows download multiple executables (ELF) into target.
If we decide to not provide DEBUGGER PLUGIN for FREE certainly we will provide useful source parts of DEBUGGER PLUGIN which can be turn into C::B DEBUGGER PLUGIN style. Interfacing piece of e.g. MEMORY window seems easy for me.

[MortenMacFly]

I just want to ask how far is the time when your C::B turns into commercial edit ?

Basically it can't, as we setup the license not to allow this.

1. sounds line SOCIALISM past 20 years in eastern EUROPE where nobody owned nothing
[...]
3. what are then the DONATIONS on your C::B page ?

1.) ??? I don't get what you mean by that.
3.) They are for e.g. server costs etc.. Not everything is for free, you know. We have quite some traffic and webspace / content which needs to be paid as we are running a dedicated server for this. And I can assure you that the donations are not even enough for that.

I will provide the C::B::E + DEBUGGER PLUGIN for ARM NXP CORTEX M3 family development for download at right time when will be sure it is stable for user.

That sounds reasonable. Without looking at it it'll be hard to say how easy it can be integrated.

[martind]

Going to gdb/mi would be better for embedded targets. In my cbmcu plugin I have to issue a "halt" command via openOCD to halt execution. I have not found a way to do this via the current exec method.

[oBFusCATed]

There is a gdb/mi plugin in the works...

[pfong]

Going to gdb/mi would be better for embedded targets. In my cbmcu plugin I have to issue a "halt" command via openOCD to halt execution. I have not found a way to do this via the current exec method.

oBFusCATed has fixed things in the debugger branch so that you can halt remote targets on Windows.  He has it send a console break event to the gdb console process.