Important Considerations in Your Embedded System's Master-Slave Communication Model

It can take a few weeks or months to finish a working prototype of an embedded system. Sometimes I would spend days working on a single part of the project. However, when your boss is looking for updates every day, it can be particularly distracting and hinder your productivity. When I started my design company, I learned not to repeat these mistakes on my team.

Like a human, embedded systems come in various shapes and sizes, and more importantly different functionalities and capabilities. Besides responding to a controller higher up in the chain of command, an embedded system needs to perform its other tasks efficiently. This includes monitoring inputs, calculating and converting values. It must also provide reliable updates or processing commands. When an embedded system is constantly being disrupted by requests from another controller, it is less efficient. In some cases this can cause it to crash without warning.

How Do Master-Slave Embedded Systems Communications Work

The simplest way for embedded systems to communicate with each other is through a master-slave structure. This is where a single embedded system is designated as a master and is responsible for initiating communication to embedded systems connected to it. Master-slave communication has a predictable pattern in the way messages are transmitted across the communication interface. Slave controllers are not allowed to transmit any data packets unless they are requested by the master controller.

One of my latest projects that used a master/slave configuration is a monitoring system for rubber manufacturing machines. A sensor monitoring controller was placed at every machine to monitor their operating cycles using various sensors. A master controller was connected to all of the sensor controllers, and it used non-volatile memory to store the collected data.

Important Considerations For Designing a Master-Slave Embedded System.

.As straightforward is it may seem, failing to address the following design considerations can result in problems after deployment.

1. Processing Power Of Microcontrollers

Often, master and slave controllers are powered by microcontrollers with varying processing power. A master controller is often powered by a more powerful microcontroller than a slave controller. Slave controllers usually perform specific tasks, like monitoring sensor inputs or driving a motor, so it makes sense to equip them with a medium or lower range microcontroller.

Programmers who are writing code for the master controller need to refrain from interrupting the slave controller too frequently with status update demands. Since they have a limited processing capability, the interruption can overwhelm the slave controller. If a slave controller is not designed to handle a high volume of requests, it can experience memory or stack overflow and can crash.

Master and Slave controllers can operate at very different speed.

2. Limiting The Number Of Slave Controllers.

Theoretically, you can link your master controller with as many slave controllers that they communication interface standards allow. For example, RS458 can have up to 32 devices connected to a single connection. However, in practice, you’ll want to consider what effects connecting a huge number of slave controllers on a single channel will have on information retrieval speed. For example, a slave controller takes 10 milliseconds to respond to a request. If there are 31 slave controllers, it will take 310 milliseconds to receive updates from the same controller on the next cycle. If the master controller requires the updates to be refreshed at a faster rate, you’ll need to limit the number of slave controllers connected to a single channel.

3. Design For Redundancy

Embedded systems that are configured in a master-slave manner are often connected with a single cable that loops from one controller to another. This multipoint wiring method is simple and low cost but also puts the entire system at risk if the cable breaks. For example, a cable that breaks between the fifth and sixth slave controller reduces the master’s communication with the first five slave controllers.

In critical applications, system developers and designers should consider adding a redundant connection from the master controller to the last slave controller in the loop as a backup. If the master controller detects a potential break in the cable, it can activate the backup connection to restore communications.

It pays to be redundant in critical applications.

Regardless of whether you’re designing a master or slave controller, choosing the right microcontroller and accompanying components is important. PCB software like Altium Designer^® and Altium Vault^® give you access to components libraries from to simplify your processes.

If you have any doubts on implementing master-slave communications, contact an experts at Altium.