• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 30 subscribers
  • Views 666 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.

Basic Read Write Instructions from / to GPIOs

Vikram Dewangan
Intellectual 520 points
Other Parts Discussed in Thread: EK-TM4C123GXL

Dear e2e members,

The question is very basic but I'm getting some fluctuations in the following case.

Hardware: EK-TM4C123GXL 

I have to configure bits 0,1,2 and 3 as output and 4,5 and 6 as input. (for a 4x3 matrix keypad for which I have a tested algorithm for de-bounce etc.)

I am testing the following elementary codes:

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);
GPIO_PORTB_DIR_R = 0x00; //define bits 0-7 as input
GPIO_PORTB_DEN_R = 0xff; // define bits 0-7 as digital pins
int val;
val = GPIO_PORTB_DATA_R; //read data from PORTB

Will this code work? What is the instruction to read data from specific GPIO bits if the last instruction is incorrect? Thanks

  • 0
    TI__Guru**** 244400 points
    Hello Vikram,

    No it will not work for the condition mentioned and secondly I would "strongly" advise you to move away from direct register access macro, Instead use the API's GPIOPinTypeGPIOOutput(BASE ADDRESS OF GPIO, GPIO PIN) for configuring a GPIO as output and GPIOPinTypeGPIOInput(BASE ADDRESS OF GPIO, GPIO PIN) to configure a GPIO as input.

    To read a GPIO the API is GPIOPinRead(BASE ADDRESS OF GPIO, GPIO PIN) the return value of which is the value of the PINS that kept in the GPIO PIN parameter.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Intellectual 520 points
    Yes Amit, You are correct. I have already used API functions. They are working fine (with subtle fluctuations sometimes. I'll discuss after this).
    Here the requirement is like this. I have certain values in hex and I have to put them in the port with some mathematical calculations but API functions allows to read/write individual pins. So any other alternatives where I can directly assign the value to the port or read them as a hex/binary input?
  • 0 in reply to Vikram Dewangan
    Guru 117855 points

    Vikram Dewangan said:
    I have used API functions...working fine (with subtle fluctuations sometimes)

    Really (subtle fluctuations)... I'd bet the car, boat & house that any such "fluctuation" is caused by your (subtle) misunderstanding and/or misuse of these long proven, API library functions!

    As to your key-scan/read - those API calls will return the Port's proper binary value (most always in hex-format - per the IDE) and the "far more usual" issue is the conversion of the returned, "hex-values" to decimal - for output to the (usual) ASCII-decimal based display...

    Do stick w/ the API - it will speed, ease & enhance your learning.

    And - many here (i.e. ALL) would be delighted to learn of those exact API calls which "suffered" subtle fluctuations!   

  • 0 in reply to Vikram Dewangan
    TI__Guru**** 244400 points
    Hello Vikram

    What subtle fluctuations???

    To read or write the entire set of 8 pins you can access the offset 0x3FC of the GPIO Base Address.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 117855 points

    Amit Ashara said:
    To read or write the entire set of 8 pins you can access the offset 0x3FC of the GPIO Base Address.

    May I (gently/politely) call, "Over complication alert!"   Does not (mere mention) of "0x3FC offset" steer poster (back) to dreaded Direct Register?

    My belief - use of the API (quite deliberately) shields/buffers users from such "offset" detail & understanding.

    As you've (already) stated for poster - full Port reads/writes may be achieved (entirely) w/in the API domain - where any such (offsets) are transparent to the user!

  • 0 in reply to cb1_mobile
    TI__Guru**** 244400 points
    Hello cb1,

    Yes. Thanks for correcting me.

    Hello Vikram,

    I conflicted myself (again). You must use the GPIOPinWrite and GPIOPinRead with the Pin Parameter as a define in the main code, instead of OR-ing the individual Pins and having the same effect.

    #define GPIO_PIN_ALL 0xFF

    Regards
    Amit
  • 0 in reply to cb1_mobile
    Intellectual 520 points
    Hi, thanks for your encouragement to put forward the issues. I never said the fluctuations are caused by TI's long proven API functions (It may be because of your habit to misunderstand the question).
    Sometimes I wonder the intentions of your presence in various threads. Is it to ease out the posters difficulty in his design/learning process by providing useful input (voluntarily) or to encourage him to indulge in unnecessary discussions by luring to offer your car boat and house. You must be having a Jet in the line for your betting business I believe.

    Well if you are really interested in delving in the case, here you go. I declared few pins as input and using Tera Term seeing the output of scanned port through UART connection.
    Results are non zero sometimes with no connections to input pins. You may like to try.
  • 0 in reply to Amit Ashara
    Intellectual 520 points
    Thanks Amit.
    It helped.
  • 0 in reply to Vikram Dewangan
    Guru 117855 points

    Vikram Dewangan said:
    I have already used API functions. They are working fine (with subtle fluctuations sometimes.

    Is your quote - above - not proof positive of your (now denied) claim that you attributed "subtle fluctuations" to API functions?  And - vendor's Amit questioned your claim of, "subtle fluctuations" - just as did I.  Such claim was very provocative - could not pass w/out challenge - and is clearly false...

    And - as to your "illustration" of those (subtle fluctuations)  "Results are non zero sometimes with no connections to input pins."

    Is this not - as I past suggested - the result of the "misuse" of the API or MCU?  Is the attempt to read one/several MCU inputs - with "no connections" (i.e. inputs floating) the normal/customary correct operation?  Clearly not - and there's nothing subtle in that diagnosis.  (Pull up Rs are the normal means of gaining correct/bounded GPIO as input behavior.)

    Your compliance with normal/customary MCU usage - and proper use of vendor's API functions - remains (unlikely) to yield "fluctuations" - not even subtle ones!