Building SVN Trunk

View: New views
3 Messages — Rating Filter:   Alert me  

Building SVN Trunk

by Ethernut :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

If someone got some spare time during the weekend, may be he/she can
help and look into the following problems.

While my cross platform script isn't complete, it reports the following
errors:

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.

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)

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)

4. Building Nut/OS libs for GBA fails with
../.././nut/arch/arm/dev/at91_reset.c: In function 'At91Reset':
../.././nut/arch/arm/dev/at91_reset.c:61: error: implicit declaration of
function 'At91WatchDogStart'

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

I assumed I fixed that one by adding the missing defines in irqreg.h.
Unfortunately it doesn't work. I'll investigate this further.

6. Building a debug version of the httpd app fails on all ATmega128
boards with
httpserv.elf section .text will not fit in region text
region text overflowed by 3848 bytes

7. Building nutpiper app for Arthernet fails with

../../arthernet1-avr-gcc-bld/lib\libnutarch.a(ih_int4.o): In function
`__vector_5':
ih_int4.c:(.text+0x108): multiple definition of `__vector_5'
../../arthernet1-avr-gcc-bld/lib\libnutarch.a(irsony.o):irsony.c:(.text+0x40):
first defined here

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'

Note, that 1-7 are GCC, 8 is ICCAVR.

Harald

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Building SVN Trunk

by uprinz :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Harald,

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

But let's jump in:

Harald Kipp schrieb:
> If someone got some spare time during the weekend, may be he/she can
> help and look into the following problems.
>
Nope, but I try my very best, as I am the reason for at least two of the
problems:

> 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.
>
> 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.

> 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.

>
> 4. Building Nut/OS libs for GBA fails with
> ../.././nut/arch/arm/dev/at91_reset.c: In function 'At91Reset':
> ../.././nut/arch/arm/dev/at91_reset.c:61: error: implicit declaration of
> function 'At91WatchDogStart'
>
> 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 assumed I fixed that one by adding the missing defines in irqreg.h.
> Unfortunately it doesn't work. I'll investigate this further.

I don't have a 9260 but only a RM9200, so I cannot check.

>
> 6. Building a debug version of the httpd app fails on all ATmega128
> boards with
> httpserv.elf section .text will not fit in region text
> region text overflowed by 3848 bytes
>
> 7. Building nutpiper app for Arthernet fails with
>
> ../../arthernet1-avr-gcc-bld/lib\libnutarch.a(ih_int4.o): In function
> `__vector_5':
> ih_int4.c:(.text+0x108): multiple definition of `__vector_5'
> ../../arthernet1-avr-gcc-bld/lib\libnutarch.a(irsony.o):irsony.c:(.text+0x40):
> first defined here
>
> 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 don't have ImageCraft and if I read this, I'd think that I don't
like to have it. I only allocate the LEDs descriptor memory and led is a
pointer and malloc returns a pointer...

int NutRegisterLed( HANDLE * ledh, int bank, int pin)
{
     LEDEventT *led;

     /* Check memory constraints and assign memory to new led struct */
285:    led = malloc(sizeof( LEDEventT));
286:    *ledh = (void*)led;
...

For accessing the LEDEvent data, it's handle is casted to LEDEventT. It
works fine here.

Best regards,

Ulrich

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion

Re: Building SVN Trunk

by Ethernut :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion