August 22, 2014, 10:41:55 am
News:
Pages: [1]
Print
Author Topic: Setting the OSD's time  (Read 1770 times)
heyrick
Global Moderator
Sr. Member
*****
Posts: 337



View Profile WWW
« on: April 29, 2012, 05:46:44 pm »

Hi,

[moved from "Solved! etcetcetc (I don't remember this part Wink )" topic]

I didn't try the settime linked as it said it was for Torfu and I guessed the move to Qt4 would have changed some stuff.

In the end, I wrote my own. Cool


The program (linked below) is called poketime. When called with no parameters, it will report the hardware clock and the system clock, like this:
   ~ $ poketime
   Current RTC date and time: 2012/04/30 00:26:27
   Current Sys date and time: 2012/04/30 00:26:27


Don't worry if the two are a second out, this could be the hemi-demi-semi-microsecond between prodding the RTC and then the soft clock. If they are a lot out, well, that's not so cool.


Otherwise, poketime takes exactly six parameters, as explained:
   ~ $ poketime ?
   Syntax: poketime <year (4 digits)> <month> <day> <hour (24h)> <minute> <second>


Thus...
   ~ $ poketime 1973 12 16 22 04 00
   ~ $ poketime
   Current RTC date and time: 1973/12/16 22:04:07
   Current Sys date and time: 1973/12/16 22:04:07
   ~ $ poketime 1973 12 16 22 08 00
   ~ $ poketime
   Current RTC date and time: 1973/12/16 22:08:05
   Current Sys date and time: 1973/12/16 22:08:04
   ~ $ poketime 2012 04 30 00 26 22
   ~ $ poketime
   Current RTC date and time: 2012/04/30 00:26:27
   Current Sys date and time: 2012/04/30 00:26:27


The time set is reflected in the UI in a few seconds.

Also attached is the source. As usual, released under EUPL.


Doesn't quite help with setting the time from my PC, but now I know I have something that will set the time correctly in both senses (I don't want to rely upon pulling the time from elsewhere, I just want to check in from time to time to keep the OSD accurate). That'll come later...


Best wishes,

Rick.

PS: In the examples, the first two dates and times given are my times of birth - I tend to use the latter frequently as a "test date", and the third is "now".
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #1 on: April 29, 2012, 05:59:20 pm »

Interesting.  A couple of questions:

1) Can you give us the compile command?  I.e., are there any defines or libs that need to be linked in?

2) A quick look at the source reveals that you include sys/ioctl.h twice, and then both times you call ioctl(), you call it twice (for no reason that I can see).  A case of double vision?

Also, it would probably be better to have an option to take the current system time and poke that into the RTC, rather than needing it to be passed on the command line.  That's the most common situation and is what the real "hwclock" program does.
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 337



View Profile WWW
« Reply #2 on: April 29, 2012, 06:16:37 pm »

[moved from "Solved! etcetcetc (I don't remember this part Wink )" topic]

Hehe, I should have known changing the subject line and unstickying the topic was too logical to work. So, had to split the topic and then resticky the original one [I'll let somebody else sticky this if they deem it worthy].
Phew.
I'm a little uncertain what is the point of changing the subject if all it does is alter a little bit of text nobody reads? Hmm...

Whatever, I have the next Nazo no Kanojo X to catch up on. Weirdest damn concept I've seen in a long time!


Best wishes,

Rick.
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 337



View Profile WWW
« Reply #3 on: April 29, 2012, 06:31:32 pm »

Interesting.  A couple of questions:

1) Can you give us the compile command?  I.e., are there any defines or libs that need to be linked in?

Libs, no. Defines, yes, the rtc.h for the time structs. You can get a copy from https://svn2.neurostechnology.com/Neuros-Cooler/branches/clin-Neuros-Cooler/include/rtc.h

What I do (using pubuntu) is use gedit to write the code. Then in a console, I:
   cd ~/osd/neuros-bsp
   ./setup-rootfs
   source neuros-env
   cd ~/osd/our-apps/poketime
   arm-linux-gcc -o poketime poketime.c
   arm-linux-strip poketime
   cp /media/cofs3/poketime poketime
   cp /media/cofs3/poketime poketime.c


I type all that. I probably oughta make a shell script to do it for me.


Quote
2) A quick look at the source reveals that you include sys/ioctl.h twice, and then both times you call ioctl(), you call it twice (for no reason that I can see).  A case of double vision?

First time:
   #include <sys/ioctl.h>
   #include <sys/time.h>
   #include <sys/ioctl.h>

Yeah, I'm a wally...

Second time:
      if ( ioctl(fp, RRB_GET_DATE, &rtc_date) != 0)
  [...blah blah...]
      if ( ioctl(fp, RRB_GET_TIME, &rtc_time) != 0)


I've highlighted the differences.


Quote
Also, it would probably be better to have an option to take the current system time and poke that into the RTC, rather than needing it to be passed on the command line.  That's the most common situation and is what the real "hwclock" program does.

T'was looking for a way to get the time to be easily updateable. The "hwclock" ought to be fairly easy to get running, although I think it uses the Neuros Cooler libraries (do you have those?).

Actually, if you can compile my code, you can roll your own without libraries. Just take the part that reads the system time and the part that writes the RTC, and chuck away the rest. I can't do it myself right now as I've got a different SD card in to toss away adverts in recorded video to free up some space.


Best wishes,

Rick.
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #4 on: April 30, 2012, 06:02:32 pm »

Can you give me a URL for the linux/neuros_rtc.h file?

I cannot compile it without that file.
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 337



View Profile WWW
« Reply #5 on: May 01, 2012, 03:07:19 pm »

Here you go!

https://svn2.neurostechnology.com/neuros-bsp/trunk/toolchain/arm-linux/include/linux/neuros_rtc.h
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #6 on: May 01, 2012, 06:33:12 pm »

OK - great.  I am able to compile and run your program.

My goal is to re-implement hwclock for the OSD.  I'll let you know when I have gotten around to doing so.
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 337



View Profile WWW
« Reply #7 on: May 02, 2012, 10:38:33 am »

See if you can compile this. It ought to do the job. [fingers crossed!]

/* hwclock [Rick's mix]

   Updates the RTC from the system clock.
     
   Version 0.01 2012/05/02

   NOT TESTED - just a hack-together from my poketime code. ;-)


   For the Neuros OSD.


   Copyright (c) 2012 Rick Murray.
   Released under the EUPL v1.1 (only).
   http://ec.europa.eu/idabc/eupl5

*/

#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/ioctl.h>

#include <linux/neuros_rtc.h>
#include "../../Neuros-Cooler/cooler/core/include/rtc.h"


int main(void)
{
   int       fp = -1;
   time_t    timeptr;
   struct tm *tp;
   struct rtc_time_type rtc_time;
   struct rtc_date_type rtc_date;   

   // read OS time
   time(&timeptr);
   tp = localtime(&timeptr);

   // copy to RTC time block
   rtc_date.year  = tp->tm_year;
   rtc_date.month = (tp->tm_mon + 1);
   rtc_date.day   = tp->tm_mday;
   rtc_time.hour  = tp->tm_hour;
   rtc_time.min   = tp->tm_min;
   rtc_time.sec   = tp->tm_sec;

   // open RTC
   fp = open("/dev/neuros_rtc", O_RDWR);
   if (fp < 0)
   {
      fprintf(stderr, "Unable to open RTC device.\n");
      exit(1);
   }

   // update RTC (date, then time)
   if ( ioctl(fp, RRB_SET_DATE, &rtc_date) != 0)
   {
      fprintf(stderr, "Unable to set system date.\n");
      close(fp);
      exit(2);
   }
   if ( ioctl(fp, RRB_SET_TIME, &rtc_time) != 0)
   {
      fprintf(stderr, "Unable to set system time.\n");
      close(fp);
      exit(3);
   }

   // done
   close(fp);   
   exit(0);
}
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #8 on: May 17, 2012, 10:01:26 am »

That certainly looks like it would work - I can see no reason why it wouldn't.

However, I've been looking at the implementation of "hwclock" in busybox - and it looks like it should be pretty straightforward to update it to work with the OSD's RTC.  It turns out that the "regular" Linux RTC uses "struct tm"s, just like the usual Unix/Linux time functions do, so, as in your code, most of the work will be copying back & forth between a "struct tm" and the special OSD structs.

Anyway, I just need to find a suitable moment to do the work.
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #9 on: May 19, 2012, 07:16:28 am »

Finally, let me note (actually, confirm) that setting the time via the GUI does set both clocks (even if all you do is go to the screen [Tools -> Settings -> Date & Time] and hit enter twice).

So, in a way, this is all moot  - unless you really do need to this on an ongoing basis.

And, now that I think about it - I think the best solution would be to hack the "date" command (in "busybox") to have an option to also get or set the RTC (i.e., it would set it if  the "-s" option is present, which sets the system date), in addition to getting/setting the regular system time.
Logged
heyrick
Global Moderator
Sr. Member
*****
Posts: 337



View Profile WWW
« Reply #10 on: May 19, 2012, 09:58:38 am »

Finally, let me note (actually, confirm) that setting the time via the GUI does set both clocks (even if all you do is go to the screen [Tools -> Settings -> Date & Time] and hit enter twice).

I know the UI method sets both clocks. What I was looking for is a command-line way to do it programmatically so something else could keep the clock in step.

As for Busybox hacking, why not make setting both clocks the default option? I can't think why you'd want to set one and not t'other.


Best wishes,

Rick.
Logged
pfft2001
Sr. Member
****
Posts: 378



View Profile
« Reply #11 on: May 19, 2012, 10:39:47 am »

Finally, let me note (actually, confirm) that setting the time via the GUI does set both clocks (even if all you do is go to the screen [Tools -> Settings -> Date & Time] and hit enter twice).

I know the UI method sets both clocks. What I was looking for is a command-line way to do it programmatically so something else could keep the clock in step.

As for Busybox hacking, why not make setting both clocks the default option? I can't think why you'd want to set one and not t'other.

1) Yes, I know you know.  I was just mentioning it for completeness (since I had suggested that it did work that way earlier, but without testing it - until now).

2) I guess just because that's the Unix way - to provide an option for everything and to not assume anything about the user's intentions.  FWIW, the only thing I can suggest is that you might want to separate them for testing purposes - to be able to do one or the other and observe that the other doesn't change.  Also, I remember way back when in DOS days - I had written a program to do the same thing we're discussing here, in 8086 assembler, incidentally, and then was annoyed when, starting in DOS 3.3, it worked as you suggest - i.e, when you set it from the command line, it also set the RTC automatically.  My wonderful program was orphaned.
Logged
Pages: [1]
Print
Jump to: