• State Resolved
  • Locked Locked
  • Replies 27 replies
  • Subscribers 33 subscribers
  • Views 2165 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Is separate GPIO read register not required in TM4C123GH6PM

VT
Genius 3300 points
Other Parts Discussed in Thread: TM4C123GH6PM

Many MCU have different read(input) & write(output) register for GPIO. Like PIC have LAT & PORT register. So whenever you have to write to pin in PIC, you write to LAT & to read you read PORT register.

Advantage of this is suppose I have a high capacitive load connected, if I write PORT register & read back to invert pin, then it may read as zero. 

Even in many ARM MCU I found different read & write register. But in TM4c123gh6pm there is only GPIODATA register.

  • 0
    TI__Guru**** 244400 points

    Hello VT

    Vindhyachal Takniki said:
    Advantage of this is suppose I have a high capacitive load connected, if I write PORT register & read back to invert pin, then it may read as zero. 

    Please explain how?

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Guru 10570 points
    Amit, it means there a separate register holding what is on the drivers and another reading the level after the drivers. It may be useful in the case where there is a heavy load on the pins that doesn't actually destroy the driver.

    Assuming that the read returns the state of the pin rather than the driver then the driver state register is unnecessary or at least easily replaced.

    Robert
  • 0 in reply to Robert Adsett72
    TI__Guru**** 244400 points
    Hello Robert,

    I don't think that the poster implied the same.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Genius 3300 points
    Hi Amit,

    Consider you have a heavy capacitive load connected. Now you write pin high. If you read back pin at once, it may read as zero, as due to capacitive load pin may not get high in that time.
    That's why a separate read & write register is provided(I think MSP430 has separate register).
  • 0 in reply to VT
    TI__Guru**** 244400 points
    Hello VT,

    Robert also mentioned the same thing, so I guess we are all on the same page. Right now we are not changing the behavior of the GPIODATA register. So a read back may have to be delayed.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 27665 points
    Umm, I think you have it backwards Amit.

    Reading the register returns the state of the driver not the pin for an output according to the documentation I have. Delaying the read won't make any difference.

    Robert
  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points

    Hello Robert

    Vindhyachal Takniki said:
    Advantage of this is suppose I have a high capacitive load connected, if I write PORT register & read back to invert pin, then it may read as zero.

    The poster wants to invert the signal when it is not yet risen high. So effectively the pin state continues to be low.

    Robert Adsett said:
    Assuming that the read returns the state of the pin rather than the driver then the driver state register is unnecessary or at least easily replaced.

    Right now it returns the state of the pin. So unless the high load causes the delay in the rise/fall of a signal, then it may be useful to wait for the signal to be at the correct level.

    Regards

    Amit

  • 0 in reply to Amit Ashara
    Guru 27665 points

    Amit, From the manual (emphasis mine)

    "A read from GPIODATA returns the last bit value written if the respective pins are configured as

    outputs, or it returns the value on the corresponding input pin when these are configured as inputs."

    Delaying readback would not make a difference, it is reading the state of the driver not the pin according to the manual.

    Robert

  • 0 in reply to Robert Adsett
    Guru 47900 points

    Seems like famed, "Keystone Kops" must "return to the scene!"   Right here - right now!

    Robert - do look (more) closely at your writing:

    "read from GPIODATA returns the last bit value written if the respective pins are configured as outputs, or it returns the value on the corresponding input pin when these are configured as inputs."

    I believe that Amit is considering the case where the pin in question is switched from OUTPUT to INPUT - and then read!   As this returns the pin's value - the delay Amit includes does provide time for the (external) level upon the GPIO pin to settle.

    Devil in the detail - technically this reporter sides w/Amit...

  • 0 in reply to cb1
    Guru 27665 points
    Ah-yup.

    Although the manual does appear clear to me. Could be wrong though, it wouldn't be the first time that's happened in this industry.

    Robert
  • 0 in reply to cb1
    Guru 27665 points

    cb1- said:
    I believe that Amit is considering the case where the pin in question is switched from OUTPUT to INPUT - and then read!  

    Umm, OK. But I don't see that suggested anywhere in the posters writing.

    Robert

  • 0 in reply to Robert Adsett
    Guru 47900 points

    I made no case for poster's protest - I was attempting to better convey Amit's position vs. the manual's writing.

    As you note - manual could have been clearer - and having such "dual register treatment for each GPIO pin" does provide (some) advantages - some of the time. When such is of (great) concern - believe staff/I would prefer several such "input pin reads" made sequentially.  (to insure that a logic based decision is not made prematurely - perhaps upon a "glitch" - it is said that, "haste makes waste!")
     
    Switching such GPIO from output to input (to enable a proper read) may not always prove best/brightest.   In such case my firm would tie that GPIO to another - w/that 2nd GPIO "reserved" for "Input" operation only - and it could be read (as desired) w/out any re-purposing...

  • 0 in reply to Robert Adsett
    TI__Guru**** 244400 points
    Hello Robert

    Yes, you are right. In case of TM4C devices it is the Data register and not the Pin which is read when in output mode. Had the connection been made to the output of the driver or a separate register given to read the output of the driver, it would have reflected the correct state of the pin under heavy load.

    Regards
    Amit
  • 0 in reply to cb1
    Guru 27665 points
    In most cases switching the output from driven to floating would cause the circuit to fail I think. Or at least become unstable.

    There are open collector cases where that might make sense, if the driven circuit somehow latched. Either having a separate pin state readback register or having the readback always return the pin state rather than the driver state will work in the case where you need to verify the pin state, otherwise you need to dedicate an extra pin to the task (the driver state is trivial to keep track of).

    Actually, I think the manual is quite clear on the subject. It could be expanded but it's not obtuse.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points
    I can identify several cases where there exist advantages to implementing the GPIO in this (TM4C) manner. I don't believe (any) single method can prove "best/brightest" for (all) possible conditions.

    Reading the pin's state - directly - as poster notes/desires - may provide an advantage (saves the toggle from output to input) yet basing any decision upon a "single such read" subjects the operation to failure under "unstable" conditions.

    Believe that when one "really has to know" - - several such reads - while maintaining the original output drive state - proves closest to best & safest method... Manual avoids such statement w/famed, "ten foot pole."
  • 0 in reply to cb1
    Guru 27665 points
    Agreed no one implementation is best. I think only those who have only worked with a single type of implementation would believe that. I mentally went over the ways I've seen simple outputs implemented, I came up with something like 1/2 dozen depending on how you draw the lines separating the methods. The separate pin status/driver status does have the advantage of being probably the most flexible but that flexibility does incur some cost as well.

    I'm with you on multiple reads being useful. Not all of the time though, I've certainly done control where such filtering would not be particularly necessary and maybe not useful.

    Reading the pin state could be an advantage in some limited conditions (basically where the load exceeds the driver's capability, although that raises other concerns). Most of the time though it's the driver state that's relevant. In the cases where you do need the pin state you can dedicate an additional input. Of course, some people insist every pin is already taken (and in some cases it's true).

    I think the manual would be working outside its area of applicability to have any notes about reading a driven output since the IC does not have a built-in capability to do so.

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points
    Aha - "outside its area of applicability" - might we need (considered) inputs from "Keystone Judge/Jury" (rather than just Kops) to so define?
  • 0 in reply to cb1
    Guru 27665 points
    Maybe Konsultants from the Keystone Konsortium

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points
    KLEARLY! Let the record show that poster/friend Robert introduced "Keystone" to this hallowed space...
  • 0 in reply to cb1
    Genius 3300 points
    Simple case in which pin has to read back before writing is pin inverting by xoring.
    DATA_REG ^= BIT5; (DATA_REG is pin register & BIT5 is pin to be written).

    Here pin is in output node, but has to read back to invert it.
  • 0 in reply to VT
    Guru 27665 points
    Vindhyachal, that reads back the state of the driver not the state of the pin.

    Robert

    Keystone Kaper Kontinues
  • 0 in reply to Robert Adsett
    Guru 47900 points

    Robert Adsett said:
    Keystone Kaper Kontinues

    That's (likely) Kataclysmic - thread should be released from its misery...

    Amit's unable to change this - semi-redesign to "meet poster's goal" extremely unlikely.   What (then) is the point?...

  • 0 in reply to VT
    TI__Guru**** 244400 points
    Hello VT

    So you mean, like bit banded operation we have XOR operation as well?

    Regards
    Amit
  • 0 in reply to cb1
    Guru 27665 points
    Kops Konfused, Kontinuance Kompletely Kuckoo

    Robert
  • 0 in reply to Robert Adsett
    Guru 47900 points
    Krazy!
  • 0 in reply to cb1
    Genius 3300 points

    Hi Robert & Amit,

    I had read earlier your point. I had just mentioned the xor code to show it could impact. Which I didn't mention in my second post.

    BTW, your's & cb1- (or I say Kobert & Kb1), oppression with K is so high that unnecessary post are been added to this thread. That's Krazy

  • 0 in reply to VT
    Guru 47900 points
    VT - Well done! You are now welcome into our "obsession" Klub. You've got your answer - let's leave this dead horse...