[En-Nut-Discussion] Building SVN Trunk

[Harald Kipp]

Hi Ulrich,

Ulrich Prinz wrote:

> Would be a fine thing to have these cross-scripts, so one could check if 
> his code is working for most/all platforms...

You can find the script distcheck.lua in nut/tools/packaging. You need
to configure the paths at the beginning.


>> 1. Building Nut/OS libs for AT91R40008 fails with compiler error,
>> because this CPU has no DBGU device. I fixed this already and will
>> commit the changes ASAP.
> 
> I excluded this CPU at my second implementation of the UART-DBGU 
> extention, but looks like I missed something. I did a new implementation 
> of my idea, as you rewrote the driver and my old version didn't work 
> anymore.

No problem. Adding a HW_DBGU_AT91 requirement in the Configurator
scripts was easy and fixed it immediately.


>> 2. Building the caltime app for AT91EB40A, SAM7S(E)-Generic and
>> AT91SAM7SE-EK fails with
>> caltime.c: In function 'main':
>> caltime.c:340: error: 'devUart0' undeclared (first use in this function)
>>
> I stumbled across one of these in my own software and afaik it was the 
> problem, that you need to include uart.h and not usart.h or vice versa.

Thanks, I'll check this. It still makes me wondering that it fails on
that platform only.


> 
>> 3. Building the ftpd app fails for SAM7S(E)-Generic and STK501 fails with
>> ftpserv.c: In function 'InitEthernetDevice':
>> ftpserv.c:359: error: 'devEth0' undeclared (first use in this function)
> 
> That one happened to me when I tried http example to test something last 
> week at work. Unfortunately the code is still at work and the machine is 
> off. So I cannot access it from here now to look what I changed to make 
> it work.

These targets do not have any Ethernet interface. But as the samples are
included in the global nut/app/Makefile, they should at least compile.


>> 5. Building Nut/OS libs for AT91SAM9260-EK fails with
>> ../.././nut/arch/arm/dev/usartat91.c: In function 'At91UsartInit':
>> ../.././nut/arch/arm/dev/usartat91.c:1409: error: 'SYSC_ID' undeclared
>> (first use in this function)
>> ../.././nut/arch/arm/dev/usartat91.c:1409: error: (Each undeclared
>> identifier is reported only once
>> ../.././nut/arch/arm/dev/usartat91.c:1409: error: for each function it
>> appears in.)
>> ../.././nut/arch/arm/dev/usartat91.c: In function 'At91UsartDeinit':
>> ../.././nut/arch/arm/dev/usartat91.c:1459: error: 'SYSC_ID' undeclared
>> (first use in this function)
>> make[1]: *** [arm/dev/usartDat91.o] Error 1
>>
> My fault, I assumed, that, as SAM7 and SM9 is handled mostly identical, 
> both ARMs habe same way of DBGU handling. I read a bit more into that 
> and correct it.

I had the same view and found, that the SYS interrupt definitions were
missing in the header file for the ARM9. After adding them, it still
didn't work. I do not think it is a problem of your code, but of the
header files.



>> 8. Building Nut/OS libs for AVR using ImageCraft fails with
>> !E C:\ethernut\ethernut-4.9.7\nut\dev\led.c(285): operands of = have
>> illegal types `pointer to LEDEventT' and `int'

I look to your code and couldn't find any problems either. After
re-arranging the header files it finally works. In the past there had
been problems with the ImageCraft linker when using standard names for
system routines like malloc. So they are re-defined to malloc_N etc.
Unfortunately this requires a specific order of header file appearance.
In most cases it works fine using lower level headers like dev/foo.h
first and high level header files like stdlib.h last. Very nasty.


> ?? I don't have ImageCraft and if I read this, I'd think that I don't 
> like to have it.

You are the developer, I'm the release guy. You write the code, I'll
check the supported platforms and targets. If it fails, I complain to
all developers (including me). If it doesn't get fixed, I'll remove the
code from the release. I won't expect developers checking all variants.

One great advantage of ImageCraft is its target support. For a long time
Richard provided the only compiler, that created stable Nut/OS binaries
for the ATmega256. GCC for AVR was working for this MCU after some
delay. Last time I tried GCC (4.3 if I remember correctly) binaries
failed again.

ImageCraft further helps to keep our code adaptable. GCC and Newlib are
not available everywhere. Btw. it is also planned to add CrossWorks for
ARM soon. It is essentially GCC, but requires some work on runtime
initialization and linking. Also the libraries differ: They don't have
strcasecmp built in, can you believe that? Shall we ignore this
excellent IDE and the exceptional user support just because it is not
GCC/Newlib conform?

Harald