i.MX6SX - Realtime CAN interfacing Part 3 (UDOO Neo)

In the last post we covered how the RX8 instrument cluster could be controlled from the A9 side. Given the A9 side is feature rich in its capabilities if offers numerous possibilities. As a simple demonstration we will attempt to replicate the RPM and Speed gauges and two warning indicators on the hdmi (720p) display to represent a simplified virtual instrument cluster. The main challenges here are:

1. On screen widget need high performance.
2. Keeping the on screen gauges/warning indicators in sync with the instrument cluster.
3. Minimising CPU usage.



In the video, the on screen RPM gauge (on left fairly) accurately tracks the RPM needle on the instrument cluster. The on screen Speed gauge (on the right tracks) the digital Speed indicator. We also toggle the battery and oil warning indicators on the screen and cluster. Notice that the cluster_gauges application is consuming rough 10% of the CPU.

In order to deliver the necessary performance the on screen gauges were rendered using custom Open GL ES 2.0 code. Note the graphic images used for gauges are modified versions derived from this Android Ardunio project. Compared to the previous post there is now a single application (cluster_gauges) on the A9 side which renders the widgets but also controls the instrument cluster through the M4.

I hope through these 3 blog posts have I managed to demonstrate how the M4 and A9 processor can be combined to provide a rich real-time interface and data distribution mechanism for your applications.

i.MX6SX - Realtime CAN interfacing Part 2 (UDOO Neo)

As mentioned in my previous post the next stage of development with the RX8 instrument cluster is to offer the ability to control the gauges/indicators on the cluster from the A9 side. In the last post I also pointed out that to keep the cluster active the M4 side has the responsibility of regularly sending/receiving CAN messages from/to the cluster. Hence we can't use the CAN interface from the A9, instead we get the A9 'to talk to' the M4. Within the i.mx6sx the Messaging Unit module enables the two processors to communicate with each other by coordinated passing message. We can make use of this feature to send messages to the M4 from A9 to ask it to update the cluster and use the M4 to forward CAN messages received from the cluster to the A9. By the way, this all happens while the M4 also is feeding the cluster with its own CAN messages. For the i.mx6sx the inter-processor communication is abstracted and implemented through the Remote Procedure Messaging (RPMSG) framework which is supported both in the Linux and FreeRTOS BSP.

Compared to the last demonstration, the main change to the configuration is the introduction of a relay board so that the instrument can be powered on and off (the Power Control box in the diagram) by the M4.

The M4 firmware has been amended to accept commands from the A9 via RPMSG. On the A9 side we have 2 applications:

1. read_can - Which constantly reads CAN messages sent from the instrument cluster via the M4 .
2. cluster_control - Controls the instrument cluster via the M4.

cluster_control has the following capabilities through a number of command line options:

-i  - turns the instrument on/off
-r  - set the RPM
-s  - set the SPEED (in kilometres although display is in mph)
-b  - set Battery Warning indicator
-o  - set Oil Warning indicator
-c  - set Cruise control indicator

The short video demonstrates two applications running on the A9, read_can is running in the window on the left and on the right cluster_control is used to manipulate the cluster. Note that prior the 2 applications being launched, the M4 was preloaded with new firmware and RPMSG initialised on the A9 side. Once cluster_control changes the cluster state, the M4 is responsible for continuing updating the instrument cluster with the new state until the next change. 

Now that we have the ability to control the cluster and receive messages from the A9 side, in the final post I will demonstrate how another feature of i.mx6sx can be used with it.

i.MX6SX - Realtime CAN interfacing Part 1 (UDOO Neo)

One of the most promising capabilities of the i.mx6sx is combing the Cortex M4 with the on board CAN interfaces. This feature opens up a number of possibilities for deploying the i.mx6sx for a varied range of automotive solutions where real-time processing of CAN messages is handled by the M4 and the A9 kept for non-critical processing. To demonstrate this, lets take a simple use case of driving an automotive instrument cluster.  In a series of blog posts I will cover how we can drive the instrument cluster initially from the M4, then from the A9 communicating via MU (Messaging Unit) to M4 and finally by a on screen virtual dials mimicking the actual instrument cluster dials.

For this exercise we used an instrument cluster pulled from a Mazda RX8. The RX8 instrument cluster interface is partially analogue and partially digital. The digital interface is provided through a high speed CAN (500 Kbps) interface that drives the dials (RPM, Oil, Temperature) , digital speedometer and a number of warning indicators. Time pending I may cover the RX8 instrument cluster CAN interface in more detail in another blog. The target board for development was the UDOO NEO complemented with SN65HVD230 CAN Transceivers.

For this first demonstration a FreeRTOS application was developed to run on the M4 that regularly sends CAN messages to the cluster and dumped CAN messages generated on the bus from the cluster to the serial port. In order to drive the dials and suppress the warning indicators, the instrument cluster requires a regular feed of CAN messages sent at 10 milliseconds intervals. When the cluster is active it also generates CAN messages roughly at 50 millisecond intervals.

The video above shows the application (rx8_can) being launched from Uboot, before launching the application notice that all warning indicators lights are active on the instrument cluster. After the application is launched all warning indicators are cleared and the RPM gauge and speedometer are active. The application also dumps the instrument cluster generated CAN messages to the serial port (shown in the terminal to the right). After launching the application we boot to a Linux console to demonstrate the A9 is unaffected while the M4 continues to control the instrument cluster.

In the next post I aim to demonstrate how we can utilise the Message Unit to allow the A9 to control the instrument cluster by communicating with the M4.