Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 7 of 7

Thread: Teensy 3.6 SPI library - garbled output on SparkFun LCDs

  1. #1
    Member
    Join Date
    May 2017
    Location
    Spokane Valley, WA
    Posts
    21

    Teensy 3.6 SPI library - garbled output on SparkFun LCDs

    Hi folks,

    I'm having an apparent "garbled comms" issue with the Teensy 3.6 and two different SPI/I2C/serial LCD's marketed by SparkFun and sold on Amazon.
    The model # is 14073, and the SPI library is from TeensyDuino 1.44. (I assume - I haven't done anything special The Arduino IDE version is 1.8.7 .

    Some characters displayed on the LCD are what I would expect to see, but most are garbage - blanks, other alpha etc. I have not as yet put a logic analyzer on, primarily because I'm old and don't have a 3.3V analyzer. (yet) The LCD is powered by a separate 5V rail with its own 3.3V sub-regulator, which is bypassed and shows no bad habits on a 100 mHZ scope. The power grounds are common, of course.

    Here's the code I'm using. I scraped the SPI commands from a demo. I've used Teensy boards primarily for audio projects up until now, so this is my first SPI project with it. I am operating under the
    *assumption* that the code below will compile/link the Teensy library, although that may or may not be true - not a TeensyDuino expert by any means.

    Ideas solicited, thanks!

    Sketch code:

    // include the SPI library:
    #include <SPI.h>

    // set pin 10 as the slave select for the digital pot:
    const int csPin = 10;

    void setup()
    {
    delay(1000); // Give the display MCU time to boot
    pinMode (csPin, OUTPUT);
    digitalWrite (csPin, HIGH);

    // initialize SPI:
    SPI.begin();

    // Write R, G & B backlight values for max brightness (initial test)
    writeLCD(0x9D);
    delay(100);
    writeLCD(0xBB);
    delay(100);
    writeLCD(0xD9);
    delay(100);
    }

    void loop()
    {
    writeLCD('A');
    delay(100);
    writeLCD('B');
    delay(100);
    writeLCD('C');
    delay(100);
    writeLCD('D');
    delay(100);
    }

    void writeLCD(int value)
    {
    // gain control of the SPI port
    // and configure settings
    SPI.beginTransaction(SPISettings(4000000, MSBFIRST, SPI_MODE0));
    // take the SS pin low to select the chip:
    digitalWrite(csPin,LOW);
    // send in the value via SPI:
    SPI.transfer(value);
    // take the SS pin high to de-select the chip:
    digitalWrite(csPin,HIGH);
    // release control of the SPI port
    SPI.endTransaction();
    }

  2. #2
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    4,457
    I was going to suggest setting the SPI bus speed slower, but the above setting (4000000) is a lot slower than the setting I needed for TFT displays (24000000) or OLED displays (11000000). You might try turning the Teensy 3.5/3.6 clock speed down, and/or adding delays before/after changing the csPin. You might also try adjusting the other delays.

    The board also has UART support. It may be simpler to hook it up to one of the hardware serial ports, and feed it text commands.

  3. #3
    Senior Member PaulS's Avatar
    Join Date
    Apr 2015
    Location
    Netherlands
    Posts
    1,248
    From the Hookup Guide of this display:

    Click image for larger version. 

Name:	Capture.PNG 
Views:	93 
Size:	11.6 KB 
ID:	15305

    I know you want to use the SPI interface to talk to the display but connecting the RX pin to 3V3 doesn't harm and may solve the garbled display.
    Reading through the Hookup Guide, it's not immediately clear to me how the display decides to listen to which interface. I guess it's just listening to every interface and displays whatever arrives in a suitable format?

    Did you try the SPI example first to see whether that works?
    I noticed in the example that a slow SPI speed is apparently required:
    Code:
      SPI.begin(); //Start SPI communication
      //SPI.beginTransaction(SPISettings(100000, MSBFIRST, SPI_MODE0));
      SPI.setClockDivider(SPI_CLOCK_DIV128); //Slow down the master a bit
    Regards,
    Paul

  4. #4
    Member
    Join Date
    May 2017
    Location
    Spokane Valley, WA
    Posts
    21
    Michael, Paul -

    Thanks for the replies and research!

    I did try taking the clock speed down, with no apparent effect.
    As an aside, last night I rewired my test lashup for I2C. While that works more-or-less, it requires the insertion of unacceptable (to me) delays between transactions.

    I think I'm going to forget about using serial displays for this project. I need fast, crisp output and so far my experiments have had disappointing results. Off to parallel-land, I suppose.

    FWIW, the application is a precision RF power/modulation/distortion "analyzer". I don't want to burden the BOM with the cost of a faster CPU and a TFT LCD, so I'm trying to come up with a reasonable peak-hold visualization using bar graphs made from extended characters available in character LCD's. Unfortunately, I'm learning that they're much slower devices than I'm used to and may not be suitable. I'm going to try a sampling of parallel displays to see what I can come up with.

    Thanks again for the help.
    --jim

  5. #5
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    11,783
    As for cost? The display that PJRC sells https://www.pjrc.com/store/display_ili9341_touch.html cost less than the SparkFun display you are trying...

  6. #6
    Member
    Join Date
    May 2017
    Location
    Spokane Valley, WA
    Posts
    21
    Quote Originally Posted by KurtE View Post
    As for cost? The display that PJRC sells https://www.pjrc.com/store/display_ili9341_touch.html cost less than the SparkFun display you are trying...
    Thanks for the recommendation. I see you're the author of one of the libraries and check in here. All good things. :-)
    I'll order a couple for testing. $15 is cheap if the display is fast enough and no "gotchas" come up.

    --jim

  7. #7
    Junior Member
    Join Date
    Apr 2015
    Posts
    4
    Hi,
    I'm having a similar problem with SD1106/SD1306 OLED displays and Teensy3.6 specifically.
    The code is Ornaments and Crimes ( https://github.com/mxmxmx/O_C/tree/m...ftware/o_c_REV )

    I'm using the Alternate SPI pins (SCK=D14, MISO=D12, MOSI=D7) and I change them using -
    SPCR.setMOSI(7);
    SPCR.setSCK(14);
    SPCR.setMISO(12);

    This WORKS perfectly with Teensy 3.2 & Teensy 3.5 - but I get a trashed display with Teensy3.6

    I've been thrashing on this for a day now -
    would anybody know why the T3.6 wouldn't run the same SPI code/config?

    (full code change here )
    from OC_DAC.cpp :

    // adapted from https://github.com/xxxajk/spi4teensy3 :

    void SPI_init() {

    uint32_t ctar0, ctar1;

    SIM_SCGC6 |= SIM_SCGC6_SPI0;
    //CORE_PIN11_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2);
    //CORE_PIN13_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2);
    SPCR.setMOSI(7);
    SPCR.setSCK(14);
    SPCR.setMISO(12);

    ctar0 = SPI_CTAR_DBR; // default
    #if F_BUS == 60000000
    ctar0 = (SPI_CTAR_PBR(0) | SPI_CTAR_BR(0) | SPI_CTAR_DBR); //(60 / 2) * ((1+1)/2) = 30 MHz
    #elif F_BUS == 48000000
    ctar0 = (SPI_CTAR_PBR(0) | SPI_CTAR_BR(0) | SPI_CTAR_DBR); //(48 / 2) * ((1+1)/2) = 24 MHz
    #endif
    ctar1 = ctar0;
    ctar0 |= SPI_CTAR_FMSZ(7);
    ctar1 |= SPI_CTAR_FMSZ(15);
    SPI0_MCR = SPI_MCR_MSTR | SPI_MCR_PCSIS(0x1F);
    SPI0_MCR |= SPI_MCR_CLR_RXF | SPI_MCR_CLR_TXF;

    // update ctars
    uint32_t mcr = SPI0_MCR;
    if (mcr & SPI_MCR_MDIS) {
    SPI0_CTAR0 = ctar0;
    SPI0_CTAR1 = ctar1;
    } else {
    SPI0_MCR = mcr | SPI_MCR_MDIS | SPI_MCR_HALT;
    SPI0_CTAR0 = ctar0;
    SPI0_CTAR1 = ctar1;
    SPI0_MCR = mcr;
    }
    }
    // OC_DAC

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •