Raspberry Pico Adventures

Mini-Review: WaveShare's RP2350B-Plus-W

noreply@blogger.com (Daniel Quadros) — Mon, 06 Apr 2026 10:00:00 +0000

An unexpected new from Raspberry Pi was the commercialization, in module form, of the Raspberry Pi Pico W radio circuit. This facilitates the creation of boards compatible with the Pico W.

The board we're looking at here is listed for US$11. Considering that the Pico 2 W is listed at US$7, does the RP2350B-Plus-W have advantages that make it competitive?

Let's start with what the RP2350B-Plus-W has in common with the Pico 2: the pinout on the edges. The physical format is slightly different: on one end, we have a USB-C instead of micro USB; on the other, the antenna extends beyond the end of the board. One absence is where to solder a debug connector.

In addition to the BOOT button, there is a Reset button (an annoying absence in the Pico).

One difference that surprised me is the use of the RP2350B instead of the RP2350A used in the Pico 2. The B model has more I/O pins. One of these pins is connected to an LED (the other LED is connected to the radio module, as on Pico boards). The remaining pins are located on the underside of the board.

The Flash memory is 16 MB, a significant improvement over the 4 MB on the Pico 2. The problem is that the Flash memory is located on the underside of the board, which complicates the use of "castellated" pins (when the board is soldered directly onto another). Also on the underside, there is a location for soldering a PSRAM.

A difference you won't see in these photos is the radio module's connections to the RP2350. Waveshare chose to use different pins, making the board incompatible with Pico2 W firmwares. The unofficial Arduino package fully supports this board (see here), but there is no support in MicroPython or CircuitPython yet.

My humble opinion is that it was a mistake to make this board in the Pico format, but with differences that make it difficult to use as a direct replacement. A different format (as we've seen in other boards) would facilitate the use of additional pins, the installation of a PSRAM, and the use of castellated pins.

The Final Countdown - An RP3250 based Event Timer

noreply@blogger.com (Daniel Quadros) — Sat, 27 Sep 2025 20:30:00 +0000

Sometimes, we are counting down the days to an important event, such as a trip or an anniversary. A few years ago, I built a timer for this, using an ESP-8266 board and two LED bar displays:

It worked fine, but powering it through the USB connector was a bit of a pain. So, I started thinking about a battery-powered device. Looking at my parts stash, I found a few components that could be used in this project:

An e-paper display: it shows the last image even if powered down.
A tinyRTC module, with a DS1307 with battery backup and an AT24C32 EEProm: it can save the event date and keep track of the current date and time.
A XIAO RP2350 board: it has support for a rechargeable battery.

I had enough experience with the first two modules, the XIAO RP2350 brought the adventure of learning about power saving with the RP2350.

Before delving into the project details, a word of caution regarding the tinyRTC module: it was designed for use with a rechargeable LR2032 battery, but it typically comes with a CR2032 non-rechargeable battery. The charging circuit also does not follow the LR2032 specifications. So, I am using a CR2032 and removing the D1 diode to disable the recharge circuit.

The interconnections are straightforward:

The display utilizes a three-wire SPI interface (MOSI, SCK, and CS), three digital signals (BUSY, RES, and D/C), plus power (3.3V) and ground.
The tinyRTC utilizes an I2C interface (SDA and SCL), plus power (3.3V) and ground.
A button is connected between a digital input and ground.
The XIAO has pins connected to the spi0 and i2c1 interfaces in the RP2350. The digital signals were assigned to the other pins more or less randomly..

The assembly was done using a protoboard PCB, female pin connectors, and wire-wrapping wires.

The code for interfacing the tinyRTC module is also straightforward. I store my "configuration" (the event date and time) in the EEProm with a simple XOR checksum.

The display itself is a little more complicated; the code for initializing and updating the display is adapted from a manufacturer's example. With enough RAM in the RP2350, I could keep an image of the display in memory.

For text, I chose a 12x16 font. This requires some bit-shifting, as the characters are not byte-aligned. To draw a simple clock dial, I added routines to draw lines and circles. The algorithm for these routines is based on my 1990 book, "PC Assembler: Usando Gráficos e Sons".

The program will wake the RP2350 every 15 minutes to update the display. That leaves us with the task of putting the RP2350 to sleep. The RP2350 documentation is not particularly informative on this matter, nor is the SDK documentation. The SDK has a module named hardware_powman with a few routines, and there are a couple of examples at a fork of the pico-examples. Not much, but enough for this project:

We will switch between two power states: P0_0 (where everything is turned on) and P1_7 (where most of the hardware is turned off).
The change from P0_0 to P1_7 is commanded by the software.
The change from P1_7 back to P0_0 can be commanded by a timer alarm or a GPIO change.
The change from P1_7 back to P0_0 will result in a reset, with the previous RAM content lost.

For now, I am using the timer alarm to wake up the RP2350. The downside is that this timer is not very precise, but I can not use the tinyRTC to drive a GPIO (more about this at the end).

I am not using the USB in normal operation; it is used for configuring the timer and debugging purposes. To reduce power consumption, the USB hardware must be disabled before the device goes to sleep. This is done by a kind of "magic incantation" copied from the powman_timer example.

The full code is available on my github: https://github.com/dquadros/FinalCountdown.git

As a future enhancement, I plan to replace the tinyRTC module with one that utilizes the DS3231 chip. This RTC has better precision and an alarm feature, allowing me to wake the RP2350 through a GPIO pin. Best yet, I found a DS3231 module with a pinout that allows for the replacement without altering the wiring of the RTC connector.

RP2350 Boards

noreply@blogger.com (Daniel Quadros) — Mon, 14 Jul 2025 10:00:00 +0000

Over the past few months, I have collected a few boards that utilize the RP2350 microcontroller. In this post, I will provide a brief description of each one.

1:RP2350USB, 2:RP2350 Stamp XL, 3:RP2350-GEEK, 4:RP2350 Stamp,
5:RP2350 Zero, 6:XIAO RP2350, 7:Feather RP2350, 8:Raspberry Pi Pico 2,
9:RP2350B Core Board, 10:Raspberry Pi Pico 2 W

Raspberry Pi Pico 2 and Pico 2 W

I already talked about these boards. They follow the shape and pin-out of the original Pico boards, including the use of a USB micro connector and the absence of a reset button. Both have 4 megabytes of Flash (an upgrade from the 2 megabytes in the original Pico) and a single user-controlled LED (connected to the RF module in the W boards).

All the other boards mentioned here use a USB-C connector and, except for the RP2350-GEEK, include a reset button.

SeeedStudio XIAO RP2350

SeeedStudio's XIAO line has many models, each using a different microcontroller, sharing the same shape and pin-out (as far as possible). The RP2350 model includes battery support and access to a few other pins through solder points at the bottom side of the board. It has two user-controlled LEDs, one single-color and the other RGB (WS2812).

It is the smallest board in this group, but it has only 2 megabytes of RAM.

Solder Party RP2350 Stamp and RP2350 Stamp XL

You can read my mini-review of these boards here. These boards have a 2 mm pin spacing and can be used with "Carrier Boards". Both have 16 megabytes of Flash. The XL modules use the RP2350B chip that has additional GPIO and ADC pins.

Waveshare RP2350 Zero

This board has the same dimensions and pinout as the RP2040 Zero (a favorite of mine for small projects). A compact board with access to many pins. It features 16 megabytes of Flash and an RGB (WS2812) LED.

WeActStudio RP2350B Core Board

Another board using the RP2350B model, it uses dual-row connectors that are not protoboard-friendly. It has 16 megabytes of Flash, one user-controlled single-color LED, and one user-readable button.

Adafruit Feather RP2350 with with HSTX Port and PSRAM

The Feather is another line of boards with different microcontrollers but the same board dimensions and pinout. The particular model I bought has 8 megabytes of Flash and 8 megabytes of PSRAM and a special connector for using the HSTX peripheral. An additional board is available to connect the HSTX port to a DVI connector for video output.

The board has battery support, one single-color LED, and one RGB (WS2812) LED.

RP2350USB

This is a no-brand board found in many stores on AliExpress. The board can be plugged directly into a USB port, and it is available with 4 or 16 megabytes of Flash. Like the XIAO and RP2350 Zero, a few additional pins are available through solder points.

Waveshare RP2350-GEEK

This board comes in a white enclosure with a USB-A connector. It has 16 megabytes of Flash, a small (1.14") color display with 240x135 resolution, and a RGB (WS2812) LED. There are connectors for USART, DEBUG, I2C, and micro SD. It has a BOOT button, but no Reset button.

Concluding Notes

For general use, particularly in a protoboard, I recommend the Pico boards. For compact projects, the RP2350 Zero and XIAO are good options. The other boards are more appropriate for specific projects.

References

https://www.seeedstudio.com/Seeed-XIAO-RP2350-p-5944.html

https://www.waveshare.com/wiki/RP2350-Zero

https://github.com/WeActStudio/WeActStudio.RP2350BCoreBoard

https://www.adafruit.com/product/6000

https://www.aliexpress.com/item/1005008622261552.html

https://www.waveshare.com/rp2350-geek.htm

https://www.waveshare.com/wiki/RP2350-GEEK

Building a One-time Password Token

noreply@blogger.com (Daniel Quadros) — Sat, 21 Jun 2025 14:05:00 +0000

One-time passwords are an alternative to the more common "permanent" passwords. The problem with a "normal" password is that it can be captured during communication, by fake login screens or by key-loggers. Once a normal password is captured, it can be used until it is changed.

To avoid this "repetition attack", one-time passwords work just once. For each login, a new password is used. This creates a new problem: how to set up these passwords? One solution is to have a "password book", but that is very clumsy.

In this post, we will see how to build a device that generates one-time passwords, one at a time. The other side can use the same algorithm to check the passwords. We will use a Raspberry Pi Pico W board with a MicroPython application.

WARNING: This is a demo only. The encrypting key will be in plain text in the code, open to any curious eyes. Do not use this with any real key!

A Little Theory

What we will use is an HMAC-based one-time password (HOTP). Both sides keep a counter and know a secret key. The counter is processed by a cryptographic hash (HMAC); the password is extracted from the resulting hash. The algorithm used is described in RFC 4226, and is the same employed by many sites (like Github) and applications (like Google Authenticator).

The counter is created from the current UTC time. To account for clock variations and user response times, the counter is incremented every 30 seconds. Furthermore, the side checking the password can accept the previous and next passwords. To account for long-time drift (in cases where the device clock is set only at manufacturing), the checking side can record the differences and take them into account in the next checks. The code uses the Unix Epoch (number of seconds from 1/1/1970 00:00:00 UTC).

HMACs are normally used to check a text integrity. They generate a value (the hash) from a text and a key. RFC 4226 mandates the use of HMAC-SHA1, resulting in a 160-bit (20 bytes) hash. The input text is the counter, encoded as 8 bytes with the more significant byte first (big-endian).

To extract the password from the 20-byte hash, we will:

Get an offset (0 to 15) from the 4 least significant bits in the last byte
Obtain a 32-bit number from the 4 bytes starting at the offset (more significant byte first, ignoring the signal bit)
Extract the 6 least significant digits from the decimal representation of this 32-bit number

Implementation

We will use a Raspberry Pi Pico W board connected to a small 128x32 OLED display:

Check the pinout for your display, mine was different!

To obtain the counter, we will:

Connect to a WiFi network
Get the current time using the NTP protocol
Divide the current time by 30
Convert the result into a bytearray

Note: On RP2040-based boards, MicroPython uses the Unix Epoch. On some other boards (like ESP32-based boards) the epoch is 1/1/2000.

The SHA1 algorithm is available MicroPython in the hashlib library. HMAC needs to be downloaded from https://github.com/micropython/micropython-lib/tree/master/python-stdlib/hmac and installed in the Lib directory on the board.

The driver for the OLED display is available at https://raw.githubusercontent.com/micropython/micropython-lib/master/micropython/drivers/display/ssd1306/ssd1306.py and needs to be installed in the Lib directory on the board.

The project is available at https://github.com/dquadros/otp_token. To use the software you will need to put your WiFi credentials in the secrets.py file. If you want, you can also change the HMAC key.

Testing

An easy way to test our project is to use the Google Authenticator app on an Android phone. You can register the secret key using a QRcode containing

otpauth://totp/{name}?secret= {secret}

where {name} is the name shown in the app and {secret} is the secret key coded in Base32.

In my repository, I included a Python script that can be run on a PC to generate the qrcode. This program requires the segno module.

Further Ideas

You can use this software with other boards supported by Micro Python, the main difference will be the display connections. Supporting other types of display should not be too hard.

You can also adapt the project for offline operation, setting manually the date and tine. An external battery-backed RTC (such as the DS1307) can be used to achieve greater precision and maintain the time when the Pico is powered off.

The biggest problem with this example is that the secret key is exposed. It would be very hard to avoid this using MicroPython. A professional solution should be written in C for the Pico 2 (or other board using the RP2350), storing the secret key in the OTP, encrypting the firmware, and disabling debugging.

Mini-Review: Solder Party's RP2350 boards

noreply@blogger.com (Daniel Quadros) — Wed, 26 Mar 2025 10:00:00 +0000

Solder Party is a Swedish company that has some peculiar boards. For the RP2350 (and RP2040), they have stamp boards, which contain the microcontroller, and carrier boards, where the stamps are connected and provide power and input/output connectors.

One detail that will bother many people is that the pin spacing on the stamp boards is 2 mm instead of the more traditional 0.1" (2.54 mm). SolderParty sells connectors with this spacing.

Although some carriers have RP2040 in their names, all models work with RP2040 and RP2350 stamps.

I purchased both stamp models with RP2350 and the three carrier models. Here are some comments on them.

The RP2350 Stamp XL installed into the RP2xxx Stamp Carrier XL

RP2350 Stamp

This is a small board, measuring 1" by 1". Along a RP2350A, it contains quite a lot of stuff:

16M of Flash
LDO voltage regulator, supplying 3.3V @ 500mA
LIPO battery support, including charging
Boot and Reset buttons
12MHz crystal

The pins on the edge include the 30 GPIO pins, USB, power, and SWD. The pinout is the same as the RP2040 model.

RP2350 Stamp XL

This model is slightly larger, measuring 1" by 1.75". The main difference is that it uses the RP2350B, which adds 18 more GPIO pins. In addition, it:

Has pads for the standard Raspberry Pi connectors for SWD (debug) and UART
Space to solder a second Flash or PSRAM

RP2040 Stamp Carrier

The stamp (RP2040 or RP2350) can be connected by direct soldering or using connectors with 2 mm spacing.

The board follows the format and pinout of the Uno R3, but with pins working at 3.3 V. It has:

Boot and Reset buttons at the edges
USB-C connector
Power barrel connector (7 to 12 VDC)
Connector (non-standard) for SWD
Connector for LIPO battery
LED
Standard Qwiic I2C connector

The through-hole connectors are supplied with the board, but not soldered.

RP2040 Stamp Round Carrier

The Round Carrier is, as the name suggests, a circular board containing 16 WS2812B RGB LEDs. The stamp (RP2040 or RP2350) can be connected by direct soldering, using connectors with 2 mm spacing, or using FlexyPins (which I will describe later).

The board has holes on the edge for connection using alligator clips and:

A USB-C connector
One normal LED
A on/off switch
A LIPO battery connector
Two user buttons

RP2xxx Stamp Carrier XL

This model is the only one that supports the RP2350 Stamp XL. It can also be used with the RP2040 and RP2350 Stamps, but then several pins will be disconnected. The stamp connection can be made by direct soldering, using connectors with 2 mm spacing, or using FlexyPins.

The board has the dimensions of the Arduino Mega/Due, but with pins working at 3.3V and without the double row of pins on the opposite end to the USB connector. It has:

Boot and Reset buttons
USB-C and USB-A connectors
A power barrel connector (7 to 12 VDC)
A micro SD card socket
Standard Raspberry Pi connectors for SWD (debug) and UART
A LIPO battery connector
One normal LED
Two user buttons
A standard Qwiic I2C connector
A micro HDMI connector for use with the RP2350 HSTX peripheral

The through-hole connectors are supplied with the board, but not soldered.

FlexyPin

The purpose of FlexyPins is to provide a solderless connection of the stamp board to the carrier. This allows for quick and easy stamp replacement.

When I first bought the boards from Solder Party, FlexyPins were out of stock. I ended up soldering an RP2350 stamp to the Round Carrier. When I managed to buy the FlexyPins, there was only one option left: the Carrier XL. Here's the first catch: when soldering the FlexiPins, you decide what type of stamp you're going to use (normal or XL).

Soldering the pins is quite laborious and slow. The biggest problem is fitting the pin to the board. Over time, I got the hang of it. But even so, the pins would sometimes rebel. Soldering is easier if you fit and solder the pins one by one. If you fit several before soldering, the access by the soldering iron becomes more restricted.

The first impression was that the spring force was insufficient, but the board worked properly.

Verdict

As I said at the beginning, these are somewhat peculiar boards. The 2mm spacing on the stamp boards is annoying, and I'm not entirely convinced of the benefits of FlexyPins. On the other hand, stamps and carriers have several useful features, such as LIPO battery support.

The RP2350 Stamp XL and RP2xxx Stamp Carrier XL combination is a great option for studying video generation using the RP2350's HSTX and the additional GPIO pins of the RP2350B.

Using an RP2040 to Load Programs from a SD Card into a ZX81 Microcomputer

noreply@blogger.com (Daniel Quadros) — Mon, 23 Dec 2024 10:00:00 +0000

This was a fun project, putting together my old and new hobbies. Back in the 80s, cheap personal computers used K7 tape to store programs. I still got a few of these old computers, but tape is pretty rare these days and my K7 players are breaking apart. You can find a lot of ZX81 software in the internet, as files for emulators. How about using an RP2040 to generate the necessary audio signals from these files?

The final assembly

How the ZX81 Loads and Stores Programs

The ZX81 microcomputer was as frugal as it comes. Using only 4 chips (a Z80 microcontroller, an 8K ROM, a 1K RAM and a custom chip known as "ULA"), it can be connected to a TV and includes a very quirky BASIC interpreter.

With cycles and ROM bytes at a premium, saving and loading was done by small loops in the BASIC interpreter (written in assembly). At the lower level, 0 and 1 bits are coded as sequences of pulses (4 pulses for a 0, 9 pulses for a 1), followed by a short period of silence. There is no special mark between bytes or signaling the start of a byte. What is saved? First there is the program name, with the last character with the high bit at 1. Then a dump of most of the memory, including some system variables, the screen, the BASIC program, and the BASIC variables (so a loaded program could just resume operation from where it was when a SAVE command was executed).

Testing using a Brazilian ZX81 clone

The usual format for the program files on the internet (.P files) is just the memory dump (sometimes with garbage at the end).

The Hardware

In the final assembly I used an RP2040 Zero from Waveshare, during developing I used a Raspberry Pi Pico (for easy access to the debugging pins). An LCD display and a rotary encoder is used for user interaction and an SD module is used for reading the SD card.

A single NPN transistor is used to interface the RP2040's signal to the tape input in the ZX81.

The Software

Here is where the fun comes! I used an existing library ( "no-OS-FatFS-SD-SDIO-SPI-RPi-Pico") is used to read the files from the SD card. I already had code for the display and rotary encoder.

That leaves the pulse generation. For a first test, I just used delay calls to timing, but I could not resist using the PIO for this task. Using the PIO I just load bytes into the PIO FIFO and it takes care of shifting the bits and generating the pulses. This eases the time constrains on my code and allows to show the progress on the LCD.

In the end, I used three PIO programs: one for the pulse generation, one for reading the rotary encoder, and one for controlling the RGB LED on the RP2040 Zero.

The full project is available at https://github.com/dquadros/PicoK7

I2C Pico USB Adapter: Part 4 - Usage

noreply@blogger.com (Daniel Quadros) — Mon, 11 Nov 2024 13:30:00 +0000

In this last part, I will show a few ways to use the adapter under Linux and Windows.

Accessing an I2C device with Python, under Windows

Linux

The i2c-tiny-usb started under Linux, and a driver is standard on Linux.

A few utilities are available in the i2c-tools package (you probably will need to install it with your distro's package manager). To check if the adapter is working and recognized use

sudo i2cdetect -l

The output should include a line like "i2c-n i2c-tiny-usb at ...", where 'n' is a number that identifies the I2CBUS. You will use this number in other i2c-tools commands. To check the address of connected devices, use

sudo i2c-detect n

You will first get a warning that probing for i2c devices can have bad effects on some devices, you can use the -y option to suppress this warning.

The 'i2c-get' and 'i2c-put' commands can be used to read and write to and from I2C devices that use the concept of registers, where a read is preceded by a write of the register's address (form 0x00 to 0xFF).

Details for the i2c-tools commands can be found on the man pages.

Like most devices, the i2cbus can be accessed like a file. The name is '/dev/i2c-n', and there are a few ioctl functions available. Documentation can be found at https://www.kernel.org/doc/Documentation/i2c/dev-interface. It is not hard to write small C programs to interact with I2C devices.

Windows

Windows does not have built-in support for the adapter, but we can still use it. You will need to install a driver (libusb) for the adapter. The easiest way is to use Zadig (https://zadig.akeo.ie/). Plug the adapter, run Zadig, and select "libusb-win32".

There are many ways to use libusb under Windows. In my testing, I used PyUSB (https://github.com/pyusb/pyusb) with Python 3. Notice that this is a low-level API that just gives access to the adapter's endpoints.

I2C Pico USB Adapter: Part 3 - I2C

noreply@blogger.com (Daniel Quadros) — Thu, 31 Oct 2024 10:00:00 +0000

I expected implementing the I2C communication would be very easy. After all, the RP microcontrollers have hardware for this and the SDK has support for it. Alas, I did not take into account some limitations of the hardware and the way i2c-tiny-usb implements its commands.

As a quick refresh, I2C is a serial protocol over two wires, one for clock (SCL) e the other for data (SDA). SCL is always controlled by the master (the microcontroller), SDA can be controlled by the master or the slave. Both signals are normally high, thanks to pullup resistors. During normal communication, SDA only changes when SCL is low. The exceptions mark the beginning (START) and ending (STOP) of an I2C transaction.

The first byte sent by the master after a START condition is a 7 bit address plus a 1 bit read/write indicator. The device with the corresponding address (if there is one) acknowledges this byte. Data bytes are sent after the address, each one acknowledged by the receiver.

As we saw in the previous post, the address byte is sent when we get the I2C_IO command in the SETUP stage, if it is a read, we then get the data from the I2C device; if it is a write, we wait until the DATA stage to send the data.

A special case is when there is no data to send or receive. This is used (as a hack) to check if there is a device with some address in the I2C bus. I say hack, because it is not part of the specification, and some devices will take some action when they are addressed, even before any data is transferred. For this reason, it is more common to use a zero-byte write operation instead of a zero-byte read operation.

The problem with the RP's I2C peripheral is that it automatically emits the START and the address when data is written. You do not have much control over the START and STOP conditions and cannot do zero-byte writes.

The solution is to do as i2c-tiny-usb does: implement I2C manually, using GPIO functions. Something I had done a long time ago, when I used PIC microcontrollers.

I2C Pico USB Adapter: Part 2 - USB Communication

noreply@blogger.com (Daniel Quadros) — Mon, 28 Oct 2024 10:00:00 +0000

The USB standard is complex. Even having studied it hard for my book on the RP2040, I admit I was sometimes confused. This particular application involves some functions of the tinyusb library that are not much discussed in the documentation.

USB Control Transfers, Taken from Figure 8-37 of the USB 2.0 specifications

Let's start from the beginning. USB devices are grouped into classes. The I2C adapter is in the vendor class, meaning it does not follow a standard set of messages (like HID or serial devices). There are a few ways USB devices can transfer data, the I2C adapter uses control transfers. These transfers have a very limited payload, but are easier to implement (that makes a lot of sense when you are bit-banging the protocol in a 12 MHz 8-bit microcontroller).

The first thing needed to implement a USB device is to create a handful of descriptors. These are structures that inform the PC what the device is, what it does, and how to communicate with it. Two important pieces of information are the vendor and product IDs; I used the same ones as the original i2c-tiny-usb, so I can use the same drivers (note that you should not do this if you intend to manufacture and distribute the adapter). As said, the class of the device is vendor, it has only one interface with the two standard endpoints (one for input and the other for output).

Messages sent through control transfers have a fixed format but the interpretation of the fields is up to the device. In this case, one of the fields contains a command:

Echo sends back information in the received message
Get_Func asks for what capabilities our implementation support
Set_Delay defines the clock frequency for the I2C bus (I am ignoring this for now)
I2C_IO transfers data to or from an I2C device. Flags in this command control the generation of START and END conditions (more on this in the next part)
Status sends back the result of the previous command

In the USB protocol, control transfers have three stages: SETUP, DATA (optional), and STATUS. One confusing thing in tinyusb is when your code is called and what you should do at each stage.

The routine you need to code is tud_vendor_control_xfer_cb(); one of its parameters in the stage:

SETUP means that the command has been received and you should set up the answer you will send. If the command is I2C_IO, send the I2C address to the I2C device and check for the device acknowledgment. If the command is an I2C read, perform the reading and pass the result back to tinyusb for transmission.
DATA means that the data transfer is done. If the command was an I2C write, now you can get the data to write from tinyusb (it took me some time to realize this).
STATUS means the transfer is completed, nothing needs to be done.

You can see the full code at github: https://github.com/dquadros/I2C-Pico-USB.

Halloween with MicroPython

noreply@blogger.com (Daniel Quadros) — Fri, 25 Oct 2024 21:40:00 +0000

This is a quick Halloween project (if you have the parts, they are easy to find). With a little imagination, you can adapt it to different components or behaviors. The software is written in MicroPython for a RP2040 (or RP2350), you can port it to other boards by replacing the PIO code for the HC-SR04 sensor with normal GPIO operations.

A resin skull (bought in a trinket store) is transformed into a spooked object that lights up and makes strange noises, especially when someone nears it.

What you need

Here is a list of the parts needed for this project

An RP2040 (or RP2350) board. We will use one UART and four GPIOs pins. The Pico or Pico2 works fine. A XIAO RP2040 or RP2040 Zero is a very compact option. In the pictures, I am using a Feather RP2040 that has battery support
Three WS2812B RGB LEDs (or more)
An HC-SR04 ultrasound distance sensor
A DFPlayer Mini MP3 Player, a micro SD card, and a small speaker

Schematic

The picture below shows the interconnection of the parts:

Nothing special here, just notice that the HC-SR04 is powered by 5V (I could not get it to work reliably at 3.3V), so a voltage divisor is used in the Echo signal.

Mechanical Assembly

The details for the mechanical assembly will depend on the particular skull you got and your skills (or lack of them, as is my case).

For easy access to the skull's interior, I use a hole saw to make a big opening at the bottom. Small holes were made at the eyes, and two RGB LEDs were fixed with hot glue, the third LED was fixed at the back with tape.

The main circuit was housed in a cardboard box used as a base for the skull. Holes were made for the sensor, speaker, and USB cable. If you power the board with a battery or USB power bank, you may do without the hole for the USB cable.

I used a small breadboard, but you can solder wires for a more definitive and rugged assembly.

Software

You can get the code (and the MP3 files I used) from github: https://github.com/dquadros/HalloweenSkull

Here is a concise explanation of its working:

The MP3 class controls the MP3 player. The command used plays files named nnnn.mp3 in a mp3 directory on the SD card. The end of the sound is detected by the Busy signal from the player.
The HCSR04 class uses the HCSR04 sensor to measure the distance of an object in front of the sensor. It uses a PIO program to trigger the sensor and measure the time to receive an echo.
The standard neopixel module is used to control the RGB LEDs. It is assumed that the first LED is at the back of the skull and the next two are at the eyes.
The main loop action depends on the distance to the object in front of the sensor:

If there is something near the sensor (less than 40 cm), the eyes will light up and a sinister laugh will be played
If there is nothing near the sensor, the eyes will randomly blink and a strange voice will sound.

Changing the Project

It should not be hard to make changes to the project. Some ideas:

Change the code to increase or decrease the occurrence of the actions
Change the sounds, by replacing the MP3 files
Increase the number of random sounds, by loading more MP3 files and changing the software
Use another kind of sensor to trigger the lighting of the eyes
Add a servo motor to make something move when someone comes near the skull

I2C Pico USB Adapter: Part 1 - Introduction

noreply@blogger.com (Daniel Quadros) — Thu, 24 Oct 2024 10:00:00 +0000

In this series of posts I will describe my latest project: an I2C to USB adapter that can be constructed with an RP2040 or RP2350 board.

The adapter using a XIAO RP2040 connected to a PCF8583 RTC+RAM

This project is an adaptation of i2c-tiny-usb, a project with the same goals but built with an ATtiny microcontroller.

The main idea is an adapter that plugs in a PC's USB port and allows the connection of one or more I2C devices. Programs running on the PC can interact with the I2C devices through USB messages,

When I found the i2c-tiny-usb project, it looked like the RP2040 (or RP2350) would be a good fit, as it is easily available, cheap, and has full USB hardware (USB is implemented in software on the ATtiny by some clever bit-banging). As we will see in the next parts, things were more challenging than I thought.

Only the USB port and a pair of GPIOs are needed for a minimal adapter, so you can use one of the small RP boards if you want a compact device.

For the firmware development, I used the Pico C SDK. As the USB is used for communication with the PC a pico debug probe was very helpful.

Another thing that attracted me to this project is the availability of driver and library support for the adapter under Linux, Windows, and Mac. In the last part of this series we will take a quick look at this (for Linux and Windows, I do not have a Mac).

I found a crazy bug in the unofficial Arduino support for the RP2040 v 4.01!

noreply@blogger.com (Daniel Quadros) — Wed, 04 Sep 2024 14:06:00 +0000

This is a strange tale... I've been using the excellent Raspberry Pi Pico Arduino Core, managed by Earle F. Philhower III, from its beginnings. It has been recently updated to support the new Pico2 and RP2350.

As part of my preparations for testing the new Pico2 (received it yesterday), I was playing with some old microcontroller benchmarks. When I tried a Whetstone benchmark in the old Pico the program just stopped somewhere in the middle of the calculations, and here starts the tale.

double X; // declared here so the multiplication is not removed by optimization

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, LOW);

  double T = millis();
  X = -1.3 * T;

  digitalWrite(LED_BUILTIN, HIGH);
}

void loop() {
  delay(100);
}

This code forces the bug!

The first messages from the full code appeared in the Serial Monitor, and then no activity. Trying to load new software using the Arduino bootloader would not work, I had to manually enter boot mode to try a new version.

I should have been more methodical. It all started with what I thought would be a quick test, re-running software that had worked fine in the past. I grabbed one of my Pico boards and a USB cable and started testing. After having to unplug and reconnect the USB cable to enter boot mode a few times, I should have moved to a protoboard with a reset button attached to the Pico board, but I never came around to it.

The first thing I did was place a few Serial.print()s. The program crashed somewhere in the middle of the first floating point calculations. I tried a few changes with no results.

I then reverted to version 3.9 and everything worked fine!

A stated trying to isolate a minimum program that showed the problem. The problem disappeared with some changes, but I could make no sense why. After a few hours, I put it aside and went to sleep.

The next day I took a look at the generated code, and found out that the error occurred on the first floating point operation. It disappeared when the compiler optimization took out the operation! I ended up with the code shown at the start, where I even removed the serial outputs and used the LED to show that the code stopped at the floating point multiply.

Out of ideas, I opened an issue at the project. To my surprise, one hour later Earle confirmed that it was bug, by looking at the logs (why didn't I do that?). Turns out that a single typo had resulted in the RP2040 ROM FPU calls not being added in the Pico library.

What "ROM FPU calls" you ask? You see, the RP2040 does not have a Floating Point Unit (FPU), so floating point calculations must be done by software routines. Raspberry Pi have written some very optimized routines (better than the ones in the gcc compiler) and placed them in ROM. Thanks to the typo, the compiler was not using the ROM routines nor the non-optimized routines - it just panicked.

The new version should be generally available soon.

Many thanks to Earl for taking the time to test my crazy error report and quickly finding the case and fixing it.

Some Fun with CircuitPython

noreply@blogger.com (Daniel Quadros) — Wed, 14 Aug 2024 10:00:00 +0000

CircuitPython Day 2024 will be next Friday (Agoust 16), so here is a simple project! I am using a few modules I got in my drawers:

An RP2040 Feather board. This is a nice RP2040 board with 8 MB of Flash and a battery charger (not used in this project).
A BMP390 sensor. I chose this particular board because it has a STEMMA QT connector, just like the Feather board.
A 128x64 pixels OLED display, with I2C interface.
A 4 by 4 WS2812 RGB LED matrix.

This project aims to use the sensor to measure temperature, air pressure, and altitude, show this information in the OLED display and set the RGB LEDs to a color based on the temperature.

Hardware

The connections between the modules are:

Pins +3.3V, GND and A0 are connected to the RGB LED matrix (Vcc, GND an IN, respectively).
A STEMMA cable connects the Feather to the sensor.
The OLED display is connected to the sensor board (to make wiring simpler). The pins used are Vin, GND, SCL and SDA.

Software Setup

The first step is to install the latest CircuitPython firmware on the Feather. Just download the uf2 file from https://circuitpython.org/board/adafruit_feather_rp2040/, connect the Feather to a PC, press boot and reset to put it in the bootloader and copy the uf2 file to the RPI-RP2 drive that will show up.

The board will reboot at the end of the copy and a CIRCUITPY drive will appear.

Now go to https://github.com/adafruit/Adafruit_CircuitPython_Bundle/releases/latest and download the Adafruit CircuitPython Bundle for the CircuitPython version you installed (in my case, 9.x). Expand the zip in your PC and copy the following files/directories to CIRCUITPY/lib:

adafruit_bus_device directory
adafruit_register directory
adafruit_bmp3xx.mpy file
adafruit_ssd1306.mpy file
neopixel.mpy file

Last, download https://github.com/adafruit/Adafruit_CircuitPython_framebuf/blob/main/examples/font5x8.bin and place it at the root of the CIRCUITPY drive.

Software

Here is the full application:

# BMP390 Sensor Example
import board
from busio import I2C
from time import sleep
import neopixel
from adafruit_bmp3xx import BMP3XX_I2C
import adafruit_ssd1306

np_onboard = neopixel.NeoPixel(board.NEOPIXEL, 1)
np_onboard.fill((0, 0, 0))

np = neopixel.NeoPixel(board.A0, 16)
np.fill((0, 0, 0))

temp_colors = (
    (12, 28, 32),  # < 0       light blue
    (0,  18, 32),  #  0 to 10  blue
    (32, 29, 8),  # 10 to 20 yellow
    (32, 13, 0),   # 20 to 30 orange
    (32, 7,  2),   # 30 to 40 light red
    (32, 0,  0)    # > 50 dark red
    )

i2c = board.STEMMA_I2C()
bmp = BMP3XX_I2C(i2c)

oled = adafruit_ssd1306.SSD1306_I2C(128, 32, i2c, addr=0x3c)
oled.fill(0)
oled.show()

def color_temp(temp):
    temp = -9 if temp < -9 else 49 if temp > 49 else temp
    return temp_colors[int(temp+10) // 10]

while True:
    # Read Sensor
    press = bmp.pressure
    temp = bmp.temperature
    alt = bmp.altitude
    print ('Temperature: {:.1f}C  Pressure: {:.0f}Pa  Altitude: {:.1f}m'.format(
        temp, press*100, alt))

    # Show Temperature and Pressure on display
    oled.fill(0)
    oled.text('Temperature: {:.1f}C'.format(temp), 0, 0, 1)
    oled.text('Pressure: {:.0f}Pa'.format(press*100), 0, 10, 1)
    oled.text('Altitude: {:.1f}m'.format(alt), 0, 20, 1)
    oled.show()
    

    # Choose color based on temperature
    np.fill(color_temp(temp))

    # Wait before updating
    sleep(2)

The New Raspberry Pi Pico 2, RP2350 and RP2354: a Short Recap

noreply@blogger.com (Daniel Quadros) — Tue, 13 Aug 2024 10:00:00 +0000

On August 8th, Raspberry announced a new version of the Pi Pico board, the Pi Pico 2, along with a new microcontroller, the RP2350 / RP2354. In this post I will tell the highlights of these new products, along with my comments.

The Raspberry Pi Pico 2

There is not much to say about the board itself. The RP2040 is replaced by the new RP2350 and the 2 MB flash is replaced by 4 MB. Everything else is about the same, including the micro USB connector and the lack of a Reset button. It is clear that a main objective was to make a drop-in replacement for the older version. Price increase from US$4 to US$5.

A Pico W 2 board is expected before the end of the year, using the same RF chip as the current Pico W.

The RP2350A, RP2350B, RP2354A, and RP2354B

This is the important stuff, with great improvements over the RP2040.

The RP2040 has two ARM Cortex M0+ cores. The M0+ is establishing itself as the most popular core for entry-level microcontrollers, replacing the old 8-bit cores.

The new RP254x chips replace the M0+ by the M33, and they are very different animals. They are more recent, have a more advanced ARM architecture ( ARMv8-M vs ARMv6-M) with more instructions and features. This includes single-precision floating-point, DSP and TrustZone instructions. The RP254x also includes a double-precision co-processor to accelerate double-precision calculations. These are great news for applications like digital signal processing and machine learning.

The clock was also improved, from 133MHz to 150MHz. The overall expected improvement in performance (compared to the RP2040) is somewhere between 1.5 and 2.

RAM was also increased, from 264kB to 520kB. If you need more, the RP254x now supports external PSRAM.

If you are a PIO (Programmable I/O) fan, you will be happy to hear that now there are 3 PIOs, increasing the total number of state machines from 8 to 12. This is important as the state machines in a PIO share some common configurations and the same 32 position instruction memory. There are also some small improvements in the instructions available.

A new HSTX peripheral can do multi-bit serial transmission at higher rates than the PIOs. Adafruit has already used it to generate DVI video.

The RP254x has a lot of security features. It is now possible to secure the Flash against unauthorized software installation and encrypt the application. A new OTP memory can be used to store cryptographic keys. There are also mechanisms against fault injection (trying to get the processor in an invalid state where it relaxes the protection).

Power consumption has been improved, especially in the sleep state.

And now the big surprise: the RP235x has also two RISC-V cores! There are a few gotchas:

You can have only two cores (from the four available) running at the same time
Core switching involves a reset, so you should select the cores at boot time and not change it
While it is possible to have an ARM core along a RISC-V core, things are a lot easier if you use only ARM or RISC-V cores.
The RISC-V cores have no float-point instructions and no access to the double-precision co-processor or some security features

The new microcontroller is available in four versions. The RP2354 versions include a 2 MB Flash in the same package. The A versions use a QFN-60 package (similar to the QFN-56 used by the RP2040), providing 30 GPIOs. The B versions use a bigger QFN-80 package and have 48 GPIOs.

My Verdict (so far)

The RP235x chips are a great upgrade to the original RP2040. Prices are slightly higher but cost/performance is better. The M33 cores will allow applications that demand more performance, particularly for computations.

The models with internal Flash may be used on smaller and cheaper boards, while the 48 GPIOs versions will eliminate the need for I/O expanders in some applications.

The Pico 2 is a good starting point to play with the new microcontroller, but other companies are already offering boards with some added features.

Mini Review: RP2040 Pi Zero

noreply@blogger.com (Daniel Quadros) — Wed, 10 Jul 2024 10:00:00 +0000

It is common to see confusion between the Raspberry Pi Pico and other Raspberry Pi boards. The RP2040 Pi Zero, from Waveshare, makes it even more confusing, putting an RP2040 microcontroller in a Pi Zero form factor (including a mini HDMI connector).

At the heart of this board, we have the same RP2040 with a 12MHz crystal as the Raspberry Pi Pico. 16 Mbytes of flash memory and buttons for Reset and Boot are provided. There is a power LED but no LED connected to a GPIO. You can solder a three-pin header for debugging. A USB-C connector is connected to the USB pins in the RP2040 and can be used to power the board.

There is also provision for a lithium battery to power the board. The battery is charged when power is applied through the USB-C or the expansion connector. A micro SD slot is connected to GPIO 18, 19, 20 and 21.

So far, nothing that will rise our eyebrows, just a nice RP2040 board. The expansion connector is 40 pin header similar to the one in the Raspberry Pi Single Board Computers. Some Raspberry Pi hats (expansion boards) should work with the RP2040 Pi Zero, as long as you can figure out the software side.

A second USB-C connector, labeled PIO-USB, is connected to GPIO6 and GPIO7. It is meant to be used with a PIO/software USB implementation, but you could use it as a very confusing GPIO connector.

Last, but not least, there is the mini HDMI connector. This is actually a DVI interface that uses various GPIOs. Its use requires special software that uses DMA, PIO, and overclocking to generate the required signals.

Of course, this board will not run Linux (but there are ports of a couple of Unix-like operating systems for the RP2040, with no DVI support).

DVI software support is very sketchy right now. There are two examples at the Waveshare wiki, based on the ones found at https://github.com/Wren6991/PicoDVI.

Should you buy this board? The answer depends on your application. The HDMI/DVI interface will be useful only if you have the knowledge and time to develop a special application or if you find someone who has done that (serial terminal and old computer emulation are likely candidates).

If you will not use the HDMI connector, you get a nice 16M RP2040 board with battery support, an SD card slot, and a second USB-C connector. In some cases, the 40-pin connector will allow you to use an existing Rapberry Pi hat. All this could reduce the amount of connections and external hardware when compared to the Pi Pico.

More details can be seem at the Waveshare wiki,

Using the LCD 12864-06D Display with the Raspberry Pi Pico

noreply@blogger.com (Daniel Quadros) — Fri, 02 Feb 2024 10:00:00 +0000

The LCD 12864-06D is a graphic (128 by 64 pixels) monochrome Liquid Crystal Display. You will find it in AliExpress and many other stores, but information on it is scarce. An intriguing point is that ads mention that it is graphic and has a Chinese font.

In this post I will present the information I have gathered and share some sample code (using the unofficial RP2040 support for Arduino by Earle F. Phillhoower III).

Technical Specs

The display area is 58 by 28 millimeters, a nice size. It is available in three different configurations (blue, gray and black background), the one I bought has white pixels on blue background.

The power voltage is 3.3V, but I've seen articles where the display is directly connected to a 5V Arduino (I recommend using level converters or voltage divisors in this case).

The display has a 13 pin connector. The first 5 pins are the traditional signals (CS, RES, RS, SCK, SI) for a unidirectional SPI connection to a display controller (ST7565R). The next two pins are the power supply (VDD and GND). Next we have 2 pins for the backlight LED (LEDA e LEDK). The last four pins are for a second SPI interface (SCK, CS, SDO e SDI) that is connected to a ROM chip (16S1Y / ER3805-1).

The ST7565R Display Controller

This controller is similar to other monochrome graphic LCD controllers. Its internal memory stores the display image (up to 132x64). It supports SPI and parallel interfaces, but in this particular display, it is set up to SPI only. The ST7565R has 23 commands, initialization is done by sending many of these commands with values specific to the display and waiting some time between them.

The figure below shows the mapping of the internal memory to the pixels, assuming the display is oriented with the connectoron top:

The Font ROM (16S1Y / ER3805-1)

This memory has 248K and contains fonts for simplified chinese and ASCII:

The memory accepts two commands through the SPI interface: "Read Data Bytes" (for up to 20MHz operation ) and "Read Data Bytes at Higher Speed" (for up to 30MHz operation). After the command you must send three bytes with the start address (plus one additional dont-care byte if using the "Higher Speed" option). After data you get one memory byte for each byte sent.

This memory is useful for systems with restricted non-volatile memory (not the case for the Pi Pico).

Connecting the Display to the Pi Pico

I used the same SPI channel for the display controller and font ROM. The display and the backlight are powered by the 3.3V output of the Pico. A 220R resistor is used to limit the backlight current.

Some Example Code

The examples I wrote are available at https://github.com/dquadros/LCD12864. At this moment there are three examples:

Basic Test initializes the display controller and writes digits on it, using an 8x8 font stored in the program.
FontDump exercises communication with the ROM, listing in the Arduino monitor one or more characters in the 7x8 ASCII font. This shows that the font is stored with 8 bytes per character (1 byte for each column, with the last byte always zero). The least significant bit in a byte corresponds to the top pixel.
UseRomFont writes a text on the screen using the 7x8 ASCII font in the ROM.

Using a Pi Pico to Test DS18B20 Temperature Sensors

noreply@blogger.com (Daniel Quadros) — Wed, 31 May 2023 10:00:00 +0000

The DS18B20 is an easily found temperature sensor, both the sensor itself (it looks like a transistor) and as a waterproof probe with the sensor inside a metallic case. What many don't know is that a large part of the sensors sold are not original parts and many have serious defects.

A throughout study on these clone sensors was done by Chris Petrich, the result can be seen at https://github.com/cpetrich/counterfeit_DS18B20. In the Arduino IDE's Library Manager, you will find the library CheckDS18B20 by Koen DV which can identify the various versions found by Chris.

I decided to make my own version of the test from Chris's observations. In my first tests, I used a Pi Pico W with an e-Paper display (just because that was what I had in my hands at that moment). Later I opted for a soldered version, using an RP2040 Zero and an OLED display. The result fits in an Altoids box:

My software is based on both documented and observed characteristics of the legit and fake sensors:

The pattern of the sensor's address (in the legit part the address is a 48-bit counter and the two most significant bytes are still zero)
The initial content of the registers (as documented in the datasheet)
The support for various ADC resolutions (some clones only support 12-bit resolution)
The time needed to do a temperature reading (as observed by Chris)

The software and hardware details can be seen at https://github.com/dquadros/TestadorDS18B20.

The bad news is that most of the sensors I have are not original parts and some have big defects.

Using WiFi in the Raspberry Pi Pico (Part 5)

noreply@blogger.com (Daniel Quadros) — Mon, 13 Mar 2023 10:00:00 +0000

In this post we will see how to access a REST API with the Raspberry Pi Pico W, using the SDK C/C++ and MicroPython.

An example of a call to a RESP API, using Postman

Basically, a REST API is uses an HTTP method (like GET and POST) to access and manipulate "resources".

Using the C/C++ SDK

For my first example I will use an API that gives information on Brazilian postcodes ("CEP"):

GET http:viacep.com.br/ws/{cep}/json/

where {cep} is the 8 digit postcode we want to consult.

The lwIP library have an HTTP_ client module for HTTP access. This module have two methods: httpc_get_file() and httpc_get_file_dns(). The "get_file" part may be confusing, originally HTTP was only used to access files in the web server.

It may also seem that the second method only resolves the server name through DNS and then does the same thing as the first method, but there is an import difference: the second method puts the server name in the HTTP headers. It is very common for a web server (with a single IP) answer requests that come to different server names and use the name in the header to figure out what it needs to do.

Now all we have to do is the old callback programming. The signature of httpc_get_file_dns() is:

err_t 	 httpc_get_file_dns (
   const char *server_name, 
   u16_t port, 
   const char *uri, 
   const httpc_connection_t *settings,
   altcp_recv_fn recv_fn, 
   void *callback_arg, 
   httpc_state_t **connection)

Where httpc_connection_t contains:

typedef struct _httpc_connection {
  ip_addr_t proxy_addr;
  u16_t proxy_port;
  u8_t use_proxy;
  /* this callback is called when the transfer is finished (or aborted) */
  httpc_result_fn result_fn;
  /* this callback is called after receiving the http headers
     It can abort the connection by returning != ERR_OK */
  httpc_headers_done_fn headers_done_fn;
} httpc_connection_t;

So there are three callbacks involved:

recv_fn is where we get the data
result_fn is where we get the final result (but not the data)
headers_done_fn is where we get the headers in the response

Let's write a very simple example that consults the 01001000 CEP and shows the response in the standard output:

#include <stdio.h>
#include <string.h>
#include <time.h>

#include "pico/stdlib.h"
#include "pico/cyw43_arch.h"
#include "hardware/i2c.h"

#include "lwip/pbuf.h"
#include "lwip/tcp.h"
#include "lwip/apps/http_client.h"
#include "secret.h"

char myBuff[2000];

// called at the end of the transfer
void got_result(void *arg, httpc_result_t httpc_result,
        u32_t rx_content_len, u32_t srv_res, err_t err)

{
    printf("\nTransfer fineshed\n");
    printf("result=%d\n", httpc_result);
    printf("http code=%d\n", srv_res);
}

// called when we get the headers
err_t got_headers(httpc_state_t *connection, void *arg, 
    struct pbuf *hdr, u16_t hdr_len, u32_t content_len)
{
    printf("\nHeaders received\n");
    printf("Content length=%d\n", content_len);
    printf("Header length %d\n", hdr_len);
    pbuf_copy_partial(hdr, myBuff, hdr_len, 0);
    myBuff[hdr_len] = 0;
    printf("Headers: \n");
    printf("%s", myBuff);
    printf("\nContent body:\n");
    return ERR_OK;
}

// called when we get the data
err_t got_data(void *arg, struct altcp_pcb *conn, 
                            struct pbuf *p, err_t err)
{
    pbuf_copy_partial(p, myBuff, p->tot_len, 0);
    myBuff[p->tot_len] = 0;
    printf("%s", myBuff);
    return ERR_OK;
}


// Main program
int main() {
    // Start stdio and wait USB connected
    stdio_init_all();
    while (!stdio_usb_connected()) {
        sleep_ms(100);
    }
    printf("\nREST API Test\n");

    // Start CYW43 and select country
    if (cyw43_arch_init_with_country(CYW43_COUNTRY_BRAZIL)) {
        printf("failed to initialise\n");
        return 1;
    }

    // Start WiFi in Station Mode
    cyw43_arch_enable_sta_mode();

    // Try to connect
    if (cyw43_arch_wifi_connect_timeout_ms(WIFI_SSID, WIFI_PASSWORD, 
        CYW43_AUTH_WPA2_AES_PSK, 10000)) {
        printf("Error connecting WiFi\n");
        return 1;
    }
    char sIP[] = "xxx.xxx.xxx.xxx";
    strcpy (sIP, ip4addr_ntoa(netif_ip4_addr(netif_list)));
    printf ("Connected, IP %s\n", sIP);

    // Access the API
    httpc_connection_t settings;
    settings.result_fn = got_result;
    settings.headers_done_fn = got_headers;

    cyw43_arch_lwip_begin();
    err_t err = httpc_get_file_dns(
            "viacep.com.br", 80, "/ws/01001000/json/",
            &settings, got_data, NULL, NULL
        ); 
    cyw43_arch_lwip_end();

    printf("Immediate Status: %d \n", err);
    while (true){
        #if PICO_CYW43_ARCH_POLL
        cyw43_arch_poll();
        sleep_ms(1);
        #else
        sleep_ms(10);
        #endif
    }
    
    cyw43_arch_deinit();
    return 0;    
}

This code is very crude and limited. Most API nowadays use https, which requires an encrypted connection. Also, the HTTP module does not support redirects (this broke my first try).

Using MicroPython

MicroPython makes things easier and does support https. For this example I will use a free and open API for information on the Star Wars movies. For the full documentation, access https://swapi.dev/documentation. A query is done by acessing https://swapi.dev/api/films/{film}/ where{film} is the film number (1 to 9 in the release order). The answer comes in json format:

{

"characters": [

"https://swapi.dev/api/people/1/",

...

"created": "2014-12-10T14:23:31.880000Z",

"director": "George Lucas",

"edited": "2014-12-12T11:24:39.858000Z",

"episode_id": 4,

"opening_crawl": "It is a period of civil war...",

"planets": [

"https://swapi.dev/api/planets/1/",

...

"producer": "Gary Kurtz, Rick McCallum",

"release_date": "1977-05-25",

"species": [

"https://swapi.dev/api/species/1/",

...

"starships": [

"https://swapi.dev/api/starships/2/",

...

"title": "A New Hope",

"url": "https://swapi.dev/api/films/1/",

"vehicles": [

"https://swapi.dev/api/vehicles/4/",

...

]

}

The code bellow consult the data on the first film and prints its title and opening crawl text.

import rp2
import network
import time
import urequests
import json
 
film = 1
url = 'https://swapi.dev/api/films/{0}/'.format(film)
TIMEOUT = 10
 
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect('essid', 'password')
 
print ('Connecting...')
 
timeout = time.ticks_add(time.ticks_ms(), TIMEOUT*1000)
while not wlan.isconnected() and wlan.status() >= 0 and \
      time.ticks_diff(timeout, time.ticks_ms()) > 0:
    time.sleep(0.2)
     
if wlan.isconnected():
    print ('Connected')
    print ('Querying film {0}'.format(film))
    r = urequests.get(url)
    if r.status_code == 200:
        response = json.loads(r.text)
        print ('Episode {0}: {1}'.format(response['episode_id'],
               response['title']))
        print (response['opening_crawl'])
    else:
        print ('ERROR: {0}'.format(r.status_code));
    r.close()
else:
    print ('ERROR: Could not connect the WiFi!')
 
wlan.active(False)

Mini Review: Banana Pi BPI-PicoW-S3, an ESP32-S3 Board with the Pico Form Factor

noreply@blogger.com (Daniel Quadros) — Mon, 06 Mar 2023 10:00:00 +0000

Banana Pi is known for its alternatives to Raspberry Pi SBCs (single board computers). Now they have launched a board with the same pinout and form factor as the Pi Pico, but with an ESP32-S3 microcontroller. Let's take a look at it.

Physically the board has the same size, the same number of pins (castellated and with practically the same signals) and the same USB micro connector as the Pico.

The difference is that it has an ESP32-S3 instead of a RP2040. The S3 line was launched by Espressif in 2020 (four years after the original ESP32) and has some advantages over the "plain" ESP32 (that is still available):

Two eXtensa LX7 cores instead of two LX6 cores, adding vector instructions. The clock remains at 240MHz
Bluetooth was upgraded to version 5
Native OTG USB (can be used as host or device).

Internal RAM is nearly the same (512k in the S3 versus 520K in the original ESP32). The chip used includes 2M of PSRAM (inside the chip but external of the microcontroller. Two features of the original ESP32 are not available in the ESP32-S3: the DAC and the ethernet interface.

Of course, the ESP32-S3 includes WiFi and Bluetooth that is not available in the RP2040 and the plain Pico. The Pico W uses an external chip to implement wireless and Bluetooth support is beta at this moment.

The board includes an 8M Flash, a Reset button and a WS2812 RGB LED. Instead of a BOOT button (like most ESP32 boards), there are two pads that can be shorted with tweezers.

On the software side, there is support for all traditional environments: ESP-IDF, Arduino, MicroPython and CircuitPython.

The BPI-PicW-S3 os a powerful and well made board with good software support and good documentation (at https://wiki.banana-pi.org/BPI-PicoW-S3). Price (in Aliexpress stores) is around US$10.

I am not sure if using the Pico form factor is a great advantage. On one hand, this gives mechanical and electrical compatibility with the few Pico expansion boards available. On the other hand, there is the question of software compatibility. Software written using the Pico SDKs will not be easy to adapt to ESP-IDF. Code written in MicroPython or CircuitPython we need adjustments, there is greater hope with Arduino code. All this if the code does not use the PIO feature of the RP2040, as the ESP32-S3 has nothing equivalent.

Raspberry Pi Debug Probe and C/C++ SDK & Tools Easy Install on Windows

noreply@blogger.com (Daniel Quadros) — Mon, 27 Feb 2023 10:00:00 +0000

In an unexpected move, the Raspberry Foundation announced the Raspberry Pi Debug Probe, an interesting accessory for the Pico boards (and other boards with ARM microcontrollers).

The Debug Probe board

A few days later, they announced the Raspbery Pi Pico Windows Installer for easier installation of the SDK and the complete toolchain needed for developing C/C++ for the Picos under Windows.

The Debug Probe is a commercial version of the picoprobe (described in the Getting Started with Raspberry Pi Pico document). Like other ARM based microcontroller, the RP2040 includes debugging facilities accessible through an SWD (Serial Wire Debug) port. This port requires two signals, SWIO (data) and SWCLK (clock), plus ground connections. Its use boils down to controlling this signals according to a protocol.

The picoprobe is an normal Raspberry Pi Pico running an special firmware to make it act as an "SWD bridge". It is pretty simple to connect the picoprobe to another Pico (the target of the debugging) . With a little more effort you can get the OpenOCD debugger working, even inside Visual Code.

My take on the picoprobe

The picoprobe (and the Debug Probe) can also be used as a serial to USB adapter for any kind of asynchronous (UART) communication at 3.3V.

The Debug Probe is a beautiful product. Instead of the Pico it uses a dedicated board (with an RP2040, of course) that has connectors for the SWD and UART. It comes in a nice transparent box and three cables:

Back there I said it takes some work to set up the debugger. The same could be said about the toolchain necessary for developing C/C++ applications for the Pico under Windows. Multiple downloads were necessary from various places. Well, no more! The Raspbery Pi Pico Windows Installer is a single download that automates all this process. It will install in a Windows machine:

Arm GNU Toolchain
CMake
Ninja
Python 3.9
Git for Windows
Visual Studio Code
OpenOCD
Pico C/C++ SDK

At the end of the install you will be ready to develop (and debug) C/C++ applications for the Pico. A great help indeed.

Using WiFi in the Raspberry Pi Pico (Part 4)

noreply@blogger.com (Daniel Quadros) — Mon, 13 Feb 2023 10:00:00 +0000

We will now take a look at TCP communication. There are client and server examples at pico-examples, let's see if we can understand what is done.

These two examples are written to talk one to the other. The clients connects to the server, that sends a message. The client receives this message and send it back to the server. This is repeated a few times and the test is concluded.

I will not analyze the code for the WiFi connection (we have looked at it before).

TCP Client

The code can be seem at https://github.com/raspberrypi/pico-examples/blob/master/pico_w/tcp_client/picow_tcp_client.c

Like in UDP, the communication state is stores in a "pcb" structure (in this case tcp_pcb). The creation of this structure, the registering of the callbacks and the triggering of the connection are in the tcp_client_open function:

// Simplified and commented version
static bool tcp_client_open(void *arg) {
	
    // create the PCB PCB (Protocol Control Block)
    state->tcp_pcb = tcp_new_ip_type(IP_GET_TYPE(&state->remote_addr));

    // Define the callbacks argument
    tcp_arg(state->tcp_pcb, state);
	
    // Register a callback called periodic
    tcp_poll(state->tcp_pcb, tcp_client_poll, POLL_TIME_S * 2);
    
    // Register a callback that is called when a transmission is acknowledge by the receiver
    tcp_sent(state->tcp_pcb, tcp_client_sent);
    
    // Register a callback that is called when data is received
    tcp_recv(state->tcp_pcb, tcp_client_recv);
    
    // // Register a callback that is called when a fatal error occurs
    tcp_err(state->tcp_pcb, tcp_client_err);

    // Triggers the connection, tcp_client_connected will be called if and when a connection is successful
    cyw43_arch_lwip_begin();
    err_t err = tcp_connect(state->tcp_pcb, &state->remote_addr, 
                        TCP_PORT, tcp_client_connected);
    cyw43_arch_lwip_end();

    return err == ERR_OK;
}

OK, we can understand this. TCP communication works through the callbacks, lwIP will call your routines when something happens. Let's see what each callback does in the example:

tcp_client_poll(): just does a print to signal it was called
tcp_client_err(): prints an error message
tcp_client_connected(): updates the application state to wait data from the server
tcp_client_recv(): receives the data from the server and, optionally, prints it. The data is sent back to the server through a tcp_write()
tcp_client_sent(): checks if the test is finished, if not waits for more data

At the end of the test all callbacks are cancelled and the connection is closed.

TCP Server

The server initiation (at tcp_server_open) is done by calling:

tcp_bind() to set the port that will be monitored
tcp_listen_with_backlog(): to get ready for connection requests, return a pcb specific for this. All connection requests will be put in a queue (in this case with just one position)
tcp_accept(): start waiting for a connection and sets the callback that will be called when it is established

The next step in the server occurs in the tcp_server_accept() function that is called when a connection is established. This routine defines the poll, err, recv and sent callbacks (as in the client) and uses tcp_write() to send data to the client.

The sent callback readies the server to receive the answer from the client. When the answer is received (in the recv callback), it is checked. If everything is OK, and the test is not finished, another data message is sent.

At the end of the test all callbacks are cancelled and the connection is closed.

Some Comments

Once you get used to the examples code structure it is not hard to understand the programs. The lwIP TCP programming interface is not complex (if you are used to work with callbacks).

This examples are written to do a single test. At the end of a connection the server will not loop to the accept to wait for another client to connect.

Based on this example (and writing a good amount of code) should not be hard to write two applications that talk to each other using simple TCP messages. By today it all about using RESP APIs and that is what I gonna try in the next post.

Support for Bluetooth in the Pico W Has Arrived (and more)

noreply@blogger.com (Daniel Quadros) — Sat, 11 Feb 2023 14:03:00 +0000

When the Raspberry Pi Pico W was launched (seven months ago), a somewhat surprise was that the hardware supported Bluetooth but the software did not. All that was said then was that it maybe added in the future. At the beginning of this year, BT support was included in the plans for version 1.5 of the C/C++ SDK, expected for the end of January. It took a few days more, but the new SDK version was released and yes, it includes support for Bluetooth in the Pico W, but it is labeled as BETA. It also includes other important fixes and enhancements.

Bluetooth support is through the BTstack open source library. One concern is that this library is free only for non-commercial applications, it is expect that the Raspberry Pi Foundation will cut some kind of deal with the developers to allow unrestricted use with the Pico W. BTstack is a very comprehensive implementation of the Bluetooth protocols with support for BLE and many BT profiles. Specific documentation for the Pico W is not available right now but there are quite a few examples available.

It is expected that MicroPython and CircuitPython will add Bluetooth support soon. Also expected are projects from the community.

But the new version is not only about Bluetooth support. The full list of changes can be seem at github, here are some highlights:

numerous bugfixes
many small enhancements to the existing libraries with the addition of new functions
upgrade of tinyusb from version 0.12.0 to 0.15.0. This can break some existing code, but promises great improvements in host mode
addition of a library (pico_i2c_slave) for implementing I2C slaves
addition of TLS support (pico_mbedtls library)
addition of the pico_rand library for generating "largely unpredictable random numbers" for better crypto applications

If you are developing for the RP2040 in C or C++, you should start looking right now into this version. If you are using tinyusb you may have to make some changes in your code.

This also means that a will have to revise my book on the RP2040 (now also available on Amazon).

Using WiFi in the Raspberry Pi Pico (Part 3)

noreply@blogger.com (Daniel Quadros) — Thu, 24 Nov 2022 10:00:00 +0000

As the next step in my studies, I implemented a SNTP client. I also connected an alphanumeric display, so there was something to see in the photo.

Compiling for the Pico W using Visual Code

Thought having Visual Code already set for the plain Pico, it took me sometime to set things for compiling a program for the Pico W (the "Getting Started" guide shows only compiling using the command line). I used Windows in this test, but the settings should also work under Linux.

In the CMakeLists.txt file, put "set(PICO_BOARD pico_w)"
Also in CMakeLists.txt, add the current directory to the list of include directories "target_include_directories(projeto PRIVATE ${CMAKE_CURRENT_LIST_DIR} )"
Still in CMakeLists.txt, put pico_cyw43_arch_lwip_poll in the library list (target_link_libraries)
Copy the lwipopts_examples_common.h file from pico_examples\pico_w to your working directory with the name lwipopts.h

I, unintendedly, built the debug version. This cause some interesting messages to be sent to stdio.

Connecting the Display

Nothing very special here. I disregarded my own advice and connected the 3.3V Pico directly to the I2C interface of the 5V display. Do that at your own risk!

I adapted the code from some old project.

The SNTP Client

I started from some code I wrote before, but the TCP communication is very different in the Pico W (as compared to the Arduino libraries). I tried to write something a little more readable than the SDK examples. My original code used synchronous functions (that block until they finished), in this version everything is done asynchronous (the SNTPupdate() function must be called periodically ).

DNS is consulted before each access to the SNTP server, like in the SDK example. Thanks to the local caching actual communication is not done at every call.

The final result can be seem at https://github.com/dquadros/SNTP_PicoW (with Portugues comments).

Using WiFi in the Raspberry Pi Pico (Part 2)

noreply@blogger.com (Daniel Quadros) — Mon, 14 Nov 2022 13:00:00 +0000

As I mentioned before, I decided to start my study of the Pi Picos's C/C++ SDK function for WiFi communication implementing an SNTP client. This just an exercise, as it is also available in both the lwIP library and the SDK examples. So we start by looking how it is done in the SDK example (code here).

The Pico example output

My first read of the code was not encouraging. To understand it we will examine it a part at a time. I am assuming you know the basics of TCP/IP and recommend you read my comments alongside the source code.

The first block to analyze is the the main() function. It contains calls to the following cyw43_arch functions:

cyw43_arch_init() - initializes the WiFi communication librarties
cyw43_arch_enable_sta_mode() - puts the WiFi in "station" mode, as we are going to connect to an WiFi AP
cyw43_arch_wifi_connect_timeout_ms() - try to connect to the AP
cyw43_arch_deinit() - ends the use of the WiFi communication librarties

All these functions are documented in the SDK manual.

So far, so good. Let's look now at run_ntp_test(), where we find the main loop. The first step of this routine is to call ntp_init(). The program is built around an structure (NTP_T) that holds all its state. ntp_init() allocates this structure and call two functions from the lwIP library (documented here):

udp_new_ip_type() - this routine returns a pointer to a udp_pcb structure. "pcb" stands for Protocol Control Block, the pcbs in lwIP contain the needed information to control the communication for the various protocols.
udp_recv() - Here we define the routine that will be called when a UDP packet is received. As we did not specify a protocol port in the pcb, this routine will be called when data is received at any port. We also define that this routine will receive the state as its parameter.

These functions are parte of the raw lwIP API. lwIP has others, higher level, APIs but they can be used only along with an RTOS (Real Time Operating System). The raw API works mainly through callbacks (don't call me, I will call you when there are news).

Going back to the main loop (and ignoring the error treatments), the following functions are called:

cyw43_arch_lwip_begin()
dns_gethostbyname() - finds out the AP address of a hostname
cyw43_arch_lwip_end()

The begin/end surround the lwIP calls to protect against concurrency problems. There are two ways to use lwIP. In the simple way is works by polling: the cyw43_arch_poll() routine must be called periodically and the begin/end routines do nothing. In the background mode, lwIP will transparently work concurrently with your code anda begin/end are essentials.

There are many possible returns from dns_gethostbyname(). The firs time it will return ERR_INPROGRESS, meaning it is still processing the request; the final result will came through a callback. If everything goes fine, the next calls (for a limited time) will use the previous result and return immediately with ERR_OK. Values different from these two indicate errors. In the example, the ntp_dns_found() callback stores the IP address and calls ntp_request(). This same routine is called if dns_gethostbyname() returns ERR_OK immediatly.

Now we get to ntp_request(), where the actual SNTP request is sent. Here is the full routine:

// Make an NTP request
static void ntp_request(NTP_T *state) {
    cyw43_arch_lwip_begin();
    struct pbuf *p = pbuf_alloc(PBUF_TRANSPORT, NTP_MSG_LEN, PBUF_RAM);
    uint8_t *req = (uint8_t *) p->payload;
    memset(req, 0, NTP_MSG_LEN);
    req[0] = 0x1b;
    udp_sendto(state->ntp_pcb, p, &state->ntp_server_address, NTP_PORT);
    pbuf_free(p);
    cyw43_arch_lwip_end();
}

A few points to highlight:

The transmitted packet is allocated using pbuf_alloc(), an lwIP routine that reserves space for the protocol headers and makes sure the packet is allocated in the appropriate memory area according to the system (in the RP2040 case, this can be anywhere in the SRAM).
The actual transmission is done by udp_sendto(), properly surrounded by cw43_arch_lwip_begin/end
The packet can be discarded as soon as udp_sendto() returns.

In this example there is no association betwen send and received packets. Received packets are treated in the receive callback.

From an SNTP standard viewpoint this implementation is not robust. Let's see if I can do better in the next post.

Using WiFi in the Raspberry Pi Pico (Part 1)

noreply@blogger.com (Daniel Quadros) — Mon, 07 Nov 2022 10:00:00 +0000

The Raspbery Pi Pico W adds to the Pico the ability to do network communication using WiFi (and, maybe, Bluetooth in the future). For starters, I will focus on C/C++ programming. The first steps in learning about the way WiFi is implemented and how to use it are the SDK documentation and the official examples. For those who want an easier and faster path, there is also MicroPython support.

My first Pico W!

The WiFi chip used in the Pico W (CYW43439 ) is a MAC (Media Access Control) layer solution. This means that it implements the physical layer with its addressing (the MAC address) and the way devices share a common communication medium.

For most practical uses we need other layers above the MAC. Theses layers are implemented in the RP2040 software. In these days, the most used network protocol is TCP/IP.

The support for WiFi and TCP/IP in the RP2040 C/C++ SDK is done by three parts:

pico_cyw43_arch: this part connects the other two so they can (potentially) be replaced by compatible alternative implementations. It also manages the LED that is connected to the WiFi chip.
the TCP/IP stack: lwIP is used by the SDK.
cyw43_driver: this is the driver for the chip used in the Pico.

Both the driver and the TCP/IP stack have routines that must be called periodically. The SDK has two versions of the pico_cyw43_arch that implement different solutions for this:

'poll': here it is the application responsibility to periodically call the cyw43_arch_poll routine. The communication functions are not interrupt or multiple core safe, you need to enclose them with calls to cyw43_arch_lwip_begin() and cyw43_arch_lwip_end() in the non-interrupt code.
'thread_safe_background': this is a more sophisticated option where things are done automatically in background an the functions are interrupt and multiple core safe. There is an specific version of this for use with FreeRTOS.

If all you want is to control the LED that is now connected to the CYW43439, and need no WiFi communication, there is a third version of pico_cyw43_arch just for this.