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

[Philipp Burch]

Hi Uwe,

On 10/08/2012 12:00 PM, Uwe Bonnes wrote:
>>>>>> "Philipp" == Philipp Burch <phip at hb9etc.ch> writes:
>
>      Philipp> Hi everyone, I'm working on a little I/O board featuring an
>      Philipp> LM3S9D90 and an FPGA.  Until some time ago I'd planned not to
>      Philipp> use an OS at all and implement a simplistic cooperative
>      Philipp> multitasking framework on my own. Well, that was before I've
>      Philipp> heard of the Ethernut project which looks very promising for
>      Philipp> this project.
>
>      Philipp> Anyway, I've fetched the latest sources from Subversion and
>      Philipp> built them.  I then noticed that there even already exists a
>      Philipp> dk-lm3s9b96 target of which I've got a board for testing.
>
> It seems the dk-lm3s9b96 conf file is all that is done for LM3/4. There are
> no stellaris directories under nut/arch/cm3/dev/ and nut/include/arch/cm3,
> so support it nearly non existant.

Ok, this is good to know. It's not what I hoped, but a clean start can 
also be a good thing :)

>
>      Philipp> I (nor the compiler) could not find however, is the specific
>      Philipp> include file for this processor. So my question is now if there
>      Philipp> is already some work in progress for this processor and it
>      Philipp> hasn't been committed yet (or I didn't find it...)
>
> Ulrich added the conf file, perhaps he has more info. Perhaps
> http://old.nabble.com/NUT-OS-and-lm3s6965-td30984294.html
> has also more info

Unfortunately not. I've seen this thread before and they (or at least 
Henrik and Harald) point out some problems with the Stellaris thingies. 
The erratas are still not very promising, but it seems to get better.

>
>      Philipp> or if I need
>      Philipp> to do this from scratch. I suppose I'd need some assistance for
>      Philipp> the latter option, as I've never done this before.
>
> Here are some advices from my side.
> - Clone the svn repo to a locate "git svn" repo.

That's good advice. I usually use Mercurial, but Git works quite 
similar, so this should be fine.

> - Add some minimal configuration in the nut/conf/ *.nut file.
> - Add something like nut/arch/cm3/dev/lm and nut/include/arch/cm3/lm
> directories.
> - Looking back at the STM32 port, it would have good if vendor delivered
> files would have been added as something like nut/arch/cm3/dev/lm/vendor and
> nut/include/arch/cm3/lm/vendor. Start with adding the original vendor
> delivered files untouched and with a clean hint on the source iand version
> you added in the commit note. Then make changes to the files inside your
> local repo, so that these files can easy be updated later.
> - Implement the clock setup

That's what I've tried on the weeking. Without much success yet, 
however. The mistake I did was that I tried to make use of the device 
independent drivers supplied by TI (stellarisware). This is probably 
almost impossible to do because it becomes extremely ugly because of all 
the #defines and friends. And it would add a huge dependency.

What I plan to do now is to start over (using the recommended local Git 
repo) and then just add support for the LM3S9B96 as a start, so that we 
can test using the devkit. So I'd trash StellarisWare and simply put the 
lm3s9b96.h into nut/include/arch/cm3/lm3/vendor. The other prototypes 
would then go into nut/include/arch/cm3/lm3/lm3s9b96.h and the code into 
nut/arch/cm3/dev/lm3/whatever.c.

Is this ok for "the clean way"?

> - Implement a GPIO driver
> - Add the board specific header in nut/include/arch/cm3/boards and a like to
> that file in nut/include/dev/boards for the board specific setup
> - Now test with app/uart.c

Ok, implementing drivers for the simple devices should not be a big deal 
thanks to all the examples. I hope to have a first working version with 
debug UART support until next weekend.

> - If you implement GPIO then, the examples using the bitbanging drivers
> (two-wire, spi, one-wire) should start to work.
> - Clean up your repo and consider psuhing to the SVN directory
> - Now add drivers at your gusto and keep commiting...
> - For the OS-Timer and the whole thread switching you need to do no work, as
> that is common to CM3.

That's good to know, thanks.

>
>      Philipp> And another thing: Is it preferable to use the cm3-ecross-gcc
>      Philipp> from Thermotemp or the one that ships with TI's stellarisware?
>
> I use a self compiled yagarto arm-non-eabi- chain. Try to keep vendor
> dependancies as minimal as possible. Also have a look at the license of
> vendor delivered files. Something like the old luminary license should not
> slip in again, see http://www.ethernut.de/en/download/index.html under
> "Latest Beta Version". However the present TI license seems suitable, also
> the disclaimers you have to accept with downloading the code is repelling.
>

Ok, I'll then stick to the eCross toolchain as a start. Let's see if it 
works.

> Why do i recommend git? You have the repo local, and you can clean up things
> as long as you have not pushed the changes to the official repo. With SVN,
> you can't even edit the commit message of the last check-in without much
> effort.

You surely don't need to convince me of any advantages of Git over 
Subversion :)

>
> B.t.w: what is you environment? If you work with non-Win32, what is your
> programmer and debugger? I consider getting some of the LM4 launchpads too..
>

I'm using Ubuntu and have set up the toolchain according to this thread:
http://e2e.ti.com/support/microcontrollers/stellaris_arm_cortex-m3_microcontroller/f/471/t/65137.aspx


@Ole:

Thanks, there will be questions for sure :)


Regards,
Philipp