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

[Philipp Burch]

Hi Uwe,

On 10/11/2012 04:49 PM, Uwe Bonnes wrote:
>>>>>> "Philipp" == Philipp Burch <phip at hb9etc.ch> writes:
>
>     [...]
>
> I learn something new every day. "Git bundle" is something I didn't know
> about and which seems usefull. However what I found (or understood) about "git
> bundle" on the net didn't work out. I tried e.g.
>> git clone repo.bundle -b master repo
>> git pull ethernut_lm3s9b96_initial.bundle
> nut nothing worked out successfull.
>
> Could you give me a head start?

Oh sorry, I missed something. The way to go would be

cd my_own_git_repo
git bundle unbundle path/to/bundle

But this cannot work, because my repo is not based on the same commits 
as yours. So git will never be able to unpack the bundle correctly. This 
would only work if we'd cloned from the same (git!) repo in the first 
place. So I'm afraid we will need to do it with diffs for now.

>
> Looking at http://hb9etc.ch/ethernut/ethernut_lm3s9b96_r4719.patch you seem
> to use very part specific defined, like (MCU_LM3S9B96). I didn't find any
> broschure on the TI website that defines classes of LM stellaris parts. But
> if such classes exist in a sensible way, perhaps try to be less
> specific. Anybody adding other parts in the same class will have a head
> start, as has somebody e.g. adding the LM4F class and parts e.g. for the 5
> Euro new Launchpad.

Yes, to be very specific for now was my intention. I'm trying to get 
just this one part working without breaking anything else. As soon as 
that works, I'll start to "refactor". A lot of code should be usable 
without further modifications for may different parts. The StellarisWare 
driverlib provides a good hint for this, the same hw_xxx.h files are 
usable for all Stellaris parts and often do not even contain a single 
#ifdef to switch between devices. Same applies to the implementations.


Ole wrote:
> [...]
>
>> Good point. I hope that my changes do not interfere with any other
>> targets, but this needs to be ensured of course. Are there any
>> testsuites for this, or do you usually do this by hand?
>
> AFAIK Harald has something like this but I don't know if it is public.
> I'm doing this manually by compiling for different targets.
>

So you just test if it still builds?

>>>>
>>>> Do you have any sample sources (CMSIS examples) which came with your
>>>> devkit? You could easily take over the settings (and code) provided in
>>>> your system.c file (most probably it will be called system.c)
>>>>
>>
>> Yes, the distribution comes with a whole bunch of examples. As
>> mentioned, the actual implementation of the drivers should not cause too
>> much trouble, but I had to know how to interface with Ethernut before.
>
> I looked a little into you patchset and found the following:
>
> - In nut/include/arch/cm3/lm3/lm3s9b96.h you are referencing a STM32
>   header.

Oh, indeed, thanks for the hint.

>
> - Further you created
>
>   nut/include/arch/cm3/lm3/vendor/lm3s9b96.h
>
>   Better place it in
>
>   nut/include/arch/cm3/lm3/lm3s9b96.h
>
>   Why the "vendor" subtree?

That was proposed by Uwe, see his other mail. The idea sounds useful :)

>
> - As Uwe just mentioned you should try to specify some "family" macros
>   instead of using CPU specific macros where ever possible.

As mentioned, I'll do this as soon as something works.

>
> - Your CPU header seem not to follow the "struct" way, like most other
>   Cortex Mx CPU headers does. Yes we just had some long discussions
>   about this. But as the STM32 and NXP port just started using this way
>   and most other CPU vendors follow this way as well it would be a good
>   idea to go the same way. Otherwise we will get in trouble with the
>   common function that use
>
>   SCB->VTOR = (uint32_t)g_pfnRAMVectors;
>
>   instead of
>
>   outw(SCB_VTOR, (uint32_t)g_pfnRAMVectors)
>
>   for example.
>
>   Does TI not provide headers of this style?

Good point. I'm not aware of any headers of this style, so maybe this 
will be a task for sed and friends...
In fact, I hoped to be able to use the vendor's files unchanged, but 
this won't be possible anymore then.

Thanks,
Philipp