[En-Nut-Discussion] NutGpio Api and Multidrive for AVR
Uwe Bonnes
bon at elektron.ikp.physik.tu-darmstadt.de
Fri Sep 28 13:45:06 CEST 2012
>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:
Ole> Hi Uwe, unfortunately I did not really understand the functionality
Ole> of your enhanced GPIO API functions "NutGpioPinDrive()" and
Ole> "NutGpioPinRelease()"
Ole> Could you explaint them a little more in detail?
>> The last NutGpioPinSetHig makes sure the AVR pullup turns on the
>> internal pullup. For non-AVR architectures, NutGpioPinSetLow(...)
>> and NutGpioPinDrive(...) are empty function in most cases
Ole> Is this just a typo or do you really mean that NutGpioPinSetLow()
Ole> is an empty function in most cases? If so, why?
Ole> I just have concerns that we might have different understanding of
Ole> what the function shall do on different architectures and will just
Ole> prevent to get some incompatibilities there.
As explained, for AVR GPIO port setup and usage are not seperated in the
registers. So there is no (easy(*)) way on AVR to make the sequence
GpioPinConfigSet(PORT, PIN, GPIO_CFG_OUTPUT)
GpioPinSetLow(PORT, PIN)
GpioPinSetHigh(PORT, PIN)
do sbi(DDR(PORT), PIN), cbi(PORT, PIN), sbi(PORT, PIN)
and
GpioPinConfigSet(PORT, PIN, GPIO_CFG_OUTPUT|GPIO_CFG_MULTIDRIVE|GPIO_CFG_PULLUP)
GpioPinSetLow(PORT, PIN)
GpioPinSetHigh(PORT, PIN)
do sbi(DDR(PORT), PIN), cbi(PORT, PIN), cbi(DDR(PORT), PIN) and eventual
additional sbi( PORT, PIN) to activate the PULLUP again.
So I require now to write the sequence like
GpioPinConfigSet(PORT, PIN, GPIO_CFG_OUTPUT|GPIO_CFG_MULTIDRIVE)
GpioPinSetLow(PORT, PIN)
GpioPinSetDrive(PORT, PIN)
GpioPinSetRelease(PORT, PIN)
GpioPinSetHigh(PORT, PIN)
if the code should be portable to AVR too, like in the bitbanging one-wire
bus driver dev/owibus_bbif.c
For any sensible architecture the new commands are defined in the header as
#define GpioPinSetDrive(PORT, PIN)
#define GpioPinSetRelease(PORT, PIN)
so they evaluate empty.
(*) We could carry shadow register to hold the configuration we set up, but
I think that is incredible overhead and memory hog. So the two new commands
are a fair price we pay for compatibility on AVR
Bye
--
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
mailing list