[En-Nut-Discussion] Device independent bitbang drivers should use the device independent GPIO API.

[Harald Kipp]

Thiago A. Corrêa wrote:

> Isn't SPI just "yet another serial port"? 

Not at all, it's a peripheral bus in the first place, which is shared
among several devices. When uninterrupted bit banging is used, the
difference doesn't matter. When using interrupts or DMA (AT91 PDC),
you'll get a lot of trouble if you don't take bus sharing into account.

Furthermore the bus controller driver has to take care, that each bus
device is addressed with the right mode and speed.


> I'm totally lost on the filesystem implementations so far, except for urom :P
> Perhaps as I work in ethernut internals with the AVR32 port this will
> be clearer later :)

My be, may be not. As Ole pointed out lately, this is a whole mess. (May
be he did it by private email to avoid bashing my reputation.) But it
works. And, as we have a device independent SPI and Block I/O framework,
we can go ahead and clean up that beast.

> I've been toying in my head with the idea of a zlib filesystem, or
> some compressed filesystem.

We will definitely need compression libs in the near future. I'm working
on a graphic lib and so far I can only display uncompressed bitmaps.


> Well, a clever compiler might inline the calls for the GPIO at least.

AFAIK, only local static routines are inlined. On the AVR the situation
is again different. This CPU has got instruction for setting and
clearing single I/O register bits in a single cycle. Usually 3 cycles
are required, read, modify, write. The compiler can only generate these
instructions, if the port address is a constant.


> No problem from here at least. I was only waiting for the release to
> commit of the discovery protocol thing, because it might cause
> problems for someone. Other than that, I've been working on the AVR32
> port in a different repository for the time being. Will merge later
> when it is less ugly and all :P

Yes, I'm aware and will try to limit further modifications. One thing,
however, I may modify in a number of files: Replacing several if()
statements by NUTASSERT() macros. This way the sanity checks can be done
in a more extensive way for better problem tracing, and they will reduce
the final production code size.

Harald