Hm, tell us what you want to have in the toolbar and we(I) will see if they could be added/implemented.
What kind of debugger?
Is your plugin going to be open sourced?
Can you show me the changes you've made?
It will be distributed freely to the developers using the microcontroller.Keep in mind that most of the sources of C::B are licensed under the GPL v3 license, some are LGPL v3. Look at the top of the files you modify for the correct license.
In order to make it work, I had to make changes to the code of CB, so it will not be available as plugin, but only as packet together with the "special" version of CB.
Hm, sounds like a big hack. And why have you copied the debuggergdb directory?
- copy debuggergdb folder and paste it as debuggerA
- renamed everything until I had a properly compiling project with two debuggers (which did exactly the same)
- adapted debuggerA (executable name, prompt, options, ParseOutput,...)
- since the debugging windows are very different and I need to call functions of their classes from ParseOutput, I created other classes for them (e.g. A_cbCPURegistersDlg instead of cbCPURegistersDlg)
- added in the .xrc files objects like "debugger_A_menu" (the same for the toolbar)
- added to DebuggerMenuHandler::SetActiveDebugger the following line: Manager::Get()->GetDebuggerManager()->GetMenu();
- edited GetMenu so that the menu gets deleted each time and then rebuilt using either "debugger_A_menu" or "debugger_menu" according to the active debugger
- added in debuggermenu.cpp the IDs, the event table entries and the event handlers for the A-menu
This works like a gem. The problem I am facing is how to adapt the toolbar, too.
Thank you for your help
e.p
Keep in mind that most of the sources of C::B are licensed under the GPL v3 license, some are LGPL v3. Look at the top of the files you modify for the correct license.
(some files in the SDK have wrong licenses btw). So if you modify a GPL file you can't redistribute binaries without redistributing the changes to that code.
LGPL is relatively similar.
Hm, sounds like a big hack. And why have you copied the debuggergdb directory?
Why haven't you started a new plugin, there is a wizard which does almost perfect job?
And I'm asking again, what do you want to have in the toolbar, how could it be so different to the normal debugger?
We have no "Run to cursor" and no "Information windows".I've plans to make most of the features optional, so in the future a plugin could make the "Run to cursor" menu item disabled or any other such item could be disabled, too.
No "Call stack" and no "Threads"."Call stack" and "Threads" windows could be made optional, too, so if plugin doesn't support them, they could be disabled.
In return we have a "Pin Emulation" and a "Debugger Link" window. And a "reset" button.You can add your windows in the debugger plugin, there is no point to modify the core of C::B. The core/sdk should have only the common GUI/features.
Sry for hijacking the topic but a 'reset' button on the debugger toolbar should be implemented somehow for microcontroller work.What is the purpose of this button?
Hm, tell us what you want to have in the toolbar and we(I) will see if they could be added/implemented.
I don't think it would make sense. The functions are very specific and would be of no use for normal debuggers (it is a hardware debugger).
It would be great to make C::B yet more customizable.Patches welcomed :)
Sry for hijacking the topic but a 'reset' button on the debugger toolbar should be implemented somehow for microcontroller work.What is the purpose of this button?
while (true)
if (state == 00)
wait t
state = 01
if (state == 01)
wait t
state = 10
if (state == 10)
wait t
state = 00
end while
I am solving my problem creating two toolbars and switching between them. Not really elegant, but it seems to work.Why are you switching? Show them both...
While we are at it... I had to modify all dialogs (Registers, Watches, ...). I think it would be useful to make the debugging windows customisable too.What changes? Esspicially for the watches? What customisation?
I do not really know a lot of debuggers, but I doubt, that all are providing the same interface and the same functionalities as gdb.
Just a suggestion... I would not know, wehre to put the line between debugger-specific interface and stiff framework.Yes, I know, with experience we all learn where to put it. I'm still learning :)
The reset button: imagine we are controlling a traffic light with a microcontroller...OK, I guess this is on the controller, I'm interested what you're doing on the PC's side :)
OK, I guess this is on the controller, I'm interested what you're doing on the PC's side :)On PC side you are send Reset command to hardware debugger =) Then debugger resets program counter, special registers and etc. on MCU.
Why are you switching? Show them both...
What changes? Esspicially for the watches? What customisation?
OK, I guess this is on the controller, I'm interested what you're doing on the PC's side :)
Our watches window is just a table with seven columns: label, value (dec), value (hex), symbol (if watched variable is char), type, address space, base address.Then you need, to add new window, because your watches are totally different from the standard ones.
There is no menu.
Alatar already ansered this question. Our hardware debugger has a command "reset" which triggers the reset. So, the only thing I do is to issue this command.Have you tried to add a menu item for this then?