[En-Nut-Discussion] Devnut_m3n: architecture dependend directories

[Ulrich Prinz]

Hi!

It was my intention to keep stm32f10x_*.c/.h for most kept original
files and stm32_*.c/.h for rewritten files.

It was agreed with ST that we can use thier files under BSD license if
we keep their header before ours.
In files that are rewritten, no ST header needs to be applied anymore.

As their code is pretty instructive but less performant, it makes
sense to rewrite the code piece by piece. I did that for the periphery
parts that I needed in our project.

It showed up that we might have to rename again as there are some
bigger incompatibilities between STM32F1 and STM32F2/4. Could be that
the files will be renamed to
stm32f1_* and stm32f2_*

I wonder if there isn't a simpler way of how to include different
architecture directories than to write these annoying c/h files that
only include other files again.

May be we could place a makefile in every arch/ directory and one that
selects the right directory and includes the Makefile there.
Then we only have to clearify a naming convention for some files and functions.

Normally the stm32f10x.h needs only to be included by the files below
arch/cm3/stm/

So we need to create a arch.h for every existing architecture and that
one includes standrised nut/os tokens.

So every architecture could define
#define NUT_DEV_USART1
#define NUT_DEV_USART2
and it could do it with logical numbers or addresses or pointers,
whatever it needs.

The user just includes arch.h and uses the tokens.

In that case we have the architecture dependent choices of wht to
include in a single Makefile instead of spreading it in several .c/.h

Just a guess, tell me what you think.

Ulrich

Am 16. Januar 2012 12:04 schrieb Uwe Bonnes
<bon at elektron.ikp.physik.tu-darmstadt.de>:
> Hallo Ole,
>
> thinking about getting your massive file move into and later out of my
> playground make my (few) hairs even greyer ;-)
>
> But shouldn't we have even more destinction, between vendor supplied files
> and NutOs-supplied files? At least for the stm32 files like
> nut/include/arch/cm3/stm/stm32f10x_rtc.h
> are still the ST-Lib files with few modification, while files like
> nut/arch/cm3/dev/stm/stm32_spi1.c
> are rewritten by Ulrich. The postion of the file in the file tree should
> clearly indicate the origin of the file.
> If all your lpc files are self written, this doesn't hold for you...
>
> Otherwise I suggest that conditional includes like in
> nut/include/arch/cm3/cortexM3.h
>
> should read
> #if defined(MCU_SAM3U)
> #include <arch/cm3/atmel/sam3u.h>
> #elif defined(MCU_STM32)
> #if defined (MCU_STMF1)
> #include <arch/cm3/stm/stm32f10x.h>
> #elif defined (MCU_STML1)
> #include <arch/cm3/stm/stm32l1xx.h>
> #else
> #warning "Unknown STM32 family"
> #endif
> #elsif (MCU_LPC)
> #if defined (MCU_LPC176x)
> #include <arch/cm3/nxp/lpc17xx.h>
> #elif defined(MCU_LPC177x_8x)
> #include <arch/cm3/nxp/lpc177x_8x.h>
> #else
> #warning "Unknown LPC family"
> #endif
> #else
> #warning "Unknown CM3 manufacturer"
> #endif
>
> and the include/cfg/arch.h should define the family additional to manufacturer.
>
> Bye
> --
> Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion