Startup files for STM32F4xx
Rikki Cattermole via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Sat Apr 25 00:08:22 PDT 2015
On 25/04/2015 7:04 p.m., Jens Bauer wrote:
> On Saturday, 25 April 2015 at 05:14:57 UTC, Rikki Cattermole wrote:
>> On 25/04/2015 5:07 p.m., Jens Bauer wrote:
>>>
>>> I hope to find a good way to use import for microcontroller libraries,
>>> so it'll be easy for everyone. I'm thinking about something like ...
>>>
>>> import mcu.stm32f439.all
>>
>> Ugh, package.d?
>
> I don't know ... Maybe, but what I have in mind is a tree like this:
> mcu/
> common/
> ... (Cypress Semiconductor here) ...
> lpc81x/
> lpc82x/
> lpc15xx/
> lpc175x_6x/
> lpc177x_8x/
> lpc40xx/
> lpc43xx/
> ... (Freescale Kinetis here) ...
> stm32f401/
> stm32f405/
> stm32f407/
> stm32f411/
> stm32f415/
> stm32f417/
> stm32f427/
> stm32f429/
> stm32f437/
> stm32f439/
> ... (Texas Instruments here) ...
>
> -Because there would be some things that can be recycled for all
> microcontrollers, and there will be a lot of different device types.
>
> Things that can be recycled would be carefully written drivers, such as
> LCD drivers that uses the SPI protocol. The SPI interface itself cannot
> be recycled, though, as each device has different SPI hardware and
> different GPIO hardware.
> It could also be 'minimalistic memory handlers' and other algorithms,
> which do not know anything about hardware.
> It might be possible to make a CMSIS which can be recycled as well.
I was referring to package.d files. And publically importing all below
modules/packages.
I wonder if you can get e.g. interfaces and classes working.
At worse maybe structs + alias this + meta programming for e.g. drivers?
More information about the Digitalmars-d-learn
mailing list