Modify and export registers data from peripheral view

[QuocTrung76]

Type: Feature Request

I am currently working with vscode-peripheral-inspector, and it has been extremely useful in managing peripheral registers through the peripheral view.

As part of my project, I would like to implement additional functionality, specifically the ability to modify and export the registers data from the peripheral view programmatically. While the current API allows for loading and reading the data, I have not found an exposed method to modify or export the registers's value.

Would it be possible to extend the current API to include such functionality?

I am implementing the peripheral view for the hardware device, it requests to send a couple of gdb commands to read-write the IO registers:
-data-write-memory-bytes --thread-group i1 0x10020028 01000000
-data-read-memory-bytes --thread-group i1 0x10020028 4

These gdb commands should be sent from the adapter layer, could it be possible to provide the API to do it?

[jonahgraham]

Would it be possible to extend the current API to include such functionality?

Yes that should be possible.

These gdb commands should be sent from the adapter layer, could it be possible to provide the API to do it?

Do you have a proposal for providing such API?

While I think this idea would be ok, I think you will need to provide the appropriate PRs for it. As a first step you can provide some details to what your new API would look like so it can be reviewed by the primary maintainers of this project (such as @thegecko)

[QuocTrung76]

Hi @jonahgraham ,
cc @thegecko ,
Sorry for not getting back to you sooner, I took some time to investigate the source code and noticed that the read memory feature is already implemented. Building on this, I plan to develop an export feature that extends the read memory functionality.

My proposal involves adding a new Export button next to the existing Copy and Update buttons. I'll declare the corresponding command across the node hierarchy and utilize the data tracker (src/plugin/peripheral/tree/peripheral-data-tracker.ts) to invoke the read memory methods, exporting the values to a file. The file path will be determined using the definitionPath argument.

[thegecko]

OK, so this isn't an API, rather an additional button?

You should be able to trivially use the existing Copy functionality as a template and I doubt you would need to call read memory again.

Out of interest, is the existing Copy operation not enough (pasted into a file)?

Other things to consider:

• Will this only be supported on leaf nodes (e.g. a single register at a time), or do you want to save part of the tree into a CSV file (or similar)?
• When accessing files, please use the vscode filesystem operations and check that it works in a browser environment.

[QuocTrung76]

I intend to export the data in XML format. An example output would be:

<module name="MODULE_name">
<register name="REGISTER_name" address="0x000000" size="B" value="00" format="H" access="RW">
<bitfield name="LEAF_name" bit="[7]" bitlength="1" value="0"></bitfield>
</register>
</module>
While debugging, the data tracker manages node information. I'll use methods like getCDTTreeItem to access this data. Unlike the Copy function, which retrieves only register or leaf values, this export will save all module information to a file. I've verified locally that it doesn’t re-read memory, as the data is already loaded in the tracker.

The export functionality will handle entire modules by default, with an option to export selected subtrees if needed. This approach leverages the existing data tracker without re-reading memory, ensuring efficiency. The generated XML will comprehensively represent module structures, including registers and bitfields.

[thegecko]

Hmm, any XML library will need to be pure JavaScript to ensure the extension remains portable. What size increase would this have?

I'm thinking a PR would be the best next step.

[QuocTrung76]

I’ve tested the feature with a Renesas device (RH850-U2A) and the resulting XML file is approximately 50MB. I’ll ensure that any XML library used is lightweight and compatible with the extension’s requirements. I appreciate your feedback and plan to start a PR soon for a detailed review. Thank you!