Not only real time suffers the issue of overflow. For example 1ms tick is a very common config, you will hit overflow after your device run continuously more than 50 days with 32bit clock_t: 2^32ms=4,294,967,296 ms≈49.71 days
On Mon, May 4, 2026 at 12:43 AM <[email protected]> wrote: > Hello, > > I tried for AVR128DA28 - tools/configure.sh -l breadxavr:nsh > > Default setting (CONFIG_SYSTEM_TIME64 not set): > > Register: nsh > Register: sh > LD: nuttx > Memory region Used Size Region Size %age Used > flash: 50457 B 128 KB 38.50% > sram: 636 B 16 KB 3.88% > eeprom: 0 B 512 B 0.00% > rodata: 592 B 4 KB 14.45% > CP: nuttx.hex > CP: nuttx.asm > > With CONFIG_SYSTEM_TIME64 set: > > Register: nsh > Register: sh > LD: nuttx > Memory region Used Size Region Size %age Used > flash: 52307 B 128 KB 39.91% > sram: 668 B 16 KB 4.08% > eeprom: 0 B 512 B 0.00% > rodata: 592 B 4 KB 14.45% > CP: nuttx.hex > CP: nuttx.asm > > 2kB seems quite noticeable for a chip with 128kB flash. Runtime costs > are somewhat hard to assess, the time_t type is used in internal > timekeeping but the code was developed with tickless mode of operation > in mind so the timekeeping functions should not run that often unless > the system gets busy with processing lots of timed events. > > As for the benefits - the real question is how many devices (designed > with a chip like this one) need to know real time and therefore handle > year 2038. (None of my use cases need that.) > > So for small systems, having the option to configure NuttX so time_t is > 32 bit wide would certainly be beneficial. Making the SYSTEM_TIME64 > option default to DEFAULT_SMALL would be nice but it's not POSIX-correct > so I don't think that's gonna fly. >
