Author: automaticaddison

Imagine you’re a software manager and are in charge of developing an embedded system. What tools will you use to debug? In this post, I will cover the common tools and instrumentation for embedded system debugging.

Host Machine with Test Scaffold

We do not want to begin our troubleshooting on the target system. Troubleshooting on the target system present a lot of complications. We need a host machine with test scaffold because the hardware might go through several iterations and is often replete with bugs and unstable early in the development process. It is also hard to create repeatable tests on the target system.

Think of a test scaffold as a test site on your host computer that mimics what would occur on the target hardware. Just like a construction scaffold, it is a temporary work area.

Finally, since embedded systems do not often contain a permanent storage medium, it can be difficult to keep track of the results of the debugging process. There is no “GitHub”-like system that can be implemented on an embedded target system.

Instruction Set Simulators

I need instruction set simulators in order to measure response time and throughput as well as to debug the startup code.

Assert Macro

The assert macro will help me to test my assumptions since it stops as soon as one of those assumptions is false.

Mechanism to Get the Software into the Target System

The locator output file needs to get into the target system somehow. We have a lot of options: PROM programmers, ROM emulators, In-circuit emulators, flash memory, and monitors. My personal choice would be PROM programmers since this is the “classic” way to get software into the target system. Using PROM programmers means that we are able to make changes to the software when we deem necessary.

Multimeter

A multimeter is a must-have tool for testing hardware. The kinds of multimeters that exist nowadays are a voltmeter, ohmmeter, and ammeter all-in-one tool.

Oscilloscope

Oscilloscopes are another useful tool for testing the hardware. Oscilloscopes enable us to receive and display analog signals.

Logic Analyzer

Logic analyzers enable us to receive and display digital signals instead of analog signals. This tool is useful for hardware debugging.

In-circuit Emulator

This tool is used as a replacement for the actual microprocessor on the target system. With the in-circuit emulator, you can to debug like you would with a normal debugger in a desktop environment.

In this post, I will discuss the differences between message queues, mailboxes, and pipes. Message queues, mailboxes, and pipes are services that are provided by RTOSs that enable tasks to communicate with each other. Tasks need to communicate with each other in order to coordinate activities and to share data.

What is a Mailbox?

If you need strong control over prioritization, mailboxes might be a good choice. You can easily prioritize mailbox messages no matter when they entered the mailbox.

This characteristic provides a definite advantage over other inter-task communication options such as queues which are particularly sensitive to the order in which messages are added and removed from the data structure.

The other benefit of mailboxes is that there is typically no size limit on individual mailboxes. The size limit is typically fixed and is set by the programmer.

What is a Queue?

If you have an implementation that requires first-in-first-out prioritization, queues are a great choice. They are flexible and relatively easy to implement, making them a common choice in RTOS implementations.

The downside of queues is that, unlike mailboxes, you are often limited in the amount of data that you can write to the queue in any given call. Many RTOSs don’t have a lot of flexibility when it comes to this.

What is a Pipe?

If you need to be able to write messages of varying lengths, pipes are the best choice. Pipes are identical to queues except they are byte-oriented. The main difference between pipes and queues is that  pipes allow you to write messages of any length, while queues do not.

Table of Contents

• What is a Mutex?
• What is a Semaphore?
• What Technique of Protecting Shared Data Requires Less Overhead?

In this post, I will discuss the difference between a mutex and a semaphore using a gas station bathroom analogy.

What is a Mutex?

A mutex (mutual exclusion object) grants exclusive access to shared data or computer hardware. It is like a bathroom key at a gas station. If you have the key, nobody else can enter the bathroom while you are using it. Only one person (task) can use the bathroom (shared resource) at a time.

If a person (task) wants to use the bathroom, he or she must first get the bathroom key (mutex) since there is only one copy. The gas station owner (operating system) is responsible for managing the bathroom key (mutex).

Return to Table of Contents

What is a Semaphore?

Continuing from our example in the previous section, imagine that there are two bathrooms (shared resources) instead of one. Also there are two bathroom keys instead of one. Since bathroom entry is no longer exclusive, this is not a mutex scenario. Instead, the keys are called semaphores.

A semaphore enables two or more (two in this example) tasks (people) to use a shared resource (gas station bathroom) simultaneously.

• If two keys (semaphores) are available, the value of the semaphore is 2.
• If one key is available, the value of the semaphore is 1.
• If no keys are available, that means that two tasks (people) are currently working (in the bathroom). The value of the semaphore is 0. The next task (person) must wait until a semaphore becomes available (i.e. a task finishes, and the semaphore is incremented by 1).

Return to Table of Contents

What Technique of Protecting Shared Data Requires Less Overhead?

Answer: Semaphore

Overhead includes things like memory, bandwidth, and task execution time. If tasks are able to work on different copies of shared data, each individual task will undoubtedly perform its function with less overhead. There is no waiting in line or waiting for a semaphore to be released.

However, the operating system (gas station owner) will have more overhead. It will spend a lot of resources having to manage the different copies of data. In addition, relative to a mutex implementation, copying data and enabling concurrent processing of that data will require more memory and processing power.

Return to Table of Contents