Saturday, September 25, 2010

"Encourage the USPTO to stop issuing software patents; deadline September 27" 2010. Bilski v. Kappos

Readers of the patent section of the Software Safety Website know that Software Patents are bad.

Software Patents stifle innovation and raise the specter of Lawyers showing up.

I generate a lot of code, unfortunately I'm afraid to publish most of it. I'm afraid that I will accidentally stumble into a Software Patent that should have never been implemented in the first place. Anything that raises the specter of lawyers is bad.

With short notice (Deliberately so We The People could not comment and the big company lawyers could?) the United States Patent Office is seeking guidance on how Software Patents should be handled in the future.

The Free Software Foundation has the details of how to submit your comments, which must be in by this Monday Sept. 27th 2010.

When was a Software Patent issued to a little guy or gal like you or I? They all seem to be to the Mega. Corps. that just want to kill competition. The language R++ is a perfect example of this. If Software Patents where in effect as today then the world would not have C++.

Get your comments in now.

All of this came to a head with the Bilski v. Kappos decision in June of 2010.

Saturday, September 11, 2010

PSGroove unexpected consequences. Guilt by Association?

I participate in several Open Source projects, for example AVR-LibC, gEDA/PCB (mostly PCB), wxWidgets (Even got my name in the wxBook) and LUFA 'Lightweight USB Framework for AVR'.

LUFA is a project of Dean Camera's, which makes a clean API for Atmel USB parts. Dean's code makes it easy to get a Atmel USB project up and going.

I had recently submitted some bug findings and fixes to Dean, for which he acknowledged me by name on his blog in several different places.

What neither of us saw coming was the PSGroove project for the Sony Play Station 3 [TM].

In early PS3 systems Sony allowed "other operating systems", typically meaning Linux, to be booted on the PS3. For reasons known only to Sony, they removed this "other operating system" option to the dismay of many. The PSGroove project was a way to restore the functionality that many had paid for, that Sony removed.

While some code is actually meant to be stolen like this package from Netrino, most code is not. Unfortunately the PSGroove project could be exploited to aid software piracy. So I wanted to be clear that neither Dean nor I support software piracy.

The Business Software Alliance is one of the few independent organization that actively fight software piracy, if you want to help stop what damages us all.

"One of the consequences to all this is that every single bleeding USB AVR in the world (which were already in short supply) have been snapped up, either by board houses trying to pump out some boards to sell to gamers as quickly as possible, or by the gamers themselves as pre-made development boards."

Sony rapidly responded to this vulnerability rendering this attack inert (I'd use an other word here, but it would set off Family Filters).

Now that PSGroove is no longer useful, can I get some Atmel AT90USB1287 again?

Atmel has really been screwing my company over on delivery times, so maybe I'll bump into you at Renesas DevCon Conference 2010?

MISRA tutorial and seminar announcement. Standards or Guidelines?

If you are a world traveler, The Motor Industry Software Reliability Association (MISRA) just announced a tutorial and seminar:

"A tutorial and seminar in collaboration with the Safety-Critical Systems Club (SCSC) will be held on 24 and 25 November 2010 in London, UK. On the first day there will be two half-day tutorials, on the MISRA C and MISRA C++ guidelines for the use of these languages in critical systems. The second day will be a seminar that will consider how the MISRA guidelines support safety-related systems development in various industry sectors, and we are particularly keen to feature presentations of case studies. If you would like to speak at this seminar, please discuss your idea with me in the first instance.

Further details of the programme will be available in due course.

There will also be a small exhibition on the second day. Details of the exhibition are available from Joan Atkinson at the SCSC

Dr David Ward
MISRA Project Manager

For those not familiar with MISRA, MISRA publishes a set of 'Guidelines' on 'Best Practices' for the languages C and C++. For example what languages constructs are bug prone and should be avoided in embedded systems used in vehicles. Many companies outside of the automotive industry have adopted the use of these guidelines, to help keep bugs out of their products.

Netrino also has a similar set of guidelines, with some links to some real world tips: Embedded C Coding Standard.

A technical semantic nit I want to pick is that these are guidelines. Standards are set by recognized bodies like IEEE and IEC - International Electrotechnical Commission. I frequently see things like "MISRA Standard". The distinction is a subtle one, but could be important to a product liability suite. Which is not to say that a company can not set 'internal standards' for coding practices. English is such a wonderful language... :-(

IEEE P730 Standards Software Quality Assurance, IEEE/EIA 12207.0 Standard for Information Technology - Software Life Cycle Processes, and IEC 61508 Functional safety of electrical/electronic/programmable electronic safety-related systems, are all example of standards used in Embedded Systems. There are more examples at my Software Safety site.

Monday, September 6, 2010

Tips on improving productivity. Lets Do Lunch.

The one thing I really like about Agile Development is that it promotes the forty hour work week, with the tenet being tired programmers make mistakes. Read Jack Ganssle's Memo to my boss, to truly understand why the forty hour work week is a good thing.

As to why we are here today, it is because of this article on CNN Money: Overworked? Take back your lunch hour by Anne Fisher.

Anne Fisher, AKA 'Ask Annie' points us to several resources to improve our daily productivity. Seems the best way to improve productivity and creativity is to stop doing both, that is take a break and rest. One of the resources is the The Energy Audit from the Energy Project. My audit score was a mediocre nine out of twenty (9 to 12:=" Significant energy deficit"). Guess that is what happens when you work twelve hour days for years on end? What was your score?

I did not like how the questions were biased to the negative, as most started with "I don't". Questions and statements geared to self-improvement should always be framed in the positive. Makes me wonder if the scores would be much lower (lower being better in this quiz) if they were worded in a positive tone? The cynic in me wonders if that is deliberate to drive business to the project?

On the question about be distracted by incoming email, I've found a good solution that works for me. I check email when I arrive in the morning, at 10 AM, and Noon, 2 PM, and 4 PM. No pop-ups to derail my train of thought like I see on most of my colleagues systems. Been doing this for years, and so far no one has complained about a slow response to an email. After taking this quiz, I think I'll check email after lunch instead of before. Do your really want to be conditioned like Pavlov's Dog, to respond to ringing bells and ringing pop-ups?

"Nothing is gained—and much is lost—by constantly pushing people to achieve more and more in less time and with fewer resources; rejuvenation and rest are necessary for creative breakthroughs and broader perspectives."
-- Tony Schwartz, CEO of The Energy Project.

Ironically if you are to busy to read the book, you can listen to it while building stress setting in traffic on CD:

Sunday, September 5, 2010

"GCC - 'We make free software affordable'". A Short history of GCC.

Richard Hillesley has written a short and interesting history
of the GCC compiler
, where its been, and where we might be going with LLVM.

For anyone that is interested in the history of computers, valuable background to understand how we got where we are today, the book Hackers: Heroes of the Computer Revolution - 25th Anniversary Edition by Steven Levy is a *must read*.

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.

Saturday, September 4, 2010

Transforming files with wildcards in Make. Makefile tip #3. Manipulating .hex files, and auto CRC generation.

Last tip, for a while, in our series of tips on using Make and Makefiles.

Make has several function that can manipulate strings. Pattern Substitution, 'patsubst', is one such function. It replaces a from, with a to in a text target string. '%' acts as a wildcard, matching any number of any characters within a word, when used in a from or to pattern of 'patsubst'.

A keyword that can be used in functions is 'wildcard'. This keyword, used anywhere in a Makefile, is replaced by a space-separated list of names of existing files that match one of the given file name patterns. By combining 'patsubst' and 'wildcard' a Makefile can be created that will transform all files in a directory to an other file type. In the following example simple text files (*.txt) are transformed into Intel Hex files (*.hex), to change human editable configuration files, to files that can be burned in to Flash.

objects := $(patsubst %.txt,%.hex,$(wildcard *.txt))

.PHONY : all
all : $(objects)

# Create hex files from txt source files:
%.hex : %.txt
 srec_cat $< -COsmac -Output $@ -Intel

The program 'srec_cat' is part of the SRecord package by Peter Miller. SRecord is a suite of programs for transforming files to and from Motorola S-Record (S9), and Intel Hex, Records, to/from many other formats.

I use a combination of Make and srec_cat to automatically calculate and append a CRC of the binary image being created, so that my Embedded System can validate that the program is good on each power up. See our past entries on IEC 60730.

In the examples below I show how I create a CRC in the Makefile, then verify it in my C application. Real Soon Now I plan on switching to CCITT-CRC with Magic Number checking. The XMODEM CRC was the only one available in both AVR-LibC and SRecord when I started down this road...

# Create final output files (.hex, .eep) from ELF output file.
%.hex: %.elf
# Do normal stuff here.
# Append CRC to the HEX file that was created in the 'normal stuff' section:
# Rename the standard compiler output from *.hex to *.org.hex:
        mv $(OBJDIR)/$@ $(OBJDIR)/$(TARGET).org.hex
# Calculate then append the CRC, to a newly created *.hex output (Watch for line wraps, the following is one long line):
 srec_cat $(OBJDIR)/$(TARGET).org.hex -Intel -Little_Endian_CRC16 -MAximum-Address $(OBJDIR)/$(TARGET).org.hex -Intel -Cyclic_Redundancy_Check_16_XMODEM -Fill 0xFF -OVER $(OBJDIR)/$(TARGET).org.hex -Intel -Output $(OBJDIR)/$(TARGET).hex -Intel

How to utilize the above CRC in an application:

/* *************************************************************************************** */
extern uint16_t __data_load_end[1]; /* Defined by the linker script.  Set to address of last byte of section */
#include <util/crc16.h>
static __inline__ uint16_t crc_flash_check_has_error( void );
static __inline__ uint16_t crc_flash_check_has_error( void )
  uint8_t  byte_u8;
  uint16_t crc_u16, i;
  uint16_t const flash_end_u16 = (uint16_t) &(__data_load_end[0]);

  for( crc_u16 = i = 0; i < flash_end_u16; i++)
       byte_u8 = pgm_read_byte( i );
       crc_u16 = _crc_xmodem_update( crc_u16, byte_u8 );

  if( pgm_read_word( flash_end_u16 ) != crc_u16 )
      return( 1 );
      return( 0 );

__attribute__ ((OS_main)) int main( void )
  hardware_setup(); /* Put system in known state.  Bootloader should have already done this, it is here in case we have old bootloader */

  if( crc_flash_check_has_error() )
    {/* Flash is corrupted: */
        {/* Blink the LEDs to indicate corrupted memory, we are dead */

}/* main() */

The great unanswerable question in some cases is what do you do when you know the Flash is corrupted? The LED_TOGGLE() section, or even the test itself, could be what is damaged.

Recursive use of Make. Makefile tip #2. Want a secret tip to faster development?

To continue our series of tips on using Make and Makefiles. Something that I've observed on occasion in top level Makefiles is this construct:

 make -f widget1.mak
 make -f widget2.mak
 make -f widget3.mak

The proper way to write this, is:

 $(MAKE) -f widget1.mak
 $(MAKE) -f widget2.mak
 $(MAKE) -f widget3.mak

That is recursive 'make' commands should always use the variable '$(MAKE)', not the explicit command name 'make'. Using recursive Makefiles properly run faster and do not suffer from hair pulling macro expansion problems in the nested Makefiles.

That would make for a rather short blog entry, so lets expand on the root cause of the problem. Did you read the manual for Make? Ever?

What is the secret tip to faster development? Like most things it is a simple one: Read the manuals for your tools, be it the new O'Scope you just bought (Did you know about the Badger and Games in the HP 54645D? Only reading will find them.), or the development tool(s) that you have been using for years. Have you ever read the excellent manual for Make for example? Ever read the manual for EMACS? GCC?

Alas far to many programs and projects suffer from no documentation, or worse yet, wrong/outdated documentation. I've always found that writting the documentation for a project before code is even considered makes for faster development, a more robust product, and stops the problem of "we'll get around to the documentation someday" after the code ships. Don't over look tools like Doxygen to help out.

Audrey Watters recently wrote Tips for Writing Good Documentation. Has links to several other guides to creating documentation, and helpful tools. Checkout the comments at the bottom as well.

If you are serious about writing good documentation, and for that matter code, make a trip to your local library and checkout a copy of the Chicago Manual of Style.

One final tip on documentation:

Read It Seven Times

9 September 1985
Z-NEWS 302

Echelon, Inc.[*]
Los Altos, CA 94022
[Now out of business, outdated info removed]

Z-News 302 is Copyright 1985 Echelon, Inc. All Rights Reserved. Permission to reprint, wholly or partially, automatically granted if source credit is given to Echelon.

WOW! again: Foot put into mouth! Suggesting (in Z-News 209, pg 2, first line) that everyone read material seven (7) times, without simultaneously giving full explanation of why, has been big stumbling block for many. So we deliver details to remove those (mental) blocks; remember, read through explanation (and everything else) seven times:

Readings 1 and 2. Skim material twice, quite rapidly. Use your finger to help your eyes play over words, lines, and paragraphs. Key words and phrases, ideas, and concepts begin to take from. You gain a feeling of the thought-flow, a framework making next step more powerful.

Reading 3. Read material now from beginning, much more slowly and carefully. Pause to re-read and ponder new ideas and deep thoughts. Use dictionary for unfamiliar words.

Readings 4 and 5. Skim over material twice again, but not quite so rapidly as first two times. Let key concepts sink in even deeper. This is a more leisurely skim. Pause at any word looked up in dictionary and make sure you know both basic meaning of word, and its meaning in present context. Sometimes the thought expressed by a particular word or phrase is so new that it's difficult to grasp at once, even with dictionary help! Do not worry at this point. Future readings add clarity.

Reading 6. Now, read material from beginning again with extreme care. Now is the time to really pause, to ponder, to digest, to impress deeply. Try to obtain essential, inner feeling of messages, even though you may not understand them fully or grasp completely at this stage. Try at this point to read material aloud!

Reading 7. It's a slow skim. Somewhere between your leisurely skim and your first careful reading, #3. It is time to enjoy, to bathe yourself in new insights and viewpoints opening up to understanding comes (in next octave)!

There you have it--we do our best to explain. Never think that learning something new, really new, comes quickly or easily. GREAT EFFORT IS INVOLVED! But keep reading even if you think you don't understand--what comes later (down the lines) explains what came before, following natural back-and-fill (smoothing) concept.

*: The Echelon above has no relation to the purported NSA Echelon spying project, nor the Echelon company that has always sold interesting control networks for buildings with you've got to be kidding prices for the development tools anytime I looked in the past.