I actually do it differently to this example and have code duplication for individual timers. That way when porting to a new chip then any svd generation diferences of the hardware are flagged up by the compiler.
I think type list generics would be perfect for this (if they existed, I shall add to my Arg request now that I understand generics better) but perhaps you have a better way that I can consider the readability of for this Timer code.
At the bottom of this file you can find the Timer Peripherals and Periphs.
This is the driver that decomposes an overlay across the timers. I don’t do that for maintenance/porting reasons.
This has Timer. I keep them individual instead.
Here is a generic for file I/O
This is a Class example and there are controllers around somewhere. I find these just complicate everything, personally.
Any thoughts are welcome and appreciated from anyone.
AdaCore abstract file system interface is pretty much the standard way to do it. In real-life there probably will be a dozen of specializations of it to reuse common cases, like a file system on top of a block device, a file system on top of network connection etc.
This is why inheritance is so important. A specialization can implement some abstract operations in terms of new abstract operations specific to the specialization. It is a very flexible model.
My approach does not differ much from the AdaCore’s one.
I have an abstract interface with a large number of abstract operations. Then on top of that come many specializations like a serial connection driver which reduce the operations to bare minimum. So when a specific serial protocol driver need to be implemented it derives from the serial driver and deals only with the protocol while the whole infrastructure akin to a file system is already there.