[En-Nut-Discussion] Ethernut on TI's Cortex-M3 (Stellaris LM3S...)
phip at hb9etc.ch
Tue Oct 9 22:08:46 CEST 2012
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
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.
More information about the En-Nut-Discussion