• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 81 subscribers
  • Views 2029 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Clever __DATE__ and __TIME__ problem

Nemanja Savic
Prodigy 20 points
Other Parts Discussed in Thread: MSP430F5438A

Hi all,

 

I was reading Anders Lindgren's response on the Internet about clever __DATA__ and __TIME__, but i have problem to implement it on my MSP430F5438A.

What I wanted is to put the time of compiling inside of microcontroler, so that I can use it later in RTC.

A piece of code is following:

#define DIGIT(s, no) ((s)[no] - '0')

const int hours = (10 * DIGIT(__TIME__, 0) + DIGIT(__TIME__, 1));
const int minutes = (10 * DIGIT(__TIME__, 3) + DIGIT(__TIME__, 4));
const int seconds = (10 * DIGIT(__TIME__, 6) + DIGIT(__TIME__, 7));
/* WARNING: This will fail in year 10000 and beyond, as it assumes
* that a year has four digits. */
const int year = ( 1000 * DIGIT(__DATE__, 7)
+ 100 * DIGIT(__DATE__, 8)
+ 10 * DIGIT(__DATE__, 9)
+ DIGIT(__DATE__, 10));

But when i want to build project i only get compiler error #28 expression must have a constant value error.

I hope somebody can help me.

Thanx

Nemanja

  • 0
    Guru 12160 points

    Hi Nemanja,

    Does your compiler accept this?

    const char c = "abc"[2];

    My guess is that some compilers do, some don't.

    If yours doesn't like it, you could just remove the "const" qualifier and let cstartup establish hours, minutes, seconds, and year for you.

    Jeff

     

  • 0 in reply to Jeff Tenney
    Guru 227245 points

    Jeff Tenney said:
    If yours doesn't like it, you could just remove the "const" qualifier and let cstartup establish hours, minutes, seconds, and year for you.


    Won't work.

    The problem is that "xxx"[y] is nothing the compiler can resolve at compile-time. So it must not be used in an initializer.

    The only solution is to declare the values as uninitialized global variables (remove the consts and the initialization), and move the assignments into the start of main. Of course this turns them into variables, using up ram. And generates some code.
    But has the same effect for the rest of the application.

    Unfortunately, the precompiler can turn values into string (well, all values are strings, just without the quotation marks) and concat them etc, but it cannot work on individual letters inside a value.
    However, if workign wiht a make-controlled compiler, you can include extraction of teh minute/second etc. values into the makefile, so a bunch of defines is passed ot the compiler which can be assigned directly to the constants. It then does not use __TIME__ etc, but will be calculated outside of the compiler.
    If your makefile is auto-generated by an IDE (such as CCS or IAR), I don't know whether(how this can be included.

  • 0
    Guru 35595 points

    Nemanja Savic said:
    put the time of compiling inside of microcontroler, so that I can use it later in RTC

    What use is the compilation time to the RTC??

    http://www.catb.org/~esr/faqs/smart-questions.html#goal

  • 0
    Expert 1725 points

    If you use TortoiseSVN then the solution is fairly simple!  I use the TortoiseSVN tool SubWCRev to substitute compile data information in a header file based on a template file.  I run it as a prebuild step from the compiler.

    This template would do what you want:

    const int hrs = $WCNOW=%H$;
    const int mins = $WCNOW=%M$;
    const int secs = $WCNOW=%S$;
    const int year = $WCNOW=%Y$;

    Running SubWCRev will expand the $...$ to actual values.

    Unfortunately this is not much good if you don't use TortoiseSVN though...

  • 0 in reply to chris_m
    Guru 227245 points

    Tortoise only does the replacement when checkign iou from a repository, so it would be the checkoput date, not the compilation date.

  • 0 in reply to Jens-Michael Gross
    Expert 1725 points

    Jens-Michael Gross said:

    Tortoise only does the replacement when checkign iou from a repository, so it would be the checkoput date, not the compilation date.

     

    You can run SubWCRev any time you want.  $WCNOW$ gives the current system time/date.  I have added a prebuild step to my project (in CCS or IAR) to run SubWCRev on my template file and create a header file containing up-to-date compile-time data every time I build the code.

  • 0 in reply to chris_m
    Guru 35595 points

    I still don't see how either the checkout date or the build date would be of any use to the RTC at run-time??

  • 0 in reply to Andy Neil
    Guru 227245 points

    Andy Neil said:
    I still don't see how either the checkout date or the build date would be of any use to the RTC at run-time??

    They don't. But the original question was about storing the compilation date/time into the firmware, there have been suggestions for this.
    However, if an RTC date is before the compilation date, the RTC would be obviously wrong. :)

    However, if date/time are not required literally, a build or a revision number would probably serve the same purpose. And then of course Tortoise can do the substitute on checkout and commit. You just have to commit any change before putting it into a release build.

    In our devices, we need the production date, which is not necessarily the compilation date and definitely not the date of laste commit/checkout. However, the firmware version is part of the Device ID too. But it is manually counted up on each 'release'.

  • 0 in reply to Jens-Michael Gross
    Prodigy 20 points

    Thank you all people, I was absent for some time, as soon as I try what you have suggested me I will write the results.

    Thank you again

    Nemanja

  • 0 in reply to Jens-Michael Gross
    Guru 35595 points

    Jens-Michael Gross said:
    the original question was about storing the compilation date/time into the firmware

    Yes - but the rationale for doing that was specifically stated as, "so that I can use it later in RTC".

     

    Jens-Michael Gross said:
    if an RTC date is before the compilation date, the RTC would be obviously wrong

    Indeed - and I have used that trick myself.

    But that doesn't really sound to me like using it "in the RTC" - but that could just be a problem in translation.

    Again, it would have helped if the OP had stated his actual goal in doing this:

    http://www.catb.org/~esr/faqs/smart-questions.html#goal

**Attention** This is a public forum