[En-Nut-Discussion] Supporting Other Target Platforms

[Harald Kipp]

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