Can I call time(NULL) from my controller code to get the time?

[JChan.0]

I'm working with a Nucleo F429ZI. I have "time.h" included in my code, and whenever I call time(NULL), I get a "-1" returned, which I think means that the function call failed. Is there anyway to get the function time(NULL) to return the time, by configuring things in a particular way, or does STM32 completely rely on RTC for the time? For example, when I enable semihosting, I can implement time.h and time(NULL) returns a time value. Does a time() call only work when semihosting is enabled, or is it something else that determines whether it works?

According to this link semihosting is the default implementation, but is there a way I can change it to get time() to work? http://www.keil.com/support/man/docs/armlib/armlib_chr1359122861930.htm

[waclawek.jan]

You need to write your own.

The idea is, that in a microcontroller, you can have any real-time source, not just the built-in RTC - it may be an external RTC, a connection to a time server, plain timer, whatever. This is how microcontrollers differ from the "big computers", where peripherals are seen just as a necessary nuissance to be handled by the underlying OS.

JW

[Tesla DeLorean]

Been a while since I've done it,but seem to recall that Keil needs you to make a clock() and _clock_init() functions to handle platform specifics. You can either have it pull from the RTC always, or you can pull it once, and count ticks with SysTick/1KHZ. The former can be a bit sluggish if other code keeps hammering the routines over and over, and the latter tends to walk away as the two clock sources aren't identical.

One of the other routines didn't work as I'd like so I had to refactor that too. Rollovers, leap years, centuries and stuff.

My approach here has been away from the UNIX time (32-bit), and to use the Win32 FILETIME/SYSTEMTIME (64-bit), and create a layer that allows testing on a Windows box and functionality on STM32 devices.

[After Forever]

> away from the UNIX time (32-bit)

To be fair, in most modern OSs and LIBC implementations the `time_t` type representing the UNIX time has been widened to 64 bits (because of this). In my old-ish `arm-none-eabi-gcc` toolchain (with newlib and newlib-nano) sizeof(time_t) returns 8 (64 bits) too.

> seem to recall that Keil needs you to make a clock() and _clock_init() functions to handle platform specifics

And in newlib(-nano) one must provide a custom `_gettimeofday_r` function, otherwise the nosys stub will be used.