[En-Nut-Discussion] Ethernut on TI's Cortex-M3 (Stellaris LM3S...)

[Philipp Burch]

Hi Uwe,

On 10/09/2012 10:55 AM, Uwe Bonnes wrote:
>>>>>> "Philipp" == Philipp Burch <phip at hb9etc.ch> writes:
>
> ...
>      >>  Here are some advices from my side.  - Clone the svn repo to a
>      >> locate "git svn" repo.
>
>      Philipp> That's good advice. I usually use Mercurial, but Git works
>      Philipp> quite similar, so this should be fine.
>
> If there is a Mercurial <-> SVN workflow, stay with mercurial

No, no, Git is fine. I'd planned to use that sometime, so this is a good 
reason to start with it now :)
This way we may be able to pass around Git bundles which should simply 
be compatible. Well, maybe.

>
> ...
>
>      Philipp> What I plan to do now is to start over (using the recommended
>      Philipp> local Git repo) and then just add support for the LM3S9B96 as a
>      Philipp> start, so that we can test using the devkit. So I'd trash
>      Philipp> StellarisWare and simply put the lm3s9b96.h into
>      Philipp> nut/include/arch/cm3/lm3/vendor. The other prototypes would
>      Philipp> then go into nut/include/arch/cm3/lm3/lm3s9b96.h and the code
>      Philipp> into nut/arch/cm3/dev/lm3/whatever.c.
>
>      Philipp> Is this ok for "the clean way"?
>
> Experimenting with code form libopencm3 for stm32, I feel that even one more
> level for directories would fit, like e.g.
> - nut/arch/cm3/dev/stm32/vendor/stm
> - nut/arch/cm3/dev/stm32/vendor/libopencm3

This could be useful for the STM devices, but probably not for the LM3s. 
Stellaris provides one single header file for every part which includes 
all the register and bit definitions. Additionally, they ship their 
StellarisWare, which is in fact an abstraction for all these register 
accesses. It's a nice thing if used on it's own, because you can then 
say, for example

MAP_SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ 
| SYSCTL_OSC_MAIN);

and it will do all the necessary register settings in a device 
independent manner. The downside of it is, of course, the huge 
dependency on this StellarisWare thingy. And it does extremely pollute 
the namespace, which even causes a few conflicts with existing Ethernut 
symbols. So this is a bad idea for implementing Ethernut drivers, it 
should only be used by the end users if they need direct hardware access.