Hi All,
I want to set the RTC time to the current time and date without hard-coding it.
I tried to use the function time() and ctime() defined in time.h, but I read that time() is a semihosted function (http://www.keil.com/support/man/docs/armlib/armlib_chr1359122861930.htm)
#include <time.h> time_t rawtime; char buffer[50] ={0}; time(&rawtime); sprintf (buffer, "%s", ctime(&rawtime) );
So if I include time(&rawtime), then the program stops with BKPT 0xAB (indicating semihosting) and if I don't include it then the buffer displays 00:00 1 Jan 1970.
So my question is, how do I write the retarget.c to use the time function? I read a lot of examples on retargeting printf, but can't find anything on time().
Or what is the normal way of setting the current date/time?
Thank you.
The end user will not have access to any JTAG interface. And you'll have to be happy if your RTC drifts less than 30 seconds/year. Not to mention the outcome when a customer needs to replace the RTC battery - or in case you use a supercap what happens if the customer (or you) keep the device on a shelf until the supercap is emptied.
And you need to consider that this world has a significant number of time zones - so a customer may not be happy with a clock that runs in your time zone.
So your device will need some interface that will allow the clock to be set out in the field. If you don't have a display and some buttons, then it's time to consider a serial port - preferably something a standard PC has, like USB or Ethernet, since RS-232 are no longer fitted on modern computers and I2C, SPI etc are intended for internal use and would require very special adapters to interface with a PC.
Or, possibly, something wireless ...
Possibly connected to a serial port.
But while WiFi would manage time, it would either require the device to have a way to manually set IP and present IP - or that the OP writes some application to let the user find what IP the unit got from the router. And then there wouldn't have been any thread about how to set the time, since the addition of NTP or similar would have been a trivial exercise.
Bluetooth allows serial ports - but isn't easy to use for an end user, unless they get an Android/iPhone application.
Zigbee isn't something an end user is likely to have a gateway for. Same with an RFID-based solution.
GPS would work, if there is enough signal - and if there is no need to play around with time zones.
DCF77 would work for most parts of Europe, but requires a backup solution unless the equipment will not only be available for mainland Europe. The TDF transmitter in France would cover a larger range but still not world-wide.
Agreed - but it may still be an option in a particular application or use-case.
That's why I just said, "possibly".
And, yes - it's quite likely that the radio would connect to the main processor via a serial port of some sort.
Of course, we don't know what connectivity and/or management options may already be present in the project/product ...
Of course it is. That's why I posted the message.
Strange that you think you need to validate the statement.