Raspberry Pi Pico

[ralphrmartin]

Some good comments there, and yes, clearly the Teensy guys got the importance of libraries. Perhaps I should have said "Libraries easily downloaded and used from within a supporting IDE". My remarks were also intended in the context of this being an educational tool for beginners (vis-a-vis the RPi Foundation's aims).

Yes, Arduino libraries often have many alternatives, and some are broken / badly written / outdated / only work for certain boards. But generally, it's still quicker to try a few and find one that works than to e.g. write a graphics library from scratch.

Yes, Micropython has some useful modules, but those are more for things like stacks and queues than hardware drivers. Yes, if you search for e.g. Micropython BME280, you do find things (and again plenty of alternatives), but users still have to figure out how to install them into whatever development system they are using. It's not the easy learner experience that the Arduino IDE has of: from within the IDE, search for a library, press download, and in one click, it's there complete with examples, ready to use. (And if Micropython is your thing - why prefer this board over say a cheaper ESP32 board with added Wifi?)

The SDK and documentation are well done, I agree, but target a sophisticated audience, rather than providing a painless experience for first time hardware users. There are no examples at the level of "my first hardware project - hook up a temperature sensor and LCD and make an electronic max-min thermometer" for example - the libraries are not there to support such projects.

[exe]

Even if they didn't suck, it would still be annoying to no COMMON abstraction.)

I think trying to get a common abstraction is what made most hals suck. I've seen a lot of hals with "opaque" arguments that are hardware-specific. There is often no validation of arguments at all. Like, it won't check if clock configuration for ADC is incorrect, or some buffer settings. I started to see why people prefer LL drivers over, say, stm32's hal.

Here I'd rant how slow and resource-consuming mbed was for me, but we are discussing micropython, which is probably not the fastest thing out there .

users still have to figure out how to install them into whatever development system they are using.

We are getting there: there is upip for network-enabled devices. And there is adafruit's library that includes tons of libraries: https://circuitpython.org/libraries . I've never used circuitpython myself, but I assume it does what you are asking for. I guess circuitpython is the tool aimed at very beginners.

[jeremy0]

I wonder how we can debug a Pico via SWD. Official documentation shows examples using another RPi (Pico or previous Linux SBC ones). Are there any other debug probes available? It would be great if we could use a ST-Link to debug Picos.

Segger's latest JLink Beta (6.95c) supports RP2040, which worked out of the box (with VTref connected to 3V3) running from flash under VS Code with cortex-debug extension.
https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPackBeta
https://forum.segger.com/index.php/Thread/7762-RP2040-Support/

So far I've only flashed the code manually (UF2 file via USB, outside the debugger).
My minimal attempts to load code to flash or RAM from the debugger didn't work, but I didn't try for long.

[jeremy0]

Coincidentally, I just got mine as well . Pin labels are at the bottom, which is a strange decision to me. Nonetheless, I got a very smooth start, connected with with thonny (IDE for beginners), works flawlessly. I think for a small project such as blinking led this is is ideal. Their micropython book is also available for free download.

A bit of a bummer is maximum SPI rate. It's only 1.8432Mbps (according to datasheet), which might not be enough to refresh my display.  For comparison, esp32 can clock spi up to 80MHz (not sure what is useful bandwidth). I have micropython fork from loboris with custom spi module, it drives my 320x480 display at quite good rate. Refresh is visible, but not too annoying. I was hoping to get similar experience with rp2040, but probably it won't be as good.

The SPI can run up to half the system clock speed.

Clarified here: https://github.com/raspberrypi/pico-feedback/issues/39

"Since the maximum frequency for clk_peri on RP2040 (and hence the maximum frequency for SSPCLK) is 133MHz, the maximum SCK output frequency is 133MHz / 2 = 66.5MHz, and the maximum SCK input frequency is 133 / 12 ~11.083MHz."

[NorthGuy]

A bit of a bummer is maximum SPI rate. It's only 1.8432Mbps (according to datasheet), which might not be enough to refresh my display.

Use PIO. It can go much faster.

[tszaboo]

Yes, Micropython has some useful modules, but those are more for things like stacks and queues than hardware drivers.

This might interest you:
https://learn.adafruit.com/adafruit-circuit-playground-express/circuitpython-libraries
I'm sure there is some source code of it somewhere.

why prefer this board over say a cheaper ESP32 board with added Wifi?)

It has native USB, with circuitpython I have UART + Storage at the same time. I can set up a logger into internal flash, plug in the board somewhere else, and read out a complete CSV file after the logging is done. Without installing any software other than a text editor or compiling anything.

[ralphrmartin]

Sure, if you dig around you can find some libraries, but that is not very beginner friendly, and I'm not sure how "without installing any software" squares with "use circuitpython". Circuitpython runs on the ESP32, too, so it too could be used  for your example (I think?).

Anyway, my main point was, and is, I still don't see why this chip / board were developed; I also note that it doesn't come with any new development ecosystem. What were the perceived shortcomings of boards and chips already out there? I've not seen any statement from the RPi folks along the lines of
"We developed this chip / board because...", or 
"This makes for a better learning experience because... "
I would love for someone to enlighten me.
Apart from perhaps the PIO, there seems to be nothing new here that takes things a step forward.

[NorthGuy]

... that is not very beginner friendly ...

What is that "beginner friendly" anyway?

[ralphrmartin]

Beginner friendly: it's a bit like getting a new toy for Xmas, and the batteries are included.

[phil from seattle]

... that is not very beginner friendly ...

What is that "beginner friendly" anyway?

Well, it is a bit subjective but friendly to me is when the new user doesn't have to download and configure all sorts of libraries and tools and also make a lot of decisions to just get a simple program, like blinking an LED, to work. As pointed out earlier, Teensyduino is a great example of friendly.  Install Arduino - easy. Install Teensyduino (which pulls in a lot of good quality libraries) - easy. Build the sketch - done. There are lot of Tom's HW tutorials that run on and on and are good examples of beginner unfriendly - way too many places to go astray.  There was one that had something like 27 steps - I would call that hostile, not unfriendly, though.

[hamster_nz]

With MicroPython the Pico is relatively beginner friendly. Just open a GUI and code.

For C/C++ development is has quite a few beginner firendly features:

The drag the file to a USB Mass Storage Device to program is very beginner friendly. No cables and wires to hook up, no cable drivers. Seems almost impossible to brick. However it's not unique - seen it before on the BBC micro:bit.

The Cmake magic in the SDK is pretty beginner friendly. Much more so than ESP32's ESP-IDF. Took a bit of tinkering to get a standalone project to build but is great.

However, writing raw C/C++ on a micro is never that beginner friendly though, even with a nice HAL.

[exe]

Any news/rumors about bare IC and stuff? I wonder about plans releasing it in smaller packages and with flash inside the same package, like, afaik, gd32f103. I don't mind if they use the same bare die in different packages and leave some pins unconnected .

[tszaboo]

Sure, if you dig around you can find some libraries, but that is not very beginner friendly, and I'm not sure how "without installing any software" squares with "use circuitpython". Circuitpython runs on the ESP32, too, so it too could be used  for your example (I think?).

Anyway, my main point was, and is, I still don't see why this chip / board were developed; I also note that it doesn't come with any new development ecosystem. What were the perceived shortcomings of boards and chips already out there? I've not seen any statement from the RPi folks along the lines of
"We developed this chip / board because...", or 
"This makes for a better learning experience because... "
I would love for someone to enlighten me.
Apart from perhaps the PIO, there seems to be nothing new here that takes things a step forward.

Last time I tried to run micropython on ESP, I had to identify and download a flashing tool for it (1), which was a python script(2), the binaries were really difficult to identify, you need a serial port application (3) if you want to up/download files, you need Thonny (4).
For Pi pico, it's windows explorer and notepad. Or the equivalent of your choice. It all comes with an operating system, you know how it works, there is 0 learning curve. The built in ROM bootloader even has a link to the website where you can download the binaries. It's a nice touch.

[tszaboo]

Ah great. So I was working on Pi Pico yesterday, trying to connect it to something with CP. For the life of me, I couldn't get the UART working.
Then  I realized that theCP implementation of UART is different than the uP. Ok, no problem, rewrote the code for that.
I get an error.
UART is not implemented   
How the hell did this ever got released, it feels like a pre alpha build?

[newbrain]

The drag the file to a USB Mass Storage Device to program is very beginner friendly. No cables and wires to hook up, no cable drivers. Seems almost impossible to brick. However it's not unique - seen it before on the BBC micro:bit.

And on every ST Nucleo board, and I think all of the mBed supported HW.
Without the need to restart board in a special mode (thanks to the integrated debug probe).

[DrG]

A decent (IMO) "Working with the Raspberry Pi Pico with Windows and C/C++" article/tutorial
https://www.element14.com/community/community/raspberry-pi/blog/2021/01/24/working-with-the-raspberry-pi-pico-with-windows

I particularly liked the Project template, including the CMakeLists.txt information.

I agree with the author's summary statements: "For those used to Arduino, the process may seem long-winded (which it is in comparison) but it only needs to be done once to get familiarity with it. These tools and all sorts of scripts are used by organizations to develop real products, so the knowledge gained is directly transferrable to engineering work environments"

BTW: I did download and install the project1.zip file and it worked fine and all from within vscode.

[hamster_nz]

A decent (IMO) "Working with the Raspberry Pi Pico with Windows and C/C++" article/tutorial
https://www.element14.com/community/community/raspberry-pi/blog/2021/01/24/working-with-the-raspberry-pi-pico-with-windows

I might have to give that a try - believe it or not I'm using 'vim' under Windows Subsystem for Linux and it is working fine. 

I've got my little I2S testing 'Drum machine' working with no resistance at all - https://github.com/hamsternz/PiPico_Drummer

I would like to try using a Pico as a debug interface for another Pico. That seems pretty worthwhile and inexpensive.

[MK14]

As time has gone on, recently. Some of the suppliers (UK, as recommended via official Raspberry PI PICO website links), which limited you to only buy a maximum of 1, and had run out of stock. Both had stock, again and increased the limit to 3.

So I've bought my first PICOs, they should be arriving soon.

At £3 + VAT (£3.60) each, plus £3 shipping (depending on which supplier, some offer free shipping, if order total is above a limit). It is not bad, for a reasonable spec'd development board(s), with decent quality, and which is well documented and supported.
Also, orderable to arrive within a day or so, rather than having to wait many weeks (potentially), if ordering from China.

I like the look of the Teensy 4.1, which has a much better specification, than the PICO. But at around £27 each (I sometimes seem to see them from around £20, upwards), it is arguably too expensive, to use in small Led flashing experiments/projects and all sorts of miscellaneous things, that need/want MCU capabilities.

It is difficult these days, to do much better than the £3.60/$4 a throw. Especially if you like/want the quick delivery, good documentation and build quality of it, compared to some of the cheap Chinese MCU development boards.

Although on paper (in theory), the cheap Chinese MCU development boards (such as the blue pills), look good. When you look at honest/detailed/accurate reviews. They seem to describe various technical difficulties, such as incorrect USB resistors, rather old cpu technology and peripheral sets, fake/clone cpus being used, which can cause incompatibilities, differences with documentation and other niggles.
Also, the USB connector, may NOT work as planned. E.g. It isn't ready to program the device (until you install a boot loader, which may need special debugging hardware connection things, although clone versions, are cheaply available on ebay, apparently), or NOT even act as a USB at all (except as a power connector).

[hamster_nz]

One nice thing I saw in the Pico datasheet:

Pico uses an on-board buck-boost SMPS which is able to generate the required 3.3 volts (to power RP2040 and external
circuitry) from a wide range of input voltages (~1.8 to 5.5V). This allows significant flexibility in powering the unit from
various sources such as a single Lithium-Ion cell, or 3 AA cells in series. Battery chargers can also be very easily
integrated with the Pico powerchain.

That's a pretty nice feature not found on most small+cheap dev boards that can be USB powered - they usually have just an AM1117 or similar LDO .

[iMo]

One nice thing I saw in the Pico datasheet:

Pico uses an on-board buck-boost SMPS which is able to generate the required 3.3 volts (to power RP2040 and external
circuitry) from a wide range of input voltages (~1.8 to 5.5V). This allows significant flexibility in powering the unit from
various sources such as a single Lithium-Ion cell, or 3 AA cells in series. Battery chargers can also be very easily
integrated with the Pico powerchain.

That's a pretty nice feature not found on most small+cheap dev boards that can be USB powered - they usually have just an AM1117 or similar LDO .

FYI - this small not cheap pic32mz dev board I've been playing with uses a switcher (the TI's TPS82130 with integrated inductor) too - up to 17V in, 3.3V out and up to 3A (!) output current..

[DrG]

I have been playing around a bit with the Pico as a USB device. There are a couple of programs in the examples. I do not have much experience programming USB devices and HID specifically. I am wondering if you have any thoughts/guidanc eon this particular issue....

I would like the Pico to send/receive packets (e.g., 256 bytes) to a Windows machine running a visual C (or BASIC) program. Ideally, the Pico would appear as a com port to the Visual Studio program. Something like a Human Interface Device to Com port since some of the sample USB device code is recognized by Windows.

I have been reading up and investigating, but again, I have not done this kind of thing before. Let me put it another way: take a look at this device:
https://store.ncd.io/product/usb-to-i2c-converter-adapter/

I can see a PIC12F1840 which is likely being used as an I2C interface (I have done that). Also I see an FTDI chip, which is obviously used for the Com port that windows sees. So, I am not interested in copying that board, but I am wondering if I can get that functionality using only a Pico.
 

[NorthGuy]

I can see a PIC12F1840 which is likely being used as an I2C interface (I have done that). Also I see an FTDI chip, which is obviously used for the Com port that windows sees.

Could've been done with a single PIC16F1454 chip.

So, I am not interested in copying that board, but I am wondering if I can get that functionality using only a Pico.

I think so. Their USB controller seems very generic. You can use either CDC (serial port emulation) class or HID class.

[westfw]

Ideally, the Pico would appear as a com port to the Visual Studio program. Something like a Human Interface Device to Com port since some of the sample USB device code is recognized by Windows.

To appear as a COM port, without writing windows-side drivers, the Pico should implement a CDC/ACM "device."  The Pico folks have already implemented this; it shows up somewhere in the build process as "use USB as STDIO" or something like that.  Note that a COM port implements a byte stream, so it doesn't preserver "packetization."
The other common thing is a HID interface, which does preserver "messages", and can be accessed with one of several PC-side application-level libraries (libusb.)  However, the maximum message size for a HID device is 64 bytes.

[DrG]

Ideally, the Pico would appear as a com port to the Visual Studio program. Something like a Human Interface Device to Com port since some of the sample USB device code is recognized by Windows.

To appear as a COM port, without writing windows-side drivers, the Pico should implement a CDC/ACM "device."  The Pico folks have already implemented this; it shows up somewhere in the build process as "use USB as STDIO" or something like that.  Note that a COM port implements a byte stream, so it doesn't preserver "packetization."
The other common thing is a HID interface, which does preserver "messages", and can be accessed with one of several PC-side application-level libraries (libusb.)  However, the maximum message size for a HID device is 64 bytes.

So, I am dealing with those issues as we speak. On a Win 7-64 if I run USB-Hello_world it (win 7) will recognize it and load usbser.sys EDIT: It will NOT automagically load USBser.sys, it sees it as a device and doesn't know what to do., but you, apparently need to do some virtual com port crap and such and such with Win. https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-driver-installation-based-on-compatible-ids

So, based on that minimal experience, I am thinking that a CDC device would not be as good as a legitimate HID dev. I can run the example dev_hid_composite and muck a bit with a mouse - no additional window-side coaxing needed.


I don't know, I need to do more studying and experimenting, but I appreciate anyone's help on the issues.

Edited again: I think I will try forcing it to do what I want with an .inf file. - will report results.

[NorthGuy]

So, I am dealing with those issues as we speak. On a Win 7-64 if I run USB-Hello_world it (win 7) will recognize it and load usbser.sys EDIT: It will NOT automagically load USBser.sys, it sees it as a device and doesn't know what to do., but you, apparently need to do some virtual com port crap and such and such with Win. https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-driver-installation-based-on-compatible-ids

Newer versions of Windows have built-in CDC drivers. HID is more universal, but communicating with a HID device requires a little bit more work on the PC side.