Teensy 3.6 SPI library - garbled output on SparkFun LCDs

Status
Not open for further replies.

audiomath

Active member
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();
}
 
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.
 
From the Hookup Guide of this display:

Capture.PNG

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
 
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
 
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/master/software/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
 
Status
Not open for further replies.
Back
Top