search

STMicroelectronics / STM32_open_pin_data

This repo provides all the information required for the pin and board configuration of products based on STM32 MCU.
BSD 3-Clause "New" or "Revised" License
56 stars 10 forks source link

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

Open Samo1289 opened 2 years ago

Samo1289 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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.