Will the MBEDDR Project save us from using C?

I came across the MBEDDR Project, last night, that seems like it might have some promise to add modern programming practices, such as Closures, Functional Programming, Modules, and others, to C language based embedded systems.

The MBEDDR Language uses JetBrains' Meta Programming System, which is an open source projectional language, as a compiler for the MBEDDR language, that ultimately produces C code to be compiled with your current C compiler.

I have lots of questions myself on this project at this point, such as how easy will it be to get directives like FLASH (IAR) or PROGMEM (AVR-GCC) in the right place? Will it do the Right Thing with volatile? They are also not sure they will open source all of the code; Will they hold back some needed part (FAQ says they might)? Will the code fit in the parts I want to use? At this point it is worth watching and maybe playing with what is currently avaiable.

The project has released code under the Eclipse Public License 1.0. My June 19, 2010 blog entry, I'm Scared, covers my view of Eclipse. It is not a kind one. With Oracles removing its Java from Linux I can't see things improving in the Java area. Any Java code I've ever tried to use has been slow and buggy.

Frama-C to prove formal properties for critical software.

I just came across a project, which has been around for a couple of years, that looks like it could be very useful: Frama-C. Frama-C stands for Framework for Modular Analysis of C programs.

Frama-C is intended to be an extensible static analyzer, that can prove formal properties for critical software. Frama-C does static analysis, dead code removal, security checks, and other functions depending on which plug-ins are used.

Armand, one of the project participants, is working on implementing the MISRA-C 2004 rules for the static analyzer.

Trying out Frama-C: analyzing a simple C program.

Building product variations without duplication of code and configuration. Makefile Tip #1

Mitch Frazier published a How To, Turn Make Options into Tool Flags, in The Linux Journal a couple of years ago, that I have found very useful in my Embedded development projects.

Using Mitch's technique I can have several different top level Makefiles to define options, source locations, and target output directories, that then includes a common Makefile called Makefile.mak. This allows me to build several variations of a product from the same set of sources, while keeping their options distinct and outputs separate.

Mitch's original technique is not MISRA friendly, as it relies on using 'ifdef', that is a missing option is considered a disabled option. MISRA does not allow this because the missing option may have been an oversight. Here is my modified MISRA friendly version:

Create a file called MakefileOptions.inc with the following code:

#---------------------- Cut Line ----------------------------------#
# Option names that start with a minus sign are disabled by default,
# option names without a minus sign are enabled by default.

#CONFIG_OPTIONS=\
#    OPTION_A \
#    -OPTION_B \
#    -OPTION_C

SET_CONFIG_OPTIONS=$(filter-out -%,$(CONFIG_OPTIONS))
UNSET_CONFIG_OPTIONS=$(patsubst -%,%,$(filter -%,$(CONFIG_OPTIONS)))
ALL_CONFIG_OPTIONS=$(SET_CONFIG_OPTIONS) $(UNSET_CONFIG_OPTIONS)
#$(info Set: $(SET_CONFIG_OPTIONS))
#$(info Unset: $(UNSET_CONFIG_OPTIONS))

# Turn config options into make variables.
$(foreach cfg,$(SET_CONFIG_OPTIONS),$(eval $(cfg)=1))
$(foreach cfg,$(UNSET_CONFIG_OPTIONS),$(eval $(cfg)=))

# Make sure none of the options are set to anything except 1 or blank.
# Using "make OPTION=0" doesn't work, since "0" is set, you need "make OPTION=".
$(foreach cfg,$(ALL_CONFIG_OPTIONS), \
    $(if $(patsubst %1,%,$(value $(cfg))), \
        $(error Use "$(cfg)=1" OR "$(cfg)=" not "$(cfg)=$(value $(cfg))")))

# Turn them into tool flags (-D).
#                                                   if   cfg > 0       True:      False:
TOOL_DEFINES+=$(foreach cfg,$(ALL_CONFIG_OPTIONS),$(if $(value $(cfg)),-D$(cfg)=1,-D$(cfg)=0))
#$(info $(TOOL_DEFINES))
#---------------------- Cut Line ----------------------------------#

A the top of your normal Makefile 'include' the above file like so:

include MakefileOptions.inc

The for a typical project I'll have a project uniquely named makefile, such as 'widget1.mak', that goes along these lines:

#---------------------- Cut Line ----------------------------------#
# Hey Emacs, this is a -*- makefile -*-
#----------------------------------------------------------------------------
#
TARGET=Widget1
F_CPU=4000000
MCU=atxmega128a1

# Option names that start with a minus sign are disabled by default,
# option names without a minus sign are enabled by default.
# Values on the command line override these:
CONFIG_OPTIONS=\
-ENABLE_CHIRP \
ENABLE_LEDS \
HAVE_RADIO \
USE_CRC_FLASH_CHECK \
-USE_DEBUGGING \
-USE_MOTION_SETTING_SCREEN

# List C source files here. (C dependencies are automatically generated.)
SRC = Accel/accel.c \
MENU_WIDGET1/menu.c \
....

ASRC = HARDWARE_XMega/sp_ReadFuseByte.S HARDWARE_XMega/sp_commoncmd.S ...

EXTRAINCDIRS = MENU_WIDGET1 HARDWARE Accel Alarm Backlight Battery CRC ...

include Makefile.mak

#---------------------- Cut Line ----------------------------------#

Each project variation gets a similar file that is invoked with 'make -f widget1.mak'.

An example C usage:

/*---------------------- Cut Line ----------------------------------*/
#if( USE_CRC_FLASH_CHECK > 0 )
extern uint16_t __data_load_end[1]; /* Defined by the linker script.  Set to address of last byte of .text+.data section */
#include 
static __inline__ uint16_t crc_flash_check_has_error( void );
static __inline__ uint16_t crc_flash_check_has_error( void )
{
...
}
#endif
/*---------------------- Cut Line ----------------------------------*/

Software Safety blog reader Michael Barr has a new article Bug-killing standards for firmware coding on Embedded.com, where he discusses "Ten bug-killing rules" Michael also has his own blog.

There is also an interesting discussion going on in the comments section related to the article.

I even added a comment of my own:

Dale Shpak wrote:

" I have debugged millions of lines of code and have encountered the following type of error many times:

while (condition);

{

/* Execute conditional code */

}"

If you put this in your .emacs file:

(global-cwarn-mode 1)

Errors such as "if(condition);" and "while(condition);", as well as "if( x = 0 )" type errors are highlighted.

No need to use the One True Brace style when you are using the One True Editor... :-)

Also MISRA 21.1(a)/2004 requires the use of static analysis tools, that would never allow the passage of an always executing "conditional".

MISRA doesn't say much about style. It does say braces will always be used. I say that they should clearly show the nesting. Path coverage testing is hard enough without playing "find the matching brace" (EMACS helps out here too).