I’m looking to use the Ada Driver Library, targeting the STM32L4xx series. These specific micros aren’t in-tree for the driver library, but it seems like the bulk of the work is just in generating the Tasking runtime (which the full driver lib seems dependent on, by way of Ada.Real_Time), and then just moving in the files from the library repo.
Generating the runtime seems simple enough according to these docs:
The driver library itself isn’t as clear (porting info is still a TODO):
I’m guessing the driver lib port is pretty straightforward. Is there anything I should know before doing this?
One complication with the low power parts is highly dynamic clocks and voltage scaling e.g. MSI/MSIS. I used the light runtime with the L4 but have switched to the U5. The U5 has slightly simpler clock control but more driver differences to the Ada_Drivers_Library.
I followed this but it does mean the loss of exceptions and protected objects and tasking and degradation to c-like interrupts.
I plan on starting out with a very simple clock setup and expanding as needed by just cribbing config values from the C API and building my own abstraction to paper over it.
I did go through that article with success with the light-cortex-m0 (for a past, unrelated experiment I was doing) and light-cortex-m4 runtimes. Not having exceptions/protected objects/tasking/Attach_Interrupt is fine for my application. I’ve been using the generic light-cortex-m4 runtime for some initial testing on the L4 part I’m looking at with some success, but I’d like to use/port the Ada Driver Library instead of just twiddling registers myself, because I’ll just end up implementing a worse homebrewed ADL.
After doing reading on the issues/discussions on the bb-runtimes repo, it seems that just using the generic Cortex light/ZFP runtime is preferred to making a BSP/runtime for a given part if you don’t need the features of the Ravenscar runtimes.
This describes me – I don’t have an immediate need for the Ravenscar profile and would be plenty happy with a light runtime and adjusting the ADL to fit. However, it appears that the ADL for the STM32 arch seems to rely pretty heavily on the Tasking facilities. Is there any way around this? I haven’t found any immediate way to use the ADL without tasking with an STM32, but I may very well be misreading or misunderstanding something.
I have used a number of the drivers in ADL as starting points but any tasking feature use has to be avoided or re-implemented. One thing Fabien pointed out was that the ADL has been used as a bit of an Ada feature demonstrator. I forget his words but I guess don’t be shy about making things more boring. You might want to consider writing the Timer driver from scratch as it uses a unifying peripheral overlay which in my opinion does not make best use of Ada and svd2adas protections when porting to a new chip.
We have a project that may require the full 160mhz instead of the 48mhz L4 msi Ada support that I had written. I am considering whether to use STS clock setup code in C as a shortcut just during initialisation. I am in two minds about it.