A few fun things you can do with C structures: 1. Bitfields

struct {
    uint32_t    year        : 7,
                    month    : 4,
                    day        : 5,
                            : 5,
                    hour    : 5,
                    min        : 6;
} compact_date;

Notes: 1. Turns out that C99 defines fixes-size integer types: no more need to define them yourself. 2. The order in which bits are placed into a bitfield (MSB or LSB first) is not standardised - which is ok if you're only on a single platform, but may get messy otherwise. 3. To leave reserved blank spaces, just leave them blank. 4. If you need fewer bits, just use fewer. This structure can store a date (up to 127 years) using only 4 bytes (as opposed to the naive implementation which would require 5 or more). Not a massive win, but convenient when alignment is a concern. 2. Unions

union {
    uint16_t    isDate        : 1,
                    month    : 4,
                    day        : 5;
    uint16_t                : 1,
                    hour    : 5,
                    min        : 6;
} datetime;

This little beauty allows overlapping bitfield definitions: depending on the value of isDate, you can access either month/day or hour:min inside the same compact storage area. 3. Head and trailer structures

struct {
    uint16_t    type;
    uint16_t    len;
    uint8_t        data[1];
} tlv;

This is a fairly common construct but still rather useful. Because C doesn't check array bounds, you can readily access additional data[] elements - the only trick becomes handling sizeof() operations cleanly. To get the size of the header (only):

&((tlv*)0)->data)

To get the size of the complete structure:

sizeof(tlv) + sizeof(tlv.data[0]) * (data_count - 1)

4. And finally, just for fun:

#define STDIO "stdio.h"
#define STRING 
#include STDIO
#include STRING

int main (int argc, char** argv) {
  printf("Don't let me catch you doing this!\n");
}

For our Big-Eye project (a 3.1 Megapixel network camera for security and remote monitoring applications), we needed an efficient software algorithm for converting the Bayer-format data used by the image sensor to RGB data suitable for sending across the network / JPEG compression. A simple C algorithm was coded which did the job. However, it was very slow - about 1.7 seconds to convert a single frame. This was using GCC 4.1.1. The code was fairly well written, using word operations to move through the three lines of the image, two pixels at a time. It was not looking good. After spending a bit of time trying a few basic optimisation techniques, we decided to try the RealView compiler. This now supports most of the GNU options and it is fairly easy to build software using it. The result was pretty astounding. With no code changes, RealView produced an execution time of around 0.3 seconds! A bit of additional fiddling suggested that further improvements might be possible. The main difference seems to be that RealView makes much better use of registers, and thus needs a lot less load/store on the stack. This is probably a common feature of many image processing algorithms. If written with efficiency in mind, they will push the register set quite hard. Much assembler optimisation relies on using the register set more efficiently. But if the compiler can do it for you, so much the better. We could easily have spent a few days working on this part of the code, and with RealView it was just a re-compile. In the end we have moved all the code over to RealView and this is now the standard build environment.

Bluewater Systems participated in a project called Sky Challenge which allows high performance aerobatic aircraft to race through virtual courses.  Using high precision GPS and inertial systems the aircraft's position is sent to a heads up display, which displays a series of objects for the pilot to fly through.  Spectators on the ground were able to watch the actual race in the sky, and a real time computer enhanced version which showed the virtual objects. Bluewater Systems' part in the project was the development of a heads-up display system which the pilot used for flying the course , and co-development of a microwave communication link which sends the positional data for the aircraft to the ground.  The heads-up display software was developed by working closely with a number of aerobatic pilots.  The main goals of the software were to provide the pilots with as much information as possible, without cluttering up the screen. Since Sky Challenge was open to an invite-only audience, have a look at what we were able to experience firsthand. http://news.bbc.co.uk/2/hi/technology/7651500.stm

Surely most engineers are familiar with the basics of the ARM7TDMI? To recap, it has a 32-bit register set with 16 registers, RISC load/store architecture, various processor modes with a role in exception processing, private registers in each mode (particular FIQ with a very useful r8-r14), a simple 32-bit instruction set with only 21 types and an additional 16-bit instruction set with zero-penalty decode logic. Since it was originally released in 1994, several of ARM's engineers wanted to improve on perfection. Perhaps the power consumption could be made even lower, perhaps the instruction set could be made even more dense, perhaps more microcontroller features should become part of the standard design? The shrinking area of silicon required for a microcontroller, and the resulting reduction in cost, presented another opportunity. It should be possible to make an ARM chip as small as an 8-bit micro, and to consume less power. Cortex-M3 is the result of these factors. It is not radically different from ARM7TDMI, and retains most of the architectural features. But it drops several, expands others, and adds a few more. Key features of Cortex-M3 are:

• You program it entirely in C. There is no longer any need for assembler, although it is still available. This doesn't mean that it is less efficient
• It won't run Linux. It is aimed at small microcontrollers so does not include data aborts for virtual memory, etc.
• Built-in microcontroller functions, such as interrupt controller, timers, memory protection
• Drops exception modes and the ARM instruction set (only supports Thumb / Thumb 2)

Some lesser features are:

• Thumb-2 instruction, a clever extension which gives the code size benefits of Thumb with the performance benefits of 32-bit ARM code
• Single Wire Debug (SWD) option, which reduces the number of pins required for JTAG/debug functions from 5 to 2
• Integrated trace functionality, traditionally only available on higher end ARM9 devices. Cunningly, it also operates over the SWD port
• Half the interrupt latency (or better), by building the concept of state saving directly into the micro. In particular, consecutive interrupts can be processed without the traditional save/restore step in between
• Half the power consumption when running, plus an integrated sleep mode
• 30% faster operation at the same clock speed
• ARMv7-M Harvard architecture with a number of new instructions

ARM's removal of the exception processing part of ARM7TDMI was not just a clever way of getting rid of stuff that low-end microcontroller engineers don't need. It also provides a clear differentiation between the higher end micros and the new microcontroller range. This make it possible, at least in theory, for companies like Atmel to sell an ARM9 range at $6, and ARM7 range at $3-4 and a Cortex-M3 range at $1. In my view this is one of the cleverest features of Cortex-M3 - it doesn't canabalise the existing market to the extent that you might think. Bluewater Systems has completed a number of Cortex-M3 designs and we have built quite complex embedded software systems using it. When combined with the RealView tool chain, it is a formidable player in the embedded market. For the price, it is surely unbeatable. Cortex-M3 micros were first shipped by Luminary Micro who have 134 models to choose from. ST Microelectronics have a respectable 38 so far. Atmel is on board now also although I can't see any devices yet. For more details on Cortex-M3, and if you have an hour spare, take a read of the original white paper on the topic from ARM's web site. You might find this useful too.

3G data modem support is a core feature for the Real Time Passenger Information (RTPI) system designed by Bluewater Systems. The RTPI system is designed to collect and display information about the arrival times of buses at a particular point on the route. This information is provided by a unit on the buses which uses a GPS receiver and GPRS or other wireless communications to pass on positional information to a central server.

The choice of the 3G modem was dictated by another requirement: to use a cheaper GSM data modem as an assembly option. Bluewater decided to use the 3G embedded module MC8775 from Sierra Wireless, a low talk and low standby current modem which comes in PCI Express Mini Card form factor.

A Sierra Wireless MC8775 PCI Express Mini Card supports third generation (3G) digital cellular standards and it is globally certified. An MC8775 supports tri-band UMTS (HSDPA): 850/1900/2100 MHz, with forward link up to 3.6Mbps, and quad-band EDGE/GPRS/GSM: 850/900/1800/1900 MHz, with forward link up to 216 Kbps.

Although the data modem has a PCI Express Mini Card form factor, it does not support a PCI Express electrical interface. The host and USIM interfaces, as well as power supply for the 3G/GSM modules, are provided via a PCI Express Mini Card connector. The communication between the 3G data modem and the host (Snapper CL15 module) is provided via a USB 2.0 interface.

The PCI Express Mini Card form factor allows a simple downgrade path if it is cheaper, however, the same form factor GSM data modem designed by Bluewater Systems is desired. Another benefit of having the same form factor for 3G and GSM data modems is a smaller main board and a simple upgrade/downgrade path.