GPIO : Reading when configured as O/P

Hi,

I am currenly integrating an 8051 soft core into our ASIC and we have
a number of GPIO ports (which are placed in the bit addressable SFR
space).

When a bit of the GPIO port is configured as an O/P
1 - Any write to the bit appears on the pin (obviously)
2 - A read of the bit returns the current value *at the pin*

Item (2) seemed to make perfect sense when performing the design (and
is how the PIC works), but now I have a doubt,  and would like to
solicit the opinion of embedded engineers which a wide breadth of H/W
and S/W.

Q : When reading a GPIO bit configured as an O/P, should I return the
value on the pin, or the value in the register?

In theory, these shoud be the same.
However, I had a discussion with a collegue who had a bug caused by
the current implementation (in a PIC based system). The GPIO pad was
low current drive, and very heavily loaded, giving a very long rise
time. The S/W was perfoming a write ('1') to this bit, and then to
another bit in the GPIO port via a RMW (which is bit addressable
registers are implemented in 8051). The RMW was performed before the
first bit had reached a '1', therefore the next write cleared this
bit.
i.e.
  SETB GPIO_0  ; // Set BIT0. This is very heavily loaded O/P
  SETB GPIO_1 ; // Implemented in H/W as RMW. Occurrs before bit 0 has
reached High, therefore
                          // after ths instruction Bit 0 = 0, Bit 1 =
1

The alternative solution would solve this problem (it would return the
data that *should* be on the register). However, I am not sure I like
this solution from a purely philisophical point of view i.e. Reading
GPIO should return the *actual* value, not the *expected* value.

Opinions/Comments/Suggestions welcome.

Thanks,

Steven

moogyd@yahoo.co.uk wrote:
> Hi,
> 
> I am currenly integrating an 8051 soft core into our ASIC and we have
> a number of GPIO ports (which are placed in the bit addressable SFR
> space).
> 
> When a bit of the GPIO port is configured as an O/P
> 1 - Any write to the bit appears on the pin (obviously)
> 2 - A read of the bit returns the current value *at the pin*
> 
> Item (2) seemed to make perfect sense when performing the design (and
> is how the PIC works), but now I have a doubt,  and would like to
> solicit the opinion of embedded engineers which a wide breadth of H/W
> and S/W.
> 
> Q : When reading a GPIO bit configured as an O/P, should I return the
> value on the pin, or the value in the register?
> 
> In theory, these shoud be the same.
> However, I had a discussion with a collegue who had a bug caused by
> the current implementation (in a PIC based system). The GPIO pad was
> low current drive, and very heavily loaded, giving a very long rise
> time. The S/W was perfoming a write ('1') to this bit, and then to
> another bit in the GPIO port via a RMW (which is bit addressable
> registers are implemented in 8051). The RMW was performed before the
> first bit had reached a '1', therefore the next write cleared this
> bit.
> i.e.
>   SETB GPIO_0  ; // Set BIT0. This is very heavily loaded O/P
>   SETB GPIO_1 ; // Implemented in H/W as RMW. Occurrs before bit 0 has
> reached High, therefore
>                           // after ths instruction Bit 0 = 0, Bit 1 =
> 1
> 
> The alternative solution would solve this problem (it would return the
> data that *should* be on the register). However, I am not sure I like
> this solution from a purely philisophical point of view i.e. Reading
> GPIO should return the *actual* value, not the *expected* value.
> 
> Opinions/Comments/Suggestions welcome.

The 8051 data explains which opcodes read the pin, and which read the 
register.

Some ASIC implementations have TWO SFR mappings, one for the PIN, and 
one for the OP Drive Register. Costs a little more decode space,
but you DO know what will happen in all cases.

When using Open drain-Bidirectional Protocols (like i2c) it is important 
to be able to read the PIN level.

Reading the Pin can have a downside, when a port is shared by multiple 
code blocks, or Peripheral HW, and care is not taken.

-jg

On Sat, 13 Oct 2007 19:44:53 +1300, Jim Granville wrote:

> moogyd@yahoo.co.uk wrote:
>> Hi,
>> 
>> I am currenly integrating an 8051 soft core into our ASIC and we have
>> a number of GPIO ports (which are placed in the bit addressable SFR
>> space).
>> 
>> When a bit of the GPIO port is configured as an O/P
>> 1 - Any write to the bit appears on the pin (obviously)
>> 2 - A read of the bit returns the current value *at the pin*
>> 
>> Item (2) seemed to make perfect sense when performing the design (and
>> is how the PIC works), but now I have a doubt,  and would like to
>> solicit the opinion of embedded engineers which a wide breadth of H/W
>> and S/W.
>> 
>> Q : When reading a GPIO bit configured as an O/P, should I return the
>> value on the pin, or the value in the register?
>> 
>> In theory, these shoud be the same.
>> However, I had a discussion with a collegue who had a bug caused by
>> the current implementation (in a PIC based system). The GPIO pad was
>> low current drive, and very heavily loaded, giving a very long rise
>> time. The S/W was perfoming a write ('1') to this bit, and then to
>> another bit in the GPIO port via a RMW (which is bit addressable
>> registers are implemented in 8051). The RMW was performed before the
>> first bit had reached a '1', therefore the next write cleared this
>> bit.
>> i.e.
>>   SETB GPIO_0  ; // Set BIT0. This is very heavily loaded O/P
>>   SETB GPIO_1 ; // Implemented in H/W as RMW. Occurrs before bit 0 has
>> reached High, therefore
>>                           // after ths instruction Bit 0 = 0, Bit 1 =
>> 1
>> 
>> The alternative solution would solve this problem (it would return the
>> data that *should* be on the register). However, I am not sure I like
>> this solution from a purely philisophical point of view i.e. Reading
>> GPIO should return the *actual* value, not the *expected* value.
>> 
>> Opinions/Comments/Suggestions welcome.
> 
> The 8051 data explains which opcodes read the pin, and which read the 
> register.
> 
> Some ASIC implementations have TWO SFR mappings, one for the PIN, and 
> one for the OP Drive Register. Costs a little more decode space,
> but you DO know what will happen in all cases.
> 
> When using Open drain-Bidirectional Protocols (like i2c) it is important 
> to be able to read the PIN level.
> 
> Reading the Pin can have a downside, when a port is shared by multiple 
> code blocks, or Peripheral HW, and care is not taken.
> 
> -jg

This is just about what I was going to say -- it's also what Motorola did
on the 68HC11 back when I was using it.

-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Tim Wescott wrote:

>>>Q : When reading a GPIO bit configured as an O/P, should I return the
>>>value on the pin, or the value in the register?
>>>
>>The 8051 data explains which opcodes read the pin, and which read the 
>>register.
>>
>>Some ASIC implementations have TWO SFR mappings, one for the PIN, and 
>>one for the OP Drive Register. Costs a little more decode space,
>>but you DO know what will happen in all cases.
>>
>>When using Open drain-Bidirectional Protocols (like i2c) it is important 
>>to be able to read the PIN level.
>>
>>Reading the Pin can have a downside, when a port is shared by multiple 
>>code blocks, or Peripheral HW, and care is not taken.
>>
> 
> This is just about what I was going to say -- it's also what Motorola did
> on the 68HC11 back when I was using it.

On the modern MCUs, there could be more then 10 different configuration 
and latch registers per every GPIO port. In the 99% of occasions I would 
be perfectly happy if I can set a port to a value and if I can read a 
value of the pins from a port. There are few rare cases where it could 
be handy to read latches and pins separately; however one can always 
find some other way around that. Those extra registers are only a 
hassle; you have to read the datasheets to configure it properly.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On 13 Oct, 06:56, moo...@yahoo.co.uk wrote:
> Hi,
>
> I am currenly integrating an 8051 soft core into our ASIC and we have
> a number of GPIO ports (which are placed in the bit addressable SFR
> space).
>
> When a bit of the GPIO port is configured as an O/P
> 1 - Any write to the bit appears on the pin (obviously)
> 2 - A read of the bit returns the current value *at the pin*
>
> Item (2) seemed to make perfect sense when performing the design (and
> is how the PIC works), but now I have a doubt,  and would like to
> solicit the opinion of embedded engineers which a wide breadth of H/W
> and S/W.
>
> Q : When reading a GPIO bit configured as an O/P, should I return the
> value on the pin, or the value in the register?
>
> In theory, these shoud be the same.
> However, I had a discussion with a collegue who had a bug caused by
> the current implementation (in a PIC based system). The GPIO pad was
> low current drive, and very heavily loaded, giving a very long rise
> time. The S/W was perfoming a write ('1') to this bit, and then to
> another bit in the GPIO port via a RMW (which is bit addressable
> registers are implemented in 8051). The RMW was performed before the
> first bit had reached a '1', therefore the next write cleared this
> bit.
> i.e.
>   SETB GPIO_0  ; // Set BIT0. This is very heavily loaded O/P
>   SETB GPIO_1 ; // Implemented in H/W as RMW. Occurrs before bit 0 has
> reached High, therefore
>                           // after ths instruction Bit 0 = 0, Bit 1 =
> 1
>
> The alternative solution would solve this problem (it would return the
> data that *should* be on the register). However, I am not sure I like
> this solution from a purely philisophical point of view i.e. Reading
> GPIO should return the *actual* value, not the *expected* value.
>
> Opinions/Comments/Suggestions welcome.
>
> Thanks,
>
> Steven

PICs always read the value at the pin.

http://www.ckp-railways.talktalk.net/pcbcad21.htm

On 2007-10-13, moogyd@yahoo.co.uk <moogyd@yahoo.co.uk> wrote:

> Q : When reading a GPIO bit configured as an O/P, should I
>     return the value on the pin, or the value in the register?

That depends on whether you want to know the value on the pin
or the value in the register. 

If you want to know the value on the pin, then return the value
on the pin.  If you want to know the value in the register,
return the value in the register.

-- 
Grant Edwards                   grante             Yow!  What's the MATTER
                                  at               Sid?... Is your BEVERAGE
                               visi.com            unsatisfactory?

moogyd@yahoo.co.uk wrote:

> I am currenly integrating an 8051 soft core into our ASIC and we have
> a number of GPIO ports (which are placed in the bit addressable SFR
> space).
> 
> When a bit of the GPIO port is configured as an O/P

Hold it right there.  As long as we're talking about 8051s, there's no 
such thing as "configuring a port as an output".  So unless you have 
good reason to construct an approximation that's fundamentally different 
from ordinary 8051s, I would have to strongly suggest you stick with the 
usual 8051 behaviour.

> Q : When reading a GPIO bit configured as an O/P, should I return the
> value on the pin, or the value in the register?

If you don't feel bound to traditional behavior of the 8051 at all, do 
whatever floats your boat.

> The RMW was performed before the
> first bit had reached a '1', therefore the next write cleared this
> bit.

> The alternative solution would solve this problem (it would return the
> data that *should* be on the register). However, I am not sure I like
> this solution from a purely philisophical point of view i.e. Reading
> GPIO should return the *actual* value, not the *expected* value.

The clue here is that RMW operations can be designed to behave 
differently than actual reads.  I.e. it can very well make sense to have 
RMW opcodes read the latch, while proper reads access the pin.

Spehro Pefhany wrote:

> That might be "interesting" in a soft core. 

Sure.  But that would be the same use of "interesting" as in the Chinese 
curse "May you live in interesting times".

The advantages of choosing a well-known CPU architecture for a soft-core 
would be diminished by such incompatibilities.

On Sun, 14 Oct 2007 13:27:30 +0200, the renowned Hans-Bernhard Br�ker
<HBBroeker@t-online.de> wrote:

>moogyd@yahoo.co.uk wrote:
>
>> I am currenly integrating an 8051 soft core into our ASIC and we have
>> a number of GPIO ports (which are placed in the bit addressable SFR
>> space).
>> 
>> When a bit of the GPIO port is configured as an O/P
>
>Hold it right there.  As long as we're talking about 8051s, there's no 
>such thing as "configuring a port as an output".  So unless you have 
>good reason to construct an approximation that's fundamentally different 
>from ordinary 8051s, I would have to strongly suggest you stick with the 
>usual 8051 behaviour.

That might be "interesting" in a soft core. 


Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com