嗯，我只是开始调侃和谐V1.09和V2.02.00。也许我根本不应该评论，但是这个论坛只是我学到的唯一实用的地方。（也许有些专家可以插嘴。）我真的很感激！总之，这里是如何运行的（我想）：TCPIPPSNTPUTCUSESGET（）调用SysTyTMR.TICKCONGTGET（），它检索SysMyRoStubj.SysStukCube。现在…SysSimRoBjC.SysStkCube初始化为零（我想），而ySysStRMJARALCALLACK（）函数负责每秒更新它。你的程序，不知何故，在SysMsRojPoto.SyStCyCalk中存储了一个有意义的值，我想你会看到自从系统初始化以来已经经过的秒数。我正在实现一个UDP客户端应用程序，并且在我的工作站的端口17上有一个UDP时间服务器。（最终，这将与DHCP后台程序和专用UDP服务器上的专有UDP服务器一起运行。）的想法是，在启动时，PIC32从工作站获得UNIX时间（从1970年1月1日起经过的秒），并以此为基础在PIC32上进行一天中的时间。系统。我还没有到达那里，但这正是我的目标。我可以告诉你，使用公历计算，这是从1月1日到0000日到1月1日1970秒的时间。当然，这是胡说八道，因为我们没有在零年的1月1日（事实上，没有零年——想想吧！）因为在第十六到第十八个世纪的日历调整大大改变了事情。（“损失”了一大堆秒，等等）。但至少这是从格里高利日历计算出来的，如果我们从1月1日1970回来。我无法想象价值2208988800是如何或为什么有用的，但它确实存在。我也无法想象这个未被评论的“神奇数字”是某种宇宙巧合。（然而：请参阅脚注）我的意思是，有人有理由定义那个特定的常数。但是，仅仅因为有一个原因并不意味着这是一个很好的理由。我简直想不出这是不是一个好理由。DaveFootnote，
以上来自于百度翻译
以下为原文
Well, I'm just starting to poke around Harmony v1.09 and v2.02.00b. Maybe I shouldn't comment at all, but this forum is just about the only place I learn anything practical, so here goes. (Maybe some experts can chime in. I would really, really appreciate it!)
Anyhow, here's how it goes (I think):
TCPIP_SNTP_UTCSecondsGet() calls
SYS_TMR_TickCountGet(), which retrieves
sSysTmrObject.sysTickCount.
Now...
sSysTmrObject.sysTickCount is initialized to zero (I think), and the
_SYS_TMR_AlarmCallback() function is responsible for updating it every second.
So: Unless your program, somewhere, somehow, stores a meaningful value in
sSysTmrObject.sysTickCount,
I think you will be reading the number of seconds that have elapsed since the system was initialized.
I'm implementing a UDP client application and I have a UDP time server on port 17 of my workstation. (Eventually this will be running along with a DHCP daemon and a specialized UDP server on a proprietary port on a dedicated laptop.) The idea is that upon bootup, the PIC32 gets UNIX time (seconds elapsed since Jan 1, 1970) from the workstation and uses this as a base for time-of-day on the PIC32 system. I haven't got there yet, but that's what I'm aiming for.
Well, I can tell you that, using Gregorian Calendar calculations, that is the number of seconds elapsed from Jan 1, 0000 through Jan 1 1970. Of course that's nonsense since we didn't have January 1 in the year zero (Actually, there was no year zero---think about it!), and because calendar adjustments in the 16th though 18th centuries changed things considerably. ("Lost" a bunch of seconds, among other things.) But at least that's what comes out of the Gregorian calendar calculations if we project back from Jan 1 1970.
I can't imagine how or why the value 2208988800 is useful, but there it is. I also can't imagine that this uncommented "magic number" is some cosmic coincidence. (However: See Footnote)
I mean, someone had a reason to define that particular constant. But, just because there is a reason doesn't mean it's a
good reason. I simply can't figure out whether it was a
good reason.
Regards,
Dave
Footnote:
嗯，我只是开始调侃和谐V1.09和V2.02.00。也许我根本不应该评论，但是这个论坛只是我学到的唯一实用的地方。（也许有些专家可以插嘴。）我真的很感激！总之，这里是如何运行的（我想）：TCPIPPSNTPUTCUSESGET（）调用SysTyTMR.TICKCONGTGET（），它检索SysMyRoStubj.SysStukCube。现在…SysSimRoBjC.SysStkCube初始化为零（我想），而ySysStRMJARALCALLACK（）函数负责每秒更新它。你的程序，不知何故，在SysMsRojPoto.SyStCyCalk中存储了一个有意义的值，我想你会看到自从系统初始化以来已经经过的秒数。我正在实现一个UDP客户端应用程序，并且在我的工作站的端口17上有一个UDP时间服务器。（最终，这将与DHCP后台程序和专用UDP服务器上的专有UDP服务器一起运行。）的想法是，在启动时，PIC32从工作站获得UNIX时间（从1970年1月1日起经过的秒），并以此为基础在PIC32上进行一天中的时间。系统。我还没有到达那里，但这正是我的目标。我可以告诉你，使用公历计算，这是从1月1日到0000日到1月1日1970秒的时间。当然，这是胡说八道，因为我们没有在零年的1月1日（事实上，没有零年——想想吧！）因为在第十六到第十八个世纪的日历调整大大改变了事情。（“损失”了一大堆秒，等等）。但至少这是从格里高利日历计算出来的，如果我们从1月1日1970回来。我无法想象价值2208988800是如何或为什么有用的，但它确实存在。我也无法想象这个未被评论的“神奇数字”是某种宇宙巧合。（然而：请参阅脚注）我的意思是，有人有理由定义那个特定的常数。但是，仅仅因为有一个原因并不意味着这是一个很好的理由。我简直想不出这是不是一个好理由。DaveFootnote，
以上来自于百度翻译
以下为原文
Well, I'm just starting to poke around Harmony v1.09 and v2.02.00b. Maybe I shouldn't comment at all, but this forum is just about the only place I learn anything practical, so here goes. (Maybe some experts can chime in. I would really, really appreciate it!)
Anyhow, here's how it goes (I think):
TCPIP_SNTP_UTCSecondsGet() calls
SYS_TMR_TickCountGet(), which retrieves
sSysTmrObject.sysTickCount.
Now...
sSysTmrObject.sysTickCount is initialized to zero (I think), and the
_SYS_TMR_AlarmCallback() function is responsible for updating it every second.
So: Unless your program, somewhere, somehow, stores a meaningful value in
sSysTmrObject.sysTickCount,
I think you will be reading the number of seconds that have elapsed since the system was initialized.
I'm implementing a UDP client application and I have a UDP time server on port 17 of my workstation. (Eventually this will be running along with a DHCP daemon and a specialized UDP server on a proprietary port on a dedicated laptop.) The idea is that upon bootup, the PIC32 gets UNIX time (seconds elapsed since Jan 1, 1970) from the workstation and uses this as a base for time-of-day on the PIC32 system. I haven't got there yet, but that's what I'm aiming for.
Well, I can tell you that, using Gregorian Calendar calculations, that is the number of seconds elapsed from Jan 1, 0000 through Jan 1 1970. Of course that's nonsense since we didn't have January 1 in the year zero (Actually, there was no year zero---think about it!), and because calendar adjustments in the 16th though 18th centuries changed things considerably. ("Lost" a bunch of seconds, among other things.) But at least that's what comes out of the Gregorian calendar calculations if we project back from Jan 1 1970.
I can't imagine how or why the value 2208988800 is useful, but there it is. I also can't imagine that this uncommented "magic number" is some cosmic coincidence. (However: See Footnote)
I mean, someone had a reason to define that particular constant. But, just because there is a reason doesn't mean it's a
good reason. I simply can't figure out whether it was a
good reason.
Regards,
Dave
Footnote:
举报
