Flexcan, canbus... brain fried and confused

SteveSFX

Well-known member
Hello all

Looking for a new project, and thought I would try and make a canbus reading gauge for the wife's Mini. Want to know the engine temp etc and it suffers from a lack of gauges.

After about 2 hrs Googling and searching in here, I am even more confused that when I started!

A 3.2 has Canbus ability I believe. Seeing as I am only reading data, I assume I can connect directly to the car's bus using CanH and CanL? (I have the Canbus transceiver board).

Next I would imagine is the Flexcan library. How do you actually determine what data to request and the format? (for instance, to request MPH)?

Any guidance to a webpage or something would be ideal. I have bookmarked several pages I found, but none explained it particularly well.

Thank you!
 
OK. Before I go anywhere, I have been trying to get this round TFT screen to work to no avail.

https://wiki.keyestudio.com/KS0454_keyestudio_Circular_TFT_LCD_Smart_Watch_Display_Module

Seems to be confusion going on here.

Using this demo code:

Code:
/*!
 * @file ST7687SLatchDemo.ino
 * @brief Use this library to display various patterns on the screen, such as, rectangles, circles, lines. 
 * @copyright   Copyright (c) 2010 DFRobot Co.Ltd (http://www.dfrobot.com)
 * @license     The MIT license (MIT)
 * @author [fengli](li.feng@dfrobot.com)
 * @version  V1.0
 * @date  2022-03-25
 * @https://github.com/DFRobot/DFRobot_ST7687S
 */
 
#include "DFRobot_ST7687S_Latch.h"
#include "DFRobot_Display_Clock.h"
#include "SPI.h"

uint8_t pin_cs = 10, pin_rs = 5, pin_wr = 11, pin_lck = 4;
/**
 * @fn DFRobot_ST7687S_Latch
 * @brief Constructor pass the pins on the main controller to enable SPI communication
 * @param pin_cs the chip select pin in SPI communication
 * @param pin_cd the data/command select pin in communication
 * @param pin_wr the data pin (MOSI) in communication
 * @param pin_rck the clock pin in communication
 * @return None
 */
DFRobot_ST7687S_Latch tft(pin_cs, pin_rs, pin_wr, pin_lck);

void setup(void)
{
  Serial.begin(115200);
  tft.begin();
}

void loop(void)
{
  delay(1000);
  tft.fillScreen(DISPLAY_RED);  //fill screen with color
  delay(1000);
  tft.fillScreen(DISPLAY_WHITE);

  tft.fillScreen(DISPLAY_BLACK);
  tft.drawCircle(0, 0, 20, DISPLAY_GREEN);  //draw circle at (0, 0) and radius = 20
  tft.drawRect(-20, -30, 40, 60, DISPLAY_CYAN);  //draw rectangle at (-20, -30), width = 40, height = 60
  tft.drawLine(-64, -64, 64, 64, DISPLAY_RED);  //draw line at (-64, -64) to (64, 64)
  tft.drawHLine(-64, 0, 128, DISPLAY_WHITE);  //draw horizontal line at (-64, 0), length = 128
  tft.drawVLine(0, -64, 128, DISPLAY_WHITE);  //draw vertical line at (0, -128), length = 128
  tft.drawTriangle(-20, -50, 0, 0, 50, 20, DISPLAY_ORANGE);  //draw triangle at (-20, -50), (0, 0), (50, 20)
  delay(1000);
  tft.fillCircle(0, 0, 20, DISPLAY_GREEN);  //fill circle
  delay(500);
  tft.fillRect(-20, -20, 40, 40, DISPLAY_CYAN);  //fill rectangle
  delay(500);
  tft.fillTriangle(-20, -50, -20, 0, 50, 20, DISPLAY_ORANGE);  //fill triangle with color
  delay(500);
  tft.fillScreen(DISPLAY_BLACK);
  tft.setTextColor(DISPLAY_WHITE);  //set text color to white
  tft.setTextBackground(DISPLAY_BLACK);  //set text background to black
  tft.setTextSize(2);  //2 * text size, default text size: 6 * 8
  tft.setCursor(tft.width / 2, tft.height / 2);  //set text position to center
  tft.print("fire");
  delay(1000);
  tft.setCursor(tft.width / 2, tft.height / 2);
  tft.print("beet");
  delay(1000);
}

This code mentions that pin WR is Mosi? That seems incorrect to the webpage I have been following.
Just got a blank screen and just cannot get the pins correct to fire it up off a 3.2

For SPI comms... do you link Mosi to Mosi, Miso to Miso, or do you cross those comms lines? Pretty sure it's Mosi - Mosi etc. Therefore, why in the demo code does it state that WR is Mosi?
 
This has appeared.... can someone shed light on what it means?

WARNING: Category 'display' in library DFRobot_ST7687S is not valid. Setting to 'Uncategorized'
 
So, got it working....

Then noticed something not quite right. That will be an accidental 5v connected to the 3.3v pin of the Teensy 3.2 :mad: Not done that in a while.

I assume that is another dead Teensy for the bin then
 
A 3.2 has Canbus ability I believe. Seeing as I am only reading data, I assume I can connect directly to the car's bus using CanH and CanL? (I have the Canbus transceiver board)
Your assumption is correct. I did the same for my motorbike using a Teensy 3.2 and CAN bus transceiver.
However, setting up the hardware and reading out the CAN bus is the easy part. You will probably have to do some serious searching for information on how your car is transmitting the engine temp on the CAN bus; which CAN message ID contains the information you are looking for and what the CAN data bytes actually represent.

Paul
 
Yes... I have been literally Googling for 2 hours on this.
Ideally, I would find someone's code I can adapt or use to try and understand the process. How I filter out the information is proving to be very difficult to pin down.

Does anyone have a link to a setup that actually can say retrieve the RPM or something? It's a minefield of garbled information and I have no idea which library to use.

I have an MCP2562S Canbus breakout board here, but I believe I can directly connect to the Teensy 3.2 using a simpler SN65HVD23 board. The MCP2562S obviously does more, so what exactly is the difference? I assume it takes some of the comms work away from the Teensy (in which case.... what library to use!).

Eyes are tired now
 
How do you actually determine what data to request and the format? (for instance, to request MPH)?

I believe you need to be looking for a list of PID's, preferably make/model specific. These serve to identify the different values and sensor readings accessible thru the CANBUS. Some of these are fairly standard/universal for the most common sensors, like VSS, O2's, ECT, IAT, etc. But I'm fairly certain there are also non-published, model specific PID's use by the car manufacturers in-house diagnostic equipment. The more expensive scan tools typically have options to pull "global" or "OEM Enhanced" readings.

noticed something not quite right. That will be an accidental 5v connected to the 3.3v pin of the Teensy 3.2 :mad: Not done that in a while.

I assume that is another dead Teensy for the bin then

The 3.2 is 5V pin tolerant (expect for the 4 "analog only" inputs), so you're perfectly safe. No harm done.
 
Ideally, I would find someone's code I can adapt or use to try and understand the process.
For what you want [reading out basic car/engine parameters], sniffing the CAN bus may not be right choice.
Lots of car diagnostic tools use the K-line signal for reading out those parameters. This K-line signal is usually part of the OBD2 connector.
Check out this article. Googled for "obd2 arduino k-line".

Paul
 
OK Thanks for the help. I will look into the K line signal as well.

As for the fried Teensy.... well it's dead! I have 2 power rails on my breadboard. Top one i5 5v supply from a 7805 that feeds the Vin. The bottom breadboard rail is 3.3v taken off the Teensy 3.3v output.
I didn't notice that I had a link (from an old project) between the two power rails, so the 3.3v output pin got 5v on it. It worked for about an hour then died. No longer available on the USB.

Looking at the spec for the main IC and the bootloader, they are not 5v tolerable, so I imagine it's fried.

I also was wondering how you determine the 'scale' of the data you are obtaining. By that I mean RPM is pretty obvious, but other things like temps etc.... they are all going to require different scales around the edge of my display with the correct format/scale.

There is some software called Torque. I have the free version. Maybe I can determine the scale values from that.
 
OK. Plodding along OK.

First.... what do these warning actually mean and how do I correct them? (do I need to correct them?)

WARNING: Category 'Utility' in library FlexIO_t4 is not valid. Setting to 'Uncategorized'
WARNING: Category 'display' in library DFRobot_ST7687S is not valid. Setting to 'Uncategorized'

I am building this on a Teensy 3.2. But... those puppies are in short supply, so I am wondering if building it on a 4.1 is a better solution.
Is the 4.1 significantly faster? My graphics to the TFT screen are OK, but a faster processor may make them smoother
 
I'll stop the thread here then.

Would switch over to a Teensy 4.1, but I may need to 'make my own' as the standard 4.1 footprint PCB is far too long for my needs. BUT.... no bootloaders available for the 4.1. This chip shortage is getting ridiculous.

We have already aborted a fairly large project based on the 3.2 chip and associated bootloaders. We designed the prototyped board and were ready to go, but can't get the parts now.
Moved that project over to Pi Zero's as we had 100 in our stock.

Also bought a much nicer round LCD display which already has Arduino support.

Might have to look at other options other than a Teensy which would suck
 
Would switch over to a Teensy 4.1, but I may need to 'make my own' as the standard 4.1 footprint PCB is far too long for my needs. BUT.... no bootloaders available for the 4.1. This chip shortage is getting ridiculous.
Why can't you use the 4.0, they are the same size as the 3.2? Oh and also way faster than the 3.2.
 
I planned to use the Ethernet breakout on the 4.1. Don't think that is available on the 4.0? (I might be wrong).

I may play about with a 4 if I can find one
 
Swapped the project over to a 4.0. Broke the code entirely.

Now the TFT doesn't seem to work properly, and the Fastled library work work either (4.0 too fast?). Tried different pins for the RGB leds. Tried slowing the for loops in the RGB draw statements, but no change.

Now got 3 error messages:

WARNING: Category 'Utility' in library FlexIO_t4 is not valid. Setting to 'Uncategorized'
WARNING: Category 'display' in library DFRobot_ST7687S is not valid. Setting to 'Uncategorized'
WARNING: Category '' in library GFX Library for Arduino is not valid. Setting to 'Uncategorized'

Hmm, starting to think this is going to be too much of an uphill struggle.
 
I would appreciate some assistance in connecting this screen to my Teensy 4.0. I don't seem to be able to work out how to declare the pins (I can literally use any pins).

https://www.amazon.co.uk/gp/product/B08V5538C6/ref=sw_img_1?smid=A3U321I9X7C9XA&th=1

The demo code I have for this is:

Code:
/*
   Arduino Watch Lite Version
   You may find full version at: https://github.com/moononournation/ArduinoWatch
*/

/*******************************************************************************
 * Start of Arduino_GFX setting
 * 
 * Arduino_GFX try to find the settings depends on selected board in Arduino IDE
 * Or you can define the display dev kit not in the board list
 * Defalult pin list for non display dev kit:
 * Arduino Nano, Micro and more: CS:  9, DC:  8, RST:  7, BL:  6
 * ESP32 various dev board     : CS:  5, DC: 27, RST: 33, BL: 22
 * ESP32-C3 various dev board  : CS:  7, DC:  2, RST:  1, BL:  3
 * ESP32-S2 various dev board  : CS: 34, DC: 35, RST: 33, BL: 21
 * ESP32-S3 various dev board  : CS: 40, DC: 41, RST: 42, BL: 48
 * ESP8266 various dev board   : CS: 15, DC:  4, RST:  2, BL:  5
 * Raspberry Pi Pico dev board : CS: 17, DC: 27, RST: 26, BL: 28
 * RTL8720 BW16 old patch core : CS: 18, DC: 17, RST:  2, BL: 23
 * RTL8720_BW16 Official core  : CS:  9, DC:  8, RST:  6, BL:  3
 * RTL8722 dev board           : CS: 18, DC: 17, RST: 22, BL: 23
 * RTL8722_mini dev board      : CS: 12, DC: 14, RST: 15, BL: 13
 * Seeeduino XIAO dev board    : CS:  3, DC:  2, RST:  1, BL:  0
 * Teensy 4.1 dev board        : CS: 39, DC: 41, RST: 40, BL: 22
 ******************************************************************************/
#include <Arduino_GFX_Library.h>

#define DF_GFX_SCK 13
#define DF_GFX_MOSI 11
#define DF_GFX_MISO 12
#define DF_GFX_CS 10
#define DF_GFX_DC 7
#define DF_GFX_RST 5
#define DF_GFX_BL 4

//#define GFX_BL DF_GFX_BL // default backlight pin, you may replace DF_GFX_BL to actual backlight pin

/* More dev device declaration: https://github.com/moononournation/Arduino_GFX/wiki/Dev-Device-Declaration */
#if defined(DISPLAY_DEV_KIT)
Arduino_GFX *gfx = create_default_Arduino_GFX();
#else /* !defined(DISPLAY_DEV_KIT) */

/* More data bus class: https://github.com/moononournation/Arduino_GFX/wiki/Data-Bus-Class */
Arduino_DataBus *bus = create_default_Arduino_DataBus();

/* More display class: https://github.com/moononournation/Arduino_GFX/wiki/Display-Class */
Arduino_GFX *gfx = new Arduino_ILI9341(bus, DF_GFX_RST, 0 /* rotation */, false /* IPS */);

#endif /* !defined(DISPLAY_DEV_KIT) */
/*******************************************************************************
 * End of Arduino_GFX setting
 ******************************************************************************/

#define BACKGROUND BLACK
#define MARK_COLOR WHITE
#define SUBMARK_COLOR DARKGREY // LIGHTGREY
#define HOUR_COLOR WHITE
#define MINUTE_COLOR BLUE // LIGHTGREY
#define SECOND_COLOR RED

#define SIXTIETH 0.016666667
#define TWELFTH 0.08333333
#define SIXTIETH_RADIAN 0.10471976
#define TWELFTH_RADIAN 0.52359878
#define RIGHT_ANGLE_RADIAN 1.5707963

static uint8_t conv2d(const char *p)
{
    uint8_t v = 0;
    return (10 * (*p - '0')) + (*++p - '0');
}

static int16_t w, h, center;
static int16_t hHandLen, mHandLen, sHandLen, markLen;
static float sdeg, mdeg, hdeg;
static int16_t osx = 0, osy = 0, omx = 0, omy = 0, ohx = 0, ohy = 0; // Saved H, M, S x & y coords
static int16_t nsx, nsy, nmx, nmy, nhx, nhy;                         // H, M, S x & y coords
static int16_t xMin, yMin, xMax, yMax;                               // redraw range
static int16_t hh, mm, ss;
static unsigned long targetTime; // next action time

static int16_t *cached_points;
static uint16_t cached_points_idx = 0;
static int16_t *last_cached_point;

void setup(void)
{
    gfx->begin();
    gfx->fillScreen(BACKGROUND);

#ifdef GFX_BL
    pinMode(GFX_BL, OUTPUT);
    digitalWrite(GFX_BL, HIGH);
#endif

    // init LCD constant
    w = gfx->width();
    h = gfx->height();
    if (w < h)
    {
        center = w / 2;
    }
    else
    {
        center = h / 2;
    }
    hHandLen = center * 3 / 8;
    mHandLen = center * 2 / 3;
    sHandLen = center * 5 / 6;
    markLen = sHandLen / 6;
    cached_points = (int16_t *)malloc((hHandLen + 1 + mHandLen + 1 + sHandLen + 1) * 2 * 2);

    // Draw 60 clock marks
    draw_round_clock_mark(
    // draw_square_clock_mark(
        center - markLen, center,
        center - (markLen * 2 / 3), center,
        center - (markLen / 2), center);

    hh = conv2d(__TIME__);
    mm = conv2d(__TIME__ + 3);
    ss = conv2d(__TIME__ + 6);

    targetTime = ((millis() / 1000) + 1) * 1000;
}

void loop()
{
    unsigned long cur_millis = millis();
    if (cur_millis >= targetTime)
    {
        targetTime += 1000;
        ss++; // Advance second
        if (ss == 60)
        {
            ss = 0;
            mm++; // Advance minute
            if (mm > 59)
            {
                mm = 0;
                hh++; // Advance hour
                if (hh > 23)
                {
                    hh = 0;
                }
            }
        }
    }

    // Pre-compute hand degrees, x & y coords for a fast screen update
    sdeg = SIXTIETH_RADIAN * ((0.001 * (cur_millis % 1000)) + ss); // 0-59 (includes millis)
    nsx = cos(sdeg - RIGHT_ANGLE_RADIAN) * sHandLen + center;
    nsy = sin(sdeg - RIGHT_ANGLE_RADIAN) * sHandLen + center;
    if ((nsx != osx) || (nsy != osy))
    {
        mdeg = (SIXTIETH * sdeg) + (SIXTIETH_RADIAN * mm); // 0-59 (includes seconds)
        hdeg = (TWELFTH * mdeg) + (TWELFTH_RADIAN * hh);   // 0-11 (includes minutes)
        mdeg -= RIGHT_ANGLE_RADIAN;
        hdeg -= RIGHT_ANGLE_RADIAN;
        nmx = cos(mdeg) * mHandLen + center;
        nmy = sin(mdeg) * mHandLen + center;
        nhx = cos(hdeg) * hHandLen + center;
        nhy = sin(hdeg) * hHandLen + center;

        // redraw hands
        redraw_hands_cached_draw_and_erase();

        ohx = nhx;
        ohy = nhy;
        omx = nmx;
        omy = nmy;
        osx = nsx;
        osy = nsy;

        delay(1);
    }
}

void draw_round_clock_mark(int16_t innerR1, int16_t outerR1, int16_t innerR2, int16_t outerR2, int16_t innerR3, int16_t outerR3)
{
  float x, y;
  int16_t x0, x1, y0, y1, innerR, outerR;
  uint16_t c;

  for (uint8_t i = 0; i < 60; i++)
  {
    if ((i % 15) == 0)
    {
      innerR = innerR1;
      outerR = outerR1;
      c = MARK_COLOR;
    }
    else if ((i % 5) == 0)
    {
      innerR = innerR2;
      outerR = outerR2;
      c = MARK_COLOR;
    }
    else
    {
      innerR = innerR3;
      outerR = outerR3;
      c = SUBMARK_COLOR;
    }

    mdeg = (SIXTIETH_RADIAN * i) - RIGHT_ANGLE_RADIAN;
    x = cos(mdeg);
    y = sin(mdeg);
    x0 = x * outerR + center;
    y0 = y * outerR + center;
    x1 = x * innerR + center;
    y1 = y * innerR + center;

    gfx->drawLine(x0, y0, x1, y1, c);
  }
}

void draw_square_clock_mark(int16_t innerR1, int16_t outerR1, int16_t innerR2, int16_t outerR2, int16_t innerR3, int16_t outerR3)
{
    float x, y;
    int16_t x0, x1, y0, y1, innerR, outerR;
    uint16_t c;

    for (uint8_t i = 0; i < 60; i++)
    {
        if ((i % 15) == 0)
        {
            innerR = innerR1;
            outerR = outerR1;
            c = MARK_COLOR;
        }
        else if ((i % 5) == 0)
        {
            innerR = innerR2;
            outerR = outerR2;
            c = MARK_COLOR;
        }
        else
        {
            innerR = innerR3;
            outerR = outerR3;
            c = SUBMARK_COLOR;
        }

        if ((i >= 53) || (i < 8))
        {
            x = tan(SIXTIETH_RADIAN * i);
            x0 = center + (x * outerR);
            y0 = center + (1 - outerR);
            x1 = center + (x * innerR);
            y1 = center + (1 - innerR);
        }
        else if (i < 23)
        {
            y = tan((SIXTIETH_RADIAN * i) - RIGHT_ANGLE_RADIAN);
            x0 = center + (outerR);
            y0 = center + (y * outerR);
            x1 = center + (innerR);
            y1 = center + (y * innerR);
        }
        else if (i < 38)
        {
            x = tan(SIXTIETH_RADIAN * i);
            x0 = center - (x * outerR);
            y0 = center + (outerR);
            x1 = center - (x * innerR);
            y1 = center + (innerR);
        }
        else if (i < 53)
        {
            y = tan((SIXTIETH_RADIAN * i) - RIGHT_ANGLE_RADIAN);
            x0 = center + (1 - outerR);
            y0 = center - (y * outerR);
            x1 = center + (1 - innerR);
            y1 = center - (y * innerR);
        }
        gfx->drawLine(x0, y0, x1, y1, c);
    }
}

void redraw_hands_cached_draw_and_erase()
{
    gfx->startWrite();
    draw_and_erase_cached_line(center, center, nsx, nsy, SECOND_COLOR, cached_points, sHandLen + 1, false, false);
    draw_and_erase_cached_line(center, center, nhx, nhy, HOUR_COLOR, cached_points + ((sHandLen + 1) * 2), hHandLen + 1, true, false);
    draw_and_erase_cached_line(center, center, nmx, nmy, MINUTE_COLOR, cached_points + ((sHandLen + 1 + hHandLen + 1) * 2), mHandLen + 1, true, true);
    gfx->endWrite();
}

void draw_and_erase_cached_line(int16_t x0, int16_t y0, int16_t x1, int16_t y1, int16_t color, int16_t *cache, int16_t cache_len, bool cross_check_second, bool cross_check_hour)
{
#if defined(ESP8266)
    yield();
#endif
    bool steep = _diff(y1, y0) > _diff(x1, x0);
    if (steep)
    {
        _swap_int16_t(x0, y0);
        _swap_int16_t(x1, y1);
    }

    int16_t dx, dy;
    dx = _diff(x1, x0);
    dy = _diff(y1, y0);

    int16_t err = dx / 2;
    int8_t xstep = (x0 < x1) ? 1 : -1;
    int8_t ystep = (y0 < y1) ? 1 : -1;
    x1 += xstep;
    int16_t x, y, ox, oy;
    for (uint16_t i = 0; i <= dx; i++)
    {
        if (steep)
        {
            x = y0;
            y = x0;
        }
        else
        {
            x = x0;
            y = y0;
        }
        ox = *(cache + (i * 2));
        oy = *(cache + (i * 2) + 1);
        if ((x == ox) && (y == oy))
        {
            if (cross_check_second || cross_check_hour)
            {
                write_cache_pixel(x, y, color, cross_check_second, cross_check_hour);
            }
        }
        else
        {
            write_cache_pixel(x, y, color, cross_check_second, cross_check_hour);
            if ((ox > 0) || (oy > 0))
            {
                write_cache_pixel(ox, oy, BACKGROUND, cross_check_second, cross_check_hour);
            }
            *(cache + (i * 2)) = x;
            *(cache + (i * 2) + 1) = y;
        }
        if (err < dy)
        {
            y0 += ystep;
            err += dx;
        }
        err -= dy;
        x0 += xstep;
    }
    for (uint16_t i = dx + 1; i < cache_len; i++)
    {
        ox = *(cache + (i * 2));
        oy = *(cache + (i * 2) + 1);
        if ((ox > 0) || (oy > 0))
        {
            write_cache_pixel(ox, oy, BACKGROUND, cross_check_second, cross_check_hour);
        }
        *(cache + (i * 2)) = 0;
        *(cache + (i * 2) + 1) = 0;
    }
}

void write_cache_pixel(int16_t x, int16_t y, int16_t color, bool cross_check_second, bool cross_check_hour)
{
    int16_t *cache = cached_points;
    if (cross_check_second)
    {
        for (uint16_t i = 0; i <= sHandLen; i++)
        {
            if ((x == *(cache++)) && (y == *(cache)))
            {
                return;
            }
            cache++;
        }
    }
    if (cross_check_hour)
    {
        cache = cached_points + ((sHandLen + 1) * 2);
        for (uint16_t i = 0; i <= hHandLen; i++)
        {
            if ((x == *(cache++)) && (y == *(cache)))
            {
                return;
            }
            cache++;
        }
    }
    gfx->writePixel(x, y, color);
}

I added those pin definitions (lines 28-34), but they don't work. Don't really understand what I am doing. I would assume I don't need Miso (DIN) for this screen, just Mosi (Dout)? Declared both anyway.

Not sure what it means regarding the backlight either? I do wish these demo's were geared towards us simple folk!
 
I would appreciate some assistance in connecting this screen to my Teensy 4.0. I don't seem to be able to work out how to declare the pins (I can literally use any pins).

I added those pin definitions (lines 28-34), but they don't work. Don't really understand what I am doing. I would assume I don't need Miso (DIN) for this screen, just Mosi (Dout)? Declared both anyway.

Not sure what it means regarding the backlight either? I do wish these demo's were geared towards us simple folk!

Without looking at the library itself, I would say the line below in the table at the top of your program indicates the default pin usage for T4.1. There is no line for T4.0, so you might have to add support for T4.0 yourself. Search the library for "teensy" (ignoring case) and see what you can find. Look for "teensy"-specific code for initialization of the interface to the screen, both for SPI and the other pins.

Code:
* Teensy 4.1 dev board        : CS: 39, DC: 41, RST: 40, BL: 22
 
I have found several resources (youtube video etc) regarding this display, but they all use an UNO.
Pretty sure this library doesn't support a Teensy 4.0 in any form.

I thought I would be able to simply add in my own pin definitions at the start and that would over-ride the preset ones

I have had many attempts here (commented out), but no idea what I am doing!

Code:
 * Start of Arduino_GFX setting
 * 
 * Arduino_GFX try to find the settings depends on selected board in Arduino IDE
 * Or you can define the display dev kit not in the board list
 * Defalult pin list for non display dev kit:
 * Arduino Nano, Micro and more: CS:  9, DC:  8, RST:  7, BL:  6
 * ESP32 various dev board     : CS:  5, DC: 27, RST: 33, BL: 22
 * ESP32-C3 various dev board  : CS:  7, DC:  2, RST:  1, BL:  3
 * ESP32-S2 various dev board  : CS: 34, DC: 35, RST: 33, BL: 21
 * ESP32-S3 various dev board  : CS: 40, DC: 41, RST: 42, BL: 48
 * ESP8266 various dev board   : CS: 15, DC:  4, RST:  2, BL:  5
 * Raspberry Pi Pico dev board : CS: 17, DC: 27, RST: 26, BL: 28
 * RTL8720 BW16 old patch core : CS: 18, DC: 17, RST:  2, BL: 23
 * RTL8720_BW16 Official core  : CS:  9, DC:  8, RST:  6, BL:  3
 * RTL8722 dev board           : CS: 18, DC: 17, RST: 22, BL: 23
 * RTL8722_mini dev board      : CS: 12, DC: 14, RST: 15, BL: 13
 * Seeeduino XIAO dev board    : CS:  3, DC:  2, RST:  1, BL:  0
 * Teensy 4.1 dev board        : CS: 39, DC: 41, RST: 40, BL: 22
 ******************************************************************************/
#include <Arduino_GFX_Library.h>
/*
#define DF_GFX_SCK 13
#define DF_GFX_MOSI 11 (dout)
#define DF_GFX_MISO 12 (din)
#define DF_GFX_CS 10
#define DF_GFX_DC 7
#define DF_GFX_RST 5
#define DF_GFX_BL 4

#define DEV_MOSI_PIN 11
#define DEV_MISO_PIN 12
#define DEV_SCK_PIN 13
#define DEV_CS_PIN 10
#define DEV_DC_PIN 7
#define DEV_RST_PIN 5
#define DEV_BL_PIN 4
*/

//#define GFX_BL DF_GFX_BL // default backlight pin, you may replace DF_GFX_BL to actual backlight pin

/* More dev device declaration: https://github.com/moononournation/Arduino_GFX/wiki/Dev-Device-Declaration */
#if defined(DISPLAY_DEV_KIT)
Arduino_GFX *gfx = create_default_Arduino_GFX();
#else /* !defined(DISPLAY_DEV_KIT) */

//Arduino_DataBus *bus = new Arduino_SWSPI (8/ DC /, 9/ CS /, 13 / SCK /, 11/ MOSI /, -1 / MISO */);
//Arduino_DataBus *bus = new Arduino_SWSPI (7/ DF_GFX_DC /, 10/ CS /, 13 / SCK /, 11/ MOSI /, -1 / MISO */);

Arduino_DataBus *bus = create_default_Arduino_DataBus();

Arduino_GFX *gfx = new Arduino_GC9A01(bus, 7 /* RST */, 0 /* rotation */, true /* IPS */);


/* More data bus class: https://github.com/moononournation/Arduino_GFX/wiki/Data-Bus-Class */


#endif /* !defined(DISPLAY_DEV_KIT) */

This is the library I am playing with:
https://www.arduino.cc/reference/en/libraries/gfx-library-for-arduino/

Video I found: https://www.youtube.com/watch?v=NK0Sx49XQdI
 
Just changed those definitions as recommended above and it's spluttering! No display yet, but occasional flashes of light are a start

Something is still not quite right...
 
My Teensy 4 just entirely died for no obvious apparent reason. I don't see anything connected incorrectly, and it's only powered from the USB lead.
Tried an UNO and the USB lead is fine, so that is the 4.0 dead I assume. I am finding these Teensy's madly tempermental and so it looks like this will have to run off an UNO now, as I don't have any more Teensy's.

No idea what kill that.

..... with the Teensy 4 out of the breadboard and connected to a USB lead, the 6 pin IC bottom left of the USB socket is red hot. Bin
 
The UNO is running at 5V?

Is the Display producing 5V? Or switched to 3.3V where it can work?

The Teensy 4 is not 5V tolerant and 5V will destroy it.
 
Yes, I know the 4.0 is 3.3v. This screen is apparently 3.3v and 5v tolerant.

Well the 4.0 is dead. Took the regulator off and the 3.3v output pin from the regulator is a dead short. So I can only assume the main processor is gone. Very annoying, as it wall all running off 3.3v and I have absolutely no idea why that died.
I had a separate 3.3v reg running the screen (too much for the Teensy regulator).

So.... that killed that idea.

Thought I would at least try and get it running on a spare 3.2, but absolutely no go. It's not supported in the Arduino_GFX_library.h file.

I tried adding the following, but it just kept throwing up errors.

Code:
#elif defined(__MK20DX128__) || defined(__MK20DX128__)     
// Teensy 3.2  
#define DF_GFX_SCK 13
#define DF_GFX_MOSI 11
#define DF_GFX_MISO 12
#define DF_GFX_CS 10
#define DF_GFX_DC 7
#define DF_GFX_RST 5
#define DF_GFX_BL 4

Would it even be possible to run it off a Teensy 3.2? I don't see why not. These pins just happen to be the ones I was using.

An UNO doesn't have the processing power, so it looks like the project is shelved until further notice. So annoying. It's when these things don't work as you expect and start fiddling around with it that results in me killing my Teensy.
I had it all nicely breadboarded until it didn't work at all and then I obviously did something wrong.

I do wish these libraries were a little bit more user friendly to us idiots. I don't find it easy at all to understand how to change settings, pins etc
 
Dead hardware is no fun. :(

Well the 4.0 is dead. Took the regulator off and the 3.3v output pin from the regulator is a dead short. So I can only assume the main processor is gone.

Usually a dead processor will result in about 0.5 to 0.9 volts on the 3.3V power line, as the regulator tries as hard as it can to power up but goes into current limit mode. Usually that means hardware loss and not worthwhile to spend time trying to fix it.

Usually if you get close to zero volts while the regulator is trying as hard as it can to deliver current, that's a pretty strong sign the short is metal rather than semiconductor. To really tell the difference between a failed semiconductor short versus real metal, you'll need a large current like a voltage regulator in current limit mode. The tiny test current from your multimeter in ohms mode (probably) isn't going to show you the clear difference between semiconductor versus metal. Since you said "dead short" I'm guessing you have a piece of metal causing the problem, but before you spend a lot of time, best to get get a good idea whether the short really is metal vs semiconductor.

If you can find and remove the metal causing the short, often the board will come back to life. Of course that's easier said than done. If you have a DC voltmeter with a sensitive mV scale, sometimes you can discover where the large current is flowing by measuring voltage between multiple GND or multiple 3.3V points. Because they're connected, you'd normally expect to see 0 volts. But if a large current from the regulator is flowing through the PCB traces or planes, you might see several mV. By measuring which pairs of should-be-connected points have mV indicating large current flow, and which pairs of locations do not, maybe you can narrow down your search for the errant metal.


I tried adding the following, but it just kept throwing up errors.

Code:
#elif defined(__MK20DX128__) || defined(__MK20DX128__)     
// Teensy 3.2  
#define DF_GFX_SCK 13
#define DF_GFX_MOSI 11
#define DF_GFX_MISO 12
#define DF_GFX_CS 10
#define DF_GFX_DC 7
#define DF_GFX_RST 5
#define DF_GFX_BL 4

I see you have defined(__MK20DX128__) twice, but no check at all for defined(__MK20DX256__). That might not work so well for Teensy 3.2, which uses the MK20DX256 chip.


I do wish these libraries were a little bit more user friendly to us idiots. I don't find it easy at all to understand how to change settings, pins etc

Arduino_GFX is relatively new. I probably need to work with it sometime soon. Right now I'm pretty overloaded with a ton of other software work and keeping up with supply chain problems.
 
Thanks for the reply Paul.
Pretty sure the processor is the cause, but I may investigate a little further. I was breadboard on my dining room table and suddenly just died, so I don't see how a metal short would have occurred.

I have looked over the entire 4.0 under the microscope and cannot see any shorted or bad solder joints.

As for my sad attempt at adding the 3.2 myself lol.... I found some other code online that appeared to use the __MK20DX128__ for a Teensy 3.2 (incorrectly then?).

I simply copied the text for the 4.0:

Code:
#elif defined(__IMXRT1052__) || defined(__IMXRT1062__)
// PJRC Teensy 4.x
#define DF_GFX_CS 10 // GFX_NOT_DEFINED for display without CS pin
#define DF_GFX_DC 7
#define DF_GFX_RST 5
#define DF_GFX_BL 4

And inserted the __MK20DX128__ twice instead.

Again, I will have another play.

Thanks for the help
 
Back
Top