Conversation
Added a MCU_To_CPU function that returns the string representation of the CPU based on the Device parameter. It is then used when generating handlers.S
|
|
|
Spello: Description_String, not Descrition_String |
| -- MCU_To_CPU -- | ||
| ----------------- | ||
|
|
||
| function MCU_To_CPU |
There was a problem hiding this comment.
You would need to declare the function first, at the beginning of the package. I'm a bit surprised this didn't raise a compilation error. I'll check the project file to make sure this rule is checked by gnat.
There was a problem hiding this comment.
We can put in place an automatic validation of the pull request with Travis-CI.
There was a problem hiding this comment.
Done. Also can confirm that the project builds and executes successfully even without the declaration.
src/descriptors-device.adb
Outdated
| Descrition_String : constant String := To_String (Device.Short_Desc); | ||
| CPU : Unbounded_String; | ||
| begin | ||
| if Starts_With (S1 => Descrition_String, S2 => "STM32F0") then |
There was a problem hiding this comment.
This patch is very useful, but I'm a bit uncomfortable with it: the element is supposed to be there for this purpose, while here we skip it entirely. So this makes svd2ada very dependant on ST-generated SVD files (and they don't seem to generate this optional information, while they should), while other vendors do and so we should first check if the information is present there.
Basically, I'm not refusing such consideration, it's only that to be fair, the SVD standard already provides means to provide this information, and having such routine that is ST-specific there without the more generic handling implemented first seems unfair, and risky (if ST decides at some point to fill the gaps).
6 participants
Added a MCU_To_CPU function that returns the string representation
of the CPU based on the Device parameter. It is then used when generating
handlers.S