{"id":764,"date":"2019-09-27T07:11:33","date_gmt":"2019-09-27T07:11:33","guid":{"rendered":"http:\/\/blogs.plymouth.ac.uk\/embedded-systems\/?page_id=764"},"modified":"2019-10-10T09:04:48","modified_gmt":"2019-10-10T09:04:48","slug":"managing-multiple-inputs-and-outputs","status":"publish","type":"page","link":"https:\/\/blogs.plymouth.ac.uk\/embedded-systems\/microcontrollers\/mbed-os-2\/courses\/level-5-embedded-and-real-time-systems\/managing-multiple-inputs-and-outputs\/","title":{"rendered":"Managing Multiple Inputs and Outputs"},"content":{"rendered":"

Table of Contents<\/a><\/p>\n

\n

In this section, we will look at digital inputs, and how we might use them to control digital outputs.
\nWe will be using a simple \u201cpush-to-make switch\u201d to generate a single digital bit of data.<\/p>\n

\"\"<\/p>\n

Activity 3.1 – Simple Switch Input<\/h2>\n

Remember that a single digital signal is either ON or OFF. Numerically, we represent this as 1 or 0 (a single binary digit). The simplest way to generate a single bit input signal is with a push switch (shown below). The schematic to generate a digital input is as follows.<\/p>\n

\"\"
Using a SPST switch as a digital input<\/figcaption><\/figure>\n

Wire up this circuit on your prototype board.<\/p>\n

\"\"<\/p>\n

Activity 3.2 – Reading Digital Inputs<\/h2>\n

Wire up 3 LED\u2019s as shown here. These will be used for outputs.<\/p>\n

\"\"<\/p>\n

For this task, we are going to read the digital input using software. The objective is as follows:<\/p>\n

When the user depresses a button, the red LED switches ON and stays ON (until the system is reset).
\nRemember – the input is connected to D4.<\/p>\n

Maybe unsurprisingly, we use a component called a DigitalIn<\/code>.<\/p>\n

\"\"
Task 3.2.1<\/figcaption><\/figure>\n
#include \"mbed.h\"\r\n\r\nDigitalOut  red_led(D7);\r\nDigitalOut  yellow_led(D6);\r\nDigitalOut  green_led(D5);\r\nDigitalIn   SW1(D4);\r\n\r\nint main() {\r\n\r\n    \/\/Switch on Yellow and Green to indicate\r\n    \/\/that the code is running\r\n    yellow_led = 1;\r\n    green_led = 1;\r\n    red_led = 0; \/\/Set RED LED to OFF\r\n    \r\n    \/\/ Wait for SW1 to be pressed\r\n    while (SW1 == 0) { }\r\n    \r\n    red_led = 1;\t\/\/Turn ON LED\r\n    \r\n    while (1) { }\t\t\/\/Repeat forever\r\n}<\/pre>\n
Under the hood, there is a significant amount of work going on to set up the hardware in the right mode. The specifics are also vendor \/ board dependent.<\/p>\n
We benefit greatly from hardware abstraction<\/strong> provided by the mbed C++ classes DigitalIn<\/code> and DigitalOut<\/code>. mbed provide identical interfaces for all supported mbed compliant boards. This is an example of a device driver<\/strong>.<\/p>\n
Once again, we use of the the component from mbed to make interfacing with hardware simple.<\/p>\n
DigitalIn SW1(D4);<\/code><\/p>\n
where SW1<\/code> is an instance of DigitalIn<\/code>, which can read pin D4<\/code>. A critical line in this code is as follows:<\/p>\n
while (SW1 == 0) { }<\/code><\/p>\n
While the digital input SW1<\/code> is equal to zero, this code blocks the CPU in a tight polling loop<\/strong>. This is also known as spinning<\/strong>. This is NOT<\/strong> power or CPU efficient. Once the switch is pressed, an attempt to read SW1<\/code> will return a 1<\/code> and so the CPU will unblock<\/strong>.<\/p>\n
It is not always bad practise to monitor peripheral hardware this way. If delays are likely to be very short, it can even have some advantages. However, the time between switch presses is indeterminate in this case, so spinning becomes wasteful of CPU time and most of all, power.<\/p><\/blockquote>\n
\"\"
Task 3.2.2<\/figcaption><\/figure>\n
\"\"<\/p>\n
You might<\/em> have found this to be an unreliable solution (depending on how clean the switch contacts are).\u00a0In the next section, we will remind ourselves about \u201cswitch bounce\u201d and how to avoid it as this added\u00a0some additional complexity to our software.<\/p>\n
Real World Signals<\/h2>\n
When working with physical hardware, both hardware and software engineers can take steps to reduce the probability of an erroneous input. In almost every case, errors are probabilistic<\/em>. You can never engineer the probability to zero (ok, philosophical point maybe, but often it\u2019s a very real issue).<\/p>\n
As engineers, we have to recognise and mitigate against such failures, and at least know the probability and impact of failure that risk can be managed. Many systems are not fully autonomous, where human operators follow a protocol that is designed to monitor, manage and mitigate against risk.<\/p><\/blockquote>\n
A consumer gadget can accept a higher chance of failure than a safety critical system such as an anti-lock braking system or fly-by-wire system in a commercial aircraft. Some medical devices have to work with small and noisy signals from the human body, and have to use sophisticated mathematics and software to manage the error.<\/p>\n
Switch Bounce<\/h3>\n
The reality is that mechanical switches are not perfect. Most switches suffer switch bounce to some degree. As you can see in the second diagram opposite, the waveform is not a perfect step like the ideal.<\/p>\n
\"\"
Top – Ideal switch behaviour. Bottom – depicts actual electrical characteristics of a mechanical switch<\/figcaption><\/figure>\n
There are two common phenomena we much consider:<\/p>\n
Noise<\/strong> – random signals superimposed on top of the waveform<\/p>\n
Reactive effects<\/strong> – if you\u2019ve not covered reactance (maybe you’re a computer science student), it should suffice to say that perfect step waveforms are almost impossible – signals often rise as an exponential curve (although it might be very rapid)<\/p>\n
This reinforces the points that electronics is ultimately analog and signals are rarely ideal.<\/p>\n
A problem with such phenomena is that their occurrence is stochastic (random, probability based). An engineer must be mindful of such issues, and design systems to minimise the probability of such events occurring or causing malfunction, especially in safety critical systems.<\/p>\n
In the case of switch bounce, the exact nature is highly unpredictable. Consider the revised flow-chart below. This has added a delay after the first press is detected.<\/p>\n
\"\"
Adding a delay to address the problem of switch bounce<\/figcaption><\/figure>\n
 <\/p>\n
\u00a0\"\"<\/p>\n
Adding the delay makes the system less responsive. This is often referred to as latency. This task illustrates some key points:<\/p>\n