[En-Nut-Discussion] Good grief, GPIO again! (was Re: Why not change from Nut/OS to BeRTOS)

[Uwe Bonnes]

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

    Harald> Hi Uwe, Note all, that I'm not upset about introducing bugs,
    Harald> that's part of the development process. But I'm quite upset
    Harald> about breaking a working code and then don't care about for
    Harald> months.

I regulary test on AVR with the hardware available here. However none of it
uses a driver using the construct in question. So it's hard to notice for me.
As I diddn't hear screams, I thought everything was alright. So I am more
upset about the minimal user base we have...

    >> I see that those definitions come from cfg/arch/avr.h. I never
    >> expected some GPIO definitions in that location and none of the
    >> examples in the app directory used GPIOx_ID, so I never stepped on
    >> that problem.

    Harald> Well, initially they come from the Configurator and we have to
    Harald> make sure, that either existing configurations are
    Harald> maintained. Or worse, give up backward compatibility and modify
    Harald> all existing configurations.


    >> Could you please try appended include/arch/avr.h? This should base
    >> all AVR GPIO acces to the new scheme.

    Harald> I'd have tested this, if it would provide a general
    Harald> solution. But it doesn't, for at least two reasons:


    Harald> 1. #define NUTGPIO_PORTA _SFR_IO_ADDR(PORTA) introduces a
    Harald> dependency on avr-libc. Although avr-libc is the first choice
    Harald> for 8-bit AVRs, I do not like to _needlessly_ add new
    Harald> dependencies. Anyway, this is a minor issue and can be
    Harald> solved. And, pleeeease, it should be solved.


    Harald> 2. Consider this

    Harald> GpioPinGet(AVRPORTF, 0);

    Harald> on an ATmega128, which translates to

    Harald> #define AVRPORTF PIOF_ID

    Harald> and with your new include/cfg/arch/avr.h to

    Harald> #define PIOF_ID NUTGPIO_PORTF

    Harald> and the final address

    Harald> #define NUTGPIO_PORTF _SFR_IO_ADDR(PORTF)

    Harald> which is at 0x62. Now

    Harald> #define GpioPinGet(bank, bit) (AVR_PINX(bank) & _BV(bit))

    Harald> and

    Harald> #define AVR_PINX(bank) (_SFR_IO8(bank -2))

    Harald> will result in

    Harald> _SFR_IO8(0x60) & _BV(0)

    Harald> But that's plainly wrong!

    Harald> PINF is at 0x20 (I/O address 0), while 0x60 (not an I/O address)
    Harald> is a reserved register.

Arg!!!!!!

PINF is at 0x20  while PORTF is at 0x62.

You found the place where Atmel violated the never explicit stated order of
PIN/PORT/DDR used nearly everywhere else! I looked at several datasheets but
didn't find that exception. So the approach is flawed.

I will restore the old situation from Sep 24 and try to come up with another
solution.

Files affected :
 nut/arch/avr/dev/gpio_avr.c
 nut/include/dev/gpio.h

In gpio_avr.c no other work outside the approach above has been done.  In
nut/include/dev/gpio.h the only surviving change is:
+#elif defined(__m68k__)
+#include <arch/m68k/gpio.h>

All flawed AVR Gpio work reverted as with r5194 now.

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

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