How Multiple Components Talk to One Another (I2C, UART, etc)

Thread Starter


Joined Nov 5, 2019
If I say Im a beginner at Electronics, but I see all the schematic design people and PCB builders in China and India etc. I've got ideas, but not much clue how to turn them into reality.

My project at the moment is essentially a modular Car PC - and I've got this working two Raspberry Pi's.

I have a "Head Unit" which has a DAC, a GPS (connected via USB) and an SDR dongle also connected via USB. It runs RaspbianOS and OpenAuto to provide an Android Auto interface.

The second raspberry pi or "Can Collector" has a CAN BUS hat, collects information from the Can Bus, and broadcasts to the Head Unit raspberry Pi to process the data and upload to the cloud where I can then run telemetry.

Im using Cat 5 cable, USB to USB C cables, USB to Micro USB cables, and my own cables using the Molex ML-XT series connectors.

But I thought wouldn't it be nice to build this from the ground up.

The biggest thing is replacing the Raspberry Pi and bringing in the same information.

So I thought I should split the project into two.

The Head Unit (v1) will be basically be an interface to the Raspberry Pi - perhaps connecting over USB or some other technology. It will have a GPS and an RTC in order to set the time on the raspberry pi. It will need two USB connections for connecting a USB-C device (mobile phone) and should support fast charging. It will have a relay to take a Permanent 12v and an Accessory 12v in order to switch itself on when a current is applied to the Accessory 12v. I'll also need two 3.1a 5v outputs (one Micro USB, one USB-C) to power a Raspberry PI 4 and the official touch screen. The USB-C output should be delayed slightly after the screen.

Head Unit v2 will add two perhaps three SDR chips, a DAC and a MosFet amplifier, will need a 7 inch touch screen, WiFi, Bluetooth and a Microphone Connection and will replace the Raspberry Pi. It will also need one CAN interface.

The Can Collector, will probably need four CAN interfaces, a relay as above and Bluetooth for transferring CAN Bus mapping files to the device so it can then send out translated CAN information to the Head Unit. This way if I need to add another unit, it can use the translated information rather than needing to map in other elements.

I don't see actual "USB" connectors on the devices or Ethernet ports, I see typical car type connectors to link everything up, but then with USB sockets or plugs where needed.

That's my plan.

Whether it's achievable I don't know. Im sure it is. Anything is.

But then this got me thinking.

Lets say I create a USB Hub type device, which has things like Bluetooth, WiFi, CanBus, RTC and GPS, how do the devices talk back to the host, or even a processors chip such as R5F563NBDDFP? In the first instance, how would they talk to the Raspberry Pi? I see I2C, UART, SPI etc. What do we do about drivers? Im imagining, USB would expose the device, while the drivers would then allow the OS to talk to the device. If I moved to a custom device and not use a Raspberry Pi, do I need to make sure I get a processor that has more UART channels? Do I need to consider what chips I use? What do I do about drivers?

Im not looking for a detailed over view as such, but if you can point me in the right direction towards a general over view of how this works and how people have mapped out interoperability etc that would be great.



Joined Oct 2, 2009
Welcome to AAC!

The must common interface channels in use are parallel, UART, SPI, I2C, SATA, USB, CAN, IrDA. Along with those we can add WiFi, Bluetooth. Then there are the physical layers, TTL, RS-232, RS-485, LVDS, 1-Wire.

Since you are contemplating an automotive application, CAN bus would be the obvious choice. Connect your devices to any MCU and communicate across one CAN bus.


Joined Feb 20, 2016
For a start, play around with such things as I2C LCDs, and MCP23017 port expanders. Maybe with Arduinos in place of the Pi, as they are cheaper when you blow them up ;)
Get some experience in running things like that on the bench, then move on to the car.
CAN is a good way to go, and a CAN Bluetooth interface will isolate things for safety.


Also, RS485 is a common control network system. I would stay away from USB and Ethernet in a car.