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