Raspberry Pi Pico

[exe]

I suspect/hope the buying limits, are only temporary.

Is buying from Europe still an option? I bought two from here, they claim to have enough stock: https://www.kiwi-electronics.nl/raspberry-pi-pico-single-board?search=rp2040&description=true

One thing about rp2040 I don't get is their target market. Anyway, I'll be happy to use if their software is better than all that stm32 HALs. The only one that I liked was from Chibios, all the rest seemed to be unneccessary complex to comprehend. I think many libs try to make generic interfaces accommodating multiple MCU ranges, but at the end it becomes a very long reading with lots of trial-and-error even for a simple task, not to say something more complex like setting up peripherial clocks and DMA transfers (or may be I simply lack skills). CubeMX was very helpful when it worked, but it had bugs.

[MK14]

I suspect/hope the buying limits, are only temporary.

Is buying from Europe still an option? I bought two from here, they claim to have enough stock: https://www.kiwi-electronics.nl/raspberry-pi-pico-single-board?search=rp2040&description=true

One thing about rp2040 I don't get is their target market. Anyway, I'll be happy to use if their software is better than all that stm32 HALs. The only one that I liked was from Chibios, all the rest seemed to be unneccessary complex to comprehend. I think many libs try to make generic interfaces accommodating multiple MCU ranges, but at the end it becomes a very long reading with lots of trial-and-error even for a simple task, not to say something more complex like setting up peripherial clocks and DMA transfers (or may be I simply lack skills). CubeMX was very helpful when it worked, but it had bugs.

Thanks for the link!

Sadly, because of Brexit, and the simultaneous introduction of new import laws (EVERYTHING, even very cheap things have to have VAT added to them, even if from the EU). I'm trying to avoid buying from abroad, until the situation settles, and we know more accurately what happens, when we import things, and if they get hit with extra charges, even when VAT has already been paid.

I suspect, I will add PICO(s), to my next electronics (or similar) order (when possible(i.e. that supplier sells PICOs)/needed). Hopefully some of the suppliers, e.g. Digikey. Will sell PICO's. In the future and/or Amazon and/or others.

In the near future, I suspect availability/stock will be much better, and hopefully a bigger range of suppliers will have them. So, whenever I am already buying an order from them (hypothetically Digikey), I can get my first PICO(s).

[MK14]

There are still some big apparently unanswered question(s) surrounding the PICO. Do they intend to sell the individual chips, to consumers and small businesses ?
If so, will it be at a competitive price ?
I.e. Like STM32's and other MCUs, which you can buy relatively cheaply, and even cheaper, in slightly larger quantities.

Who will sell those chips ?
Will it just be the limited number of approved suppliers, who can put on idiosyncratic requirements, such as you can't buy more than 1, and/or you have to pay a relatively expensive delivery charge, even for just one small/tiny chip ?

To me, and maybe others. They are important questions. Because if the answers are mainly/fully NO. It makes the PICO unsuitable, for various applications. I.e. our own custom PCBs, if we don't want to put a custom module onto our PCBs.

The module is not the end of the world, but would make it unsuitable for very small projects and/or large scale ones (probably) and/or other problems, if you can't get/buy the bare chips.
I.e. Will the likes of Mouser/Digikey/LCSC etc, start selling them ?

[ataradov]

There is no way they do not sell bare chips. They will have to, otherwise there is no real point to any of this. You don't just design a chip and not sell it.

It takes time to setup distribution channels and build up inventory.

[MK14]

There is no way they do not sell bare chips. They will have to, otherwise there is no real point to any of this. You don't just design a chip and not sell it.

It takes time to setup distribution channels and build up inventory.

That makes a lot of sense, and it can/does take a long time to sort out new distributors. $3,000,000 to $4,000,000 (mentioned in earlier post(s) ) development cost, plus lots of hard work, blood, sweat, tears and hassle, plus a degree of business risk, I would guess.

The raspberry PI 4, loses out on a lot of application areas, because you would have to install and pay for, such a relatively large and expensive module, in your project. Many of which couldn't cope with the size or the cost.

So a massively cut down, but tiny IC chip version of the Raspberry PIs, does kind of make sense.

[rstofer]

If the maximum order limit of 1, is NOT removed, later. E.g. It doesn't seem to have been lifted with the Raspberry PI Zero things. That could be problematic, if anyone wants to use it, in a project that gets sold, small scale, and/or needs many boards to work.
E.g. A big LED display controller setup, with 10 or 20 boards, spread around, to control the flash patterns on the various banks of Leds.

I suspect/hope the buying limits, are only temporary.

Wrong country, I know, but there didn't seem to be a limit at Sparkfun so I ordered 4.  They are sold out until late February when they expect to get 5000+.  Sadly, there is going to be a limit of 100 per customer on this batch.  Maybe I'll have my wife place a second order...

https://www.sparkfun.com/products/17829

I have no intention of buying 100.  I'm still trying to figure out what to do with the first four.

[tszaboo]

There is no way they do not sell bare chips. They will have to, otherwise there is no real point to any of this. You don't just design a chip and not sell it.

It takes time to setup distribution channels and build up inventory.

The only fear that I have for the ICs, is that they might be more expensive than the modules.
We've seen this for the rPi foundation. The compute module is (was?) more expensive than the regular pi. Significantly more expensive. While the manufacturing cost is less, It doesnt have the IO, and the ethernet controller (some models). It's SMD only.
I hope I'm wrong.

[westfw]

There are still some big apparently unanswered question(s) surrounding the PICO.Do they intend to sell the individual chips, to consumers and small businesses ?

They have said YES to this one; repeatedly.https://www.raspberrypi.org/forums/viewtopic.php?t=299523

If so, will it be at a competitive price ?

Pricing, and distributor arrangements, have not been disclosed.
What do you consider "competitively priced"?  If it's $4, would that be awful?  (It's approximately similar to a SAMD21G18.  It'd also be similar to the Arduino vs bare AVR situation we have now, where you can buy Arduino pro-mini clones-from-China for only slightly more than you can buy bare ATmega328p chips...)

[MK14]

Wrong country, I know, but there didn't seem to be a limit at Sparkfun so I ordered 4.  They are sold out until late February when they expect to get 5000+.  Sadly, there is going to be a limit of 100 per customer on this batch.  Maybe I'll have my wife place a second order...

https://www.sparkfun.com/products/17829

I have no intention of buying 100.  I'm still trying to figure out what to do with the first four.

I think you are right, across other countries as well. I think by delaying my order for a few days (but it could be weeks). The supplier(s), will both have stock and allow the purchase of more than 1. It is only the initial shortage, that has caused the out of stock situation (and my hesitancy at buying into the first batch of them), that is causing this situation.

tl;dr
Hopefully shortly, more suppliers will have stock and allow >1 to by purchased. Then I can get some.

If so, will it be at a competitive price ?
Pricing, and distributor arrangements, have not been disclosed.
What do you consider "competitively priced"?  If it's $4, would that be awful?  (It's approximately similar to a SAMD21G18.  It'd also be similar to the Arduino vs bare AVR situation we have now, where you can buy Arduino pro-mini clones-from-China for only slightly more than you can buy bare ATmega328p chips...)

There were too many nested quotes, so I may have changed your post a bit, when I tidied it. Hopefully NOT.

I agree, even $4 (for the chip), would not be too bad. Unless we are talking about bigger volumes and/or very cost sensitive applications. Hopefully it will be cheaper in practice, and even better if they have discounted volume purchase quantities, as well. Especially if the volume discount points, are not too big, either. I.e. x100 and x1,000. Rather than needing to be hundreds of thousands or millions, which it is rumored to be, for some MCUs. Otherwise the MCU manufacturer doesn't want to deal with you.


Anyway, overnight (and a result of what has been said in this thread). I'm planning to get some (I'm patient), and will wait until the supply situation gets better.

Also, I think I've had the WRONG attitude about the PICO. The issue isn't exactly what you get for your $4, or me complaining about some missing features, such as > 3 or 4 A2D inputs.
Because SOFTWARE really is a massive thing. This product is likely to be VERY popular, and have a big and very significant following.
So, various pre-made hardware things are likely to become available (such as plug in mini push switch sets, with 4 to 8 buttons), Led panels with 10 (very approx quantity) RGB Leds, plug in speakers, etc etc.

Also a big software eco system.

Those are the really big factors. Not the exact price or functionality.

I.e. I could (the prices seem to have gone up hugely, recently) 6+ months ago, get a complete STM8 microcontroller board, assembled with header pins (loose/not-fitted) and mini USB power connector, for around 85p, if buying in multi packs of x2, x5 or x10.
E.g. x10 pack, for around £8.50 (including delivery), from China.

But it lacked a proper/full software eco system, information (although there was some, and more still if you searched for it), and wouldn't really work 100% properly, and could be cloned chips, etc etc.

So, $4 for a proper working, non-fake/cloned chip, with huge amounts of accurate information available for it. Many hardware devices (as upgrades) and software, such as multiple programming languages and example projects. Makes it a sort of 'Arduino on steroids', kind of system.

tl;dr
On reflection, this is looking more and more like a real bargain.

[exe]

I wonder if they already decided on the price of bare ICs, or they are looking for reception. I'd also love to see the roadmap, but I expect it to be top secret for the company. On the other hand, it's been only two weeks or so since they launched their very first MCU, but we already comparing them with bigger and more established players on the market. Isn't it amazing?

Concerning the price, I've seen some estimations on reddit how much a bare die would cost (based on speculation that one 40nm waffer from TSMC costs $2500 and they got 20k dies with very low defect rate), but this doesn't include packaging and distribution. Distributors love big margins (I think), but I hope it will be in $1-2 final "retail" price in single qty. It makes little sense to sell chips for more than the board with xtal and flash .

[tszaboo]

So I just got my boards, here is a short review:
- Board is only 1mm thick, I expected normal 1.6
- Setup to micropython was very easy and painless. You plug in the board, it has a link, download the file, write to Pi. It automatically reboots, and pops up as serial port. REPL connect with any speed. 1 minute and done. Good user experience
- LED on the board doesn't come on while doing this.
- Uses 0201 capacitors, for 99% of users there is not a chance to repair this. Not sure why, there is space on the board. Feels fragile.
- Board date code is 5020, middle of December
- There are no silkscreen on the top for the GPIO pins
- Board is tiny bit longer than 50mm, so you cannot place them into those handy 50mm long boxes.
- Help() on modules seems OK, help on functions is somewhat short and cryptic. I think we still need the reference guide. It is fair, since this all takes space from the flash. Maybe there should be different versions of the firmware for different levels of help
- Tab while typing works
- Command memory is 8 commands long
- There is no upip. This is somewhat bugging me.

[exe]

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.

[Tagli]

- Board is only 1mm thick, I expected normal 1.6

The official "Hardware design with RP2040" document mentions that this is due to USB signal integrity.

The board is nominally 1mm thick, but it could be manufactured with a thicker PCB, for example 1.6mm is very common, but you might run into difficulties with the USB characteristic impedance (discussed below).

[tszaboo]

- Board is only 1mm thick, I expected normal 1.6

The official "Hardware design with RP2040" document mentions that this is due to USB signal integrity.

The board is nominally 1mm thick, but it could be manufactured with a thicker PCB, for example 1.6mm is very common, but you might run into difficulties with the USB characteristic impedance (discussed below).

I'm quite sure they described it, and it is just something that was surprising for the first 10 seconds.
It is due to the two layer construction that results such wide traces for USB. They are also not taking any chances with the USB after failing with it.
I must say it is somewhat disappointing that they dont have a composite USB device, where you could access the file system and REPL at the same time.

[yann]

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.

You should be able to get at least 40MHz out of the PIO state machines. Also, I think you misread an example describing the required input clock for a particular baud rate as the limit; the datasheet also says "Bit rates are supported to 2MHz and higher" for the SPI.

The SPI block is fed from clk_peri, which can run at 12-125MHz. It divides the clock by 2-65024 (254*256) to generate SSPCLKOUT. So that gets us a max SPI clock rate of 62.5MHz (only in master mode). What actually works may be a different matter.

The PIO can run as fast as sysclk (nominal 125MHz, supposedly limited to 133MHz for CPUs if run through pll_sys), but SPI still involves the clock going up and down, so that only pushes it to 66MHz. DDR SPI can work around that limit.

The I/O buffers have configurable drive power which might help you if you need to push it (SLEWFAST and DRIVE in GPIOn registers).

https://github.com/raspberrypi/pico-micropython-examples/blob/master/pio/pio_spi.py

[exe]

I must say it is somewhat disappointing that they dont have a composite USB device, where you could access the file system and REPL at the same time.

I'll prove technical details why this is a bit unreliable below, but before that let me ask what's your workflow? May be thonny may help. It allows working with files stored on rp2040, as well having repl. The way it works is it uses repl to work with "remote filesystem". I used to have scripts to automate that on esp32 (upload new version of files, then run code), but I think I'll be fine with thonny for now.

Simultaneous access may also lead to concurrency issues when code tries to access half-written data. Most filesystems are not designed to be simultaneously used (unless in read-only mode). I think that was the reason why android devices stopped exposing their storage as mass storage. Instead, they use higher-level protocol such as MTP. Anyway, I did that in the past with filesystems, I either explicitly flushed caches after each write operation, or open filesystem in synchronous mode .

You should be able to get at least 40MHz out of the PIO state machines. Also, I think you misread an example describing the required input clock for a particular baud rate as the limit; the datasheet also says "Bit rates are supported to 2MHz and higher" for the SPI.
[...]
https://github.com/raspberrypi/pico-micropython-examples/blob/master/pio/pio_spi.py

This is fantastic, thank you! Going to give it a try. I find it fascinating that I can write asm code from python and have it automatically compiled for me. All that on an Arm Cortex-M0+ MCU!

[tszaboo]

I must say it is somewhat disappointing that they dont have a composite USB device, where you could access the file system and REPL at the same time.

I'll prove technical details why this is a bit unreliable below, but before that let me ask what's your workflow? May be thonny may help. It allows working with files stored on rp2040, as well having repl. The way it works is it uses repl to work with "remote filesystem". I used to have scripts to automate that on esp32 (upload new version of files, then run code), but I think I'll be fine with thonny for now.

Simultaneous access may also lead to concurrency issues when code tries to access half-written data. Most filesystems are not designed to be simultaneously used (unless in read-only mode). I think that was the reason why android devices stopped exposing their storage as mass storage. Instead, they use higher-level protocol such as MTP. Anyway, I did that in the past with filesystems, I either explicitly flushed caches after each write operation, or open filesystem in synchronous mode .

You should be able to get at least 40MHz out of the PIO state machines. Also, I think you misread an example describing the required input clock for a particular baud rate as the limit; the datasheet also says "Bit rates are supported to 2MHz and higher" for the SPI.
[...]
https://github.com/raspberrypi/pico-micropython-examples/blob/master/pio/pio_spi.py

This is fantastic, thank you! Going to give it a try. I find it fascinating that I can write asm code from python and have it automatically compiled for me. All that on an Arm Cortex-M0+ MCU!

I don't have a workflow yet for micropython.
Usually I work with notepad++ and putty. Or Jupyter notebook. on regular python.
I briefly tried it last year, on an ESP32 board. I liked the simplicity of python, but it was limited by the hardware. Namely it only had the serial port. I've tried this Thonny, but honestly, this looks like a janky thrown together software, that was written by 1 guy who really likes linux.
For now, I'm testing Circuitpython. This seems to enumerate as a drive, serial port and (as a test) HID device at the same time. I kinda like it.
It blows my mind, that with two cores, I can just upload a script to the flash drive, and un it on the second core, and keep using the interpreter at the same time, and (for example if it is a logging task) I can just read the results with a standard text editor.

[yann]

That's not because of the two cores - CircuitPython only uses one. It's MicroPython's async threading. On the ESP32, MicroPython can use both cores and talk to serial ports and network simultaneously. It just shares the same REPL.

[MK14]

Digikey, seem to have announced that they will be stocking it, for around $4, it appears on their system, already. They seem to be just waiting for stock to arrive.

https://www.digikey.com/en/products/detail/raspberry-pi/SC0915/13624793

Perfect solution for me. As I buy stuff from them, from time to time, so I can add PI PICO(s), to the order, and buy anything else I need for the PI PICO, at the same time.

UK Digikey link:
https://www.digikey.co.uk/product-detail/en/raspberry-pi/SC0915/2648-SC0915CT-ND/13684020

[ralphrmartin]

What seems to be missing here: libraries. I think one main reason for Arduino's success in general is the huge range of libraries. You can get code for driving an LCD, or reading a temperature sensor, and so on, without having to worry about details of I2C or other low level stuff. ARM's mBed also goes quite a way in offering libraries for a range of hardware. Raspberry Pi Pico doesn't have this by itself.

Now, it seems Arduino will be bringing out a Pico based board, and supporting the Raspberry Pi Pico. I suspect that may be the thing which actually makes the Raspberry Pi Pico take off. So, this seems llike a smargt move for the Raspberry Pi guys. But what's in it for the Arduino guys? Just hoping to take advantage of the RPi name? I can't see it being because of any technical advantage of the (current) Pico chip.

[rstofer]

Think about the Teensy 4.1 - a 600 MHz Cortex M7 with a bazillion features:
https://www.pjrc.com/store/teensy41.html

The first thing PJRC did was recreate the Arduino library functions so that the device can be programmed from the Arduino IDE and use existing source code (more or less).  The point was to have the same library features as the standard Arduino.  Those who want to move beyond can certainly do so but at least the base Arduino functionality is present from day one.

Clearly, this requires a different version of gcc (AVR vs ARM) but that stuff is all taken care of when Teensyduino is installed.  Afterwards it is as simple as choosing a 'board' to have the IDE choose the proper compiler tools.

It would be worthwhile for the RPi folks to recreate the Arduino library functions if they think their market is with beginning hobbyists.  I would suggest integrating the Pico with mbed but since mbed itself is owned by ARM, that may not happen.

Notice how there are several options for programming software.

[exe]

What seems to be missing here: libraries.

They support micropython, so they support micropython libraries. I was able to find all the code for popular display controllers, etc. Also, porting is not that difficult, if needed. I was able to port an arduino display driver (hardcoded with avr-specific optimizations) into stm32.

[exe]

I just ran ili9341 (this driver: https://github.com/jeffmer/micropython-ili9341), and did memory test. It shows 156kb after gc after I draw a full-screen rectangle. Disabling some fonts got me 170KB of RAM. Huh, now I remember why I wanted esp32 with 8MB* PSRAM...

I ran current test using standard SPI interface (machine.SPI), next time I'll try PIO as suggested earlier.

* several sources claim esp32 can directly address only 4MB of PSRAM.

[tszaboo]

What seems to be missing here: libraries. I think one main reason for Arduino's success in general is the huge range of libraries. You can get code for driving an LCD, or reading a temperature sensor, and so on, without having to worry about details of I2C or other low level stuff. ARM's mBed also goes quite a way in offering libraries for a range of hardware. Raspberry Pi Pico doesn't have this by itself.

Now, it seems Arduino will be bringing out a Pico based board, and supporting the Raspberry Pi Pico. I suspect that may be the thing which actually makes the Raspberry Pi Pico take off. So, this seems llike a smargt move for the Raspberry Pi guys. But what's in it for the Arduino guys? Just hoping to take advantage of the RPi name? I can't see it being because of any technical advantage of the (current) Pico chip.

I dont know what your experience was with libraries, but mine wasn't that great. Either you stick to the mainstream boards, and then you end up with an abundance of libraries. Then you spend time finding he one that actually does what you want. There are 17 libraries for SSD1306 OLEDs, that I can see. The description of the packages are cryptic help is non existent, and coding stile is all over the place. Are you supposed to call a function with a pointer? Create a class item? Call an init? Who knows.

Or you use a part which is not mainstream, and you end up with a library, written by someone in 2013, who didn't really understand programming, and there have been a dozen breaking changes since then. And it is only written to work on another board, not the one you have.

So no, it's not just plug and play.

For this, you should search for modules or packages,  they aren't called libraries.

[westfw]

It would be worthwhile for the RPi folks to recreate the Arduino library functions

Yeah, probably.  The Pico seems to have a pretty complete "SDK", but I'm essentially pretty tired of having a NEW SDK (HAL, Framework, etc) to learn for each new chip vendor. :-(  (this goes beyond the "many vendor HALs really suck", which we also tend to believe.  Even if they didn't suck, it would still be annoying to no COMMON abstraction.)