1. Home
  2. Embedded Programming
  3. GPIO : Reading when configured as O/P

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

Reply to
moogyd
Loading thread data ...

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

Reply to
Jim Granville

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
Reply to
Tim Wescott

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

formatting link

Reply to
Vladimir Vassilevsky

PICs always read the value at the pin.

formatting link

Reply to
Marra

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?
Reply to
Grant Edwards

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.

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

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.

Reply to
Hans-Bernhard Bröker

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.

Reply to
Hans-Bernhard Bröker

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
Reply to
Spehro Pefhany

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.