Implementation of system time in Embedded LINUX

Implementation of system time in Embedded LINUX-general Linux technology-Linux programming and kernel information. The following is a detailed description. First, clarify a problem:

1. the time on the embedded system board is viewed using the date standard system command, and the date is a SHELL command, such as busybox or sash on uClinux. This time is maintained by running embedded LINUX software. It is actually a global variable in the memory. By default, the value assigned to this global variable by LINUX Startup is 19700101.

2. The time for maintaining the internal registers of the RTC chip (many built-in RTC modules of the embedded processor, that is, the internal registers of the CPU.

Generally, after LINUX is started, you can use the date command to set and change the system time. However, if the power is down, the system will be lost. After LINUX is started, it will be 1970 again. If you want to save the system time after the date setting so that it can be maintained after the next restart, you must have the hardware and software support for the RTC + backup battery.

For example, we can set the system time on the PC, and it will not be lost after restart, because we have RTC support on the PC motherboard.

RTC can be an external chip, such as common X1226/1227, which is connected to the processor through I2C.

Of course, the CPU has a built-in RTC module, so you only need to provide a backup battery if you design the hardware.

After clarifying the two concepts of system time, let's look at the implementation mechanism of RTC.

In an embedded system, the implementation methods can be flexible and varied, as long as the ultimate goal is achieved:

You can get the current correct time through some operation, and the restart will not be lost.

Let's look at several implementation mechanisms.

Before introducing several methods, let's first explain the method of software time:

Our platform is embedded LINUX. To implement RTC support, we must use the "Driver + application" method. We recommend that you use the MODULES method to independently load our drivers, this does not affect the entire Linux kernel.

The following describes the implementation method:

From the above we can see that the time is actually maintained at the same time in two places, one is the RTC chip internal register or the RTC register of the CPU; the other is the LINUX maintenance time. LINUX will be lost when it is restarted, and RTC will not be lost because of the backup battery protection, and the timing can be maintained after the Board is powered off. Therefore, it is best to understand that the implementation method is to read the time value from the RTC chip and assign it to the LINUX time variable when the LINUX kernel is started. In this way, the LINUX Startup time is corrected, and it is no longer 1970. Of course, in this way, the module form of the independent RTC driver cannot be used. When you use the date command to set the LINUX time, you also need to modify the code of the date command to modify the internal register value (or the internal register value of the CPU) of the RTC chip through I2C. Of course, in this case, a RTC driver is required.

The following is a simpler implementation method.

That is, when LINUX is started, the time is not read from the RTC chip. Instead, you can directly modify the date Command Code so that it cannot be read from the interfaces provided by LINUX, instead, it is directly read from RTC through the driver.

In addition, if your system permits it, you can skip the date route, that is, you can read the system time without using the date command, you can directly write a function to read the time, for example, read_rtc/write_rtc, use these two functions to replace the date command to read and set the system time.

Well, I have written so much that I don't seem to make it clear. Finally, remember:

The time we see is actually maintained in two different places

One is maintained in LINUX and the other is in the RTC chip.

In this way, there is a problem of two time syntaxes. One occurs when LINUX is started, the time needs to be obtained from RTC; the other needs to be changed at the same time when you set the system time.

Of course, some tricks can happen in the middle. For example, you can skip the LINUX time and let date or your own code directly read the RTC time, and completely ignore the LINUX time (also let it be 1970... right)

In the arm9-experiment box and other board, we are through the modification of busybox date. c code to achieve; and in the HHGW-LITE-R3 and other HHPPC platform is written by their own writeRTC.

The previous method changes the system running mode, and the later method does not associate the hardware time with the LINUX system time.