[En-Nut-Discussion] GPIO on the ethernut board 3.1
Ulrich Prinz
uprinz2 at netscape.net
Fri May 7 19:18:06 CEST 2010
Hi!
Am 07.05.2010 02:23, schrieb Eric Haver:
> Hello List,
>
> You can go without double access, on the AT91SAM7 anyway: From the
> detailed manual:
>
> 27.4.5 Synchronous Data Output
>>>
>>> Controlling all parallel busses using several PIOs requires two
>>> successive write operations in the PIO_SODR and PIO_CODR
>>> registers. This may lead to unexpected transient values. The PIO
>>> controller offers a direct control of PIO outputs by single write
>>> access to PIO_ODSR (Output Data Status Register). Only bits
>>> unmasked by PIO_OWSR (Output Write Status Register) are written.
>>> The mask bits in the PIO_OWSR are set by writing to PIO_OWER
>>> (Output Write Enable Register) and cleared by writing to PIO_OWDR
>>> (Output Write Disable Register). After reset, the synchronous
>>> data output is disabled on all the I/O lines as PIO_OWSR resets
>>> at 0x0.
>>>
Thank you for the hint, that was new to me too.
But the discussion started cause of the time needed for doing 2 cycles.
In this case the time needed is only shiftet.
For every access you need to do a setup of the pins to write and another
cycle for writing the pins again. This is especially needed if you have
connected several periphals to one GPIO port. So for the mentioned
display this means:
Set PIO_OWSR to data-bit-mask
Set PIO_ODSR to data-bits
This respect to the LCD driver it doesn't make sense to discuss if an
access needs 2 cycles or 4, as doing it with less cycles only results in
a longer wait loop afterwards.
With the GPIO connected display it is also no problem to have the above
mentioned spikes as the data is fetched from the display on Enable
signal, what is done in a separate cycle after setting up all data GPIOs.
There is only one condition in that you can use the above trick. If
you're using the databus for one or more periphals in exactly the same
way it may work, but this will result in lots of problems if you like to
keep Nut/OS flexible.
I thought about speed optimization of the driver too by bundling Enable
and databus, as you can set them together, but then release Enable
first. But the #if #else #endif orgy was far to large. Without the
conditions we would have lost the option to have Enable, RS and R/W on
different ports.
On the other hand, for fast periphals it is interesting to know the
above trick, here one could argue that speed is needed.
Best regards, Ulrich
More information about the En-Nut-Discussion
mailing list