-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WiFi Support #20
Comments
@Kintar here is the issue I created based on the work you are doing. The branch is 20-wifi-support |
Regarding your comments from the other discussion, which lwIP implementation are you using? I am trying to think forward to adding support for other MCU platforms - I know there is a lwIP library in the Pico SDK, but perhaps we should use the GitHub mirror as a submodule at or near the top level? Then any interface between lwIP <-> CYW43 would reside in In general, for this first implementation, I would say we pick a particular configuration and go with it, foregoing "flexibility" for now. That could come later as more features are added. If your end goal for now is getting MQTT working, do what works for that. We do however want the stack to run in FreeRTOS for sure - but within the Let me know your thoughts! Also, feel free to send PRs to this branch at any time, don't need to fully bake anything yet, the above is Pie in the Sky and may take a minute to get there. |
@mcknly I think we should have a Discord conversation. I've run across some...oddities with the Pico SDK, lwIP, and FreeRTOS. If you want to shoot me an email at the address listed on my commit messages, let's find a time to talk. The short version is that the lwip implementation included with the Pico SDK won't compile with the current mainline of FreeRTOS, and your CLI code won't compile with the Pico SDK's required version of FreeRTOS...or at least, I can't get them to play nicely together. |
@mcknly : You can ignore that last message from me. Looks like there's an update to one of the configuration options that was causing the issue. |
…configs to manage RAM usage
@Kintar I had a brief look at your WiFi feature branch, looks like good progress so far, your compilation issues are resolved now? |
@mcknly Yep. Gotta love how thoroughly Amazon documents stuff, don't you? I work with AWS daily for my "real" job, and their documentation practices are a constant source of irritation so I wasn't surprised to find Amazon is the maintainer of FreeRTOS. ;) I'm thinking a service is the wrong way to go, now that I've been a little further into your existing code, and it would make more sense as an entry in the /dev node, with commands like:
Then
And we can expand from there if we need more data. This should be everything we need for basic connectivity and MQTT/Telnet implementation, though. Thoughts? |
@Kintar could you expand more on
Do you mean the stack should run outside of the In terms of your functions/commands - we are aligned, although in the future when we have more WiFi/networking/MQTT stuff, it may make sense to have a new CLI node (maybe |
@mcknly I meant that the stack should run outside of the 100% agreed on your comment about a new CLI node in the future. For now I'm going to leave it in |
…configs to manage RAM usage
…sions of FreeRTOS
Well...it compiles and boots, but it now hangs when it tries to initialize the wifi chip. I've tried several configuration tweaks to no avail. I'm going to spin up a small FreeRTOS-based project and see if I can get it running without any of the other plumbing and maybe that will offer insight. |
Oh. My. God. >.< Okay, the solution is simple. Look for a commit in a few hours. |
Well...the solution I found worked in the pico FreeRTOS ping example, but not in BBOS. Still investigating. |
I'm so confused by this it's not even funny. I spent a great deal of time yesterday evening and today looking at this problem, and I can find no reasonable explanation. The issue is occurring in the cyw43_arch_init() function, and is related to the changes made to FreeRTOS-Kernel to support SMP on the mainline branch. After identifying all of the issues which prevented the pico SDK examples from compiling and running against the current I then built a new FRTOS project from scratch and got it working and connecting on the pico_w, and tried copying the config file from bbos over to it...and it still works. O.o At this point, I'm a at a loss as to what the issue could be. Something is interfering with the proper initialization of the cyw43 module, but I'm baffled as to what. I think my next move is going to be to start bringing microshell and the other subsystems from bbos over to the new project and see how long it takes me to break the new project. That might give a better hint as to the culprit. If you have alternative suggestions @mcknly, I'm all ears. |
I FINALLY found it. There was a call into |
Congrats Those are a painSent from my iPhoneOn Jun 29, 2024, at 4:46 PM, Alec Lanter ***@***.***> wrote:
I FINALLY found it. There was a call into onboard_led_init that I'd missed!
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
SLOWLY, painfully getting closer. I'm now getting to the point of enabling station mode before everything locks up. At this point, I think I'm going to have to change the entire bootup sequence in order to validate what I'm doing. I know WiFi works with FreeRTOS, I've done it in two other from-scratch projects, plus the iperf and ping examples from the pico-examples project. There has to be something interfering. The thing that really baffles me is that the hardware watchdog isn't restarting the system, either, which is distressing. |
Hardware defines are all correct? And init for all the devices?Sent from my iPhoneOn Jun 29, 2024, at 10:11 PM, Alec Lanter ***@***.***> wrote:
SLOWLY, painfully getting closer. I'm now getting to the point of enabling station mode before everything locks up. At this point, I think I'm going to have to change the entire bootup sequence in order to validate what I'm doing. I know WiFi works with FreeRTOS, I've done it in two other from-scratch projects, plus the iperf and ping examples from the pico-examples project. There has to be something interfering. The thing that really baffles me is that the hardware watchdog isn't restarting the system, either, which is distressing.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
Expect a lack of communication from me for a few days. Starting a new sprint at work, and getting together the parts to do a proper debug probe setup. |
@Kintar I appreciate your tenacity on this. Proper debugger support should hopefully help tremendously. I apologize for not giving you more support with a second set of eyes (and a JLink), been super busy with family + prepping for a 1100 mile bike ride. That said, I will also be mostly offline for the next week and a half, out somewhere on my bicycle. Thanks again for your work! Will check in mid July! |
No worries, @mcknly, I know how it goes. I've been lucky to have this much time to dedicate over the past week, honestly. I finally started over yesterday evening and created my own little "smol-os" project to prototype with. I also FINALLY found my other pico, so I now have a picoprobe set up for SWD. Couple that with work today that involved lots of thumb-twiddling while waiting on cloud deployment pipelines to run (<grin>), I now have a working FreeRTOS base system that will boot the pico_w, set up UART comms single-threaded, then launch a task to configure the cyw43 arch and join WiFi while another task blinks the onboard LED. I've learned the following:
So, I have enough information (and a working debug probe) now that I should be able to get back to implementing this in bbos once I have free time again...but this presents a couple of new issues. First, the startup process of BBOS will need to be modified when using a pico_w. In order to monitor boot status, we'll need UART immediately after power-on, but we must then launch ONE and ONLY one RTOS task to start the WiFi initialization process. Once that task gets past the cyw43 init call, we can start creating other RTOS tasks and continue startup as normal. Second, the mysterious "bad auth" errors worry me. I'm hopeful that there's just something screwy with my pico_w board, but it's hardly been used at all so that seems unlikely. I'd really like for other folks with access to a pico_w to try the code I'm using in my experiments and see if their experience is the same. If this really is something in the wifi stack, it means we'll need to put in a fairly robust retry system, and give lots of feedback to the end user. Third...I've honestly forgotten what my third topic was because I had a meeting in the middle of typing the second point and have completely lost my train of thought. =) As always, I'd love to hear other people's thoughts on this stuff. I'll get my experiment project cleaned up and link it in a comment as soon as I won't be embarrassed to have other people read it. :D @mcknly : Good luck on your bike...race? Ride? Self-imposed penance tour? ;) Talk to you mid-July! |
Being an embedded hardware designer by trade this all sounds suspiciously like the peculiarities you might see when you have two MCUs that aren't playing nice together. Possibly a race condition at boot... State machines getting out of whack when one chip resets but the other does not.... Maybe the CYW43439 is still connected/authenticated after RP2040 reboot causing authentication errors? And then there's this interesting note in the datasheet:
I haven't dug into the schematics yet... |
Nailed it. Voluntarily suffering planned with a small group of like-minded idiots. |
@Kintar I have had a couple of busy weeks but I finally got time to pull down and test somethings or help out. I'll be looking at your pull request but I'm wondering: you have it labelled as NON FUNCTIONAL can you just summarize where its at? Again I haven't looked at it yet but just wanted to get up to speed on where you're left it when you did the pull request. Thanks. Great work btw. |
The summary is in the text of the PR. The short version is that it work to connect to WiFi most of the time, but the RTOS system hangs when it starts to initialize the NVM system (littlefs, if I recall, not at my computer at the moment). |
Oh gotcha I'll take a look thanks! |
* refactor: cmake and interfaces Retooled the cmake configuration such that the hardware library is now an INTERFACE library, rather than directly modifying the root project. This allows us to remove numerous link_lib defs from the cli and root project, as well as provides an easier method to pass hardware-level compiler definitions up to the main project in the cases where that is necessary. * feat(#20): need configUSE_PASSIVE_IDLE_HOOK defined for SMP versions of FreeRTOS * feat(#20): more necessary FreeRTOS config updates * feat(#20): include lwip_sys_freertos lib, decrease heap space accordingly * wip: wifi functions * wip: implemented all necessary wifi wrapper func * wip: correctly toggle hw_wifi.c inclusion based on HW_WIFI * wip: first pass at the actual service * fix(#20): apparently, configNUM_CORES still has to be defined!?!?!? * fix(#20): watchdog priority, update cli printing from wifi * chore: update with mcknly's PR comments
@Kintar had a few brief moments to test the branch today. I see the issues you have mentioned - I can get it to connect at first powerup, but for subsequent boots I need to pull power completely and hard reboot the entire board. I've had a look at the Pico_W schematics (here), looks like there is a |
Oh, wow. That STINKS, because the project I'm working on that brought me to BBOS needs multicore support. :( It's also very strange, because the project I built to test WiFi+FreeRTOS without BBOS was working fine. I really need to figure out why my GDB breakpoints have stopped working. I've mucked up something config-wise with my picoprobe, and just haven't had the time to figure out what. |
@mcknly : Did you do a squash-merge when you merged PR #22? I see commit 0e74b9 was merged when that PR was closed, and it's not something I have on my branch. Attempting to merge or rebase my 20-wifi-support with yours is throwing all sorts of conflicts, which I wouldn't have expected if this was a full merge of the PR. |
@mcknly : Okay, nevermind. I see what's going on. I'm just not used to the "github way" of merging PRs. |
Can you give any more detail on how you intend to use multicore? FreeRTOS on one? Both? With AMP or SMP? Maybe there is an easy fix. SMP with support for the RP2040 port should be in mainline and working these days, I've just never messed with it. I'm hoping that the fact it just hangs when trying to initialize with the SMP options means there is something easy config-wise that we are missing. |
FreeRTOS in SMP on both cores of a Pico. One core will be mainly concerned with an arbitrary waveform generator that's pinned to that core, while the other will be performing sensor-related tasks and dropping messages into a process queue to alter the output from the AWG. I don't really need BBOS for this project, it was just going to be a convenient way to interact with the system while I'm tweaking parameters and doing performance profiling. |
Exactly the purpose of the project! Let's figure this out. I will do my best to support. I really wanted to release with some form of multicore functionality but it was beyond scope at the time. Let me know if you are willing to discuss how to tackle this and we can break it into another issue. |
@mcknly I'm back from vacation, so absolutely. Let's talk about it! |
Adding basic WiFi support with CYW43+lwIP stack. Goals of this implementation:
hardware
folderThe text was updated successfully, but these errors were encountered: