Making things do stuff – Part 5

We’ve been looking at using C++ to manipulate I/O hardware.   Previously, we’ve looked at the fundamentals of hardware manipulation; and how to encapsulate these mechanisms into classes.  If you’ve not been following along I’d recommend reading the previous articles first before continuing.

This time we’ll explore a lesser-known feature of C++ and its application in hardware manipulation – placement new.

Continue reading

Posted in C/C++ Programming | Tagged , , , , , | Leave a comment

Making things do stuff – Part 4

In the last article we explored the design of a class to encapsulate a physical hardware device.  In that article I deliberately ignored how the class would actually interact with the hardware.

In this article we explore the options available to us for accessing hardware and the consequences of those choices.

Continue reading

Posted in ARM, C/C++ Programming, Cortex, General | Tagged , , , , , , | Leave a comment

Making things do stuff – Part 3

Previously, we’ve looked at the basics of hardware manipulation in C++ and applied that to a simple GPIO implementation.

In this article we’re going to have a look at encapsulating our code in a class and look at some of the design choices we have to make.

If you’re not familiar with hardware manipulation in C++ I’d highly recommend reading the previous articles in this series before continuing.

Even if you’re familiar with the concepts of hardware manipulation, if you haven’t read the second article I’d highly recommend reviewing it so your familiar with the problem we’re tackling.

Continue reading

Posted in C/C++ Programming, Cortex, Design Issues | Tagged , , , , , , , , | Leave a comment

Making things do stuff – Part 2

Last time we looked at the basics of hardware manipulation in C++.   This time we’ll apply this to some real hardware and have a look at the code generated.

Continue reading

Posted in C/C++ Programming, Cortex, General | Tagged , , , , , , , | 4 Comments

Agile for Embedded Conference – Early Bird registration ends this week

Our early bird offer ends on 31 March, so book now and join us on 3 May for a day dedicated to Agile for Embedded.

The agenda pronises an exciting event and included talks from industry guest speakers Ericsson Television, Altran, and Dyson, all sharing their experiences.

Click here to find out more about the speakers, presentation abstracts or to book your place.  https://www.feabhas.com/agile-for-embedded-conference.

Posted in Agile, General | Leave a comment

Making things do stuff – Part 1

C has long been the language of choice for smaller, microcontroller-based embedded systems; particularly for close-to-the-metal hardware manipulation.

C++ was originally conceived with a bias towards systems programming; performance and efficiency being key design highlights.  Traditionally, many of the advancements in compiler technology, optimisation, etc., had centred around generating code for PC-like platforms (Linux, Windows, etc).  In the last few years C++ compiler support for microcontroller targets has advanced dramatically, to the point where Modern C++ is a increasingly attractive language for embedded systems development.

In this set of articles we will explore how to use Modern C++ to manipulate hardware on a typical embedded microcontroller.

As the articles progress we’ll look at how we can use C++’s features to hide the actual underlying hardware of our target system and provide an abstract hardware API that developers can work to.  We’ll explore the performance (in terms of memory and code size) of these abstractions compared to their C counterparts.

We’ll begin by having a look at the very basics of hardware manipulation – accessing hardware devices and bit manipulation.

Continue reading

Posted in C/C++ Programming, Cortex | Tagged , , , | 13 Comments

Agile for Embedded Conference announcement

Whilst there are a number of conferences dedicated to Agile and Scrum, content dedicated to looking at Agile from an embedded systems development perspective is much more scarce and a topic in which many of us are interested.

Although we don’t generally use the Blog to promote events, we think our conference is unique and definitely worth a mention.Agile for embedded conference

3 May, Easthampstead Park, Berkshire

The day offers a pragmatic and practical approach to using Agile in the embedded development environment.

What’s on the agenda?

Using a mix of keynote sessions, user experiences, vendor presentations and an exhibition, the day will review modern Agile practices in the context of embedded development, share experiences of using Agile in this context, as well as stimulate discussion around Agile development and the specific challenges of being Agile in an embedded environment.

Who should attend?

It is aimed at senior engineers and managers responsible for the development of embedded systems, as well as at embedded developers and engineers with an interest in Agile.

Learn more.

Book your place

For information on sponsorship opportunities, please contact +44 (0) 1793 792909 or email conference@feabhas.com.

Posted in Agile, Testing, training | Tagged , | Leave a comment

‘Abusing’ the C switch statement – beauty is in the eye of the beholder

Copyright: <a href='https://www.123rf.com/profile_stocksnapper'>stocksnapper / 123RF Stock Photo</a>

The C Language

Before we start, let’s get something straight; for over 30 years now I have had a love-hate relationship with the C programming language. The ‘engineer’ in me[1] sometimes just cannot believe we are still using C as the dominant embedded programming languages after all these years, and yet, I also see the simplicity and elegance the C code can bring. After all it’s just a tool, and even a good tool in the wrong hands; well we have plenty of examples of that…

To the task ahead

Let’s assume we’ve got a simple task to program; we have a byte-based interface where we’ll receive either command or status messages. The command messages are the byte value 0..3 and the status 10..12. From this we can create a pair of enum’s:

enum { CMD1, CMD2, CMD3, CMD4, END_CMD};
enum { STATUS1 = 10, STATUS2, STATUS3, END_STATUS };

We have three functions to invoke depending on the byte value:

void process_command_msg(int i);
void process_status_msg(int i);
void report_error(int i);

We could start with a if-else-if chain:

if ((num >= CMD1) && (num < END_CMD))
    process_command_msg(x);
else if ((num >= STATUS1) && (num < END_STATUS))
    process_status_msg(x);
else
    report_error(x);

Then refactored to:

#include <stdbool.h>

bool valid_command_message(int num) {
    if ((num >= CMD1) && (num < END_CMD)) return true;
    return false;
}

bool valid_status_message(int num) {
    if ((num >= STATUS1) && (num < END_STATUS)) return true;
    return false;
}

void process_message(int x)
{
    if (valid_command_message(x)) {
        process_command_msg(x);
    }
    else if (valid_status_message(x)) {
        process_status_msg(x);
    }
    else {
        report_error(x);
    }
}

Alternatively, we might consider that for the small set of message types it might be more efficient to use a switch statement:

void process_message(int x)
{
    switch (x) {
        case CMD1:
        case CMD2:
        case CMD3:
        case CMD4:
            process_command_msg(x);
            break;
        case STATUS1:
        case STATUS2:
        case STATUS3:
            process_status_msg(x);
            break;
        default:
            report_error(x);
            break;
    }
}

If the implementation uses a form of jump-table then this has the benefit of giving you an O(1) performance based on the messages, whereas with the if-else-if chain, the commands will be checked and processed before status and errors.

Adaptability

The common issue associated with switch statement is typically maintenance; especially where the set of ‘valid’ values needs extending. Let’s assume in v2.0 of the system we want to extend the message set to include two new commands and one new status message; thus:

enum { CMD1, CMD2, CMD3, CMD4, CMD5, CMD6, END_CMD};
enum { STATUS1 = 10, STATUS2, STATUS3, STATUS4, END_STATUS };

The significant difference is, as the code stands, that the if-else-if version will handle the change without modification, whereas the existing switch statement treats the new commands still as errors.

So, could we have structure the switch in a way it could have accommodated these potential changes?

Accommodating change

By simply combining the switch and the if-else-if we’d naturally achieve the desired result:

void process_message(int x)
{
    switch (x) {
        case CMD1: case CMD2: case CMD3: case CMD4:
            process_command_msg(x);
            break;
        case STATUS1: case STATUS2: case STATUS3:
            process_status_msg(x);
            break;
        default:
            if (valid_command_message(x)) {
                process_command_msg(x);
            }
            else if (valid_status_message(x)) {
                process_status_msg(x);
            }
            else {
                report_error(x);
            }
            break;
    }
}

Okay it works, but it just doesn’t sit right, does it?

Abuse ahoy

Now here it comes; please don’t read on if you have a nervous disposition…

Let’s start by moving the default around:

void process_message(int x)
{
    switch (x) {
        default:
            if (valid_command_message(x)) {
                process_command_msg(x);
            }
            else if (valid_status_message(x)) {
                process_status_msg(x);
            }
            else {
                report_error(x);
            }
            break;
        case CMD1: case CMD2: case CMD3: case CMD4:
            process_command_msg(x);
            break;
        case STATUS1: case STATUS2: case STATUS3:
            process_status_msg(x);
            break;
    }
}

We’ve moved the default from the last to the first label; as the switch is a conceptual jump-table this means if x == CMD1 it will bypass the default and jump straight to the case label CMD1.

Now if this means we will always jump to the label, then we can do this:

void process_message(int x)
{
    switch (x) {
        default:
            if (valid_command_message(x)) {
            case CMD1: case CMD2: case CMD3: case CMD4:
                process_command_msg(x);
                break;
            }
            else if (valid_status_message(x)) {
            case STATUS1: case STATUS2: case STATUS3:
                process_status_msg(x);
                break;
            }
            else
                report_error(x);
            break;
    }
}

And for the cherry on the top, the else statement (in this context) can act as the equivalent of a break statement. We can, therefore, remove all the break statements (thus also allowing us to remove the need for all the blocks)!

void process_message(int x)
{
    switch (x)
        default:
            if (valid_command_message(x))
            case CMD1: case CMD2: case CMD3: case CMD4:
                process_command_msg(x);
            else if (valid_status_message(x))
            case STATUS1: case STATUS2: case STATUS3:
                process_status_msg(x);
            else
                report_error(x);
}

Finally…

At this point I’d expect one of two responses[2]; the majority of you are reaching for a paper bag to help control your breathing and quoting how many MISRA-C rules this single bit of code actually breaks and why we should be using [insert your favorite language here] instead, etc.

But maybe, just maybe, some of you see the beauty…

[1] C.Eng.

[2] Well maybe a 3rd from all the HN trolls who claim they were taught this in kindergarten

Posted in C/C++ Programming | Tagged , , | 29 Comments

2016 – The Year of the Hack

IoT security has been headline news for at least the past 12 months, and we’ve also had an unprecedented number of incidents affecting consumers in more traditional areas: online banking account thefts, online fraud, OS vulnerabilities, you name it, it’s probably happened. In researching this blog, I found over 400 hack-related stories in The Register alone.

With increasing numbers of embedded devices becoming connected, we are going to hear more and more about security breaches, and guaranteeing security in increasingly sophisticated end-to-end systems is becoming an increasingly difficult task.

Here I’ve picked out just 12 examples:

Continue reading

Posted in Design Issues, General, Linux | Tagged , , | Leave a comment

A convenient untruth

Array notation in C is a lie!

Sorry, dear reader*, but I cannot participate in this conspiracy any longer.  You have been lied to, manipulated and coerced into thinking arrays are a construct of the C language.  I feel it is my solemn duty to blow the whistle on this charade and expose the dirty secrets of C’s so-called arrays.

(* It is statistically possible that more than one person might read this, of course)

Continue reading

Posted in C/C++ Programming | Tagged , , , | 9 Comments