add example pico_w/wifi/ntp_system_time

[mjcross]

A proposed new NTP example that differs from the existing pico_w/wifi/ntp_client in the following ways:

1. uses the SNTP app already provided by lwIP (in threadsafe background mode)
2. uses pico_aon_timer to create a time-of-day clock that can be read asynchronously from user code
3. illustrates the use of a POSIX timezone (TZ) to convert UTC to local time with daylight saving
4. includes a README.md to explain what the example does and how to use it

The program connects to Wi-Fi, initialises the lwIP SNTP app, syncs the pico_aon_timer to NTP and then enters a loop to display the local time in London (or UTC, or whichever timezone the user defines); resynchronising to ntp.pool.org in the background every hour.

I suggest it's quite an important use case for the Pico-W, and illustrates a couple of features users may find helpful (such as how to create and use a POSIX timezone).

[lurch]

Hmmm, if #716 and #714 got together and had a baby... 🤔 😂

[mjcross]

Hmmm, if #716 and #714 got together and had a baby... 🤔 😂

https://digitalcollections.smu.edu/digital/collection/tir/id/205/

[lurch]

Thanks for the extra comments 👍
Not having done any time-based processing in C myself, I was misreading asctime() as ascii_time() whereas I guess it's actually meant to be read as as_ctime() 😂

[mjcross]

I was misreading asctime() as ascii_time() whereas I guess it's actually meant to be read as as_ctime() 😂

Oooo never considered that... My "lengthy and extensive research" (ha ha) suggests it might be the former: https://retrocomputing.stackexchange.com/questions/25601/what-is-the-meaning-of-asctime
In fact for anything more complex than a timestamp it's probably better to use strftime() but that's a bit OTT for an embedded app :-)

[mjcross]

Found a way to avoid hardcoding the timezone names in the printf() :-)

[mjcross]

Many thanks for the excellent suggestions - should be all wrapped up in the latest commit (please let me know if I missed anything)

[mjcross]

Looking really good now - many thanks again for your time to review

[mjcross]

Spent far too long today chasing down why some simple test code couldn't find the function definition for setenv(). Eventually realised it was because in the example I'd forgotten to #include <stdlib.h>, and got away with it because lwIP pulls it in.
Hopefully by importing it explicitly it'll save someone else from the same fate...

[mjcross]

I discovered this was giving very incorrect times of day when run on RP2040. This is because the aon_timer on that platform has a resolution of only one second, which is incompatible with SNTP round-trip compensation. To fix this I have added a test in the example's CMakeLists.txt to disable SNTP_COMP_ROUNDTRIP in lwipopts.h for RP2040.
If you know of a cleaner/better way of handling it I'd be happy to oblige :-)

[lurch]

Looking at the RP2040 datasheet it seems like you could set up the RTC peripheral to trigger an interrupt once a minute (e.g. when the "seconds" value rolls around to 0), and then you could use the callback for that interrupt to read the current Timer peripheral value ("The system timer peripheral on RP2040 provides a global microsecond timebase for the system"). And then when you need the time with a smaller granularity than a second, you could re-read the timer again, subtract the value you stored in the callback, and that would give you the number of microseconds since the start of the last minute? (I guess it's very unlikely that an SNTP round-trip would take longer than a minute!)

Of course it's entirely up to you to decide if it's worth adding that level of complexity to your example 😉

[mjcross]

Looking at the RP2040 datasheet it seems like you could set up the RTC peripheral to trigger an interrupt once a minute
[...]

very inventive!

Of course it's entirely up to you to decide if it's worth adding that level of complexity to your example 😉

To be honest if anyone needs round-trip compensation that much it'd be more cost-effective to just send them a free Pico2_W!

[mjcross]

@lurch I was thinking more of the proposed method of adjusting the lwIP options depending on the platform (i.e. the condition in the CMakeLists.txt): I was wondering whether there was a more preferred way of doing that :-)

[lurch]

@lurch I was thinking more of the proposed method of adjusting the lwIP options depending on the platform (i.e. the condition in the CMakeLists.txt): I was wondering whether there was a more preferred way of doing that :-)

That's more of a question for @peterharperuk - he's much more familiar with lwIP than I am!

[mjcross]

Thanks @lurch 👍
Having had a look at §2.6 of the SDK pdf I'm more comfortable that the conditional target_compiler_definitions() in CMake is a fairly normal thing to do.