Check Your Math

How well do you trust the basic mathematical operations of your processor? Subtle math errors in code can allow access secure data. Even if you are not implementing a security algorithm, potential problems from basic mathematical errors can cause results that would seem impossible. There are methods to help prevent these problems:

• Use asserts before any critical operations.
• Test important (security) results for consistency.
• Use a watchdog timer.
• Check processor errata sheets (both for development and production versions).
• Use mature, well tested math libraries.
• Write unit tests for the mathematical sections of the code.

This all adds another layer of complexity to embedded system design, but that cannot be avoided with the increasing complexity and security of modern systems. So make sure to check your math.

Adding Math to List of Security Threats - NY Times Math Error Could Compromise Cryptographic Systems - Information Week

Using Google SketchUp for Electronics Projects

You might find Google's free 3D software, Google SketchUp, useful for your next hardware project. Here are a few examples from Google's 3D Warehouse design repository.
This single board computer model was created by special computing for an embedded computer board.

This Calao Systems Single Board Computer has a 200Mhz Atmel AT91SAM9263 ARM926EJ-S, 256MB flash, 64MB SDRAM, EEPROM, U-Boot, Linux 2.6, 4 USB ports, 1 programming/debug, 2 stacked host, 1 mini device, and an expansion connector (for I2C, Audio and Video).

It was pretty easy to for me to use SketchUp to manipulate the 3D model to see all of the components. You can also export any view as a 2D image or an animation to show customers your designs. It didn't take me long to create an animation once I learned the basic controls.


Here is another example of a 3D model created for a PCB layout.

Benford's Law

While updating my page of DSP links, I noticed a new chapter to The Scientist and Engineer's Guide to Digital Signal Processing about the solution to Benford's law. This phenomenon was first noticed in 1881 by Simon Newcomb, but the rediscovery by Frank Benford in 1938 gives it its name. Both noticed something odd about books containing tables of logarithms, pages with data with 1 as the first digit were worn more than pages with other digits. Benford found this type of pattern in a wide variety of data sets such as numbers in magazine articles and baseball statistics. It seemed that the data should be random and the first number would have an equal probability to be any digit between 1 and 9, or 11.1% for each. In fact, the pattern of leading digits fits a logarithmic distribution, with 1 having a 30.1% probability.

This phenomenon was observed but not understood until recently, and that gives it the connection with DSP. A proof can be constructed using signal analysis techniques, in particular convolution, the Fourier transform and homomorphic processing. See Steven Smith's new chapter for details, but you might not need mathematics to understand the mystery. According to Smith, the key is to realize that we are transforming the data when we extract the first digit. Since it so easy to see the first digit, we do not realize that we are performing any operation on the data. This operation is taking the anti-logarithm of the data, and that gives the logarithmic pattern to the leading digits. Wikipedia has a few other explanations as well, but I think there is a counterexample that is much easier to understand:

If we assume that a random event has a random leading digit, then we are saying that a number with a leading 1 has an 11% probability. That would be true if we had a single die with 9 sides. Any of the sides would correspond to a different leading digit, but what about a die with 20 sides? There are 11 digits that would start with 1 out of the 20 for a 55% probability of a 1. For an average 7 sided die, it would be 14%. In fact, I think you will find it would never be less than 11% for any number of sides, but we find many cases where it is greater than 11%. So for data that can have any value between 1 and N, the probability of a 1 must be greater than 11%.

This is not a complete proof, and even if true, the counter-example does not address events like the roll of two or more die, or fractional data, but it is enough to remove my initial disbelief in Bedford's law. If books with tables of numbers are worn the most on pages with data that has a leading 1, it could just be that the type of data being analyzed follows this 1 to N pattern. I would imagine that many types of data sets have this property.

For more information about Bedford's law I recommend the pages on Mathworld and Wikipedia. It was also featured in the episodeThe Running Man, of the TV show NUMB3RS.

Welcome

Welcome to my blog about embedded systems development. In this first post I would like to tell you a little about myself and what I plan on writing about in the future. I encourage your comments on this blog and hope that I can use it to collaborate with my embedded systems colleagues.

I have been developing embedded systems since 1995, at a number of companies, both small and large, and on a variety of products. These include consumer, defense, and industrial products such as toys, computer peripherals, networking hardware and communication equipment. I really enjoy designing new products and bringing them to fruition. I am now practicing as an independent consultant, continuing to work on innovative and challenging product development.

In my career I have worked with many great people, and been part of some terrific development teams. I hope some of my former coworkers get a chance to visit and possibly contribute to this site. I have learned a lot from them and I'm sure others could benefit from their insight as well.

In the past I have worked mostly on the embedded software side of the engineering team, but I always worked very closely with the hardware developers in design reviews and system debugging. More recently, I have been developing my own hardware designs. I think hardware/software co-design is extremely important in embedded systems development and I plan on covering this topic. I would also like to explore development team structures and project management.

In summary, I would like the embedded coding blog to be a place to share my development experiences and knowledge, keep up with new technologies and discover some best-practices with the help of my readers. Some of the topics I would like to discuss include embedded microprocessors, development tools, network programming, system architecture, test equipment, system testing, and version control. Please feel free to e-mail me at ac@aaronclarke.com with any suggestions to improve this site.