Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 2 1 2 LastLast
Results 1 to 25 of 39

Thread: Flexcan, canbus... brain fried and confused

  1. #1
    Senior Member
    Join Date
    Sep 2019
    Posts
    233

    Flexcan, canbus... brain fried and confused

    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!

  2. #2
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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_k...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?

  3. #3
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    This has appeared.... can someone shed light on what it means?

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

  4. #4
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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 Not done that in a while.

    I assume that is another dead Teensy for the bin then

  5. #5
    Senior Member PaulS's Avatar
    Join Date
    Apr 2015
    Location
    Netherlands
    Posts
    827
    Quote Originally Posted by SteveSFX View Post
    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

  6. #6
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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

  7. #7
    Junior Member
    Join Date
    Feb 2020
    Posts
    9
    Quote Originally Posted by SteveSFX View Post
    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.

    Quote Originally Posted by SteveSFX View Post
    noticed something not quite right. That will be an accidental 5v connected to the 3.3v pin of the Teensy 3.2 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.

  8. #8
    Senior Member PaulS's Avatar
    Join Date
    Apr 2015
    Location
    Netherlands
    Posts
    827
    Quote Originally Posted by SteveSFX View Post
    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

  9. #9
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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.

  10. #10
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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

  11. #11
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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

  12. #12
    Senior Member BriComp's Avatar
    Join Date
    Apr 2014
    Location
    Cheltenham, UK
    Posts
    819
    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.

  13. #13
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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

  14. #14
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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.

  15. #15
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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/...1I9X7C9XA&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!

  16. #16
    Quote Originally Posted by SteveSFX View Post
    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

  17. #17
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,249
    Found US: amazon.com/gp/product/B08V5538C6

    Title notes : SPI Interface Embedded GC9A01 Driver

    Led to: github.com/carlfriess/GC9A01_demo

    That link for STC12C5A driver led to this: arduino.cc/t/240x240-round-display-with-gc9a01-driver-undocumented-command/661217

    Not sure if that gets anywhere to finding a better library ...

  18. #18
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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/...y-for-arduino/

    Video I found: https://www.youtube.com/watch?v=NK0Sx49XQdI

  19. #19
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,249
    In github.com/moononournation/Arduino_GFX/blob/master/src/Arduino_GFX_Library.h

    I see this 'hardcoded' at: github.com/moononournation/Arduino_GFX/blob/master/src/Arduino_GFX_Library.h#L117
    Code:
    #elif defined(__IMXRT1052__) || defined(__IMXRT1062__)
    // PJRC Teensy 4.x
    #define DF_GFX_CS 39 // GFX_NOT_DEFINED for display without CS pin
    #define DF_GFX_DC 41
    #define DF_GFX_RST 40
    #define DF_GFX_BL 22
    That looks like it will take precedence.

    Perhaps editing that to expected SPI pins ???

  20. #20
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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...

  21. #21
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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

  22. #22
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    16,249
    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.

  23. #23
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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

  24. #24
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,574
    Dead hardware is no fun.

    Quote Originally Posted by SteveSFX View Post
    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.

  25. #25
    Senior Member
    Join Date
    Sep 2019
    Posts
    233
    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

Posting Permissions

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