Where I begin to develop applications for the RP2040 (Pi Pico and Pi Pico W) using Micropython.
In Getting Started, we created simple programs and used paste mode to enter the programs into the Pico storage. This works well for short programs and particularly well, for debugging. It will continue to be a valuable technique. That said, paste mode becomes cumbersome for developing longer programs and programs with multiple files. For this we want to be able to quickly upload a file or set of files, preferably remaining in our code editor.
Where I describe various methods of debugging programs using MicroPython on the RP2040 (Pi Pico and Pi Pico W).
Programming is a science, debugging is an art. When I chat with students learning to program, I’ve found it isn’t “programming” which causes the most problems, its “what to do when the programming doesn’t work.”
On any new microcontroller, there is a new tool chain and a new process, which affects how you debug. For example, with the AVR family of microcontrollers, you have gdb, bloom as a hardware debugger (which is fantastic!), make and gcc. Or you may use the Arduino framework. Both approaches are well-defined, well-understood and work well.
Where I work with the Adafruit Feather RP2040 (Feather), Mecrisp-Stellaris Forth (MSForth) and create Forth versions of ManPinTest and PinTest.
This entry will be very similar to the one using the RP2040 and MicroPython, the difference will is I will use MSForth instead.
I’m going to assume that the serial connection, Forth installation and the ability to write/edit/run Forth programs on the RP2040 already exists. If not see this entry.
Where I begin to work with the Adafruit Feather RP2040 (Feather) and MicroPython (uP) and use the Labrador to test the board.
After being disappointed with the uP development for the ESP32, I thought it would be fun to try the latest and greatest, hottest, just out of design, the Raspberry Pi RP2040 Microcontroller. I was able to secure two Adafruit Feather versions and will use those to test.
Where I use the Labrador to test specific functions of the ESP32 running MicroPython.
The best way to begin to understand a board is to play with it. In more technical terms, this means writing software and learning how the board responds. The higher the capability of the board, the greater the need for examining the board with high functioning tools. In our case, we are going to keep things very inexpensive, however, extremely capable and powerful.
Where I investigate using MicroPython on the HUZZAH32.
I have spent quite a few years using Python to develop applications. I like the language, however I believed it wasn’t a good candidate for microcontrollers. Given the strong development behind both CircuitPython and MicroPython, I though it would be a good idea to test it and determine via testing and not assumptions.
I followed the steps Wolf Paulus provides on his website and had no problems. I am using macOS Big Sur with the Apple native USB drivers. Which means I’m using /dev/tty.usbserial-01F4D567 and not /dev/tty.SLAB_USBtoUART. I haven’t had any problems…yet.
Where I write an Arduino program to test pins on a specific board in order to confirm a Forth HAL for the same board.
When writing software which will control a circuit, it is best to confirm the behavior of circuit using known or familar test software before attempting to write with a new language. For example, I am developing a HAL/Primitive/User layer for the ESP32 using ESPForth. As the board, the Adafruit HUZZAH32 has an Arduino framework already developed for it, it is a good idea to test the board using the Arduino C++ code before testing it with the ESPForth words.