Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Extend GDB plugin to communicate with other plugins
oBFusCATed:
I guess, I'm not getting the idea of svds.
In the beginning you wanted to plug them in the cpu register's window, now you want to plug them in the examine memory or make new window.
I'm totally confused.
p.s. m_count doesn't make sense when m_data is a vector...
BlueHazzard:
i never wanted to put them in the cpu register window, that was your idea... Ok from the beginning:
1) Microcontroller have special function register (SFR), where the functionality of the periphery is controlled. This register are mostly stored in a RAM block, or at least accessible over a RAM instruction, so they can be read out with the debugger with the "x" command. They are called register, but have nothing to do with the CPU internal register like the EIP or the PC (program counter) found in the CPU.
2) SVD files are special files (from ARM) that describe the location and the value of this special function register. They describe that on location 0x123413 is the SFR called UART_CTRL and if this register has the value 0x44 then the UART is activated, but if it has the value 0x33 it is deactivated. The SVD file describes also how you create header files to control this registers and many more things. This files are provided by the hardware manufacturers of the microcontroller. SVD is some file standard mostly used for ARM, but similar files exist for other microcontroller
3) So I want a window (property grid tree) that displays me the status of this SFR. For this the debugger reads some part of the RAM and interprets the data in it with the help of the svd file
4) What is needed: A interface to the debugger that lets you read , not necessarily connected, parts of the RAM (1). Where can this be found: In the memory window, so my thoughts were to connect this two things.
The interpreting and displaying of the SFR is a microcontroller specific task, so i personally think it should be put in a plugin. The needed functionality to the debugger is only read pieces of memory, what every debugger should be possible, but the plugin needs a interface for this. My idea is to introduce the concept of "memory watches" as described above, so any plugin can add watches to the current running debugger and keep track of them with a shared_ptr (probably not the best way, but hey this is how it is made with the watches)
(1) for example 12 Bytes starting from 0xAA1234, 4 Bytes starting from 0xAA1223 ecc.
oBFusCATed:
Are these things always read using the x command? For all controllers or this is stored in the svd?
The term memory watches is not a good one. It is close to data watches.
Is it possible for these things to have sub-fields? Or do they store just a single value?
Do we need to display them in the UI like we display a C/C++ struct?
The cbMemoryWatch proposal is not a good one because it expands the API too much.
Lets see if we can reuse the watches functionality for these things.
edit: What is the cheapest way I can get one such controller+jtag debugger for experimentation?
BlueHazzard:
--- Quote ---Are these things always read using the x command? For all controllers or this is stored in the svd?
--- End quote ---
As far as i can tell all big microcontroller map their periphery register to ram, so it should always be possible to read them from ram with x.
--- Quote ---Is it possible for these things to have sub-fields? Or do they store just a single value?
Do we need to display them in the UI like we display a C/C++ struct?
--- End quote ---
I can not find any nice image but you can get a idea from here: http://www.forward.com.au/BluetoothLedDriver/PINB_PB2.JPG for AVR
PORTB is a periphery with the register PINB (at address 0x36 with the value 0x04), DDRB (at address 0x37 with the value 0x00) and PORTB (at address 0x38 with the value 0x04)
Now if i would use the memory watch idea, i would create a watch with the address 0x36 and the count of 3. This would return me {0x04, 0x00, 0x04} and the plugin would interpret it and fill the property grid..
This image is not ideal, because one register can be divided in more Bit fields (from different size) and every bit field can have multiple values, selected by a drop down list. Each bitfield can have different attributes like: read only, write only, write only once ecc...
Also one register can be multiple bytes large (AVR 8Bit register vs ARM 32 or 64bit register), this is described in the svd file.
--- Quote ---Lets see if we can reuse the watches functionality for these things.
--- End quote ---
i am open for ideas, but keep in mind that it should be fast and the data should be as raw as possible...
--- Quote ---The cbMemoryWatch proposal is not a good one because it expands the API too much.
--- End quote ---
I can understand this point to some extend if there are a lot external plugins, but codeblocks, at the moment, is not a application with tons of external plugins (at least i am not aware of them), so breaking the API should not be a big deal.
--- Quote ---edit: What is the cheapest way I can get one such controller+jtag debugger for experimentation?
--- End quote ---
probably a NUCLEO-F103RB, nucleo-f091rc or a other stm discovery board (ARM controller from STMicroelectronics ) with around 15€. The debugger (SWD) is included and you get the possibility to make a full j-link ( https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ ) out of it. Note: i have yet to try to use the stm controller to work in codeblocks. At the moment i use an arduino due and a j-link from segger (Atmel ARM controller)
oBFusCATed:
API Breakage is not problematic. I just don't want to make the API big. I prefer if we could re-use as much as possible.
Do you expect to add "watches" for all supported "registers" from the file at once or do you add them one by one (the ones you need at the moment)?
Can you find some example svd file and then show the UI we should generate? So we can have something more concrete example we could discuss.
If you read every register with a single x command then the performance will be rather bad (similarly bad as if you add many watches).
The commands are executed synchronously, if you want asynchronous execution then gdb/mi protocol should be used.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version