Multiple screens best solution query

Projects General Guidance
1

Hey all,

First post, long time lurker. A bit of backstory, I have a project car that I want to replace the 5 auxiliary analogue gauges (circa 1981) with a digital solution. These gauges display data like battery voltage, coolant and oil temperature and pressure (NTC sensors and voltage based pressure sensors), fuel level (resistance based) of various components.

I have already done this in a previous vehicle with less requirements where I found 2 OLED (SPI) screens that fit very well in the old gauges spots, hooked them up to an Arduino Uno over SPI and used some motorsport sensors (because they came with data sheets) for the data. It was a lot of fun learning all the maths around NTC sensors and how to use SPI.

However one of the main issues I ran into was the amount of memory and processing power required for the Arduino to hold the graphics and render both screens in a timely manner (potentially due to my programming ability as well). This was not an "issue" in the practical sense but it's working at the limits of the Uno.

Coming into this new project I want to use 5 screens to replace all the auxiliary gauges (I will be leaving the Tacho and Speedo analogue). This has coincided with me discovering the DWIN Dgus ii screens and Nextion screens which have an onboard graphics processing unit allowing for all of the heavy graphics processing to be moved from the Arduino over to the actual screen (I think this is so cool btw). The issue with these screens is they seem (as far as I can tell) to only work over a UART serial connection. The Arduino mega is the biggest board I know of and it has a maximum of 4 serial lanes, not to mention SPI is waaay faster than UART. Which leads me to my question.

Is there another Arduino device with more hardware serial lanes which I can use?
I know I can use the software serial library, this will be my solution if I can't find better hardware.

Are there another other screens with onboard graphics processing that I can communicate to via SPI instead of UART, noting the screens have to be about 2.1" and round?
This would be ideal as I believe the limit to SPI on a mega is way more than my requirements.

Thanks for any help

2

SAMD21 based boards have theoretically up to 6 sercoms (that you can use for uart, spi or i2c). Arduino Zero and MKR Zero are some of them, Adafruit also has some.

I'm not familiar with boards with the SAMD21. It might depend on the board design if they are all linked to board pins and some might be in use for other functionalities on the board.

You also have to configure the additional sercoms manually, there is e.g. only Serial1 on the Arduino Zero (Serial is the USB).

Alternative can be to use I2C/SPI UARTs like the dual UART https://www.robotics.org.za/CJMCU-752.

Note:
This is all 3.3V stuff.

3

Why do you need a faster interface? I mean if you're using displays like Nextion, which have a graphics microcontroller, you're actually sending a lot less data to the display.

1 Like
4

The PI pico can have up to 6 serial port if you use the PIO feature.

5

A designer would start with specifying how much data needs to be transported to each device per second, and for what purpose. With that in hand, you can choose capable hardware solutions appropriately.

For example, for each device, do you want 1, 10, 100 data updates per second, are the graphics displays things like needles (where an insignificant data change still causes noticeable twitch in the needle tip, unlike a true analog meter), are you trying to incorporate ballistics in the meter movements, etc. Or, conversely, are they numeric displays like 888.88, where too-frequent updates cause digits to blur?

6

This should help you in getting a good design that will survive.
Valuable Resources for Automotive Electronics:

  1. STMicroelectronics Application Note AN2689:
    This application note provides guidelines on protecting automotive electronics from electrical hazards, focusing on design and component selection. Reading this will greatly enhance your understanding of automotive circuit protection.
    Read AN2689
  2. Analog Devices: Automotive Electronics Design:
    This article distills key insights into designing automotive electronics, offering practical advice for engineers.
    Read the article
  3. Diodes Incorporated: Transient Voltage Suppression in Automotive:
    Learn about techniques to protect automotive circuits from transient voltage, which is critical for ensuring reliable operation in harsh conditions.
    Read the article
  4. AEC-100 Standards Webinar:
    This webinar from Monolithic Power Systems provides a detailed overview of AEC standards, essential for understanding automotive electronics requirements.
    Watch the webinar
  5. Understanding Automotive Electronics, An Engineering Perspective by William B. Ribbens:
    This comprehensive book offers an in-depth look into automotive electronics from an engineering perspective, making it an invaluable resource.
    Access the book
  6. Check this for OBD ISO9141 Code Meaning & How To Fix
  7. Load Dump and Cranking Protection for Automotiv Backlight LED Power Suppl https://www.ti.com/lit/an/snva681a/snva681a.pd

These resources should provide a strong foundation for anyone involved in automotive electronics design.

2 Likes
7

That's true but...

With SPI displays you need to send waaay more data to them, compared to a Nextion display.

For example if you want to print "Hello World" on a Nextion display, you only need to send 10 bytes, one byte for each character (ok, maybe a few more than that, there are always overheads).

But with an SPI display, let's assume each character is 8x8 pixels and each pixel is 3 bytes (R, G and B values) then printing "Hello World" would take 10 * 8 * 8 * 3 = 1920 bytes.

8

Hey all,

Thanks heaps for the replies so far. I don't really know how to effectively reply in a forum like this so I'll just cover what I think is relevant.

I like these solutions, although the challenge of understanding how the board is wired and how to manually define the serial lanes is something I don't know how to do yet.

I like the idea of finding an external SPI to multi UART bridge, although I imagine that will bring its own issues of finding a library that is compatible?? Aside from that I think it would be an ideal solution, I just can't find anything above a 4 way bridge.

Here's a link I found where someone built a 4 way UART bridge

In saying this, I could theoretically use more than one bridge right? Either 4 of the 2 way bridges or 2 of the 4 way bridges? Would I run into any issues doing this or is it a feasible solution?

How is the support for the PI Pico? It's not an Arduino, so I would imagine compatibility to the Arduino libraries will be a bit "how ya goin"? How does it differ from an Arduino when programming? I've read a few articles that suggest it's not straightforward?

This also looks like a great solution provided I can get the screens to talk to it.

Thank you very much for these resources, I'll try read them all, there are a few questions I've been try to find answers for in there, specifically how to protect my devices from the dirty power input and noisy environments typical of an automotive application. The setup in the other car has no protection at all, car battery straight into the 12v input on the Uno :sweat_smile::sweat_smile::sweat_smile:

To clarify my point about UART vs SPI a bit more

I am partial to SPI because I've used it before, I am familiar with it and it would solve the device number limitation I'm presented with, I also figured "faster is better". However, what you both said about needing less data per frame is a very important point.

The point made by @PaulRB was the primary issue I ran into with the UNO, the screens were 128 x 64, no RGB, but it has dimable pixels. Just updating both screens with an on or off value (not including brightness or any other parameters) works out to 32,768 bytes of data every frame. This is because the Arduino is drawing every frame unaided (potentially a major flaw in my programming, I don't know how else to do it).

I guess the idea I'm looking at now is to be able to send just the message I want to display, similar to @PaulRB's UART example, over an SPI connection to a display with onboard graphical processing. This would solve all my issues about device limits with the added benefit of having all the speed I need. I would be limited by the refresh rate of the screen not the arduinos communication rate.

I don't really care what the refresh rate is at this point, I'm more concerned with just finding something that will work first, however, to answer you question, I will be running both dials and a numbers on the display, so I think I'll need a higher refresh rate for the dial gauge, while sending numerical updates intermittently to prevent blurring and decreasing communication frequency.

9

I think you could use something like this to multiplex the uarts the multiple Nextions.

https://www.sparkfun.com/sparkfun-analog-digital-mux-breakout-cd74hc4067.html

Since the mux/demux also works with digital signals, you can use it to pipe TTL-level serial data to or from multiple devices. For example, you could use it to connect the TX pins of 16 devices to one RX pin on your microcontroller. You can then select any one of those 16 devices to listen to. If you want two-way communications, you can add a second board to route your microcontroller's TX line to 16 device's RX lines.

1 Like
10

That board has CS signals so you can select one board out of many. Each board that you connect will require a dedicated pin for CS on your microcontroller.

For the board that I mentioned it can work the same (SPI) as the board that you did find or you can configure 4 I2C addresses giving you a total of 8 UARTs.

11

It sounds like you have some skilz and, if you've deployed to the automotive environment, some experience with getting that to work.

Even if you got an SPI bridge functioning, you'd still be using serial UART control, so… I suggest to you to fearlessly embark on a USRT solution, either with N real UARTs, or synthesized Software serial or the bridge thing.

As @camsysca said, first step is to weigh things up. Then learn/research using the more sophisticated display using serial comms.

Start with one display on a real serial port using a Mega and see what you can get it to do.

I started with a quote about your chops and wonder if you would post the sketch that does two OLEDs at the edge of the possibility of success so we can gauge (see what I did there?) your level of ability and confidence. TBH Imma guess you got this and it won't be that hard to figure out how to wring the max out of the better displays.

We here to help. I can't much, as I have never used those displays, but I will pay attention because they do sound like the bomb. And the rest is just code.

a7

1 Like
12

Just a little update for posterity,

I've done some more research, I thought I'd give ChatGPT a go since google is so good awful these days. So there's your forewarning

It's looking like I will use the DWIN displays and an Arduino mega. Coupled with the board recommend by @sterretje (SC16IS752). This will give me effectively 6 serial TX/RX channels to work with.

I think it is also important to note that I believe that you cannot configure the 8 programmable GPIO as TX / RX lines (this is how I interpreted the replies) they can only be programmed for uses like interrupt (request to send or clear to send for example). I'm pretty sure this board is only capable of dual channel full-duplex communication.

I believe there are a few other options for those wanting to undertake a similar project.

I have found these ESP32-S3 displays that have a ESP32 on board. You would be able to use 5 of these, program them all individually and connect each sensor directly to the display.

The downside would be, if you want to make changes to the dash, there would not be a single point of contact to edit code, you have 5 individual devices. It will also make integration into a powertrain control module (Haltech for example) very difficult as you would be connecting 5 devices over the canbus instead of 1. I also thinks this will complicate a power supply solution, although I'll have to power 5 screens somehow so I think I'll be dealing with this regardless (I don't think the Arduino is up to the task).

Based on the data sheet I think these devices only allow peripheral connections over I2C or SPI and cannot be made to act as a slave. The nextion displays do not have a ~2.1 round design. It is for these reasons why I will be using the DWIN devices.

I also want to have a singular hub for controlling the sensor inputs and outputs as I will also be controlling some rudimentary devices (A/C evaporator ice up prevention) via the Arduino. Coupled with my plans to install a modern PCM, I want to be able to use my screens as Canbus dash down the line.

So Arduino with DWIN is the plan.

I'm not sure how I'm going to do power management yet, but I will update.

13

Hello Again,

So, I have been doing a fair bit of research into this topic and long story short I stumbled upon a YouTube channel called Garage Tinkering which has already designed and documented pretty much everything I want to do. He has also recreated the NFSU2 Gauge designs for anyone who's interested in that haha. This is the video that documents how to use an ESP32 as a canbus controller, everything else you'd need to know about this project is on that channel.

A quick overview:

Use ESP32 and Canbus instead of Arduino and Uart/I2C/SPI.

The reason for using an ESP32 and Can over an Arduino.

  • Some ESP32's have an inbuilt canbus controller.
  • ESP32 has way better specs
  • Canbus is much more stable in an automotive environment.
  • There is already documentation for it

There's more reasons but I can't think of them right now.

The parts will include:

I will refer to the automotive guides linked above when designing the power supply and I will link any code I write here if I compete it in the next 6 months (before the thread is locked). As stated in my first post the graphics will be uploaded to the individual gauges and sensor data (and whatever other coms I want to communicate) will be passed over the canbus. This should allow for efficient and fast communication as well as keeping the screen refresh rate quick.

I am also looking at expanding my scope to do every gauge in the car which would mean I add 2 x 3.4 Inch ESP32-P4 round displays to the project to replace the RPM and Speedo.

Thanks heaps for all the healp

14

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.