20 wifi support - Initial Work

[Kintar]

Well, that was a wild journey, and it's still not QUITE working. At this point, the wifi connection works, but the NVM system fails to initialize.

I've done quite a few things in this branch, let me give a quick overview:

• Reworked the way the platform/rp2040 directory is handled, creating an INTERFACE library instead of adding sources directly to the main project
• Updated the FreeRTOS_Config.h file to bring in changes necessary for the pico FreeRTOS and lwIP ports
• Made more tweaks to the hardware_config files to (hopefully) properly initialize cyw43 when wifi isn't needed but skip that init when the wifi service is enabled

There's still an issue with the watchdog forcing a reboot occasionally, and wifi intermittently fails to connect if the watchdog restarts the system.

Also, I still can't get the _async version of the wifi connection to function correctly, so the wifi service uses a blocking connect call, although this doesn't actually block the RTOS, just that task.

[mcknly]

@Kintar - I'm finally back in front of a screen and taking a look at this. First off great work hammering on this and getting something functional. A few comments right off the bat:

• Most likely the watchdog reboots are happening because of the blocking connect - it will block kicking the dog based on priority and resulting OS timer tick task switching schedule
• I see you increased watchdog priority, I assume to alleviate the above. Watchdog needs to stay lowest priority otherwise it will not do its job properly. We'll have to figure out how to make the connect non-blocking, or some other workaround.
• I still suspect some reset issues when RP2040 reboots but CYW43 does not. Will have to figure out some method to force-reset the wireless module which may clear up some of the re-connect issues
• Looks like there are some changes present that already got merged in Fix #11 - Onboard LED for pico_w not working #21, but it's on v0.3-pre branch. I'll merge that into the 20-wifi-support branch, you can rebase off there, and that will be our working branch for this feature (stand by).
• You've done some good things that probably address some of Decouple project top-level from RP2040/Pico #8 - I have to look at this more

That's as far as I've gotten from reading your code from a phone screen. Thanks again. Will be in touch shortly.

[mcknly]

20-wifi-support branch is up to date with your other CYW43 library/LED changes. Use that as your upstream, rebase and update your PR and we can work off that as a feature branch.

[Kintar]

Welcome back, @mcknly! I hope the self-punative bike ride was a success. ;)

• From what I could determine, the "blocking" connect actually uses an RTOS async connect under the hood when the FreeRTOS lib is in use, it just doesn't return until the link is up or failed. This is indeed why I changed the watchdog priority, so that the two tasks would share time slices until WiFi was done with its work, but this was a stop-gap during debugging. I thought about just disabling the watchdog until WiFi was up, but then I discovered the SDK doesn't have a method to disable the pupper once it's let off its leash. :/ It looks like it's possible, but the register writes are a bit beyond my comfort zone in MCU code at the moment. Therefore, config twiddling. I just forgot to add the todo comment to remind myself to change it back.
• Issues with the rp2040 resetting and CYW43 not resetting are almost certainly part of the culprit. Over the last week, I've run across a few threads online that claim the hardware reset on the Pico (not the Pico W) doesn't actually reset everything on the board. It would surprise me absolutely none if this issue was also relevant to the wifi module on the Pico W. Not really sure what to do about that.
• I've adjusted the PR to target the feature branch. Since the changes I added from v0.3-pre were part of the git graph on both repos after your merge, the rebase on my side was functionally a no-op. You can verify this by looking at the oneline output from git log. It shows 20-wifi-support and v0.3-pre from your repository as sharing the same commit, f08115a, which is part of the history of my 20-wifi-support branch.
• As for the changes related to Decouple project top-level from RP2040/Pico #8, glad you approve, but the update was entirely self-serving. I was having a hard time reasoning about the link and CMake graphs in my head without making those changes. XD Anything you'd like changed on this branch to better fit with your idea of project strucure, feel free. Now that I have the compiler playing nicely with the wifi toggle, I don't need to keep thinking about that stuff. :D

Looking forward to hearing more from you!

[Kintar]

I've also changed the title of this PR. Since we have a feature branch, tagging it as "NON FUNCTIONAL" seems a tad redundant.

[mcknly]

Just a few nit-picky things to fix before merging into the feature branch, otherwise I will forget I was thinking of them.