1

Working on a embedded Linux device built using yocto that is pulling a date via uart from another device with a satellite connection. By the time we have access to this date, we are well into a fully initialized multi-threaded application as well as various daemons running etc.

From what I have read, using stime() or settimeofday() can result in breaking anything relying on timers. I'm guessing that something like std::this_thread::sleep_for() would be included in this?

Is there a safe way to set the system time at this point or how do most embedded Linux devices that do not have internet access navigate this problem?

Edit: We do have an RTC but the implementation of hwclock we are using does not allow us to directly write to it, at least through the hwclock api. Here is the --help:

BusyBox v1.24.1 (2018-11-14 12:40:41 PST) multi-call binary. 
Usage: hwclock [-r|--show] [-s|--hctosys] [-w|--systohc] [-t|--systz] [-l|--localtime] [-u|--utc] [-f|--rtc FILE]

And the link to the hwclock source.

  • There is the RTC point of view, the system pov, and could even be the application pov....what do is necessary to do, what is needed and what exactly breaks? Could it pay out initializing the applications after getting the time if getting it on time is critical? What time resolution does the app need? And is there an RTC? – Rui F Ribeiro Feb 26 at 16:39
  • 1
    Can you slow down everything else (i.e. full application waits to start until time is valid)? – drewbenn Feb 26 at 16:42
  • 1
    I used to have some apps running in an iOT, and they were quite happy even if the time via NTP got later in the game. Granted that after I bought an RTC for that, things were smoother, but it all depends on what you want to do and whether time is critical for the apllicational part. – Rui F Ribeiro Feb 26 at 16:45
  • 1
    There can be always the possibility of feeding an NTP daemon. As an example: unixwiz.net/techtips/raspberry-pi3-gps-time.html – Rui F Ribeiro Feb 26 at 16:59
  • There is an rtc but our hwclock implementation doesn't have the ability to write directly to it -- only to and from the system time from what I can tell. See my comment below on the usage options for our hwclock. – jpsalm Feb 26 at 17:14
0

You can use hwclock which should be built into every embedded linux distro.

$hwclock is - as the command name suggest - a hardware clock, independent of the OS being used. These days it uses a low-power oscillator built into the motherboard, that tracks the passage of time even when the machine is powered down (uses mb battery that will last a long time)

If hwclock is not available, there are other alternatives which I will gladly go over, but hwclock should be your goto command if available.

  • 1
    hwclock works in normal devices that have RTC - it writes and reads from it. There are iOT devices without an RTC. – Rui F Ribeiro Feb 26 at 16:35
  • I assume you are referring to the Raspberry Pi case, where a fairly advanced embedded device lacks a hardware clock capable of RTC. Raspberry Pi is a example of an outlier, because it tries to offer an enormous range of capabilities at as low of a price as possible, hence they chose to save money by forgoing a built-in battery powering one tiny IC capable of RTC. – BarBar1234 Feb 26 at 16:44
  • 1
    The rpi suffers from it, but it is not alone, unfortunately. – Rui F Ribeiro Feb 26 at 16:46
  • Unfortunately the we are using the BusyBox 1.24.1 hwclock which as far as I can tell can only write to and from the system time. Writing directly to hwclock would be ideal but doesn't seem to be available to me: BusyBox v1.24.1 (2018-11-14 12:40:41 PST) multi-call binary. Usage: hwclock [-r|--show] [-s|--hctosys] [-w|--systohc] [-t|--systz] [-l|--localtime] [-u|--utc] [-f|--rtc FILE] – jpsalm Feb 26 at 17:07
  • Here is the hwclock implementation. I believe the -f option just allows us to point hwclock to a specific rtc. – jpsalm Feb 26 at 17:24
0

My solution was to write directly to the rtc using ioctrl. Here's an implementation for anyone who comes across this:

#include <linux/rtc.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/ioctl.h>


int main(void)
{
  int fd;
  fd = open("/dev/rtc0",0);
  if (fd < 0)
    printf("Can't open rtc!");

  struct rtc_time time;

  time.tm_sec = 12;
  time.tm_min = 12;
  time.tm_hour = 7;
  time.tm_mday = 12;
  time.tm_mon = 7;
  time.tm_year = 118;

  if (ioctl(fd, RTC_SET_TIME, &time) < 0 )
    printf("Set rtc failed!");

  return 0;
}
  • Isn't this exactly what the "-w" option to your hwclock does? – Murray Jensen Feb 27 at 4:10
  • The -w option for BusyBox hwclock takes no arguments and simply writes the system clock into the rtc. I needed the ability to load an arbitrary time into hwclock and then load that into the system on the next boot. – jpsalm Feb 27 at 5:38
  • Usually, the "-r" option is run at boot time, and the "-w" option is run at shutdown (via init scripts). If your system is set up this way, you could just set the system time and reboot (bit of a sledge-hammer approach, I know - but would do the job) – Murray Jensen Feb 27 at 9:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.