Generic Android Head Unit/MCU Explained
All these units, whether "pure android" or WinCE based ones, or even those with neither, are built with a couple of layers of hardware working together to allow integration of all components involved into a seemingly singular interface. It is important to know the basics of how these units are assembled and how they operate because it will allow us to understand reasons for certain limitations and problems as well as the benefits.
A common thoughts for some, when first considering the purchase of such unit, is "why spend so much for a car stereo when I can just incorporate a tablet in my dashboard? It's got all the processing power I need, it's 'open' it's just a matter of installing or developing the right apps and adding a couple of amps". And many people have done just that.
Aside from the obvious aesthetic challenges of making it look right, there is other advantages these units offer that Android itself and the hardware it's made to run on does not natively handle:
- Sound Controls: Balance, Fader, Audio levels, pre-amp out levels, and hardware controlled tones, mixing and switching of audio inputs etc. All these are (in any modern car stereo unit) controlled by a Analog Audio Processor, for example in the case of the AN-21 U, the Sound Processors with built-in 3-band Equalizers - BD37534FV is the Audio processor chip.
- Video controls: Video input and output switching and video overlays/OSD. These units provide Aux input, rearview camera with separate switching, DVD etc. as well as Aux video out all these inputs and outputs (android being just one of them, more on this later) are controlled by a separate chip, again in the case of the AN-21 U the FMS6502 − 8 Input, 6 Output Video Switch Matrix
- Dvd/cd playback: Android currently has no real provision to handle DVD/CD drives for movies and music playback. A dvd unit much like a cheap home dvd player with it's own firmware is included in most of these units and it's video and audio outputs routed through the processors described above.
- Bluetooth: This frustrates many, as these unit provide bluetooth out of the box but do not support any of the "simple" things any android device supports if it has bluetooth. The main complaint is lack of support for BT ODBII readers, but also, bluetooth keyboard, bluetooth filesharing and many others.
The key here lays in the Bluetooth Profiles supported. While android supports many profiles natively, these units bluetooth is a separate board not even visible to android, that supports the few android doesn't, notably the Hands-Free Profile (HFP) and Advanced Audio Distribution Profile (A2DP) AS CLIENT. Researching the subject of using an android tablet as a headphone will return many thread like this one. To date I have not found a solution that doesn't involve external or additional hardware. Hence, the separate bluetooth hardware to handle that, of course as anything else, with it's audio routing through the audio processor described above.
- Steering wheel controls (SWC) and Canbus interface
- Front face buttons/knobs and illumination
- I-pod interfacing
- Radio and TV tuners. While some Android devices do support some tuners, those are usually specific to manufacturer specific hardware.
- Power state and switching such as provision to turn the unit off when ignition is off, video input switching when in reverse, antenna and amplifier switching and Video playback block for laws Compliance.
- Video player and music player. While android definitely can handle those tasks on it's own, these radios supply built in players separate from it. Mainly because they already had that functionality before adding an adroid board to the equation.
Introducing the 'MCU'
A microcontroller (sometimes abbreviated µC, uC or MCU) is a small computer on a single integrated circuit containing a processor core, memory, and programmable input/output peripherals. Program memory in the form of NOR flash or OTP ROM is also often included on chip, as well as a typically small amount of RAM. Microcontrollers are designed for embedded applications, in contrast to the microprocessors used in personal computers or other general purpose applications.
For an in depth definition see http://en.wikipedia.org/wiki/Microcontroller_unit
Specifically for our units
The MCU in these units is a special purpose microcontroller designed to control all the different parts of the car stereo described above.
Keeping with the AN-21 U as an example, the specific MCU for this unit is a STM8AH with 64kb of flash memory
The MCU's embedded application program handles all the logics for operating the unit as a single device rather than many separate devices. For example, if we're listening to the I-pod and decide to push the radio button, the MCU and it's program is the one responsible to sense our decision, turn off the I-pod control, switch audio input to the radio, turn the tuner ON and 'tell' Android (or whatever device is responsible for displaying a user interface for example WinCE) to show us the radio interface. It communicates with all the other chips and boards in the system through a serial communication line, more than likely I2C or Asynchronous serial communication.
"Native Apps" and integration with Android
In the forum we refer to all the apps that come with the unit and control unit specific things as "Native Apps". Those are merely front-end interfaces to MCU applications, they are android applications that have the sole purpose of displaying what the MCU is doing and controlling some of it, the actual logic processing of those operations is handled by the MCU.
Some of the MCU operations do not require user input at the interface. for example, when you put your car in reverse, the MCU detects that through an input (12v. on the reverse wire) and "tells" the Video Switch Matrix chip mentioned above to display the rearview camera; also it tells the sound processor to mute the volume from all other possible audio sources if set to do so. This proces does not involve Android at all, even the setting to mute sounds or not is believed to live on the MCU memory. This setting is user defined, and as such it needs a way for the user to turn it ON or OFF. This brings another "native" layer to android: some of the settings in the familiar "Settings" application of android are comparable to the "native Apps" in that they display in android as any of the usual android setting, but they are really a front end to settings that get set and reside in the MCU. This also includes some sound settings, Steering wheel controls, radio and tv settings and more.
Other MCU operations such as listening to radio etc. do require user input and require the ability to display status to the user. Hence the need for "Native Apps". Many have complained that those apps could be better and often we can se the question on forums "Can we replace the radio app with a better one?". While I tend to agree those apps could be better, we need to understand that not all the logics processing (if any) is done by those app therefore some of the fanciness in logic and options we're used to with more complex real android applications might not be possible due to the phisycal limits of the MCU and other processing chips where the real logics are handled and not only do those apps display and control the task at hand (for example play the radio) but they also initiate other functions such as audio/video switching etc. Some units need at least one of those apps to be active at least in the backgroung for the head unit to work properly.
"Let me give you analogy though to explain how they work. The comparison would be like a television remote control and a television. In this case, the Android APK is the remote control and the MPU is television. When you press a button on the remote it triggers a function on the television. The remote control does not actually participate in processing for the function, it merely triggers it. Additionally, just because you like the look and feel of a particular remote control, doesn't mean that you can use it with a different television."
So far some small changes have been succesfully made to alter some of the look of these apps. For a complete redesign we would have to reverse engineer the communication protocol with the MCU and replicate any and all functions and commands. As for the functionality, most of it is dealt with by the MCU's firmware so it wouldn't be possible to change that.