Telnet support/Wireless support.

[glennswest]

Love to see telnet support and wireless support for the wireless models.
Even better option for a web server as well.
Even better if we can script within some nodejs on client.

[mcknly]

I love these ideas. We have just recently added basic wireless support for CYW43 on PicoW, but have not done anything with it yet.

These are the steps I am envisioning:

1. Create a simple driver for connecting to a WiFi AP via CLI, and save config to the onboard flash filesystem
2. Implement a basic Telnet server (integrate an existing project would be ideal)
3. Create a BBOS service for CLI over Telnet

Once those features are in place, doing other fun things over wireless should be easier to implement.

Are you interested in contributing?

[Kintar]

I'm actually working on this right now. (EDIT for clarity: I'm working on IP stack support and MQTT integration, telnet if I'm feeling really froggy. While I can see uses for nodejs, I'm not up to the hassle of finding and bundling an embedded-system-capable nodejs interpreter. 😂 ) One question I had for @mcknly is; where do you want to include the lwIP configuration? It can be bundled in the hardware/rp2040 directory, but lwIP is a fairly common library, so it might make more sense to put it at the same level as the rtos includes.

This is complicated by the fact that there are specific changes to required link libraries for pico depending on how the user wants to interact with lwIP. I could go the route of assuming we want full FreeRTOS integration by default and leave documentation breadcrumbs for people who want to switch to the non-OS or polling backends. That's probably the simplest to start with. This would involve:

• A new switch for lwIP support. Probably just LWIP_ENABLED
• Possibly CMake-level support for switching LWIP_SOCKETS in the lwipopts.h file? (Whether or not to include the BSD socket operations.)
• Adding an lwip directory to hold the default lwipopts.h file.

We could then add the pico-specific library includes to hardware/rp2040/prebuild.cmake, and add a new lwip_optional.cmake include that works at the project level to add the lwipopts header.

Thoughts?

[mcknly]

@Kintar this is exciting! I'm looking forward to seeing your progress. I will convert this issue to a discussion thread, and then create a new issue+branch specific to your CYW43+lwIP implementation.

[Kintar]

Wunderbar! I have the branch replicated in my fork and am starting work in earnest as of today. ( I almost threw the whole project out and started over because I couldn't get your linked FreeRTOS to play nice when I switched it to the SMP branch, then I realized I'd COMPLETELY mis-read the SMP information and didn't need to use the separate branch, so hopefully that will be the only major stumbling block. XD )

[Kintar]

I have the pico lwIP stack successfully compiling with breadboard-os on my fork now, so here's a quick dump regarding initialization of the system vs. run-time support of WiFi commands and a request for comment:

My current idea is as follows.

• When the system starts, the WiFi service startup task performs board-specific initialization. On the pico, this is a call to cyw43_arch_init(), while some boards -- like the esp32 -- don't need any special initialization.
• When the WiFi service task actually starts, it checks for the presence of a wifi configuration in the flashfs. If the config exists, it queues a 'start wifi' command for itself before entering the main loop.
• The main task loop for the WiFi monitors the task's communications queue for work items and invokes the necessary function calls when items arrive.

This would give us the ability to define the available commands for a given board in that board-specific logic, e.g., hardware/rp2040/wifi.c, and provide a common mechanism for the cli wifi commands to invoke the board-specific options, as well as providing a way for the board definitions to inform the cli which commands are available.

Basic commands that would need to be implemented for all boards include (but I'm definitely open to more suggestions):

• set station id
• set authentication mode (WPA, WPA2, mixed, etc)
• set password
• connect
• disconnect
• clear existing configuration

Note: I'm explicitly omitting standard networking commands like ping and nslookup for now. All I'm focused on is geting a pico_w to successfully connect to a wifi network and obtain an IP address, and re-establish the connection if it's restarted.

[glennswest]

Looks good. I'd recommend your setup a two modes, default mode is "portal", where it comes up as a access point, and you can telnet in to be able to "set" the settings above. As I suspect you will only allow you to connect to one, you may want to more set the mode, and have a state machine to try reconnecting if in client mode. If in portal mode, you should support dhcp least one address. A third mode to be "off" would be good as well.

…

On Wed, Jun 26, 2024 at 9:53 AM Alec Lanter ***@***.***> wrote: Quick dump regarding initialization of the system vs. run-time support of WiFi commands and a request for comment: My current idea is as follows. - When the system starts, the WiFi service startup task performs board-specific initialization. On the pico, this is a call to cyw43_arch_init(), while some boards -- like the esp32 -- don't need any special initialization. - When the WiFi service task actually starts, it checks for the presence of a wifi configuration in the flashfs. If the task exists, it queues a 'start wifi' command for itself before entering the main loop. - The main task loop for the WiFi monitors the task's communications queue for work items and invokes the necessary function calls when items arrive. This would give us the ability to define the available commands for a given board in that board-specific logic, e.g., hardware/rp2040/wifi.c, and provide a common mechanism for the cli wifi commands to invoke the board-specific options, as well as providing a way for the board definitions to inform the cli which commands are available. Basic commands that would need to be implemented for all boards include (but I'm definitely open to more suggestions): - set station id - set authentication mode (WPA, WPA2, mixed, etc) - set password - connect - disconnect Note: I'm explicitly omitting standard networking commands like ping and nslookup for now. All I'm focused on is geting a pico_w to successfully connect to a wifi network and obtain an IP address, and re-establish the connection if it's restarted. — Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAHYLP4JOUDKXEI7LXNDPTZJLIXJAVCNFSM6AAAAABJ6CLCJ6VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQOBTHEYTM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Kintar]

It's an interesting idea, but since anyone using BBOS is going to be a tinkerer/hacker with basic serial comms ability, I think that's a lot of extra work that's not really needed. Flash the OS to the chip, then connect via UART/USB and use the CLI to set up the SSID and password. From there, you should be able to telnet in (once telnet is implemented).