~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Firmware Update
- June 14, 2011
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
in this issue
-- Threads vs. State Machines
-- Is "(uint16_t) -1" Portable C Code?
-- Industry News That's Not Boring
-- Reader Q&A - Shared Source Files

Firmware Update® is a free e-mail newsletter by embedded software expert Michael Barr. The contents are Copyright 2011 by Netrino, LLC, but may be reprinted for non-commercial purposes. Please forward it to colleagues who may benefit from the information.

Threads vs. State Machines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 A thread preserves the context of computation in the call stack and the program counter. This nicely matches languages like C and C++ so that programmers used to the sequential way of thinking can continue to apply it to non-sequential event-driven problems.

By contrast, pure event-driven programming naturally partitions programs into small chunks that handle events. State machines partition the code even more finely, because you have small chunks that are called only for a specific state-event combination.

Which style is better overall?


Is "(uint16_t) -1" Portable C Code?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Twice in the last month, Netrino's engineers have run across third-party middleware that included a statement of the form: uint16_t variable = (uint16_t) -1; which we take as the author's clever way of coding hex 0xFFFF.

I'm not naturally inclined to like the unnecessary obfuscation, but wondered if it was portable C code? And, if portable, if there is some advantage to suggest using that form over the hex literal? In the process of researching these issues, I learned a helpful fact or two worth sharing.

Well, is it portable or not?


Industry News That's Not Boring
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Do Small-RAM Devices Have a Future? http://bit.ly/impC4f

7-segment LED birthday cake. "Recipe": http://j.mp/mb4dQR

CS Enrollments Going Up. Article: http://nyti.ms/jikpo5 // But not fast enough to meet demand!

A compact sturdy USB-rechargeable 500 lumem flashlight with an MCU running upgradeable open source firmware? I'll take two please: http://hexbright.com

Nobody Writes Perfect Software. Not Even You: http://bit.ly/ltHdwc

Is there a useful subset of C that is safe from compiler bugs? Probably not: http://bit.ly/lND2iE

License, Registration, and Firmware Update History File Please! Our Future: http://nyti.ms/lLxciD

Want more stuff like this?


Reader Q&A - Shared Source Files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 From a reader: "I'm working on an embedded control system that shares source files with a data server on a PC. The data server reads the same configuration files (describing the sensors) as the firmware. The embedded system uses the shared files to configure the sensors while the data server uses them to create headings in the data files. The simple solution I used was an #if compile_embedded to #include "other_code.c" for the embedded system at the end of the shared source code file (common.c). I see that this violates one of the rules of your Embedded C Coding Standard. Is there a better way of sharing source code? Thanks for your insight and a great book."

Why don't you just use a makefile (or similar) to build two files instead of one? There's no apparent reason that "other_code.c" needs to be built within "common.c". I suggest that common.c and other_code.c each define their "public" services in common.h and other_code.h, respectively.

Have a question?


Quick Links
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  • Embedded Software Training in a Box
  • Embedded C Coding Standard
  • Embedded Systems Books
  • Embedded Software Boot Camp 2011


    • Contact Information
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    phone: 866.78.EMBED
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~