I have a rare Right-hand drive Japanese car here in the United States (Customs told me it was the first ever legally imported of this type). The car runs one of the most powerful 3.0l engines that was ever made. The Toyota 2JZ-GTE Twin-Turbo. The vehicle is being built to approach 4-digit horsepower ratings. I wanted a custom solution for the dashboard, so I bought a Dash2 by Race Technologies in the UK. While they do make a CAN to Serial converter, the CAN-TO-DASH2 that I have isn't functioning properly. I decided that the Teensy 3.6 was a great replacement as I would have complete control over the CAN-bus decode.

Currently, I am using a Teensy 3.6 as an ECU simulator that outputs the exact same messages as the actual ECU. (We will call this ECU-SIM).
I have a Teensy 3.6 on the 1M/bit CAN-bus as a node (We will call this DECODER).

The ECU-SIM rotates through two messages (RPM and GROUND_SPEED) with a loop that changes the values with a delay of 10ms (There are currently 33 total ID broadcasts available).
The DECODER gets these messages, buffers the packet (8 bytes), then decodes the byte buffer based on the known values.
The DECODER takes this information, formats it to the known protocol for the DASH2, and pushes this information via TTL-RS232(MAX3232) to the DASH2.

This was a MAJOR component to the vehicle as I will be using the CAN-bus to decode various messages with multiple nodes to control WS2812B chips located throughout the vehicle.

It is still very early in development, and I have a lot of work left to do, but this is progress. I am not overly happy with the Big-O of the algorithm, but I will be working on efficiency in the future. The Proof-Of-Concept was the first important phase in the architecture of the CAN-bus for the vehicle.

(If anyone is interested in adding to or collaborating on this project, I would love some input and would love to have someone to bounce ideas off of. Not sure if I should put the on github as a public project, as my code is not production-ready and my feelings might get hurt when people see the Big-O of the current Proof-Of-Concept )

Credit: CollinK and his amazing FlexCAN library ( https://github.com/collin80/FlexCAN_Library ).
A Video:

Next steps:
Multi-thread the application
Get the information into a teensy-friendly database without overrunning the variable storage on the teensy.
Hashed lookups for processing.
Algorithm/hardware development with a focus on reliability and redundancy. (This is my only speedometer and primary systems display for the vehicle. A failure of a single-point system would mean systems monitoring would be null)

Possible future development milestones:
Interrupt-based message processing