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

[Ole Reinhardt]

Hi Philipp,

> Thanks again for your great support!
> I finally managed to get my patches into SVN, so you should be able to 
> checkout the latest version for testing. Please note that I did not 
> commit the CMSIS header file because of the damn license. I've instead 
> placed a readme in the folder which contains instructions for how to 
> fetch the file(s) manually.

Thanks! It took me some time, but I got everything together now and
tried to compile the tree.

So here is my experience:

- The user-downloadable header is ok, your introduction is good, but we
  need a suitable solution here :-)


- You have to set the I/O pin configuration for the UART in the
  configurator, there is no pre-defined config set in the .conf file
  yet. If it is not set, the Nut/OS tree would not compile, as the
  cfg/arch/lm3s/lm3s_uart.h file (which is created by the configurator)
  is missing.


In general I would prefer (thats my very personal opinion) if the I/O
pin configuration would not be configurable in the configurator but
would be left up to the user.

In other words: Either it should be implemented in the board file (e.g.
arch/cm3/board/dk_lm3s9b96.c) or it's up to the user to use the GPIO api
(extension) (as discussed during the last weeks) to configure the
alternate function for the UART pins correctly.


> Then the only working example I have is the simple one, which I've 
> modified in such a way to make it blink the user LED on the demo board:

> > Even if you have a network peripheral with integrated PHY, it should be
> > possible to use the generic PHY driver. In this just just add the PHY
> > IDs to the PHY driver.
> 
> Uff, ok, that looks complicated. But it's manageable, especially with 
> your detailed instructions. Thanks!

Yes it is. Better start with some more simple drivers first and try to
follow the Nut/OS concepts as good as possible.

E.g. first try to get the UART driver running before starting with the
next one...

> >> Still working on the UART driver, I got some linker issues as mentioned
> >> in the mail before. When linking this example:
> >> http://ethernut.de/nutwiki/Printing_to_Strings
> >> I get the following output:

I tried compiling with eCross and arm-none-eabi-gcc. Both with the same
result.

The explanation is quite simple (same problem that I had):

Your UART driver (lm3s_uart_common.c) is using some 64 bit divisions in
Lm3sUsartGetSpeed / Lm3sUsartSetSpeed (variable clk64 if type long
long).

GCC creates code which refers to the libgcc library for 64 bit
divisions. Unfortunately this library again refers to the newlib
provided syscalls like abort(), they again refer to other newlib
provided functions as well.

To make a long story short:

Nut/OS does not implement all these syscalls, as they are normally not
needed.

I run into the same problem some time ago. One solution was to implement
stubs for these syscalls, but that triggered even more linking problems.
So I decided to avoid 64 bit divisions at all and you should try to
avoid them as well :-)

It should be fairly simple to restructure your code so that you won't
need to use 64bit integers.

> Ok, so that debugging may get somewhat annoying, right? Do you know of a 
> way to easily track down the function in question? I suppose it has 
> something to do with the printf() stuff. But if so: What to do then?

No, not really. I did a lot of googling but did not find any good
answer. But my research led me to the 64 bit division problematic and
after all I could isolate the problem.


Best regards,

Ole


-- 

Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting

http://www.embedded-it.de

Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen - 
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97

Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280