Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Extend GDB plugin to communicate with other plugins
oBFusCATed:
--- Quote from: BlueHazzard on September 26, 2016, 01:23:46 am ---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)..
--- End quote ---
I think some of the embedded forks of cb has a parser for this added to the wizard.
--- Quote from: BlueHazzard on September 26, 2016, 01:23:46 am ---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
--- End quote ---
Unfortunately the propgrid is the best ui for this, but I'm not sure I like this control. Especially the migration from 2.8 to 3.x. :(
--- Quote from: BlueHazzard on September 26, 2016, 01:23:46 am ---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.
--- End quote ---
Don't worry too much about this. The cpu registers window needs improvements. If you make them general enough it might be good for all users.
And there people which will be happy to use something like cb, instead of the vendors ides.
--- Quote from: BlueHazzard on September 26, 2016, 01:23:46 am ---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...
--- End quote ---
This is totally separate topic and probably a lot more work and it is better to discuss it later, when the cpu registers problem is solved.
The problems with interfacing with the debugger from another plugin is that:
1. parsing the output is hard and is done on per command basis, so you need to do some parsing in your plugin.
2. you make a connection where your plugin starts to depend on the behaviour of one particular debugger plugin, which is not a good idea.
--- Quote from: BlueHazzard on September 26, 2016, 01:23:46 am ---Sad... i think there would be a lot potential. Specially in automation of gdb things and embedded stuff (see previous image)...
--- End quote ---
Now we have python printers directly in gdb, which do better job handling the watches. Our scripts for the watches need lots of work, I'm not sure how to do even. We need a way to execute a command, wait for its output, parse it, execute another command and so on.
If you have idea where scripting might help, I'm ready to discuss them.
oBFusCATed:
And for the record I don't like the idea to have two separate cpu registers windows - one for host and one for embedded development.
BlueHazzard:
--- Quote ---I think some of the embedded forks of cb has a parser for this added to the wizard.
--- End quote ---
I have looked into emBitz, but it is somehow closed source and won't run on linux...
--- Quote ---Don't worry too much about this. The cpu registers window needs improvements. If you make them general enough it might be good for all users.
And there people which will be happy to use something like cb, instead of the vendors ides.
--- End quote ---
--- Quote ---And for the record I don't like the idea to have two separate cpu registers windows - one for host and one for embedded development.
--- End quote ---
The thing is this: periphery register are not cpu registers... (like the program counter or the cpu status register) this register are read with the info registers command of gdb.
Periphery register on the other hand are located on a special memory location and read with the x command.
It is possible to merge this two register views, but i don't know if this is a wide spread opinion...
oBFusCATed:
--- Quote from: BlueHazzard on September 26, 2016, 11:49:55 pm ---I have looked into emBitz, but it is somehow closed source and won't run on linux...
--- End quote ---
Does it still look like code::blocks 10.05?
--- Quote from: BlueHazzard on September 26, 2016, 11:49:55 pm ---It is possible to merge this two register views, but i don't know if this is a wide spread opinion...
--- End quote ---
Why not?
BlueHazzard:
I looks somehow like visual studio 2012 or so... And the settings ui is quite different, i had difficulties to find me around...
--- Quote ---Why not?
--- End quote ---
Well lets try it...
Can you give me some overlook over the architecture?
What is the intention to not call (queue) the debugger commands from the DebuggerGDB class, but translate them through the driver?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version