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.

  • Resolved

clock set on EKS-LM4F232

Mastermind 7845 points

Replies: 7

Views: 660

Hi,

I loaded the latest Tivaware and the qslogger example into my Stellaris EKS-LM4F232 Evaluation Kit.

Selecting CONFIG -> CLOCK -> CLOCK SET gives

70/01/01

00:05

OK CANCEL

That is different from previous example. When trying to change  the year I cannot go down from 70.

Should I press the UP button 1943 times (2013-70) or is there an easier way to do it?

Jan

  • Guru 26105 points

    Hi,

     The  clock widget will display the year, month, day, hour and minute on the display. The
     user can highlight the fields with the left/right keys, and can change the
     value of each with the up/down keys. When finished the user highlights
     the OK field on the screen and presses the select button.

    As for going down from 70, you cannot - this is time reference in computer technology today (unless you write your own routines for that - or modify the existing ones).

    Petrei

  • In reply to Petrei:

    Petrei,

    The previous version shows the screen

    CLOCK SET

    1970/01/01

    00:00

    OK CANCEL

    and enables to set the date and time easily

     

    the new version shows

    70/01/01

    changing the year goes 70...99..101..

    so the is a bug and my question is how to fix it.

    Jan

  • Guru 26105 points

    In reply to jan2809:

    Hi,

    Did you started the debugger and set some breakpoints?

    What do you understand by "new version"?

    You have the source code also - try to understand what is going - also changing the other two fields is OK?

    Petrei 

  • In reply to Petrei:

    Petrei,

    If I import the qs-logger project from C:\StellarisWare\boards\ek-lm4f232\qs-logger everything works fine

    If I import the qs-logger project from C:\ti\TivaWare_C_Series-1.1\examples\boards\ek-lm4f232\qs-logger then I have that funny problem with setting date/time and maybe others I haven't discovered yet.

    Both projects are created and possibly tested by TI as part of Stellarisware and Tivaware respectively.

    Of course I can debug and fix the problem in TI's code, but I was hoping that someone already discovered it and that will save me a lot of time and I guess there is a huge amount of time an effort required to fix it (it involves grlib as well). The code is supplied as a working examples and I was hoping that creators of it will be happy to know the problems.

    As well that decreases my trust in Tivaware library as there might be more bugs in there. Remember that Stellarisware was a main selling point of Stellaris micros (now dead and replaced by Tiva's and Tivaware).

    Anyhow, it will be left as one of the annoing things, that don't work, but not worth time and effort to be solved

    Thanks for your help.

    Jan

  • In reply to jan2809:

    Jan,

    I will check into this and pass it along to the SW team.  It is possible that issues were introduced in TivaWare 1.1.  This app may have changed as we added support for the new Tiva DK-TM4C123G which is the Tiva branded and slightly updated version of the EK-LM4F232.

    Dexter

  • In reply to jan2809:

    Jan,

    Thank you for letting us know about this. I went poking around and found out what happened. With the transition to TivaWare the software team took the opportunity to overhaul several components of the core software libraries that were out of date. One of the things updates was how time is handled in the standard library. The decision was made to standardize the time format as an offset from 1900. This is apparently the standard and our teams implementation was an outlier. This means that time is now represented as an offset from 1900.

    Since the qs logger was written before the tivaware transition this means it still assumes time is given as an absolute, not a relative value. This is causing the issue. It is not a bug, simply old code that needs to be updated to the new standard. I apologize for the inconvenience it has caused. I am currently updating the code and will include it in the next release.

    In the mean time, the simple fix would be to add 1900 to any instance of tm_year that is printed out. In particular I would recommend adding it to clocksetwidget.c on line197 (approximate) so it should read like this

    usnprintf(pcBuf, sizeof(pcBuf), "%4u", psTime->tm_year + 1900);

    -Austin

  • In reply to TI Austin:

    Austin,

    Thank you for looking at this problem, appreciate it.

    We are using the kit in a students lab, so we really care to give students a good example how

    things should be done.

    Regards

    Jan

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.