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

[Philipp Burch]

Hi Ole!

On 10/30/2012 02:30 PM, Ole Reinhardt wrote:
> Hi Philipp,
> [...]
>
> Could you perhaps start applying patch by patch to the new branch and
> drop me a line as soon as everything is checked in? I can than start
> testing it on my own board.
>

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.

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:

------ 8< ------- 8< --------
#include <compiler.h>
#include <sys/timer.h>
#include <dev/gpio.h>

/*!
  * \brief Main application routine.
  *
  */
int main(void) {
   GpioPinConfigSet(NUTGPIO_PORTF, 3, GPIO_CFG_OUTPUT);
   GpioPinConfigSet(NUTGPIO_PORTJ, 7, GPIO_CFG_INPUT);

   for (;;) {
     if (GpioPinGet(NUTGPIO_PORTJ, 7)) {
       GpioPinSetHigh(NUTGPIO_PORTF, 3);
       NutSleep(100);
       GpioPinSetLow(NUTGPIO_PORTF, 3);
       NutSleep(200);
     }
   }
   return 0;
}
------ 8< ------- 8< --------


>
>[...]
>
>> I've already planned to write down some of the things I found out on my
>> "journey" for those who come after me. But at the moment, I need to get
>> it working for my board, as the software is a critical part of this project.
>
> If you need any help, please drop me a line!
>

Well, that's what I'm doing all the time, right? ;)

>
> [...]
>
> [... Lots of instructions ...]
>
>
> In most cases you should be able to follow the same driver layout.
>
> 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!

>
>
>> 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:
>>
>> The "multiple definition" errors probably arise because the linker sees
>> nutcrt.a and the compiler's own libc. However, passing -nodefaultlibs
>> and -lgcc does not solve anything, still the same errors.
>>
>> And what really looks strange are the "overlapping sections". I'm
>> diggin' into some articles concerning this at the moment, maybe I'll
>> figure it out. But if you could give me a hint, this would be greatly
>> appreciated ;)
>
> Oh yes, I had the same problem just several times. In most cases you
> have a call to any newlib function included that itself depends on some
> other functions that will use the newlib supplied "syscalls".

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?

>
> For example I stumbled about this problem when trying to use 64bit
> divisions.
>
> I don't have a real idea right now without looking into the code.
>
> If you could first apply your patches to the newly created branch I will
> have a look on it later this day.
>

Feel free to play with the newly populated branch :)

Cheers,
Philipp