[En-Nut-Discussion] Bitbanging Drivers: Configuration in library or user code
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
>> 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
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
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
>> 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