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.

SSD1306 for launchpad EK-TM4C1294XL

Other Parts Discussed in Thread: EK-TM4C1294XL

Hi everyone,

I am trying to use the driver API for SSD1308 based I2C OLEDs in this link: e2e.ti.com/.../835676 SSD1306.

But it doens't work. I checked every address and still don't know the problem.

I'm using the EK-TM4C1294XL launchpad and I think it may have some changes to do but I don't know what it is.

Thanks, 

Mayli.

  • Mayli Souza said:

    trying to use the driver API for SSD1308 based I2C OLEDs in this link: e2e.ti.com/.../835676 SSD1306.  

    You did note that those two "SSD Controller" part numbers differ - did you not?   Might that matter?   Have you checked?

    Solomon-Systech is the creator of both devices - have you acquired - then compared - data sheets/manuals for each device?   That's the obvious "course of action" - is it not?

    And - we must note - your report of, "Doesn't Work" some way/how does not prove especially helpful or descriptive.   (some detail is required...)

  • Yes, I've noticed that and completely read both the datasheets. The only real difference between the SSD1306 and the SSD1308 is the charge pump, which is onboard on the SSD1306 and not on the other one. Therefore, it is needed to use the 0x14 command to activate it.
    All the addresses are the same for all the commands.

    I had to change the initialization routines to match those on the TIVA for the clock configuration and the I2C. The rest of the code is basically the one on the library.

    I have also tested the code sending the commands to an Arduino Due that I have, and it is receiving all the commands it should from both the initialization of the SSD1306 and the string print.

    Also, I have tested the display with the arduino using a library made for it and it worked, so the problem is not on the display itself.
  • Bravo - your latest post fully & quickly corrected (all) of the deficiencies w/in the (too short/vague) initial one!     Well done!

    You may want to present (some) of that (essential) background info - during future postings.   (saves wear/tear upon your helpers - both official & outsiders)

    The fact that you have:

    • working code under an Arduino "Duo"
    • succeeded in getting a properly performing display

    speaks strongly to your potential for success.

    If you can gain access to an oscilloscope that would help immensely.   My guess is that the TM4C - being faster than the Arduino - may be sending commands & data in violation of the display's "timing" or "command processing" specifications.   (both are usual suspects)

    Inserting long delays between each display command - especially during initialization - usually proves helpful.

    While the charge pump has been enabled - have you (really) measured the exposed pin & installed the (normal/proper) capacitors to smooth that voltage?   Further - are there not commands which adjust (or step) the charge pump?    (that operation usually is critical)

    As last resort - cannot you perform scope caps - both via Arduino & then via TM4C of:

    • display initialization sequences
    • clearing and homing the display
    • attempt to write a few pixels to the display

    You want to capture that data as close as possible to the display's "data input pin."   (Probing the MCU is not effective - the display must receive the data correctly.   And - perhaps the Arduino employs (real) pull-up resistors - your TM4C does not - and the enfeebled (internal) ones often land posters like you here.   (heartbreak hotel)   External pull-up Rs - even though claims for internal ones are made (especially as claims for internal are made) prevent endless problems due to signal skew and marginal levels @ speed.

    Do you note any pixels upon the display?