[En-Nut-Discussion] Porting to other platforms

Harald Kipp harald.kipp at egnite.de
Thu Jul 3 11:22:31 CEST 2003


>
>One thing i've noticed so far is the casting of pointers to u_shorts in
>heap.c and thread.c , this is OK if pointers are 16 bit as on the AVR but
>does not work so well on the H8 or the ARM.
>
>I'm just casting them to u_ints instead which at a guess should be a more
>portable way to do things.

IMHO u_int is a good solution. I'd also like to introduce a new
type for loop counters 0..255. Using u_char is nice for 8-bit
machines but bad for larger CPUs. u_int is nice for 16-bit and
above, but bad for 8-bitters.


>One thing to think about, should there be a different variant of thread.c
>and atom.h (and any others I havn't discovered yet) for each processor or
>should there be one difficult to read version with countless #ifdefs ?

I'd vote for splitting the files even futher. May be we can
remove hardware dependencies from thread.c and create libraries
in arch/avr, arch/arm etc. If these libraries are kept small,
porting would be easier in general. If I remember correctly, uCOS
is using this scheme and others may use it too.

Harald




More information about the En-Nut-Discussion mailing list