2020-07-20 01:46 AM
Hi,
I am looking at:
STM32Cube_FW_H7_V1.7.0\Middlewares\Third_Party\LwIP\src\apps\sntp
How is it supposed to be used ?
What I did:
void SNTP_Thread(void const *arg)
{
sntp_setoperatingmode(SNTP_OPMODE_POLL);
sntp_setserver(0, &sntp_addr);
printh(" (%d) %s: Server: %s (%u.%u.%u.%u)\r\n",
__LINE__,
__FUNCTION__,
SNTP_SERVER,
((u8_t *)&sntp_addr.addr)[0],
((u8_t *)&sntp_addr.addr)[1],
((u8_t *)&sntp_addr.addr)[2],
((u8_t *)&sntp_addr.addr)[3]);
while (1) {
sntp_init();
if (sntp_rxts() == 1) {
sntp_time(&tim); /* get seconds to time_t tim */
printh(" (%d) %s: SNTP ctime: %s\r",
__LINE__,
__FUNCTION__,
ctime(&tim));
}
}
}
Modified sntp.c, to add the following:
extern time_t tim;
volatile int ts_status;
time_t sntp_time(time_t *t)
{
*t = tim;
return tim;
}
int sntp_rxts(void)
{
return ts_status;
}
and
void sntp_init(void)
{
ts_status = 0;
..
}
Modified sntp_opts.h to reflect a changed SNTP_UPDATE_DELAY to 30s
/** SNTP update delay - in milliseconds
* Default is 1 hour. Must not be beolw 15 seconds by specification (i.e. 15000)
*/
#if !defined SNTP_UPDATE_DELAY || defined __DOXYGEN__
#define SNTP_UPDATE_DELAY 30000 //3600000
#endif
The results that I do get:
SNTP Server : pool.ntp.org (162.159.200.1)
(1050) print_dhcp_state: Lookup Success!
(1081) SNTP_Thread: Server: pool.ntp.org (162.159.200.1)
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:31:42 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:31:54 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:32:13 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:33:16 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:33:46 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:34:46 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:35:45 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:36:03 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:36:55 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:37:13 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:37:26 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:37:45 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:38:17 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:38:56 2020
(1106) SNTP_Thread: SNTP ctime: Mon Jul 20 08:39:16 2020
The deviation in between updates seem to be too wide.
I guess something is wrong ? The way I am using it, probably ?
Can someone comment, please ?
Thanks,
Manu
2020-07-20 02:15 PM
Replying to my own post.
I've managed to fix the issue.
Removing all the timeout bells and whistles in sntp.c, fixed the problem.
Also, the code became very small, efficient and highly readable.
(1195) SNTP_Thread: Server: pool.ntp.org (162.159.200.123)
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:36:32 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:36:52 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:37:12 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:37:31 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:37:51 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:38:11 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:38:31 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:38:51 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:39:11 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:39:31 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:39:51 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:40:11 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:40:31 2020
(1141) sntp_recv: SNTP ctime: Tue Jul 21 02:40:51 2020
Somehow, I feel that the timeout_xx functions should not be a part of lwip, but part of arch/bsp would be simpler and efficient, I think.
2020-07-21 08:51 PM
You cannot call sntp_*() functions from a thread without proper measures. That's written clearly in lwIP documentation!
https://community.st.com/s/question/0D50X0000C6eNNSSQ2/bug-fixes-stm32h7-ethernet
2020-07-22 08:11 AM
The readability of the source file, sntp.c was a bit bad, Is it just me, or someone else feel the same ?
I am not familiar with the lwip stack.
Eventually ended up with a thread doing sntp_send() having a udp_sendto() and a sleep() in the thread.
It appears to be working. No locking in there atm, the pcb isnt shared. So, I guess not an issue there, prolly.
That said, I was reading the other threads which pasted in as a reference.
The problems that you raised in the past, exists in the CubeH7 1.7.0 package as well ?
Thanks!
2020-07-23 02:56 PM
> The readability of the source file, sntp.c was a bit bad
This is the cost of free, opensource software. Get the source free, pay later with your time and effort.
-- pa
2020-07-24 01:02 AM
Being an opensource advocate and an opensource contributor,
I've worked with some opensource communities, vendors, maintained multiple code bases for quite a long .. time.
That said, opensource software quality need not be bad.
It all depends upon how the release is managed and what your goals/intent are.
But, you are absolutely right, one needs to give back to the community.
Regards,
Manu