You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
@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)
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.
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.
The text was updated successfully, but these errors were encountered: