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

Harald Kipp harald.kipp at egnite.de
Fri Sep 28 16:21:40 CEST 2012

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.

You mean you got smaller code for the AVR when replacing the macro
MMC_MOSI_LO() with GpioPinSetLow()? That's interesting, because the
porttrans macros are intended to provide the best code density for all
platforms and runtime libraries.

Not sure, whether spending more effort into sbi_mmc.c makes sense.
Today's recommended MMC drivers are based on the bus model, where the
driver is split into the SPI MMC driver and the SPI bus controller
driver. See


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

On the other hand, the SPI bus model may be overkill for applications,
which want to use SPI to read from MMC only. They will probably prefer
the old sbi_mmc.c and benefit from your 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..

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

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

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

>     Harald> In general I have another problem with your latest changes, but
>     Harald> will open up a different thread for this.
> I think it is solved now as some later mail from you implies.

AVR-GCC again compiles without error for all supported boards. I still
have issues with Imagecraft. But they doesn't seem to be related to any
of your changes.



More information about the En-Nut-Discussion mailing list