[En-Nut-Discussion] Bitbanging Drivers: Configuration in library or user code

[Harald Kipp]

Hi Uwe,

On 28.09.2012 17:05, Uwe Bonnes wrote:
>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
>     Harald> Hi Uwe, On 28.09.2012 15:39, Uwe Bonnes wrote:
> 
>     >> changed, 31 insertions(+), 61 deletions(-) and got smaller code.
> 
>     Harald> You mean you got smaller code for the AVR when replacing the
>     Harald> macro MMC_MOSI_LO() with GpioPinSetLow()? That's interesting,
> 
> I only taked about source code density, not binary code density. The source
> code reduction comes from the fact that the port clock initialization is
> done by GpioPinConfigSet(). I could take a look at binary code size, as it
> didn't compile for AVR...

OK. I do not expect any binary code reduction.


>     Harald> Today's recommended MMC drivers are based on the bus
>     Harald> model, where the driver is split into the SPI MMC driver and the
>     Harald> SPI bus controller driver. See
> 
>     Harald> http://www.ethernut.de/en/documents/ntn-6_spi.html
> 
> Either we have drivers in a usable state or they are useless....

Without question. Most of them should work fine. I know a few, which
haven't been maintained for a long time and I'm considering to remove them.


> And it is hard so understand the plethora if driver flavours...

That's indeed a big problem, but difficult (if not impossible) to solve.
The old AVR uart driver provides the best performance with minimal code
size, but lacks several features. The AVR usart driver supports almost
everything, but suffers performance. The AVR hdlc provides everything
necessary for PPP, but not more. All of them did not really fit to other
platforms, so we even face changes in the interface, which spoils the
AVR advantage of single bit access.

Recently I tried to get everything done in the right way. This required
a complete new interface to serve all platforms, implemented as
usart_cb.c. It still needs testing and porting. So we finally end up
with 4 uart driver flavors for the AVR.

What's your opinion about solving this?


> I don't want comment of the driver API. I want comment on the way the
> information about Pin/Port is passed to the creation of the interface.

You are quite persistent. ;-) OK, OK! I'll try to have a look and
provide some feedback.


> And while Onewire is very common with house automation projects, NUTOS seems
> to have to such users. 

Definitely. Many of these 1wire products

http://www.hw-group.com/

are based on Nut/OS, for example. But they are using their own drivers
and keep them secret, which is fully acceptable and according to the
license.

Regards,

Harald