Closed pat-rogers closed 8 years ago
For the record, the following proposals are being investigated, but we're very open to other suggestions:
What about including 'ARM', 'Cortex' or 'Cortex M' in the name? Something like Ada_Cortex-M_Library? Or do you want to keep the possibility to extend the library to totally different architecures?
Indeed, ideally the HAL layer and the components layer could be used on different architectures, and we may add support for other architectures later on
Well, I have currently a design issue here: when automated resolution is OK, I create union types at the register level, while when the svd2ada file is in use, the union type is at the peripheral level.
I guess I'll have to fix that first before being able to merge anything and provide this kind of functionality.
This comment seems to belong to another issue...
Indeed, ideally the HAL layer and the components layer could be used on different architectures, and we may add support for other architectures later on
OK. Then perhaps 'Microcontroller' instead of Cortex M? After all, it's a library for microcontrollers and their peripherals, isn't it?
Oups, a cache issue I guess from my browser :(
Even microcontroller is a bit restricting here, as the components could perfectly be used with a Cortex-A for example. We'd like to not bring limitations here if we can have a more generic goal (even if this generic goal is never achieved). It's basically about Ada and how to write drivers in Ada. Embedded however might be an appropriate keyword.
'Embedded' is fine!
On the micro-controller side it's likely that ARM Cortex-M/R will be the major architectures, but we may see some Leon3/4 or even AVR someday.
For the "bigger" platforms, as Jerome said, there's the possibility of bare-metal support on Cortex-A and it's also possible to consider Linux/Windows with the Raspberry-Pi and other single board computers. The Intel Edison platform is very interesting, it's a x86 running Linux and GNAT GPL works like a charm on it. I can easily see some HAL interfaces (I2C, SPI, UART) implemented on those platforms and then it should be easy to use the components drivers.
I was writing something about the repository the other day and noticed that I kept referring to it is an Ada driver library, so I think I have convinced myself in favor of Fabien's suggestion. :-)
I also do keep referring to the library in those terms. Driver already means embedded anyway, so no need for duplication here. It's a library in Ada, about drivers. So I'm now really convinced that this name is just appropriate.
Sounds like we've reached a consensus on "Ada_Drivers_Library", so lacking any further inputs I'll get the name changed.
Done.
We are thinking of changing the name to something more descriptive that "bareboard" and are hereby requesting suggestions.
What do you suggest?