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

Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Fri Sep 28 17:05:32 CEST 2012

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

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

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

More information about the En-Nut-Discussion mailing list