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.

  • TI Thinks Resolved

CCS/SW-EK-TM4C1294XL: need help with PCF8574AT i2c (16x2)LCD controller with tm4c2194xl

Intellectual 350 points

Replies: 17

Views: 1969

Part Number: SW-EK-TM4C1294XL

Tool/software: Code Composer Studio

i have been trying to interface the 16x2 lcd with my tm4c1294 launchpad but i'm unable to make any progress tried lots of address as mentioned in many pages but no luck.

please help!!

  • Rohan Parvatiyar
    i'm unable to make any progress - tried lots of address as mentioned in many pages - but no luck.

    While "feeling your pain" - the description,  "unable to make any progress" proves (very) vague - does it not?

    The powerful  "Development & Diagnostic" Technique  "KISS"  provides  helpful  "specifics"  - which guide & inform your actions.     Several follow:

    • you note  "PCF8574AT" as (both)  I2C based & capable of  "LCD Control."     Are both capabilities confirmed?     (it is preferred that poster's (link) to such devices - reducing excess demands upon "helpers.")
    • have you "scoped" - or otherwise confirmed - that your MCU is outputting the I2C signals - both SDA & SCL?
    • and - have you confirmed those (same) signals - safely arriving - at your  "PCF" device?
    • have you employed (proper, external) pull-up resistors (10K suggested) upon both SDA/SCL?
    • have you "ohmed out" your connections between "PCF" and the "2x16 char Lcd?"    (assumes that the "PCF" is NOT resident w/in that display)
    • is the "PCF" compatible w/the 3V3 signal levels - produced by your MCU?     Usually this will NOT prove the case should the "PCF" be powered by 5V.    (varies - on a case by case, basis)
    • should "all of the above" prove correct/true - is your software properly configuring the "PCF?"     These chips usually include a "Command-Control" byte(s) - which must be properly written - to enable correct operation.     Note that you MUST supply the proper I2C Address to the "PCF" - to have ANY chance at success.     (scope confirmation proves ideal for this task)

    It is hoped that this brief guide will enable,  "some progress"  to arrive.    

    Do note the value & power provided by "KISS" - and its systematic - "one (measurable) step at a time" - focused probing.

  • Hi,
    cb1 provided very good tips for you to diagnose your problem and the best of which is to use the scope to capture your bus activities. Make sure you have pullup resistors on the SDA and SCL bus as noted by cb1.

    The PC8574AT is an 8-bit I/O expander for I2C bus. Is your problem between the MCU and the I/O expander or between the I/O expander and your LCD?

    regards,

    Charles

     

  • In reply to Charles Tsai:

    Greetings Charles,

    Still "on the road" - but today @ (near) sea-level.    Poster described the "PCF" as "LCD Controller" - and not providing a link - I accepted his description.

    Now - as you've made the effort to discover the "PCF's" real functionality (i.e. 8-bit Port expander) - I note a caution.      Poster's Char-based Lcd includes an 8-bit data bus (accommodated by the PCF expander) - yet  TWO ADDITIONAL "COMMAND SIGNALS" (RS & R/W) - are required!      Thus - the objective of "I2C to LCD" - may have  "Fallen off - poster's tree!"

    These Char LCDs (may) operate via 4-bit data bus - yet the complexity is (then)  raised an "order of magnitude higher" - and that difficulty is greatly MAGNIFIED - when (both) the "PULSING "E" Signal" (and RS) must be embedded w/in that same,  PCF expander.

    Poster's (superior) choice - if ONLY I2C (or SPI) interface (to the Lcd) is desired -  is a, "16-bit (not 8-bit) Port Expander."       (with the LCD operated in the safer, faster, more robust,  8-bit data mode!)

    May it be noted that,  "Rather than (pedestrian) "Scope Use" - many would (surely) award "BEST" to  the "Proper,  SOLUTION-GUIDING,  PROCESS KISS!"     (even though - especially though - KISS (appears) banned here ... leading to: "Tortured, ineffectual, non-memorable/unknown, multi-phrased substitutes!"     Pity!)

  • In reply to cb1_mobile:

    Hi cb1,
    That is a good insight on the 16x2 LCD needing the RS and R/W signal for 10 I/Os if not operated via the 4-bit bus which would have complicated the LCD interface. I remember you mentioned the same thing in another post a while back.

    regards,

    Charles

     

  • In reply to Charles Tsai:

    Thank you, Charles - indeed.       You surely know - but others should  "be mindful"  that the,  "Employ of an 8-bit Port Expander"  comes at the cost of 2 GPIO (and 4 GPIO - if the expander is SPI based  [many are]) - thus 25% of the "expansion" is devoured via the MCU <-> Expander Interface.      Such proves yet (another) reason why firm/I most always choose the 16-bit Port Expanders.    

    Note that the Signal LOSS - when employing an 8-bit Port Expander - via SPI - is especially grievous.    (4 pins lost yields (only) 4 pins of net gain!)     NOT too useful...

    Dawns that those here may enjoy seeing my firm's creation of  (what's believed) to be the world's smallest,  "Intelligent  I/O Module -  including Native:  I2C, SPI, CAN, UART & USB Interface."    (that "well attached" (PROTOTYPE shown)  "5-Way NAVigation Switch" - comfortably, efficiently & compactly satisfies - the "Input Aspect" of  this "giant client's" desired I/O module...)

    and "illuminated" (for viewing w/in "dark ambients")

    While "small" - NOT to doubt the power of such a device.     Shown below - a 60 pound "Inertia Wheel" - fully  spun-controlled - via this unique I/O Module's  ARM MCU.    (used w/in Autonomous Auto,  BLDC  Motor-Controller Development)     Note the,  "NO Expense Spared Workbench" ...  that's a "defrocked Bowing Alley Lane" ... (gutters were "extra" - thus bypassed (even when "used" - especially when used - as (originally) intended.)     (extra-credit if  one  "gets that.")

    and here ...  Not quite your  "Father's  Autonomous Cars"    OR     "Sheep in Wolf's Clothing"     (cloth  "traded"  for  "hi-gloss paint & sheet-metal")

  • In reply to Charles Tsai:

    Sorry it was my bad that i couldn't explain my difficulty. i'm not using the PCF8574AT ic only but the i2c lcd module which is a 16 pin i/o device and is totally devoted to controlling the lcd

    the above module is the one that im using.

    please help

  • In reply to Rohan Parvatiyar:

    Hi Charles,

    WHAT to say?        (maybe if I "worked harder" - created a (more) detailed list - or included a photo, proving operation?)
    I cede this poster to, "you/others."

  • In reply to cb1_mobile:

    Sorry for the inconvinence but it would be very nice if you could help me in the situation.
    have to complete this as project!!
  • In reply to Rohan Parvatiyar:

    Here I copy and paste cb1's last listed tip for diagnosis.  Please report back what your I2C address on the scope? Did you have a chance to go through the PCF datasheet for the I2C slave addresses. Don't mix up between the slave address and the address byte. For example, the slave address may be 0x27 but the address byte will be either 0x4E or 0x4F depending on the write or read. The LSB is to control the direction. You should go to 14core to research your product. r

    • should "all of the above" prove correct/true - is your software properly configuring the "PCF?"     These chips usually include a "Command-Control" byte(s) - which must be properly written - to enable correct operation.     Note that you MUST supply the proper I2C Address to the "PCF" - to have ANY chance at success.     (scope confirmation proves ideal for this task)

     


    regards,

    Charles

     

  • In reply to Charles Tsai:

    regards,

    Charles

     

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.