Handling of drivers referencing non-existant hardware features in svd #340

Activity

1. Fabien-Chouteau commented on Apr 14, 2020

   

   Fabien-Chouteau

   on Apr 14, 2020

   Member

   More actions

   Hello @Hendrik410 ,

   I've also created the necessary entries and runtime projects for the board.

   Did you add the board and device definition in the config scripts?

   Now if I understand it correctly, the drivers are common for all STM32 devices.

   They are at least common to all the STM32 devices that we support so far. But since we do not know the hundreds of STM32 devices available (and the ones to come),

   My question is, how should missing peripherals be handled?

   There is no easy answer I am afraid. Adding to discussion @pat-rogers who wrote this package.
2. Fabien-Chouteau

   assigned

   Fabien-Chouteau

   and

   pat-rogers

   and unassigned

   Fabien-Chouteau

   on Apr 14, 2020
3. Hendrik410 commented on Apr 14, 2020

   

   Hendrik410

   on Apr 14, 2020

   Author

   More actions

   Hi @Fabien-Chouteau ,

   yes, I've used the config scripts.

   I'm not to firm in Ada, I know that in C, compiler dirictives would be used.
   Is there a similar construct in Ada?
4. Fabien-Chouteau commented on May 28, 2020

   

   Fabien-Chouteau

   on May 28, 2020

   Member

   More actions

   No, Ada doesn't have the same feature, which is a good thing in most cases :)

   @pat-rogers what is your opinion on this?
5. pat-rogers commented on May 28, 2020

   

   pat-rogers

   on May 28, 2020 via email

   Contributor

   More actions

   Now if I understand it correctly, the drivers are common for all STM32 devices. They are at least common to all the STM32 devices that we support so far. But since we do not know the hundreds of STM32 devices available (and the ones to come), My question is, how should missing peripherals be handled? There is no easy answer I am afraid. Adding to discussion @pat-rogers <https://github.com/pat-rogers> who wrote this package.

   When I wrote this package I admit thinking to myself that these "timer classifier" functions needed to go in some device-specific location. A separate package from STM32.Timers certainly. They can't go in package STM32.Device because that would create elaboration order circularities, due to the Timer formal parameter. This is a fundamental issue so making a board-specific version of the STM32.Timers package itself is not the right approach. (As an aside, based on the manual I think it is safe to say that the only issue is the presence or absence of any given timer itself, not whether any given timer should be in any given classifier function. In other words, for example if TIM2 exists (TIM2_Base is defined) then TIM2 has the remapping capability and can be in that classifier function.) It may be that we have to put these functions in the STM32_SVD package hierarchy. We'd need to pass something other than Timer though, so this needs thinking about. There are one or two other cases like this too, in other packages, IIRC. I'll give this some thought over the next couple of days (can't do it tonight, in other words). If time is critical, in the short term you could make a separate device-specific version of the Timers package and edit the classifier functions, but that's not a good solution in the long term.
6. pat-rogers commented on May 28, 2020

   

   pat-rogers

   on May 28, 2020 via email

   Contributor

   More actions

   They can't go in package STM32.Device because that would create elaboration order circularities, due to the Timer formal parameter. ...

   I'll give this some thought over the next couple of days (can't do it tonight, in other words).  If time is critical, in the short term you could make a separate device-specific version of the Timers package and edit the classifier functions, but that's not a good solution in the long term.

   It is not a simple problem, due to the elaboration order and the formal parameter type Timer. One possibility, that would be simple and clean, would be to generate the declarations for all the timer addresses (eg TIM1_Base) defined by the manual, located as now in STM32_SVD, but giving the null address value to those not actually declared in a particular SVD file. I don't consider that a hack, actually.
7. pat-rogers commented on Jun 2, 2020

   

   pat-rogers

   on Jun 2, 2020

   Contributor

   More actions

   Earlier I said:

   One possibility, that would be simple and clean, would be to generate
   the declarations for all the timer addresses (eg TIM1_Base) defined by
   the manual, located as now in STM32_SVD, but giving the null address
   value to those not actually declared in a particular SVD file.

   Modifying svd2ada is not the right approach because it is device and vendor independent and, as such, is driven purely by the svd input file. I think the right thing to do is for you to augment the supplied svd file to include the otherwise non-existent timers, assigning them null base addresses. Then the base address decls will be generated and the problematic functions (the timer classifiers) will compile (and function correctly). For example, let's say that TIM20 was a real timer not implemented on a given device, and therefore was not in the svd file. If we add the following to the svd file:

   <peripheral derivedFrom="TIM3">
     <name>TIM20</name>
     <description>Nonexistent</description>
     <groupName>TIM</groupName>
     <baseAddress>0x0</baseAddress>
   </peripheral>
   

   we will get a declaration for TIM20_Base, which is what the classifier functions need:

   TIM20_Base : constant System.Address := System'To_Address (16#0#);

   We'll also get a corresponding device declaration:

   -- Nonexistent
   TIM20_Periph : aliased TIM3_Peripheral
   with Import, Address => TIM20_Base;

   The Import aspect ensures no initialization code accesses address zero, and no other code will reference the fake device (only the base address is referenced in the classifier function comparisons).

   By having the svd input say that TIM20 is derived from some other timer that is truly present, we will get a usable type for the fake object declaration (TIM3_Peripheral above). The actual type doesn't matter.

   Now, all that said, I would prefer a better solution so I will keep thinking about how to address it at the device driver level, rather than the svd generator.
8. Fabien-Chouteau

   closed this as completedon Oct 7, 2020
9. pat-rogers commented on Oct 7, 2020

   

   pat-rogers

   on Oct 7, 2020

   Contributor

   More actions

   I'm still thinking about this, in the background.
10. pat-rogers

    reopened this on Oct 7, 2020
11. kevlar700 commented on Feb 21, 2022

    

    kevlar700

    on Feb 21, 2022

    Last edited by kevlar700

    More actions

    I have found that svd editing is required anyway, so keeping patches may be a good idea?
    "https://community.st.com/s/feed/0D53W00001JWpMGSA1"

    I am currently wondering whilst looking at STM32L4R9 if Timer record types showing the register differences (Basic, Advanced, 15, 16_17, Low_Power) and using Generics or overrides to enable common functionality would make this package easier to digest and port to other STM devices by making it clearer which Timers have which registers?
12. pat-rogers commented on Feb 22, 2022

    

    pat-rogers

    on Feb 22, 2022 via email

    Contributor

    More actions

    On 21-Feb-22 8:28 AM, Kevin Chadwick wrote: I am currently wondering whilst looking at STM32L4R9 if Timer record types showing the register differences (Basic, Advanced, 15, 16_17) and using Generics or overrides to enable common functionality would make this package easier to digest and port to other STM devices by making it clearer which Timers have which functionality?

    I looked into various approaches somewhat, initially, but I didn't spend a great amount of time trying to arrange them into something simpler. I looked into an inheritance hierarchy but don't recall the problems(s) encountered. I got the impression from the online support groups that the STM32 timers were unusual in their complexity as a collection, in that it is difficult to understand them individually without understanding the entirety. A better approach would be very welcome. Best regards, Pat
13. kevlar700 commented on Feb 24, 2022

    

    kevlar700

    on Feb 24, 2022

    Last edited by kevlar700

    More actions

    A better approach would be very welcome.

    Better is easy, until you notice the regressions!

    I looked into various approaches somewhat, initially, but I didn't spend a great amount of time trying to arrange them into something simpler. I looked into an inheritance hierarchy but don't recall the problems(s) encountered. I got the impression from the online support groups that the STM32 timers were unusual in their complexity as a collection, in that it is difficult to understand them individually without understanding the entirety.

    Okay, Thank You. I like the info that the contracts provide in the ads file. In a couple of places, it seems like a counter size and Channel mode selection enforced by 5-7 Timer types instead of throwing exceptions on pre conditions, would be nice. I am not fluent on ST hw yet. Therefore, I will try it out piecemeal and make considerations as I require the functionality in real world use cases instead of trying to understand everything now. Then review it further at a later date.

    Regards, Kc
14. FredPraca commented on Feb 24, 2022

    

    FredPraca

    on Feb 24, 2022

    More actions

    On 21-Feb-22 8:28 AM, Kevin Chadwick wrote: I am currently wondering whilst looking at STM32L4R9 if Timer record types showing the register differences (Basic, Advanced, 15, 16_17) and using Generics or overrides to enable common functionality would make this package easier to digest and port to other STM devices by making it clearer which Timers have which functionality?
    I looked into various approaches somewhat, initially, but I didn't spend a great amount of time trying to arrange them into something simpler. I looked into an inheritance hierarchy but don't recall the problems(s) encountered. I got the impression from the online support groups that the STM32 timers were unusual in their complexity as a collection, in that it is difficult to understand them individually without understanding the entirety. A better approach would be very welcome. Best regards, Pat

    That's something we discussed a long time ago in #196 .
    There was some circularities problem AFAIR.
15. pat-rogers commented on Feb 24, 2022

    

    pat-rogers

    on Feb 24, 2022 via email

    Contributor

    More actions

    On 24-Feb-22 8:19 AM, Kevin Chadwick wrote: A better approach would be very welcome. Better is easy, until you notice the regressions! I looked into various approaches somewhat, initially, but I didn't spend a great amount of time trying to arrange them into something simpler. I looked into an inheritance hierarchy but don't recall the problems(s) encountered. I got the impression from the online support groups that the STM32 timers were unusual in their complexity as a collection, in that it is difficult to understand them individually without understanding the entirety. Okay, Thank You. I like the info that the contracts provide in the ads file. In a couple of places, it seems like a counter size and Channel mode selection enforced by 5-7 Timer types instead of throwing exceptions on pre conditions, would be nice. I am not fluent on ST hw yet. Therefore, I will try it out piecemeal and make considerations as I require the functionality in real world use cases instead of trying to understand everything now. Then review it further at a later date.

    Sounds like a good plan. Good luck! Pat