Technique for automatic firmware version number assignment

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Like Jedi crafting their own light-sabers, it seems that every software embedder devises their own scheme for stamping version numbers into firmware builds. Mine's just been installed into its third product build process with good success, so I thought I'd share it FWIW. Besides, it has a nice green color and makes a cool "Fweezzzhhh" sound when it's switched on.

It's based on a Perl script that uses the SHA1 library module to generate a unique signature representing the contents of a list of files. Those files are usually the compiled objects for the product in question, so that the "what version is this?" question is determined on the basis of everything that's pertinent to the final product, and not on things like source file dates or comments.

The most straightforward application uses a line like this in the product's Makefile:

LDSWITCHES += $(shell perl assignVersion.pl --Wl,--defsym=Version= $(TARGET) $(OBJ))

(perhaps suitably modified to reflect the exact whereabouts of the assignVersion.pl script). Somewhere in the code there'll be some "spit out your version" query that could have a form like so:

uint8_t getVersion(void)
{
    extern void *Version;
    return (uint8_t) (uint16_t) &Version;
}

All this works well for standalone projects. I have a couple, though, that include significant content from a link archive of precompiled modules, and the content of the linked modules wouldn't contribute to the hashed signature if done as above. In those cases, I add a line to the stock Makefile's ".hex from .elf" rule that uses the extracted .hex file as the only contributor to the signature, and then edits that .hex file to insert the computed version number in some appropriate place.

The attached script has commented-out steps for maintaining its archive of "version numbers assigned so far" in the Clearcase version-control system my group uses, but should be adaptable to other tools, or run without any version control for that matter.

I had to change its extension to a ".txt" one to make the Forum tolerate it as an attachment, but it was intended to have a ".pl" extension.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

LDSWITCHES +=

Do you mean LDFLAGS by any chance? ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Version numbers in Git are sort of built-in. Git does a source hash for every commit, so you can change a hard coded version number and commit that with the comment "Version x.x.x". Then you have searchable tags for each version and can easily move back and forth between versions. The build will show the version used, but it's still useful to show the date of the build as well, so you know which toolchain bugs to watch out for.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

LDSWITCHES +=

Do you mean LDFLAGS by any chance? ;-)
Yes, that would have been clearer. Somehow, my reused core Makefile has had this derivation for "LDFLAGS" since forever (with comments removed for brevity):
PRINTF_LIB = 
SCANF_LIB = 
MATH_LIB = -lm
LDFLAGS += $(COMMON) $(LDSWITCHES) $(PRINTF_LIB) $(SCANF_LIB) $(MATH_LIB)

, so I got into the habit of applying my tweaks to the "LDSWITCHES" part for no good reason. Giddy with macros, I guess.