[En-Nut-Discussion] Supporting Other Target Platforms
Mike Cornelius
mikec at call-direct.com.au
Mon Feb 2 23:45:10 CET 2004
Jan Wrote:-
>>Please look at http://www.kpitgnutools.com - you can find there Linux
>>and Windows gcc binaries for H8/300H and SuperH MCU families. In order
>>to download them you have to create an account first.
Harald Wrote:-
>Any good reason, why to prefer this one?
Jan got in before me but I will second his sugestion.
This is the toolchain I used when I ported Nut/OS to the H8 so the first
reason to prefer it is that it's know to work, it installed without any
trouble and I was up and running in only a few minutes.
Secondly it's very well supported, KPIT are activly maintaining this
release.
Thirdly it is compatible with the HEW IDE which may be useful to some
people.
Regards,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
Mike Cornelius Internet: mikec at call-direct.com.au
Call Direct Cellular Solutions Phone: +61 2 9209-4259
Suite 145 FAX: +61 2 9209-4196
National Innovation Centre URL: http://www.call-direct.com.au
Australian Technology Park
Eveleigh NSW 1430
Australia
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
-----Original Message-----
From: en-nut-discussion-bounces at egnite.de
[mailto:en-nut-discussion-bounces at egnite.de] On Behalf Of Harald Kipp
Sent: Monday, February 02, 2004 9:44 PM
To: Ethernut User Chat (English)
Subject: Re: [En-Nut-Discussion] Supporting Other Target Platforms
Hi Jan and others,
At 03:15 02.02.2004 +0100, you wrote:
>On Sun, 01 Feb 2004 20:38:17 +0100, Harald Kipp <harald.kipp at egnite.de>
>wrote:
> > Hi,
> >
> > Some files in CVS had been split by CPU families:
> >
> > os/timer.c: tmr_arm.c tmr_avr.c tmr_h8.c tmr_m68k.c
> > os/thread.c: ctx_arm.c ctx_avr.c ctx_h8.c ctx_m68k.c
>IMO there should be created "arch" directory with MCU/CPU dependent
>subdirectories in it - please look at arch directory in the Linux
>kernel sources as an example. Then the above files should be moved to
>appropriate subdirectories. So finally there should be two eg. timer.c
>files: first under "os" directory which should contain hardware
>independent functions and the second under eg. "arch/h8300" with
>hardware dependent
Frankly, most posters vote for the structure used
with Linux, but without actually pointing to any
advantage. Btw. "standard" is often a weak argument,
IMO.
>stuff. Next, IMO it isn't elegant using
>#if defined(__AVR_ATmega128__) || defined(__AVR_ATmega103__) #include
>"tmr_avr.c" #elif defined(__arm__)
>#include "tmr_arm.c"
>#elif defined(__H8300__)
>#include "tmr_h8.c"
>#elif defined(__m68k__)
>#include "tmr_m68k.c"
>#endif
>IMO better solution is to compile all hardware dependent files
>separately and consolidate them into one library, let's say libarch.a.
No, it isn't elegant but proofed in dev/usart.c
to produce the least duplicate code.
On the other hand, creating hardware dependant
libraries simplifies the make process configuration.
>We should also take into account that different devices can be build on
>the same MCU/CPU, eg. there are different EVBs for H8/3068F.
>
>[.....]
> > Other candidates are
> >
> > 1. Atomic functions
> > 2. Enter/Exit critical functions
> > 3. Checksum calculation
> > 4. Interrupt stuff
>5. os/nutinit.c
>6. Serial port stuf (initialization, enabling/disabling and control) 7.
>EEPROM stuff - AFAIK avr-gcc and Imagecraft do supply library with
> appropriate functions, H8 gcc doesn't
OK.
> > I have currently now idea, wich compilers I should
> > chose in the first place for ARM7TDMI, H8/300 or Coldfire.
>Of course gcc. ;-) At least for H8/300H.
As far as I found out, almost all ARM compilers are
GCC. But there seem to be different binary distributions,
at least for the Win32 platform. For most Linux flavors building the
toolchain is simple. But on Windows this might be a pain.
> > Linux seems to be no big problem.
> > Can anybody recommend any pre-build binaries for Win32?
>Please look at http://www.kpitgnutools.com - you can find there Linux
>and Windows gcc binaries for H8/300H and SuperH MCU families. In order
>to download them you have to create an account first.
Any good reason, why to prefer this one?
Thanks,
Harald
_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo.cgi/en-nut-discussion
More information about the En-Nut-Discussion
mailing list