Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding all possible tables from datasheets and reference manuals #7

Open
Samo1289 opened this issue Aug 29, 2022 · 3 comments

Comments

@Samo1289
Copy link

Samo1289 commented Aug 29, 2022

Hello,

Codegen and compile time static analysis is very desirable feature to have and many nice structures can be generated, to help programmers correctly tie together peripherals (TIM to peripheral, DMA to peripheral, RCC to peripheral, etc).

From quick glance over the STMicroelectronics project here on gitlab, there is not repository with SVD files, so would post it here:

People are encouraged to write tools (codegen, analysis, frameworks) internally in many companies, or, they are interested in creating a framework for their firmware projects. SVD files, while used by debuggers, are easy to parse and use to define such tools. It is a bit shame, they are lacking (being wrong or incomplete) and missing many informations available in datasheets (e.g. modifiedWriteValues, readAction, enumeratedValues where it makes sense, writeConstraint, etc..)
Also, defining SVD file for the whole "family", and not for the concrete IC in its package also does not help this issue.

In my opinion, a thoroughly done and correct SVD files and other XML files with information from datasheets would be greatly appreciated by the community (especially with emerging Rust popularity) and could give potential competitive edge to the ST.

Thank you.

@salkinium
Copy link

I've written my thesis on this topic, and it turns out to be non-trivial to generate a better SVD file from the technical docs alone.
But perhaps merging the CMSIS header files with the reference manuals may be a good option for fidelity and resolution.

@Samo1289
Copy link
Author

@salkinium Thank you very much for the paper, I will read it during the weekend. Generating might be non-trivial, but maybe we can consider human resources; retrospectively fitting all the data into the SVD files is a tedious, boring job but it can be done; while all the new products from vendors (not only ST) could have the engineers writing the datasheet, generate the SVD files (this can also be automated quite well)

@salkinium
Copy link

We want the same thing, I'm just tired of waiting for it to happen 😜
We can ask for more data, but I don't think it'll happen anytime soon, it's just difficult to sell to hardware companies that don't understand the new embedded software world.

By parsing the PDFs directly, we can circumvent any vendor gatekeeping and even retroactively apply this method to deprecated documentation as well.
The vendors are then simply not part of this discussion anymore, we don't need them to cooperate and they cannot stop us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants