Raspberry Pi Pico

[phil from seattle]

Yeah, a lot to like right off the bat. Perhaps the biggest loser is all the blue/black pill vendors.  Now we can get a cheap AND very consistent product.  I expect wifi coming soon so Espressif should be feeling the need to accelerate what ever they have next.

I ordered 3.  I also ordered the SFE Micromod version.  Uh, well, actually I pre-ordered it - Mid-Feb delivery.

My biggest complaint is I wish they had used ARM M3 instead of M0.  FP matters for my applications.

[rstofer]

I know next to nothing about Python and even less about microPython.  This is as good an opportunity to learn as any other.

As stated above, the documentation is amazing!

[Nominal Animal]

Maybe they needed two Cortex-M0 cores, because the Broadcom cores occasionally skip instructions due to hardware limitations?

[MK14]

Apparently, it comes for free on the front cover of the magazine (HackSpace). Available locally (Not sure if they mean UK, EU or Worldwide, local).

https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-now-on-sale/

Also, a PDF (direct download without needing to supply email, is possible), of the magazine.

Which includes an article (by the boss, himself  https://en.wikipedia.org/wiki/Eben_Upton  ) on why the product was produced, and who it was designed for. It even says how much the design cost to make (approx).

Direct PDF link (web page comes up initially, link on page):
https://hackspace.raspberrypi.org/issues/39/pdf

(FULLY direct link not supplied, scroll down, to see direct link on the above page).

[ataradov]

I'm so glad that traditional magazines are mostly dead. Who needs that 116 pages of full page pictures of random nonsense? Just print the damn article text in one coherent block. This could have been a regular blog post and the value would have been much higher. But no, we have to fish out information from random blobs of text randomly sprinkled around.

For the curious, the chip cost 3-4 million GBP to design. This is about what you expect for a design like this. You could probably make it a bit cheaper, but at much higher risks.

[newbrain]

Yes, but I personally am very impressed by this thing. It is a functional MCU (apparently, we'll have to see, of course) with excellent documentation. Sure, it lacks some peripherals, but so are many other MCUs on the market. There is nothing exceptional about it, but it is not bad, which is something you can only hope for for your first part.

Off-chip flash will be a more common approach in the future. It may be stacked dies without an external flash IC, of course. Flash is a pain to manufacture on the same die as the logic. And QSPI/Octal flash can be as fast as internal one, given wait states.

I have ordered four from a local distributor (electrokit), two for me and two for a friend of mine. But I'm a sucker for arm dev boards...
About the documentation I would like to object:
In the datasheet, the timing characteristics (max clocks, rise and fall times etc.) are either missing or buried in text...

The ADC is quite meh, but I do not care much.
This chip has some interesting features, which I find quite unique:
E.G.the SIO:

• HW spinlocks
• Fifos
• Divide coprocessor (8 cycles!)
• Interpolators!

A strange programmable PIO, can proabably cobble out an I2S from it.
Bit Set/reset/XOR register aliases (more useful than bitbanding, probably).

My major complaint would be  that (apart from Systick) there's only one other timer, with a fixed 1 MHz clock (and 64 bit, so with a rollover time of more than half million years!).
Really a bummer, partly compensated by presence of a number of PWM channels and a fractional counter linked to systick in the DMA engine for periodic transfers.

[hamster_nz]

I too ordered one - at least the price is good. However:

- No WiFi

- Shipped without headers is a big mistake

- The stacking scheme for 'packs' sucks. What if you need two packs? Should have used through-headers, with User I/O on top and system I/O below.

- Poor low power performance

- Minimal I/O - not even a few buttons?

- It's ARM - I know the Pi history, but I think RaspPi and ARM need to start to part ways.

Not sure who the target market is for a naked board focused on running MicroPython. I think the BBC micro:bit does it better for education & recreational use, and the ESP32 and STM32 does it better for 'makers'.

It is hard to think that anybody making anything but an MVP prototype use it as a module...

[ataradov]

Low power is something you address with iteration. A lot of it relies on the process, which requires cooperation of the fab. And for the first device, I guess they did not have much pull.

Number of timers is strange indeed. Timers are the most trivial peripheral, so not clear why save them. If anything bus matrix to accommodate more slaves would take more die area than the timer itself. But that is solved by making a multi-channel timer peripherals.

My CanaKit order just shipped out, so they are indeed in stock.

I would like to see how soon (if ever) they plan to make the ICs available and at what price. At this point I assume all the supply goes to the various board makers.

[MK14]

Its specification is confusing. Unless it is already planned for some application already, with defined I/O needs. But the article I linked to above, seems to say it was purpose designed for their own use.

Why only 3 (or 4) A 2 D converter pins ?
3 is such a small number. They went to all the trouble to give it a 12 bit 500KHz version, why not have more I/O pins, configurable to use it. Maybe at least 8 if not 12 or 16 ?

Because they were determined to make it for a selling price of $4, I suppose it limited their development budget, the number of pins on the device package, and whatever chip foundry requirements and/or pricing deals, applied.

(Speculation) Because the M0 core is the 'free' arm core (if I remember correctly, I know there are others, such as M3), its licencing requirements, may limit the chip features, so it doesn't compete too badly with the paid licence, better arm chips, or they would have had to pay higher licence fees, or something, maybe.

The guaranteed availability, until at least 2028, is a very big deal to some people. Because it means they can design with it, without needing to worry about the MCU disappearing, and a very expensive and time-consuming hardware change, and software rewrite.

That point alone, could allow it to be used in all sorts of manufactured items.

tl;dr
I agree, it does seem to have too few I/O pins, timers and some other stuff. Even in its lowly entry level segment.
But it still seems an interesting device, especially at that price point.

I also wonder why it is dual cored. I bet most people won't bother to use the second core. But maybe some tricky embedded applications, can benefit from a second core, to make the timing/interrupt management easier.

[tszaboo]

- No RTC

Datasheet[1] for the chip says it has a RTC, section 4.8.

[1]: https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.pdf

I mean no RTC on the board. A MCU without RTC would be really 1990.

- Sleep current is more than 1 mA for the board, and 180uA for the micro alone

The chip datasheet says

Note also that DORMANT does not halt PLLs. To avoid unnecessary power dissipation, software should power down PLLs before entering the DORMANT state, and power up and reconfigure the PLLs again after exiting.

However from what I can see the "hello_dormant" example used for the 180uA number in the power consumption table does not power down the PLLs?

So maybe potential for a bit better deep sleep performance.

The datasheet is not very clear about the power consumption of the part, I'm also missing the current vs voltage charts.
The datasheet looks like the typical crap that is done by programmers. They write all the registers states and spend 1000 pages on digital crap that nobody cares about, and they dont even measured the ADC's performance. It's 9 bit "simulated". What a joke.

I'm not sure this product really makes sense.

I think it does. It's now the cheapest micropython development board. It is in the price range, even if it gets copied, it won't matter. Because maybe you can get a copy of it from Aliexpress for 2.5 or the original from Amazon for 4. And it has a brand recognition with hobbyist. And they are a serious company, unlike Adafruit or Sparkfun.
Like try to do a business presentation for investors. Try telling them: I built a smart meter based on the Feather Huzzah itsy bitsy, I would like you to invest into my company.

If I buy from China, I have to wait 3-4 weeks or longer, or the package does not arrive at all
I never know what I will really get (counterfeit BluePill, Atmega328PB ...), often lack of description and documentation.
I can buy Rasspebry Pi Pico locally with good support.
Price is not always the most important thing.

Quite some products from SeeedStudio are available from Mouser. Not $4 though, but still considerably cheaper than their Western counterparts.

Took you 3 posts, to turn a microcontroller release into a political discussion. What is wrong with you, seriously.

[ataradov]

Unfortunately ADC and generally analog characteristics even in "grown up" devices often based on simulation. Fully characterizing a device is no small task, so they may simply not have complete characterization data. Have you seen real datasheets for brand new devices (not iterations of the same family)? They often have information missing. And those are done by companies that released hundreds of devices before that.

I just opened a datasheet for STM32G031x4/x6/x8, a relatively new device. Entire ADC section is under a footnote "1. Guaranteed by design". This is the same exact thing as "based on simulation", just different wording. Although accuracy characteristics are indeed "1. Based on characterization results, not tested in production."

Dual cores is to debug the dual core process. As was mentioned before, possibly for the second core running a wireless stack.

Again, people are missing the point. This type of device is typically not released by regular vendors, it just remain internal. And I for one want to encourage this behaviour. If anything this lets more community feedback into the final design. Imagine if ST released preliminary versions of their parts with crazy pinouts and then changed the design based on the feedback? We may end up with parts where all bits of the parallel bus are at least on the same side of the package. Imagine how great that would be.

Will I ever design that into a real product? No, I'm not crazy. Is it good enough to test drive on Arduino and other product that ultimately don't matter? Sure, why not?

For a big company it makes no sense to release this kind of product, as it will require a lot of support. RPi basically relies on community support, so it works. Nobody is forcing you to use that chip. Having one more vendor on the market is a good thing.

I would give this at least a year. If after a year the datasheet is not expanded to contain a whole lot more characterization data, then yes, we can safely say that they are not serious about it.

[JohnnyMalaria]

FFS an 133MHz CM0+, with off chip flash. That deceptively large SRAM is probably going to store all the program code in order not to choke the cache-less CPU.

Also the price . $4 in China gets you an FPGA board or a Linux-capable MPU board.

Yeah, but it's available from a US supplier immediately which means I can get it in a couple of days instead of <random number if at all> days and, unlike most complex electronic items I've bought from China, actually come with instructions and *support*.

[mairo]

Any one knows what would be the price of the RP2040 IC itself?

[artag]

Have ordered two to play with but not exactly enamoured of the idea of a Pi dev environment and I'm hopeful there'll be a version that works on a 'larger' machine

I had no problem installing their SDK on my desktop machine. In fact it was much smaller and faster than many recent toolchains.

[PCB.Wiz]

The MCU side is somewhat limited.

Looking into timer capture, there seems to be after-thought modes in PWM, but very vague if that data can flow back up the DMA ?
It is also annoying to see a 32b MCU with 16b timers in 2021 !!!

[westfw]

Not sure who the target market is for a naked board focused on running MicroPython.

Adafruit sells about a dozen different boards that fit that description...

133MHz CM0+, with off chip flash. [it will] choke the cache-less CPU.

It apparently has 16k of cache.  Just because the ARM M0 spec doesn't include cache, doesn't mean a vendor can't add it to their memory systems.  Especially if it's essentially read-only memory...  Performance tests will tell, I guess.
ESPxxx chips have been running from QSPI flash for quite a while now, with few complaints about performance loss.

Number of timers is strange indeed. Timers are the most trivial peripheral, so not clear why save them.

It does sound strange.  Perhaps they've observed that vendors have so many vastly different timers, usually of several types on a single chip (SAMD has TC and TCC, each with a bunch of modes, RTC, PIT, SysTick), that few people actually use.  (Look at all the Arduino users that pretty much use a Systick and PWM only...)

A 64bit 1MHz timer meshes well with Python requirements, I guess.

I found the "USB 1.1 port" particularly confusing.  Granted that most "USB 2" peripherals in microcontrollers don't go any faster than 12Mbps (USB 1.1 "Full Speed") anyway, I don't even recall what other differences there are between 1.1 and 2.0...

[MK14]

It does sound strange.  Perhaps they've observed that vendors have so many vastly different timers, usually of several types on a single chip (SAMD has TC and TCC, each with a bunch of modes, RTC, PIT, SysTick), that few people actually use.  (Look at all the Arduino users that pretty much use a Systick and PWM only...)

A 64bit 1MHz timer meshes well with Python requirements, I guess.

On reflection, and because of what you just said. Maybe they went for a simplified timer system, to make it much easier for their target market (Hobbyists, makers and the education sector), to use and easily/quickly understand the timer system.
If it was given 24 timers, of a very complicated type, with many different modes of operation, and a 2,000 page technical manual, just to explain the timer subsystem, and how to generate PWM waveforms. It would tend to NOT be so easy to use/understand etc.

So, maybe it was an intentional design decision ?

[ataradov]

This is a wrong way to approach this. If you see that others are having issues with complexity of the timers, you don't remove the timers, you remove the complexity. Even having having 5-6 SysTick-like timers with literally 3 registers each (control/compare/count) would be great. And everyone would be able to understand that.

[hamster_nz]

I've been reading up on the PIO (Programmable I/O), which can have fractional clock dividers.

The Pico has four 9-intruction state machines, with a shared 32-instruction program space, FIFOs fed/feeding DMA and a few other little tricks.

My guess it was in reaction to how un-ideal the Raspberry Pi was as driving smart LEDs, which seem to be it's major use 

[MK14]

This is a wrong way to approach this. If you see that others are having issues with complexity of the timers, you don't remove the timers, you remove the complexity. Even having having 5-6 SysTick-like timers with literally 3 registers each (control/compare/count) would be great. And everyone would be able to understand that.

I agree with you. But I was just speculating on why they may have gone that route.
Really, I think 32 bit timers, make it easier than 16 bit ones. Because you don't have to mess with clock divider chains, shared between multiple timers, or worry about timer overflows, for most applications.
Although even a 32 bit timer, runs out (overflows), after around 5 or 6 minutes, if it can toggle at the full 133MHz clock rate.

Another possibility (far fetched), is that it has got much more complicated timers, but they haven't worked properly (or weren't finished in time). So, in the first revision of the silicon, they have been left out and/or disabled, until they can be fixed in a later mask/revision of the chip.

[MK14]

I've been reading up on the PIO (Programmable I/O), which can have fractional clock dividers.

The Pico has four 9-intruction state machines, with a shared 32-instruction program space, FIFOs fed/feeding DMA and a few other little tricks.

My guess it was in reaction to how un-ideal the Raspberry Pi was as driving smart LEDs, which seem to be it's major use 

I presume the intention is for library code/functions to be created/released, so that although it sounds like it is too complicated for outright beginners to use directly themselves. They can use those library code/functions, to perform tasks, such as interfacing to a particular type of programmable Led, or whatever needs a complicated driving pattern, at somewhat high speed.

A bit like the extensive Arduino eco-system, which includes things like various LCD display driver routines, and all sorts of other stuff. Hence allowing beginners, who probably wouldn't know how to write such complicated software, can just use the appropriate library (calls), in their code.

[aheid]

I presume the intention is for library code/functions to be created/released

Well yeah they've already done a few examples, surely there will be more.

https://github.com/raspberrypi/pico-examples/tree/master/pio

[MK14]

I presume the intention is for library code/functions to be created/released

Well yeah they've already done a few examples, surely there will be more.

https://github.com/raspberrypi/pico-examples/tree/master/pio

I hadn't looked at their software/library releases, just some of the documentation and one or more reviews. But that is really good, if they have already released such code. As it can be used as-is, or used as examples, to write your own 'drivers' for that new hardware feature.
I suspect, some people may use it to do a number of weird and wonderful projects, with it.

One already demonstrated, is a complete working (emulated) BBC microcomputer (it even does the later/improved 'master' version), complete with graphics output, all done by this new Pico thing (and the available expansion hardware bits, like SD card readers or whatever their setup needed).
It is amazing that it can do it, especially the real time graphics output to a screen. Here is a video of it in operation:

[kjw]

The CircuitPython examples for PIO, so far, are in https://github.com/adafruit/Adafruit_CircuitPython_PIOASM/tree/main/examples

I'm still a bit puzzled as to where the Pico board and RP2040 fit in but time will tell. The BBC micro:bit V2 is cheap, easy to use and very capable for beginners.

The HackSpace interview with Eben Upton is commendable for not shying away from a difficult question at the end.

HS: But why? You can buy a bunch of chips off the shelf and design a board and have a great product.

EU: You want to make something perfect, and in this space, there's no way to make a perfect thing without making your own silicon. There's a reason why the other fruit company does this, right? It's not that they want to save money. They have margin to burn. If they thought they could make great Macs using Intel chips, they wouldn't make their own silicon just for the vanity. They do it because it's what it takes to make a great product, and this is the same thing.

That's the privilege of working at Raspberry Pi. You get to watch a great team do great engineering. And they've done it again with the Pico!

Readers can judge for themselves whether that comparison with and analysis of Apple's approach is accurate and complete.

It would have been interesting if the interview covered whether the RPxxxx series will be profitable over time. If it isn't then a vald question is whether the millions spent on development could have been better used in other directions to fulfill the Foundation's mission. If it is then it could be useful to support the Foundation in the future.

Does anyone have any thoughts on whether they would have considered RISC-V as the basis for the chips?

[westfw]

Quote>we have commissioned optimised floating-point functions from Mark Owen, author of the popular Qfplib libraries; these are substantially faster than their GCC library equivalents



I’m happy to see Mark’s code get some more traction, especially since the gcc m0 code is so sucky (non-existent, afaik, causing the generic C floating point code to be used instead...)