Adding compile time / date to hexfile

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

Hi !
I want to add automaticly the build time and date to my binary (so that I can read it out while running)... and perhaps a firmware version....

And if it's possible, the outputfile (hex) could be renamed, so that the date/time is added to its filename ?

Best regards,
Andreas

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

Maybe not exactly what you want, but have a look at the __DATE__ and __TIME__ predefined macros

http://gcc.gnu.org/onlinedocs/cp...

JW

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

baer.ac wrote:
And if it's possible, the outputfile (hex) could be renamed, so that the date/time is added to its filename?
To do this, I recommend that you start by building an external makefile for your project (WinAVR's MFile template is an excellent start on this).

Unfortunately, there is no way (that I could find) to invoke the date/time facility from inside the makefile. So, you will need to feed the date/time into the invocation of make:

> DATE=`date +#Y#m#d-#H#M#S` make all

(Warning: in the above, replace # with % - this blog doesn't like the % with a following character.) This will pass the symbol DATE (with the date in the form, for example, 20100329-095354) into the make. You then would modify the hex generation rule to something like:

#.hex: #.elf
	@echo
	@echo $(MSG_FLASH) $@
	$(OBJCOPY) -O $(FORMAT) -R .eeprom $< $@
	mv $@ $(TARGET)_$(DATE).hex

(Same comment about % ) This would rename your final .hex file to, for example, foo_20100329-095354.hex. Check out the GNU Make Manual for more details.

The above assumes you have Cygwin installed. If you only have the DOS prompt (poor soul) I'm sure there is an equivalent call to the date function.

Of course, you could then encapsulate the above make with time setting stuff into a script file of some sort.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

I just do this in a .c file that I "touch" with the Makfile to ensure it is rebuilt every time:

const uint8_t help[] PROGMEM = { 
"\
Program version "__DATE__" "__TIME__"\r\n\n\
1 - toggle LED1\r\n\
2 - toggle LED2\r\n\
etc...

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

stu_san wrote:
baer.ac wrote:
And if it's possible, the outputfile (hex) could be renamed, so that the date/time is added to its filename?
To do this, I recommend that you start by building an external makefile for your project (WinAVR's MFile template is an excellent start on this).

Unfortunately, there is no way (that I could find) to invoke the date/time facility from inside the makefile. So, you will need to feed the date/time into the invocation of make:

> DATE=`date +#Y#m#d-#H#M#S` make all

(Warning: in the above, replace # with % - this blog doesn't like the % with a following character.) This will pass the symbol DATE (with the date in the form, for example, 20100329-095354) into the make. You then would modify the hex generation rule to something like:

#.hex: #.elf
	@echo
	@echo $(MSG_FLASH) $@
	$(OBJCOPY) -O $(FORMAT) -R .eeprom $< $@
	mv $@ $(TARGET)_$(DATE).hex

(Same comment about % ) This would rename your final .hex file to, for example, foo_20100329-095354.hex. Check out the GNU Make Manual for more details.

The above assumes you have Cygwin installed. If you only have the DOS prompt (poor soul) I'm sure there is an equivalent call to the date function.

Of course, you could then encapsulate the above make with time setting stuff into a script file of some sort.

Stu

DATE=`date xxxx`

works just fine in makefiles for this application.
(Assuming you have a decent version of make - not some kind of Microsoft tool called "make" that isn't really make)
Technically its not done in the makefile but it does work.
I've used it off and on for situations exactly like this for decades.
Depending on how you do it, it may look odd as the command is echoed out by make but the shell will expand the date command out properly to do what you want/expect.

The date command comes with WinAVR.
It is in {WinAVR-XXXXX}/utils/bin
(along with lots of other the goodies)

so even if you don't have Msys/Ming installed on your machine you can still use the WinAVR util version of the commands.

BTW, there is no way to do this in a batch file. I just spent an entire day pulling my hair out trying to do it for a person that has no real tools installed on their Windoze machine.
The windows date command is really brain dead and the output format is dependent on localization so you never know how the users machine is configured.
So even if you do use the wimpy string extraction capabilities inside windows batch files, you can't ever guarantee a portable way of getting all the date fields because of the date format being locally customized.
In fact some formats are not don't have all the information so you can't even get all the information without altering the localization settings.
Windoze is so lame when it comes to commandline capabilities.
Ended up giving up since there was a need for having people in different countries run the same batch file.

--- bill

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

bperrybap wrote:

DATE=`date xxxx`

works just fine in makefiles for this application.

Good to know -- it is not listed in the Gnu make manual, but I'm not surprised it's there. I just didn't want to assume that it was there and have the OP end up in the weeds if I was wrong.
bperrybap wrote:
(Assuming you have a decent version of make - not some kind of Microsoft tool called "make" that isn't really make)
Since the OP was talking about WinAVR, he has a reasonable make.
bperrybap wrote:
BTW, there is no way to do this in a batch file. I just spent an entire day pulling my hair out trying to do it for a person that has no real tools installed on their Windoze machine.
As good an argument for installing Cygwin as I have ever heard.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Link as follows:

avr-gcc -options linktime.c fred.o greg.o ... -lm

The content of linktime.c is left as an exercise for the reader.

Iluvatar is the better part of Valar.

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

stu_san wrote:
bperrybap wrote:

DATE=`date xxxx`

works just fine in makefiles for this application.

Good to know -- it is not listed in the Gnu make manual, but I'm not surprised it's there. I just didn't want to assume that it was there and have the OP end up in the weeds if I was wrong.

Stu

But technically I don't think that it is part of make.
I believe that it is the shell that is doing it.
I think make blindly passes the `date xxx` on the command line and lets the shell do the expansion.

So I believe it requires a normal unix style shell to work as well but where there is a "make" there is usually a shell available as well.

--- bill

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

Quote:

So I believe it requires a normal unix style shell to work as well but where there is a "make" there is usually a shell available as well.

In the case if WinAVR \WinaAVR\utils\bin\make.exe will invoke \WinAVR\utils\bin\sh.exe to execute shell functions. While any DOS command may be used the fact is that Eric has thoughfully provided MinGW/Msys builds of many common *nix tools in \WinAVR\utils\bin:

=======================================================================
C:\WinAVR-20100110\utils\bin>dir /w
 Volume in drive C is ACER
 Volume Serial Number is C6B0-75D7

 Directory of C:\WinAVR-20100110\utils\bin

[.]                [..]               ansi2knr.exe       basename.exe
bc.exe             bison.exe          bison.hairy        bison.simple
bunzip2.exe        bzcat.exe          bzip2.exe          cat.exe
chgrp.exe          chmod.exe          chown.exe          cksum.exe
cmp.exe            comm.exe           compress.exe       cp.exe
csplit.exe         cut.exe            date.exe           dc.exe
dd.exe             df.exe             diff.exe           diff3.exe
dircolors.exe      dirname.exe        du.exe             echo.exe
egrep.exe          env.exe            expand.exe         expr.exe
factor.exe         false.exe          fgrep.exe          find.exe
flex.exe           flex.lib           fmt.exe            fold.exe
fromdos.exe        fsplit.exe         gawk.exe           gclip.exe
gplay.exe          grep.exe           gsar.exe           gunzip.exe
gzip.exe           head.exe           id.exe             indent.exe
info.exe           infokey.exe        install-info.exe   install.exe
join.exe           jwhois.exe         less.exe           ln.exe
logname.exe        ls.exe             m4.exe             make.exe
make.exe.old       makeinfo.exe       makemsg.exe        man.exe
md5sum.exe         mkdir.exe          mkfifo.exe         mknod.exe
mount.exe          msys-1.0.dll       msys-1.0.dll.old   mv.exe
mvdir.exe          nl.exe             od.exe             paste.exe
patch.exe          pathchk.exe        pclip.exe          pr.exe
printenv.exe       printf.exe         ps.exe             pwd.exe
rm.exe             rman.exe           rmdir.exe          sdiff.exe
sed.exe            seq.exe            sh.exe             shar.exe
sleep.exe          sort.exe           split.exe          stego.exe
su.exe             sum.exe            sync.exe           tac.exe
tail.exe           tar.exe            tee.exe            test.exe
texindex.exe       todos.exe          touch.exe          tr.exe
true.exe           type.exe           uname.exe          unexpand.exe
uniq.exe           unshar.exe         uudecode.exe       uuencode.exe
wc.exe             wget.exe           wget.GID           wget.hlp
which.exe          whoami.exe         xargs.exe          yes.exe
zcat.exe

But coming back to the original request. When building binary (not .hex) final outputs we've always used a hangover from Open Solaris' SCCS system known as "what strings". These are strings you can embed into the code that, because they start with an unsuual sequence of characters "@(#)", can later be pulled out for documentary purposes using a utility called "what".

In one of the main source files we'd include:

char ver[] = "@(#) Ver="__DATE__" "__TIME__;

then after building the what utility can produce the following output to easily identify anonymously name files:

D:\test>for #a in (test.*) do c:what #a
D:\test>c:what test.aps
D:\test>c:what test.aws
D:\test>c:what test.c
 Ver=
D:\test>c:what test.eep
D:\test>c:what test.elf
 Ver=Mar 31 2010 10:50:43
D:\test>c:what test.hex
 Ver=Mar 31 2010 10:50:43
D:\test>c:what test.i
D:\test>c:what test.lss
 Ver=
D:\test>c:what test.lst
 Ver=Mar 31 2010 10:50:43
D:\test>c:what test.map
D:\test>c:what test.o
 Ver=Mar 31 2010 10:50:43
D:\test>c:what test.s
D:\test>c:what test.sym

The one "clever" bit in the above is that I took the open source of the what utility and I've added the ability for it to spot a ".hex" extension in which case it decodes it into an internal memory buffer then does the what search on that. If anyone's interested I've attached the utility.

Attachment(s): 

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

clawson wrote:
...we've always used a hangover...

Hummm.... ;-)
clawson wrote:
... I took the open source of the what utility...
Is there also a "why" utility, preferrably open source?

JW

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

Cliff,

This sounds very much like the version utility. Which will find embedded 'version strings' in both text files and binary files.

So you can identify the individual modules in an executable.
However, modern intelligent linkers are likely to remove unreferenced anonymous data.

It is very unlikely that embedded apps would be happy with any unnecessary use of flash.

I also got fed up with adding the 'version' step to my makefiles. So looking through my executables on the PC, very few reveal any information.

I ran "version *.exe" on all the U*ix utilities that come with WinAvr. And there are no embedded strings at all. So I suspect few people use 'version' any more.

I guess that your 'what' is my 'version'.

David.

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

We extract the subversion revision and pass that in as a #define using the -D option in a makefile (and whether it's clean or dirty).

We always put in the final 5 bytes of the application space (or bootloader space, if we're compiling the bootloader) so that the bootloader can read the version of the application and vice-versa.

-- Damien

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

clawson wrote:
When building binary (not .hex) final outputs we've always used a hangover from Open Solaris' SCCS system known as "what strings".
Wow, Blast From The Past time! That goes back to the roots of Unix. I used that in code I wrote for good ol' HPUX back in the 80's and it was old then. As you said, I think it was introduced in SCCS, but who knows? It may go back earlier than that.

Stu (remembering the days when 66 MHz RAM was FAST)

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Quote:

I think it was introduced in SCCS, but who knows?

This man page seems to suggest that the technique belonged to SCCS:

http://sccs.berlios.de/man/what....

I got the source I added .hex support to from:

http://heirloom.sourceforge.net/...

(I love the fact they called them "heirloom"s!) the actual source was here in fact:

http://heirloom.cvs.sourceforge....

I actually got my Intel Hex code from the TeensyUSB man:

http://pjrc.com/tech/8051/ihex.c