Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Extend GDB plugin to communicate with other plugins
BlueHazzard:
For embedded arm development i would like to use the gdb debugger. But the current plugin is missing some features i would like o add (like a peripheral register watch ecc.). I would like to avoid to clone the current plugin but instead create a type of cross plugin communication... The easiest would be to add a function to send Commands to the debugger and return the answer from gdb... Probably over the event system for asynchronous calls?
Are there any thoughts, counter arguments?
oBFusCATed:
I don't like the idea. If we do this then we need to have code that handles plugin deps and makes sure that dependant plugins are loaded before the plugin that needs them.
This is complex and error prone.
Why don't you just extend the cpu registers window with the needed functionality and the debugger api to match the needed features?
I'll be happy to guide you, review and commit the changes.
BlueHazzard:
--- Quote from: oBFusCATed on September 25, 2016, 06:05:57 pm ---I don't like the idea. If we do this then we need to have code that handles plugin deps and makes sure that dependant plugins are loaded before the plugin that needs them.
This is complex and error prone.
--- End quote ---
I see the problem here... Couldn't this be handled by using events? If the receiver plugin is not loaded the the events simply get to nirvana and the plugin detects it somehow over a timeout (wild speculations here)...
--- Quote from: oBFusCATed on September 25, 2016, 06:05:57 pm ---Why don't you just extend the cpu registers window with the needed functionality and the debugger api to match the needed features?
I'll be happy to guide you, review and commit the changes.
--- End quote ---
I am not happy with extending the current plugin with the features, because i would like to make something like this:
and for this i need a .svd file parser and so on. This would bloat the plugin and if someone is not using the embedded stuff this is not needed...
An other possibility would be to extend the watch parsing (squirrel) with the ability to modify the controls....
oBFusCATed:
--- Quote from: BlueHazzard on September 25, 2016, 06:54:32 pm ---and for this i need a .svd file parser and so on.
--- End quote ---
What is a svd file?
--- Quote from: BlueHazzard on September 25, 2016, 06:54:32 pm ---I am not happy with extending the current plugin with the features, because i would like to make something like this:
--- End quote ---
Do you need this to be a tree ctrl?
--- Quote from: BlueHazzard on September 25, 2016, 06:54:32 pm ---This would bloat the plugin and if someone is not using the embedded stuff this is not needed...
--- End quote ---
It could be enabled per configuration and not on by default.
--- Quote from: BlueHazzard on September 25, 2016, 06:54:32 pm ---An other possibility would be to extend the watch parsing (squirrel) with the ability to modify the controls....
--- End quote ---
Don't do this, the squirrel code in the debugger plugin will be removed as soon as I finish merging the sqrat stuff.
BlueHazzard:
--- Quote from: oBFusCATed on September 26, 2016, 12:50:44 am ---What is a svd file?
--- End quote ---
for ex. http://www.keil.com/pack/doc/cmsis/svd/html/svd__example_pg.html The file describes the internal periphery register structure of arm and other µC (i know the files also for atmega/xmega)..
--- Quote ---Do you need this to be a tree ctrl?
--- End quote ---
i don't know the UI yet.... some kind of property grid, it should have the possibility to use drop down menus,check boxes and text fields. Custom controls like leds (red dots) would also be nice... A search field would also be needed, because there can be ton's of register and flag names
--- Quote ---
--- Quote ---Quote from: BlueHazzard on Yesterday at 18:54:32
This would bloat the plugin and if someone is not using the embedded stuff this is not needed...
--- End quote ---
It could be enabled per configuration and not on by default.
--- End quote ---
By bloating i mean code/ binary size... More things to maintain for the main dev team ;) Of corse it is possible to add it at the core and make it configurable, but i don't like the idea to add something to the main plugin what is not needed for the core. Because there is also potential for more logging/debugging like:
I don't think this functionality should be in the core. But if you want to use codeblocks (i think there is no really nice, cross platform and fast IDE for debugging embedded systems out there) for embedded development you "need" this things. It would simply be nice to have somehow an interface to gdb...
--- Quote ---
--- Quote ---Quote from: BlueHazzard on Yesterday at 18:54:32
An other possibility would be to extend the watch parsing (squirrel) with the ability to modify the controls....
--- End quote ---
Don't do this, the squirrel code in the debugger plugin will be removed as soon as I finish merging the sqrat stuff.
--- End quote ---
Sad... i think there would be a lot potential. Specially in automation of gdb things and embedded stuff (see previous image)...
Navigation
[0] Message Index
[#] Next page
Go to full version