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.

Compiler/TM4C1233H6PM: concatenation of pins of different ports into one BUS

Part Number: TM4C1233H6PM

Tool/software: TI C/C++ Compiler

I m deficient of pins, No port  available is left with all 8 pins unused as i have used them for other purpose in project. Is there any way that i could use 4 pins from one port and 4 from other as data bus for 16x2 LCD?

  • Hello Muhammad

    Yes, you can use the same, but when doing bitbanded operation do make sure that the timing of the LCD is maintained. Also when doing access do make sure that the GPIOPinWrite uses the correct set of pins for each port.
  • Firm/I have done (exactly) what this poster seeks. (i.e. harvested a total of 8 pins from 2 (or even 3) separate GPIO ports)

    I'm not sure that "bit-band" is required - poster will wire/connect 4 bits from (separate) MCU Ports to the appropriate LCD, 8 bit, Data bus.   This requires separate MCU Port writes.   Only after that 8 bit (DATA) is present & stable - should the LCD's "E" signal be toggled.   (that's further detailed, below)

    Necessary in this circumstance is to insure that all (combined) 8 pin data is ready & stable - and (only then) toggle the display's "E" pin. Complications exist should the "Control Signal Port" be a duplicate of any one of the ports which provide Lcd data. The "E" signal must toggle alone, uniquely, by itself - affecting "no other" Lcd pins.  (nor "RS" or "R/W" should R/W be in use)

  • You might also look into using SPI to remove pins from existing usages. For many uses that's fast enough and allows for a lot of I/O using only a few pins. That allows you to reserve your I/O pins for special functions (PWM etc...) and high speed requirements.

    Robert
  • Poster Robert (once more) raises a most valid alternative.

    Your initial MCU Design (usually) should key upon the "reservation" of key/critical pins/functions - ideally those (only) available from the MCU. Such would be PWM, I2C, SPI, UART, Timer In/Out among others.

    GPIO have been (deliberately) removed from this fray - they are (easily) regenerated from SPI/I2C based "GPIO Extender ICs." Further - that same SPI signal chain enables "more than one such, GPIO Extender IC" - yielding (almost) unlimited GPIO expansion...

    The software is rendered more complex when "splitting" the MCU Ports - to assemble into a "normal" 8 bit port - as you've earlier noted...
  • Hello cb1

    I was referring to the bitbanded ports for the set of pins being used from each of the ports.
  • Hi Amit,

    Might the bitbanded method reduce the Lcd (8 bit data) write from TWO (4 bit writes, from 2 different Ports) to just ONE (8 bit bitbanded) Write? In that case - the added complexity of bitband appears worthwhile. If (still) two port writes remain - then I'd label "bitband" as, "Not so much."
  • If I understand it (and thus why I'm repeating it) bitbanding would remove the need for any pre-masking but not for shifting and writes to multiple ports.

    IE shift, mask, read, mask,  or, write becomes shift, write
     
    Robert

  • Your understanding is similar to mine - thus the advantage of bitbanding - when synthesizing, "One, wider data port from two (smaller, bit port writes)" appears slight.   (or - slight is my understanding)

    Vendor's API well provides for the "isolation & transfer" of selected port bits.    The impact of, "two or more such "bit isolation & transfer" - from different ports" - appears to erode (any) benefits provided by bitbanding!