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

[Uwe Bonnes]

>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

    Harald> Hi Uwe, On 28.09.2012 15:39, Uwe Bonnes wrote:

    Harald> Your latest changes to gpio_avr try to combine both, having the
    Harald> clean code of the runtime API without too much processor
    Harald> overhead.
    >>  Should I go ahead and change the nut/dev code still using porttrans
    >> to the use of the GPIO api?  I tried for nut/dev/sbi_mmc.c | 92
    >> ++++++++++++++++++----------------------------------- 1 files
    >> 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,
    Harald> because the porttrans macros are intended to provide the best
    Harald> code density for all platforms and runtime libraries.

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

    Harald> Not sure, whether spending more effort into sbi_mmc.c makes
    Harald> sense.  

The effort was done for a proof of concept.

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

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

    Harald> As far as I can see, we already have spibus0gpio.c based on the
    Harald> GPIO API.

    Harald> On the other hand, the SPI bus model may be overkill for
    Harald> applications, which want to use SPI to read from MMC only. They
    Harald> will probably prefer the old sbi_mmc.c and benefit from your
    Harald> change.


    >> However I don't know about the status of the GPIO api on Platforms
    >> beside AVR and STM32. And I have no hardware to test..

    Harald> I'm using porttrans.h macros and GpioXXX() functions with AVR
    Harald> and AT91SAM7/9 and I'm able to test almost any platform except
    Harald> STM and AT91SAM3/4.


    Harald> I haven't done anything with 1wire so far, sorry.
    >>  I don't want you to test the code. But I want some feedback about
    >> how the interface is designed.

    Harald> Still better, if someone, who is more familiar with 1wire, will
    Harald> comment on that one.

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.

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

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------