[En-Nut-Discussion] Good grief, GPIO again! (was Re: Why not change from Nut/OS to BeRTOS)
bon at elektron.ikp.physik.tu-darmstadt.de
Tue Jun 11 14:35:02 CEST 2013
>>>>> "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
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> #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.
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
Files affected :
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:
All flawed AVR Gpio work reverted as with r5194 now.
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