Autonomous vehicle - design questions to ponder

Ed Nutter January 27, 2016

When designing an autonomous or remotely-controlled vehicle, there are a few factors to take into consideration. Three of these are purpose, environment, and terrain.

What is the purpose of the vehicle?

Will it be used in an industrial setting with people moving around it that it must not run over?

Will it be used in a hazardous environment, like Fukushima or Chernobyl, where it would be exposed to high levels of radiation and must be cleaned or left behind? If it must be left behind, any...

Margin Call: Fermi Problems, Highway Horrors, Black Swans, and Why You Should Worry About When You Should Worry

Jason Sachs December 6, 20152 comments

“Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don’t know. But there are also unknown unknowns — there are things we do not know we don’t know.” — Donald Rumsfeld, February 2002

Today’s topic is engineering margin.

XKCD had a what-if column involving Fermi...

Coding Step 4 - Design

Stephen Friederichs November 24, 2015

Articles in this series:

The last article in this series discussed how to write functional high-level requirements: specifications for what your software is supposed to do. Software design is the other side of the coin....

The three laws of safe embedded systems

Michael J. Pont November 12, 20151 comment

This short article is part of an ongoing series in which I aim to explore some techniques that may be useful for developers and organisations that are beginning their first safety-related embedded project.

In the last two weeks, I’ve had the opportunity to discuss the contents of my previous article on this site with a group of very smart and enthusiastic engineers in Cairo (Egypt). As part of this discussion, it has become clear that I should add a few more details to explain the work...

Developing software for a safety-related embedded system for the first time

Michael J. Pont October 31, 20151 comment

I spend most of my working life with organisations that develop software for high-reliability, real-time embedded systems. Some of these systems are created in compliance with IEC 61508, ISO 26262, DO-178C or similar international standards.

When working with organisations that are developing software for their first safety-related design, I’m often asked to identify the key issues that distinguish this process from the techniques used to develop “ordinary” embedded software.


“Smarter” cars, unintended acceleration – and unintended consequences

Michael J. Pont October 20, 20151 comment

In this article, I consider some recent press reports relating to embedded software in the automotive sector.

In The Times newspaper (London, 2015-10-16) the imminent arrival of Tesla cars that “use autopilot technology to park themselves and change lane without intervention from the driver” was noted.

By most definitions, the Tesla design incorporates what is sometimes called “Artificial Intelligence” (AI).Others might label it a “Smart” (or at least “Smarter”)...

Important Programming Concepts (Even on Embedded Systems) Part V: State Machines

Jason Sachs January 5, 20158 comments

Other articles in this series:

Oh, hell, this article just had to be about state machines, didn’t it? State machines! Those damned little circles and arrows and q’s.

Yeah, I know you don’t like them. They bring back bad memories from University, those Mealy and Moore machines with their state transition tables, the ones you had to write up...

Important Programming Concepts (Even on Embedded Systems) Part IV: Singletons

Jason Sachs November 11, 20142 comments

Other articles in this series:

Today’s topic is the singleton. This article is unique (pun intended) in that unlike the others in this series, I tried to figure out a word to use that would be a positive concept to encourage, as an alternative to singletons, but

The CRC Wild Goose Chase: PPP Does What?!?!?!

Jason Sachs October 23, 20142 comments

I got a bad feeling yesterday when I had to include reference information about a 16-bit CRC in a serial protocol document I was writing. And I knew it wasn’t going to end well.

The last time I looked into CRC algorithms was about five years ago. And the time before that… sometime back in 2004 or 2005? It seems like it comes up periodically, like the seventeen-year locust or sunspots or El Niño,...

Important Programming Concepts (Even on Embedded Systems) Part III: Volatility

Jason Sachs October 10, 2014

1vol·a·tile adjective \ˈvä-lə-təl, especially British -ˌtī(-ə)l\ : likely to change in a very sudden or extreme way : having or showing extreme or sudden changes of emotion : likely to become dangerous or out of control

Merriam-Webster Online Dictionary

Other articles in this series:

Implementation Complexity, Part I: The Tower of Babel, Gremlins, and The Mythical Man-Month

Jason Sachs June 9, 2013

I thought I'd post a follow-up, in a sense, to an older post about complexity in consumer electronics I wrote a year and a half ago. That was kind of a rant against overly complex user interfaces. I am a huge opponent of unnecessary complexity in almost any kind of interface, whether a user interface or a programming interface or an electrical interface. Interfaces should be clean and simple.

Now, instead of interface complexity, I'll be talking about implementation complexity, with a...

Modern Embedded Systems Programming: Beyond the RTOS

Miro Samek April 27, 20167 comments

An RTOS (Real-Time Operating System) is the most universally accepted way of designing and implementing embedded software. It is the most sought after component of any system that outgrows the venerable "superloop". But it is also the design strategy that implies a certain programming paradigm, which leads to particularly brittle designs that often work only by chance. I'm talking about sequential programming based on blocking.

Blocking occurs any time you wait explicitly in-line for...

Embedded Programming Video Course Shows How OOP Works Under the Hood

Miro Samek September 29, 2019

If you'd like to understand how Object-Oriented Programming (OOP) really works under the hood, here is a free video course for you:

OOP part-1: Encapsulation: This first lesson on Object-Oriented Programming (OOP) introduces the concept of Encapsulation, which is the ability to package data and functions together into classes. You'll see how you can emulate Encapsulation in C, what kind of code is generated, and how to debug such code. Next, you will translate the C design into C++ using...

Coding Step 4 - Design

Stephen Friederichs November 24, 2015

Articles in this series:

The last article in this series discussed how to write functional high-level requirements: specifications for what your software is supposed to do. Software design is the other side of the coin....

Implementation Complexity, Part II: Catastrophe, Dear Liza, and the M Word

Jason Sachs June 16, 2013

In my last post, I talked about the Tower of Babel as a warning against implementation complexity, and I mentioned a number of issues that can occur at the time of design or construction of a project.

The Tower of Babel, Pieter Bruegel the Elder, c. 1563 (from Wikipedia)

Success and throwing it over the wall

OK, so let's say that the right people get together into a well-functioning team, and build our Tower of Babel, whether it's the Empire State Building, or the electrical grid, or...

Designing Communication Protocols, Practical Aspects

Fotis Chatzinikolaou May 14, 20192 comments

For most embedded developers always comes the time when they have to make their embedded MCU talk to another system. That other system will be a PC or a different embedded system or a smartphone etc. For the purpose of this article I am assuming that we are in the control of the protocol between the two ends and we don’t have to follow something that is already in place on one side.

So let’s say that we have our embedded MCU, we have implemented and configured the USB stack (or just...

Racing to Sleep

Jason Sachs December 30, 2019

Today we’re going to talk about low-power design.

Suppose I’m an electrical engineer working with wildlife biologists who are gathering field data on the Saskatchewan ringed-neck mountain goat. My team has designed a device called the BigBrotherBear 2000 (BBB2000) with a trip cable and a motor and a camera and a temperature sensor and a hot-wire anemometer and a real-time clock and an SD card and a battery and a LoRa transceiver. The idea is something like...

Efficiency Through the Looking-Glass

Jason Sachs December 8, 20134 comments

If you've ever designed or purchased a power supply, chances are you have had to work with efficiency calculations. I can remember in my beginning electronic circuits course in college, in the last lecture when the professor was talking about switching power converters, and saying how all of a sudden you could take a linear regulator that was 40% efficient and turn it into a switching regulator that was 80% efficient. I think that was the nail in the coffin for any plans I had to pursue a...

UML Statechart tip: Handling errors when entering a state

Matthew Eshleman March 8, 20204 comments

This is my second post with advice and tips on designing software with UML statecharts. My first entry is here.

It has been nearly 20 years since I first studied UML statecharts. Since that initial exposure (thank you Samek!), I have applied event driven active object statechart designs to numerous projects [3]. Nothing has abated my preference for this pattern in my firmware and embedded software projects. Through the years I have taken note of a handful of common challenges when...

Metal detection: building the detector

Fabien Le Mentec February 6, 20164 comments
IntroductionBefore starting, you may want to read this post describing the BFO stage:


I have detailed the implementation of a BFO stage for detecting metal. Now it has been validated on the bench, the next step is to integrate it in a stand alone instrument for testing on the field. A few things have to be done to reach this goal:

  • make a PCB for the electronics,
  • house the PCB in a box,
  • add a power supply,
  • make a frame to hold...