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.

accessing GPIODATA register

Hi,

i am trying to understand how can i rea d/write value to GPIODATA register.

i know that i if i working with port F for example and enter the address 0x400253FC to GPIODATA register  i can access all 8 bootom bits.

when i read the value from the register to another varaible the value was: 0x0000011.

can anyone explain me why the value is as i mention and not:0x000000FF.

how can i read/write value to GPIODATA register? with simpler explantion then the datasheet. 

thanks for your help.

  • Hello Shlomi

    What is the configuration of the GPIOs in terms of direction and open-drain control and if they are all inputs are they all connected to logic 1 or 3.3V?
  • how can i read/write value to GPIODATA register? with simpler explantion then the datasheet.

    The TM4C is a complex part - you will have a hard time if you shun datasheet.

    If you had invested the time and read it, you would perhaps understand that the peripheral registers (including the GPIODATA register) is just an interface for the core to the actual IO hardware.

    And since a GPIO can be configured as either input or output, read and write will yield different results, according to that configuration. Write access affects only output pins, while read access will return meaningful results only for inputs. And both access types (read and write)  >> can << be implemented in one access register.

    Reading the datasheet is highly suggested. It's a shame TI has no Cortex M0 controllers to offer, which tend to be simpler, and easier to understand ...

  • Hello f.m.

    How would Cortex M0 ease the task of a peripheral?
  • Amit,

    f.m. said:
    It's a shame TI has no Cortex M0 controllers to offer, which tend to be simpler, and easier to understand ...

    Emphasis added. It's a tendency for simpler devices to have simpler peripherals not a requirement. The trend is there simply because not many vendors want to put  complex peripherals on an M0 when for slightly more cost they can pair them with an M3 or M4. The M0s get the simpler, cheaper peripherals so the whole solution is less expensive.

    Robert

  • Hello Robert

    Thanks for the emphasis. Now is the intent is to read a set of pins wouldn't an 8-bit or 16-bit micro also do the job (of course Cortex cores are more scale-able)
  • Yes. Or even a 4 bit micro. Although 16 bits are becoming rarer (being squeezed out by 32bit processors on the performance side and both 32 and 8 bit on the cost side). The smaller 32bit processors are even squeezing the 8 bits on the cost side.

    In the case of 8 bit controllers even if the peripherals are simpler the architecture is often more complex. And 16 bit micros often have peripherals that match the mid to higher end ARMs in complexity

    If you don't have existing investment in 16bits it's getting harder to justify a 16bit micro over a cortex of some flavour. Even for 8 bit micros, their biggest advantage is simple market inertia.

    Robert
  • Hello Robert

    I agree and the poster has to then validate the requirement for a 32-bit micro if the target is sufficiently achievable on an 8-bit micro. However coming back to the poster question, I am still awaiting inputs on the configuration of the GPIO and the physical IO state.
  • Robert, I agree with your line or arguments - that's why I wrote "tend to have". There is no need for a M0 to be less complex than an M3. In fact, some recent M0/M0+ controllers have more complex and powerful peripherals than "old" M3 designs.

    The M0 is aimed at the very-low-end market, poised to replace 8-bit and 16-bit MCUs. Price is a primary issue in this segment - I know that first-hand.

    And I avoided to mention 8-bit and 16-bit controllers, as this seemed unfair to me. Their "primitive" core and peripherals are owed to the technology at the time of design. However, they are much easier to understand...

  • I am still awaiting inputs on the configuration of the GPIO and the physical IO state.

    When reading the first post of the OP carefully - there is nowhere implied that his question is related to a specific project/source code/configuration.

    His question might be purely theoretical, i.e. he is struggling with the idea behind that.