[En-Nut-Discussion] Portability suggestions

[Harald Kipp]

Ralph,

Many thanks for your 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.

For optimized code we should additionally define
a new type, which got the size of the CPU register,
but is limited to 0...255.



>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)

I already tried to do so. Most functions not following
this rule are deprecated already.



>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)

As I wrote in a previous email, I do not like to redefine
exisiting macros or functions. But this is a good point.



>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.

Oops, good point too. I already switched from outx to reg=,
because it's easier to read and most common in the embedded
world. But now I see the problem and will switch back.



>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!

Creating a public CVS repository is on top of my list. It's a
problem of lack of time right now.

In the past this would have caused additional problems, because
Nut/OS has undergone major changes, like integration of stdio.
Such tasks are difficult to divide and require some time without
new releases. PPP is hopefully the last big part for a while.
I also specified a recommended code formatting recently. It's
mainly 'indent -kr -nut' and I recently added option '-l132'.
People, who are not familiar with indent, please have a look
at http://www.gnu.org/software/indent/indent.html. You can
use this tool, to format the code to your preference and reformat
it before sending it to egnite.

In the meantime the situation changed, as more and more people
are contributing. My small company is already swamped (correct
term?) with implementing and testing all the changes. Linux
users can tell.

On the other hand, every time we offered a prerelease, we
received almost no response from the testers. But, I guess,
this requires more patience. :-)


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

I'm aware.

Harald