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.

Defining parallel port using GPIO pins

Hello,

I want to create a parallel port, 8-bits wide in the TIVA Launchpad. Port B is already available for use but some of the pins are conflicting with another use for them.

Suppose, i wanted to define a port say. PORT J which has PB7, PB6, PA1, PA2, PA3, PD2, PD3, PD4 as the 8 pins in parallel, how would I have to define the port?


( Currently, for PORT b, i use the following macros :

#define DATA_PERIPH    SYSCTL_PERIPH_GPIOB
#define DATA_PORT    GPIO_PORTB_BASE

and subsequently use them)

I would appreciate very much a quick reply.

  • Hello Ashwin,

    Is there a requirement that all Pins should toggle at the same time or a few clocks of difference is OK?

    You cannot define PORT J with pins from other ports together.

    Regards

    Amit Ashara

  • Hello Amit,

    I using the port as the data port for a GLCD. So, I guess a few clock cycles wouldn't harm it's operation as I would be latching it anyway. The reason behind me asking the question was the fact that it would make it that much easier to work with an 8-bit variable if I had a port defined for it.
    So, now if I have to use pins of multiple ports, say n different ports, for a single write, I have to call GPIOPinwrite n times and also have to split the 8-bit data accordingly.

    So, I was looking for a way to combine pins of different ports to define a new virtual port.

  • Hi Ashwin,

    Yes, that is correct. To write to different GPIO Port Pins you need to write it N times. A virtual port in SW "will not" translate to a single write in HW.

    You can create a function to write the value as parameters and in the function call the N GPIOPinWrite's

    Regards

    Amit Ashara

  • Have long worked w/displays - suspect there's a, "yet better" means to achieve your objective. 

    You state that you're "latching" this data - outside the MCU.  You may consider the use of SPI or I2C, "Port Extender" ICs - available this vendor and others.  This chip eliminates your requirement for an external latch IC - so that's a "wash." 

    Big benefits accrue (rather major - our experience teaches) by eliminating any, "multi-port data massaging" - by which you synthesize multiple ports into a single, 8 bit data byte -  for presentation to the display.  You simply direct your desired "display byte" to the SPI or I2C port extender - there is no need whatsoever for any complex, bit/byte logical combination or manipulation. 

    While you limited your query to data byte port - you've surely noted strobe and various control bit requirements which also are "de rigeur" when running displays.  That same port extender IC may be had in 16 bit "flavors" - which allows a 2nd (simple) byte to be passed between MCU & the display (controller).  That 2nd byte may provide the control/strobe signals & - if you're clever/resourceful" - may even "auto strobe" - saving an additional SW port access/manipulation...

    Harvesting pins from different ports can (and is) being done - but requires attention to detail.  I detailed the how/why of this perhaps one year back in answer to a user's need to operate a 2x16 Lcd...  Search under cb1_mobile & 2x16 should detail...