cancel
Showing results for 
Search instead for 
Did you mean: 

LWIP and SNTP

Manu Abraham
Senior

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

5 REPLIES 5
Manu Abraham
Senior

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.

Piranha
Chief II

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!

Pavel A.
Evangelist III

> 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

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