我正在开发一个项目，我需要支持ms粒度的日历+时钟。 我设法配置芯片的RTC以帮助我保持时间，但是我很难找到正确的数据类型来显示时间。
我总是使用time_t（Unix纪元），但它基于秒，所以它不会起作用。
那么struct timeval呢？在演示文稿（asctime）的上下文中，似乎不支持此结构作为struct tm。
在嵌入式系统中表示时间的首选方法是什么？
注意：这个系统连接一个基于java的后端服务器，需要与它同步时间，所以我正在寻找一种可以用几种语言开箱即用的结构。
答案 0 :(得分：1)
您需要毫秒级的粒度并与基于Java的东西进行交互，这表明自epoch以来的64位时间将是一个合适且直接的选择。
今天大多数编译器都有64位类型;如果不是，你可以将它作为两个32位类型的结构以本地字节顺序处理，并放入代码来处理进位。
答案 1 :(得分：0)
有毫秒和毫秒，一个很容易，另一个很难。
我们运行1ms硬件定时器中断循环来处理必须在固态光栅上运行的东西（例如电机控制）。我们在此例程中递增一个全局32位“ticks”值，然后可以用它来计算需要以亚秒间隔发生的事情（EG每隔50ms轮询一次）。
这与使用micro的硬件定时器作为计时参考不同，在这样的系统中存在任何问题的准确性问题 - 从时钟晶振的准确性到所有各种预分频器，中断延迟等现在，我们不关心我们的电机控制程序是每秒运行999次还是每秒运行1001次，或者如果我们每49.5ms而不是50次轮询一个引脚的状态，因为它足够接近，重要的是它及时发生。在24小时的过程中，我们最终可能会得到比当天毫秒更多的“嘀嗒”，这将成为一个可怕的手表。
例如 - 时钟预分频器是否计数到N然后复位，或者n-1和复位？它会立即复位还是需要一个时钟周期？这种细节使微观计时头痛。
我会使用RTC作为时间参考，然后可能将ms计数器与秒的滴答同步（每1Hz RTC中断重置“滴答”为0）这意味着你的ms值只会相对于RTC而言，这一点非常轻微。您甚至可以直接读取RTC的输入时钟寄存器，以提取运行RTC的更快的时钟（通常为32.768kHz时钟）。我们这样做是为了从1kHz定时器的预分频器时钟寄存器中获取微秒值。它并不完美，我们不会用它来保持时间，只是为了捕捉sub-ms事件。
或者，看看你是否真的需要 ms来完成应用程序，或者如果你可以只编一个100ms以内的数字并报告，那就不像JS是原子钟等级时间明智 - 它甚至不是米老鼠手表等级。如果你确实需要这种准确性，那你做错了。