[En-Nut-Discussion] Bit banging drivers broken?
bon at elektron.ikp.physik.tu-darmstadt.de
Fri Oct 5 18:12:23 CEST 2012
>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
Harald> Hi Uwe, On 05.10.2012 15:35, Uwe Bonnes wrote:
>> And inventing a new name is hard, should it be e.g. sbi_newgpio.h? So
>> perhaps lets make in the nut/dev directory a subdirectory
>> incomplete_gpio and move the old files there. Every occurancy of the
>> driver in the configurator is changed form <driver_name.c> to
>> incomplete_gpio/<driver_name.c>. If an architecture now implments the
>> complete NutGpio Api, we change back incomplete_gpio/<driver_name.c>
>> to <driver_name.c>.
Harald> OK, I understood that.
Is this a "go" for the incomplete_gpio/<driver_name.c> approach?
Harald> Please note, that other developers (like me) have existing
Harald> applications, which will break.
>> I don't see where such a setup breaks applications.
Harald> As long as no change is required in app/tcps.c, app/portdio.c
Does app/tcps.c work reliable on any architecture that has the need to
enable a port clock, like at91sam7, STM32 or LPC? There is no call to
GpioPinConfig, so the port clock is not switched on. _Maybe_ something else
did the initialization before, but no guarantee.
app/portdio.c carries the arch/board specific cruft that should be
avoided. board.h should define generic values like LEDX_PORT ans LEDX_PIN
It also carries hard coded values, as
#if defined(ETHERNUT1) || defined(ETHERNUT2)
#define INBANK 2 /* PORTB */
which should be
#define INBANK NUTGPIO_PORTB /* PORTB */
on platforms with "incomplete" Gpio API.
Harald> then existing applications should survive this change.
Why does http://www.ethernut.de/nutwiki/Generic_Port_Access do board
specific stuff. The example only works on Ethernut1-3.
Otherwise "no change is required" (famous last words ...)
Harald> Btw. are you aware of
Harald> This had been done by Ulrich Prinz (and partly by Thiago Correa)
Harald> more than 2 years ago.
How can I write access the document? There are flaw that I want to point
out and maybe introduce more considerations.
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