Spin compiler request - date/time stamp & eeprom defaults

Peter Jakacki

I have a simple request to make as an enhancement to the Spin compiler. I like to embed my version number in my compiled code with a date/time stamp as is possible in other compilers.
At present I have to update this stamp manually, I use a MSB to LSB stamp that is "YYMMDDHHmm" like this:

byte " FIRMWARE: MODBUS SERIAL-TCP BRIDGE V1.0-0902171050",$0d,$0a,0

I would like to automate the stamp in a manner simiilar to this:

byte " FIRMWARE: MODBUS SERIAL-TCP BRIDGE V1.0",DATE,TIME,$0d,$0a,0

While I am on the subject of the compiler sometimes I like to place data in specific locations relative to the EEPROM as I also use it for configuration parameters. It would be nice to be able to define the addresses and the default contents in the Spin source in a similar manner to PASM.

EEPROM $7F00
eebaud      long 9600
eeID           long 4

That also means that I can reference the variable in hub memory with a simple long[noparse][[/noparse]@eebaud] rather than creating another variable and copying it.

*Peter*

P.S. make that long[noparse][[/noparse]eebaud]

Post Edited (Peter Jakacki) : 2/17/2009 1:32:02 AM GMT

heater

Write yourself a little program, shell script in Linux say or whatever Windows guys do, that runs as a background service. Have it write your version string and date/time to a file every second or so. Include that file into your Spin program with a "file" statement on a DAT section.

Getting a bit more clever it could monitor the update time of your eeprom file and bump the version number or a build number to be included in the string.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Peter Jakacki

That's what I call a workaround
But it certainly would do the trick, I'll look into it.

Any ideas about the eeprom? I'm just defining it as constants at present and accessing them as long[noparse][[/noparse]eebaud] etc but it would probably be good if I didn't have to worry about the eeprom address at all. Maybe I could just define them as normal variables but use the @variable when I go to read or write it from eeprom like this -> i2c.write(@baud,baud). This means that the eeprom variables may be anywhere in the eeprom but it doesn't really matter although some applications use a LOAD/SAVE block for backup. These still leaves the requirement that variables be preset from eeprom at compile time. Ah, maybe next version.....

*Peter*

Peter Jakacki

I think there is that 16 byte header thing that needs to be considered so I looked into the eeprom file generated by the Spin compiler. I placed a long variable right at the start of all the variables and checked it's address at runtime. My trusty code said "1EE4" and that certainly seems to matche the file.

00001ED0  D6 1C 36 A8  0E 3D B4 64  A8 0C 3D B4  35 A8 0E 3D  ··6··=·d··=·5··=
 00001EE0  B4 60 33 32  00 00 00 00  00 00 00 00  00 00 00 00  ·`32············
 00001EF0  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ················
 00001F00  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ················

So It looks like it should work. Trying this out confirms that I can simply refer to the address of a variable to update that variable in eeprom. It will automatically be preset next time the Prop boots!

i2c.eewr(@baud,baud) ' updates the variable baud in it's corresponding location in the eeprom so that it is preset on boot

Still not preset at compile time but good enough and keeps the code simple.

*Peter*