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.

TM4C123GH6PM: GPIODATA offset

Part Number: TM4C123GH6PM

The data sheet mentions that the offset of GPIODATA is 0x00. 

Why do we have to use an offset of 0x3FC? 


  • Greetings,

    Muhammad Inam Ul Haq said:
    Why do we have to use an offset of 0x3FC? 

    You are correct in noting that such is (not) directly explained w/in the MCU Manual.   Instead the "0x3FC offset" is said to provide increased software efficiency - especially w/in "Read-Modify-Write" implementations.

    It is possible to "Search" the MCU Manual - while targeting "0x3FC" for you my small team found (only) 2 "Hits" (on page 601) - neither too enlightening...   You (may) wish to review the MCU Manual's description of "Bit-Banding" - for further detail...

    Digging deeper - this was discovered:

    Yet - good as this is - the (calculation) of "0x3FC" remains illusive...

    Now note those key bits [9:2] (in highlight) - which serve to mask the address bus.   When we "Add the bit-based value of each bit" (again bits [9:2]) your "mystery" 0x3FC (1020 decimal) reveals!

    And - the highly capable "API" almost always, "Manages such low-level detail" for you!    (Freeing users from such "exhaustive" detail ... unless they 'really' want it...)   "GPIO.C() code follows:"

    void
    GPIOPinWrite(uint32_t ui32Port, uint8_t ui8Pins, uint8_t ui8Val)
    {
    //
    // Check the arguments.
    //
    ASSERT(_GPIOBaseValid(ui32Port));

    // Write the pins.
    //
    HWREG(ui32Port + (GPIO_O_DATA + (ui8Pins << 2))) = ui8Val;    // (255 << 2 = 1020 (0x3FC)  
    }

    While it's good that you are, "Recognizing & attending to (fine) detail" - in the scheme of things this is a (relatively) minor point.   And there are (many) such "interesting" - yet "Non-Vital" points - which (may) negatively impact your learning!

    Instead my young tech team finds:

    • Study of the PDL User Guide (an absolutely terrific/helpful resource)
    • Review of the (many) programming examples - thoughtfully grouped via "peripherals"
    • You may also review the API's "Source Code" (in which the GPIO control mechanisms are revealed! - under "Examples\Peripherals\")
    • Obtain the excellent "LPad(s)" - and "Actually: Write, Debug, & Observe" just how the running code behaves.   An (almost) unmatched learning tool!
    • Study of the MCU Manual's Peripheral Chapters (those which most appeal)

    proves (both) a more efficient & productive method (i.e. a more unified means) to gain understanding & competence - and (in time) "mastery" of these ARM MCUs.     Happy studies...