[En-Nut-Discussion] Portability suggestions

Ralph Mason ralph.mason at telogis.com
Tue Apr 8 00:02:13 CEST 2003


I have mostly ported NutOS to windows and would like to make a couple of
suggestions for future portability. I welcome any suggestions.

1 Use u_int not u_short: This means that things can scale to the size of the
compilers int. Means printf (with %i) keeps working, and expands the range
of the heap functions to the machine size.  I could easily see NutOS running
on a arm or the like.

2. 'Virtualize' Device drivers (this makes sense even if your not porting
it)
By virtualize I mean when you call other driver functions from driver
functions call them through the pointers in the NUTDEVICE structure.

example in uartavr.c function UartAvrPut

rc =  UartAvrFlush(dev)

becomes

rc = ifs->if_flush(dev);

By making these changes I was able to implement another uart driver (for PC
uarts) by providing 3 functions,

UartPCInit,UartExtIOCtl,UartPCOutput (I also was able used the same for a
16550 driver attached to an AVR - three funtions resusing most of the AVR
uart driver)

3. Define a MM_IO macro and use that for all memory mapped IO.  This allows
and emulation of a device to run (by trapping the MM_IO addresses) or a
device with a separate IO space to use the same code.

I suggest

WRITE_MMIO8(address,val)
WRITE_MMIO16(address,val)
WRITE_MMIO32(address,val)

READ_MMIO8(address)
READ_MMIO16(address)
READ_MMIO32(address)

4. Don't use the IOREG = Value ,  Value = IOREG notation (eg  PORTD=0xf0 ;
someval = PORTD ). Use outb, outw, inb & inw.  This allows traping and
emulation.

5. Make the development version Available :-) Doesn't seem like a good use
of time to have many people tracking down and fixing the same bugs!

Also as noted earlier use u_char* when casting to do pointer arithmetic
(rather than u_short)

Cheers
Ralph




More information about the En-Nut-Discussion mailing list