The Pico W has WiFi and getting started is easier than you might think from the documentation. Try our easy Web Client to see just how easy. This is an extract from our latest book all about the Pico/W in C.
Programming the Raspberry Pi Pico In C
By Harry Fairhead
Buy from Amazon.
Extra: Adding WiFi To The Pico 2
<ASIN:1871962803>
<ASIN:187196279X>
The Pico and the Pico W are very similar and, with the exception of anything that uses the built-in LED, all of the programs presented so far work on both models. The important difference between them is that the Pico W has additional hardware that enables it to use WiFi. From the programming point of view, however, the task is to learn how to use the new WiFi driver and the LwIP library that provides higher-level networking. This is made more difficult than need be by the inadequate documentation provided for both. This will probably improve over time.
Now that we have managed to make the connection the WiFi, the next step is to transfer data. There are lots of low-level LwIP functions concerned with data, but in most cases we need to work at a higher level with a well defined protocol. One of the most common is HTTP which is used to transfer HTML web pages and this is easy enough to implement using LwIP. You can use raw low-level functions to implement an HTTP client and this is what the example in the SDK does, but there is a much simpler way to achieve the same result. LwIP has a ready built HTTP client that you can use to download any file from a web server. The HTTP client makes use of the raw API, so it can be used without the need for freeRTOS.
The HTTP client has two functions:
As you can see they are very similar. The only real difference is that the first makes the connection using an IP address and the second uses a URL or an IP address and performs a DNS lookup if necessary.
Both functions are asynchronous and you need to define three callback functions to accept the results. Notice that this means you could initiate multiple file downloads that would proceed in parallel.
The first three parameters specify the server and the file to be downloaded. The settings parameter specifies callbacks etc to be used as the connection proceeds. The recv_fn callback is called with the body of the web page, i.e. minus any headers. The callback_arg is passed to the callbacks and the connection parameter can be used to identify the connection if the callbacks are used to download multiple files.
The recv_fn callback provides access to the data:
The first parameter is the argument specified in the original call. The tpcb parameter gives the TCP control block which provides information about the connection which generated the data. The p parameter is a pointer to a pbuf linked list which contains the data, the contents of the requested file. How to make use of pbuf is described later. The final parameter gives the code for any error that has occurred.
A simplified definition of the settings type is:
The first three fields are used to set a web proxy and you can ignore them unless you need to use a proxy. The final two define callbacks. The first result_fn is called when the file transfer is over and it is given the results of the transfer:
The first parameter is the argument specified in the call that started the transfer. There are three parameters concerned with reporting the status of the transfer. The httpc_result parameter gives you the status of the HTTP connection e.g. HTTPC_RESULT_OK or HTTPC_RESULT_ERR_HOSTNAME.
The srv_res parameter gives you the status code from the web server – usually 200 if the file was found and downloaded and 404 if it wasn’t. The err parameter gives you any errors generated by the LwIP functions themselves.
The rx_content_len parameter gives you the number of characters downloaded, but notice you don’t have access to the data in this callback, just the final status of the transaction.