[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