Intel NUC board for RealDash Can\K-Line
Posted: Sat Mar 11, 2023 11:08 am
Hi all .
Having decided that I need a digital Dash, my choice fell on RealDash Software from Finland (http://realdash.net/index.php).
The software is released for Linux, Windows and Android platforms.
I chose Intel NUC DC3217IYE With two HDMIs on board, because I plan to output TunerStudio to a second monitor to configure Rusefi. I want to attribute to the obvious advantages of Intel Nuc
-Very fast exit from sleep (4 Seconds to fully loaded application)
-Low power consumption in sleep 100mA at 19V
- Availability of implementation
I would like to point out obvious flaws.
-Storage information on SSD
-Intel NUC temperature ranges that can go beyond +100 C ranges
- A large number of unnecessary IC as a result of a possible failure
-Other shortcomings of Windows OS So now about how to convey data to RealDash. Since we have CAN, we decided to use it.
The data chain is
Rusefi To CAN (Rusefi Board)
Can To Serial Port (MCP2515->Atmega2560->Atmega8u2)
I used haltech as the CAN description protocol. It is already described by Rusefi and supported by Realdash.
Now about the Can to Serial Port Adapter as an example of Realdash placed on the Github page (https://github.com/janimm/RealDash-extras/tree/master/RealDash-CAN) Can description file and sample code for the Wiring framework
My code is
#include <SPI.h>
#include <mcp2515.h>
struct can_frame canMsg;
MCP2515 mcp2515(53);
void setup() {
Serial.begin(115200);
SPI.begin();
mcp2515.reset();
mcp2515.setBitrate (CAN_500KBPS, MCP_8MHZ);
mcp2515.setNormalMode();
}
void loop() {
if (mcp2515.readMessage(&canMsg) == MCP2515::ERROR_OK) {
unsigned long canFrameId = canMsg.can_id;
const byte* frameData = canMsg.data ;
const byte serialBlockTag[4] = { 0x44, 0x33, 0x22, 0x11 };
Serial.write(serialBlockTag, 4);
Serial.write((const byte*)&canFrameId, 4);
Serial.write(frameData, 8 );
}
}
This is very Ugly I know but I have very little knowledge in programming in any languages
This is how the data comes And video
From which it is clear in what form it is necessary to send data to the serial port in order for Realdash to correctly see the messages.
After everything is quite simple, I connected the MCP2515 library and read the data from CAN, transferring them in the same form to the serial port, adding BlockTag so that Realdash Starts receiving data from 4 bytes, after which CanFrame should be sent, after which FrameData and CanMsg should be sent.
I also found an implementation of the K-Line to can adapter on the MC33660 chip
https://thefactoryfiveforum.com/showthread.php?34088-Subaru-SSM-to-Can-Bus-Convertor-DIY
In this article, a person reads data from a standard OBD2 connector using the Subaru SSM protocol, packing the data into Can Masage data form. However, the K-Line reception rate is 4800 baud, which is enough for all data except the tachometer.
Here is a link to his Github branch https://github.com/alan-polk/subduino
And video
Now about the output to the display. I use round 5 inch screens from ali express which work on MIPI interface and use converter to HDMI so I don't have EDID problems and they are PnP on Windows. The displays have a resolution of 1080 by 1080, which in one by one gives us 2160 by 1080. An Intel Nuc with this resolution has over 60 frames, which is quite enough for smooth animations. This display is not certified for use in cars, and has a low brightness. However, this is enough for me and I decided to go this way.
Display's
Today, I realized that in addition to CAN, we also need external ADC signals for fuel level or other sensors, we also need external signals that will not enter the ECU, such as turn signals, battery charge signals, and others. At this stage, I had a need to make a printed circuit board in the size of the old dashboard board, I want everything to be Pnp and not affect any factory wiring. Next, I go by building a prototype on a debug board, after which I will draw up a project in Kicad if they don’t dissuade me;) I understand that Atmega is a very strange choice, but the wiring language is available to me. I hope this information will be useful and arouse interest in this topic. I'll be happy to answer any questions, if any.
Having decided that I need a digital Dash, my choice fell on RealDash Software from Finland (http://realdash.net/index.php).
The software is released for Linux, Windows and Android platforms.
I chose Intel NUC DC3217IYE With two HDMIs on board, because I plan to output TunerStudio to a second monitor to configure Rusefi. I want to attribute to the obvious advantages of Intel Nuc
-Very fast exit from sleep (4 Seconds to fully loaded application)
-Low power consumption in sleep 100mA at 19V
- Availability of implementation
I would like to point out obvious flaws.
-Storage information on SSD
-Intel NUC temperature ranges that can go beyond +100 C ranges
- A large number of unnecessary IC as a result of a possible failure
-Other shortcomings of Windows OS So now about how to convey data to RealDash. Since we have CAN, we decided to use it.
The data chain is
Rusefi To CAN (Rusefi Board)
Can To Serial Port (MCP2515->Atmega2560->Atmega8u2)
I used haltech as the CAN description protocol. It is already described by Rusefi and supported by Realdash.
Now about the Can to Serial Port Adapter as an example of Realdash placed on the Github page (https://github.com/janimm/RealDash-extras/tree/master/RealDash-CAN) Can description file and sample code for the Wiring framework
My code is
#include <SPI.h>
#include <mcp2515.h>
struct can_frame canMsg;
MCP2515 mcp2515(53);
void setup() {
Serial.begin(115200);
SPI.begin();
mcp2515.reset();
mcp2515.setBitrate (CAN_500KBPS, MCP_8MHZ);
mcp2515.setNormalMode();
}
void loop() {
if (mcp2515.readMessage(&canMsg) == MCP2515::ERROR_OK) {
unsigned long canFrameId = canMsg.can_id;
const byte* frameData = canMsg.data ;
const byte serialBlockTag[4] = { 0x44, 0x33, 0x22, 0x11 };
Serial.write(serialBlockTag, 4);
Serial.write((const byte*)&canFrameId, 4);
Serial.write(frameData, 8 );
}
}
This is very Ugly I know but I have very little knowledge in programming in any languages
This is how the data comes And video
From which it is clear in what form it is necessary to send data to the serial port in order for Realdash to correctly see the messages.
After everything is quite simple, I connected the MCP2515 library and read the data from CAN, transferring them in the same form to the serial port, adding BlockTag so that Realdash Starts receiving data from 4 bytes, after which CanFrame should be sent, after which FrameData and CanMsg should be sent.
I also found an implementation of the K-Line to can adapter on the MC33660 chip
https://thefactoryfiveforum.com/showthread.php?34088-Subaru-SSM-to-Can-Bus-Convertor-DIY
In this article, a person reads data from a standard OBD2 connector using the Subaru SSM protocol, packing the data into Can Masage data form. However, the K-Line reception rate is 4800 baud, which is enough for all data except the tachometer.
Here is a link to his Github branch https://github.com/alan-polk/subduino
And video
Now about the output to the display. I use round 5 inch screens from ali express which work on MIPI interface and use converter to HDMI so I don't have EDID problems and they are PnP on Windows. The displays have a resolution of 1080 by 1080, which in one by one gives us 2160 by 1080. An Intel Nuc with this resolution has over 60 frames, which is quite enough for smooth animations. This display is not certified for use in cars, and has a low brightness. However, this is enough for me and I decided to go this way.
Display's
Today, I realized that in addition to CAN, we also need external ADC signals for fuel level or other sensors, we also need external signals that will not enter the ECU, such as turn signals, battery charge signals, and others. At this stage, I had a need to make a printed circuit board in the size of the old dashboard board, I want everything to be Pnp and not affect any factory wiring. Next, I go by building a prototype on a debug board, after which I will draw up a project in Kicad if they don’t dissuade me;) I understand that Atmega is a very strange choice, but the wiring language is available to me. I hope this information will be useful and arouse interest in this topic. I'll be happy to answer any questions, if any.