That datasheet is a thing of beauty. Things are written in plain english, diagrams are in color, there are inline code snippet examples in both asm and c most of which link to a file in a github repo that show how they fit in a larger program.
Seriously that is so many orders of magnitude better than any datasheet I’ve ever had to read before.
I’m curious why they chose a Cortex-M0. The M3 is a lot more powerful (there are a handful of quite annoying limitations in the M0 compared to the rest of M-class) and the cost difference is not great in a device whose price is measured in dollars, not cents. Both have off-the-shelf licenses available from Arm. With over 200 KiB of RAM, they’re well above the amount that a typical M0 has (the one I have comes with 16 KiB of SRAM, it’s pretty common to see M3s with 64 KiB and M5s with 256 KiB).
It definitely is, but I don’t think the difference is very much. It makes a big difference for 25 cent chips, but for $4 ones it’s likely to be in the noise. As I recall, the M0 is one cent to license (I don’t know if the M0+ costs more), I believe the M3 is something on the order of 10-25 (though I’ve no idea why I think that, it may be very wrong). I don’t think it’s worth saving 50 cents to go with M0 instead of M3. It would be worth saving $1.
Something else I thought of was it could be cheaper to manufacture on a fab due to transistor count, but I’m not sure how well that explanation holds up with the rest of the chip’s architecture.
A colleague recently pointed out that, on a modern process, the latest M0 core is the same size as a single transistor in the ARM1 chips. It’s also about the same transistor count as ARM1, which I find incredibly impressive given how much more powerful it is (larger instruction set, variable-length instruction encoding).
This is really exciting, especially at this price point. The datasheet is really excellent. A lot of products in this space, even if they have similar features on paper usually have crappy, badly documented toolchains, and often don’t have very good or detailed data sheets.
Considering it has a USB PHY onboard, I expect this will quickly become the go-to board for keyboard DIY-ers. Personally, I wonder if it would be possible to get it to show up as a keyboard and a mouse at the same time. That could be really useful for building a low-cost KVM (the “proper” kind that keep a keyboard/mouse device attached to all the clients at once, rather than physically changing the circuit paths of the USB connection when the input changes).
I’m especially interested to see what will happen with the “PIO state machines”, discussed in Chapter 3 of the data sheet. I imagine people will find all kinds of nifty use cases for these.
I wonder if it would be possible to get it to show up as a keyboard and a mouse at the same time
Why wouldn’t it be possible? E.g. LOGITacker on the nRF52 shows up as four endpoints – CDC-ACM console, mouse, keyboard, custom raw HID. If you have low-level USB access, you can do whatever you want. Having multiple endpoints is actually pretty common.
this will quickly become the go-to board for keyboard DIY-ers
Yeah, probably, due to the power of branding. But honestly I would stick to STM32 for things that don’t need wireless.
I have not personally worked with the STM32. Most of my experience is with AVR. I am curious why you would prefer the STM32?
Indeed as you say, it appears to support all 15 endpoints specified by full speed, so presumably it could identify as a composite device with two different HID endpoints. I have not worked very much with USB at such a low level though.
I have done it on the raspberry pi zero. It emulates a keyboard, mouse, network interface, and a block storage device all at the same time.
I believe it should definitely be possible with this new chip.
Also, I think you are spot on about the keyboard aspect. I am personally looking at using it for a homebrew mechanical keyboard project.
STM32 has a big ecosystem already, it’s like, the most popular brand of Cortex-M microcontrollers.
Sure, the Raspberry chip will have a decent ecosystem soon-ish too, but it will take time before there’s good bootloaders, support in RTOSes, full support in OpenOCD and probe-rs, etc. etc. But like, if you look past the branding, the only advantage it has is the PIO thing, which sure is cool, but probably not required for your next project :)
I see no reason to use Raspberry PI Pico instead of the existing Arduino/ESP/….
Users will be confused that Raspberry PI Pico is not Raspberry PI 1/2/3/4/W/…
The fact that’s its ARM means it has better support for languages that aren’t C, C++, or Arduino C++. I do agree about the naming though, maybe call it a Raspberry Tart.
We’ve had ARM microcontrollers (e.g. STM32-based boards) that were faster and more capable than Arduinos for years now, and my impression is that they haven’t taken off because they don’t have either the Arduino “brand” or the ecosystem. If this is true, then while the Raspberry Pi Pico will have an advantage due to the RPi brand, they won’t have the “real” Raspberry Pi ecosystem becase that runs on Linux (which this thing lacks).
It seems like it’ll be a bit of a challenge for the Pico to gain traction, but I’m rooting for them - I have a bit of a grudge against the Arduino folks for not including debugging in their IDE.
Except that Cortex M0+ has effectively a different instruction set to all the Thumb2 Cortex M and Cortex A CPUs. It’s basically ancient Thumb1, with just a handful of 32 bit Thumb2 instructions added. It also doesn’t run the traditional fixed length 32 bit ARMv6 instruction set that all previous Raspberry Pi software has been written for.
Sure, gcc and llvm can target it, but I’d bet money that most of those “languages that aren’t C, C++” with their own compiler or JIT don’t.
Sure, gcc and llvm can target it, but I’d bet money that most of those “languages that aren’t C, C++” with their own compiler or JIT don’t.
JIT? Maybe not. You could run a JIT written in BBC BASIC on the BBC Model B, but it’s not a great idea. Running a JIT with anything less than 4-8 MiB of RAM is usually a bad idea. Their own compiler? If it’s based on LLVM and is able to target things with such a small amount of memory, I don’t see why not. Things like the LLVM D or Pascal compilers should be able to target this without much effort.
Yeah seconding this. Having a straightforward CPU arch could do wonders for beginner materials (try figuring out the ESP32/Espressif stack for anything that doesn’t go through C/++)
Espressif licensed the ESP32’s architecture from Tensilica, and as a result the ISA documentation is only available under NDA. That’s kind of a roadblock to implementing new compilers. I’m sure there are reverse-engineered docs on the instruction set, but I would be surprised if they weren’t incomplete and buggy…
I think those other languages are not worth the trouble. They don’t even hold their advantages in the context of things like bit flipping and very limited resources.
Which percentage of people uses mocropython, nodemcu, etc instead of just uploading their own firmware written in c? I would guess very low.
I think this argument can be made for the range of memory Arduino typically targets, (often less than 4kb of ram) but with the Pico’s 264 kb it’s not a very good argument; the benefit of working in a language that actually Has Strings is worth the overhead of a few more kilobytes of space for most use cases.
Thx for mentioning this. When I glanced over the blog post, I totally missed this important point.
The PIO is actually really interesting from what I have read so far.
“It seems like every fruit company is making its own silicon these days, and we’re no exception.”
Nice.
Here is the data sheet:
https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.pdf
That datasheet is a thing of beauty. Things are written in plain english, diagrams are in color, there are inline code snippet examples in both asm and c most of which link to a file in a github repo that show how they fit in a larger program.
Seriously that is so many orders of magnitude better than any datasheet I’ve ever had to read before.
I totally agree. They really spent some quality time on it. I think this is going to help them sell a lot of these.
This looks even better then TI datasheets (which I found to be very readable for a software guy).
I’m curious why they chose a Cortex-M0. The M3 is a lot more powerful (there are a handful of quite annoying limitations in the M0 compared to the rest of M-class) and the cost difference is not great in a device whose price is measured in dollars, not cents. Both have off-the-shelf licenses available from Arm. With over 200 KiB of RAM, they’re well above the amount that a typical M0 has (the one I have comes with 16 KiB of SRAM, it’s pretty common to see M3s with 64 KiB and M5s with 256 KiB).
My bet it that it was the cheapest core to license
It definitely is, but I don’t think the difference is very much. It makes a big difference for 25 cent chips, but for $4 ones it’s likely to be in the noise. As I recall, the M0 is one cent to license (I don’t know if the M0+ costs more), I believe the M3 is something on the order of 10-25 (though I’ve no idea why I think that, it may be very wrong). I don’t think it’s worth saving 50 cents to go with M0 instead of M3. It would be worth saving $1.
That’s fair.
Something else I thought of was it could be cheaper to manufacture on a fab due to transistor count, but I’m not sure how well that explanation holds up with the rest of the chip’s architecture.
A colleague recently pointed out that, on a modern process, the latest M0 core is the same size as a single transistor in the ARM1 chips. It’s also about the same transistor count as ARM1, which I find incredibly impressive given how much more powerful it is (larger instruction set, variable-length instruction encoding).
This is really exciting, especially at this price point. The datasheet is really excellent. A lot of products in this space, even if they have similar features on paper usually have crappy, badly documented toolchains, and often don’t have very good or detailed data sheets.
Considering it has a USB PHY onboard, I expect this will quickly become the go-to board for keyboard DIY-ers. Personally, I wonder if it would be possible to get it to show up as a keyboard and a mouse at the same time. That could be really useful for building a low-cost KVM (the “proper” kind that keep a keyboard/mouse device attached to all the clients at once, rather than physically changing the circuit paths of the USB connection when the input changes).
I’m especially interested to see what will happen with the “PIO state machines”, discussed in Chapter 3 of the data sheet. I imagine people will find all kinds of nifty use cases for these.
Why wouldn’t it be possible? E.g. LOGITacker on the nRF52 shows up as four endpoints – CDC-ACM console, mouse, keyboard, custom raw HID. If you have low-level USB access, you can do whatever you want. Having multiple endpoints is actually pretty common.
Yeah, probably, due to the power of branding. But honestly I would stick to STM32 for things that don’t need wireless.
I have not personally worked with the STM32. Most of my experience is with AVR. I am curious why you would prefer the STM32?
Indeed as you say, it appears to support all 15 endpoints specified by full speed, so presumably it could identify as a composite device with two different HID endpoints. I have not worked very much with USB at such a low level though.
I have done it on the raspberry pi zero. It emulates a keyboard, mouse, network interface, and a block storage device all at the same time. I believe it should definitely be possible with this new chip. Also, I think you are spot on about the keyboard aspect. I am personally looking at using it for a homebrew mechanical keyboard project.
I don’t suppose you would happen to have the source code available?
My keyboard emulation is public: https://github.com/drudru/kb-key/blob/master/src/main.cpp
The USB OTG magic happens when you configure the OS to create the proper devices.
A good Google search to get you started is: “pi zero gadget mode”
Also, check out the PiKVM project on github
good luck 👍
Awesome. Thank you for the link!
STM32 has a big ecosystem already, it’s like, the most popular brand of Cortex-M microcontrollers.
Sure, the Raspberry chip will have a decent ecosystem soon-ish too, but it will take time before there’s good bootloaders, support in RTOSes, full support in OpenOCD and probe-rs, etc. etc. But like, if you look past the branding, the only advantage it has is the PIO thing, which sure is cool, but probably not required for your next project :)
I see no reason to use Raspberry PI Pico instead of the existing Arduino/ESP/…. Users will be confused that Raspberry PI Pico is not Raspberry PI 1/2/3/4/W/…
But yes, they will replenish their portfolio
The fact that’s its ARM means it has better support for languages that aren’t C, C++, or Arduino C++. I do agree about the naming though, maybe call it a Raspberry Tart.
We’ve had ARM microcontrollers (e.g. STM32-based boards) that were faster and more capable than Arduinos for years now, and my impression is that they haven’t taken off because they don’t have either the Arduino “brand” or the ecosystem. If this is true, then while the Raspberry Pi Pico will have an advantage due to the RPi brand, they won’t have the “real” Raspberry Pi ecosystem becase that runs on Linux (which this thing lacks).
It seems like it’ll be a bit of a challenge for the Pico to gain traction, but I’m rooting for them - I have a bit of a grudge against the Arduino folks for not including debugging in their IDE.
Except that Cortex M0+ has effectively a different instruction set to all the Thumb2 Cortex M and Cortex A CPUs. It’s basically ancient Thumb1, with just a handful of 32 bit Thumb2 instructions added. It also doesn’t run the traditional fixed length 32 bit ARMv6 instruction set that all previous Raspberry Pi software has been written for.
Sure, gcc and llvm can target it, but I’d bet money that most of those “languages that aren’t C, C++” with their own compiler or JIT don’t.
JIT? Maybe not. You could run a JIT written in BBC BASIC on the BBC Model B, but it’s not a great idea. Running a JIT with anything less than 4-8 MiB of RAM is usually a bad idea. Their own compiler? If it’s based on LLVM and is able to target things with such a small amount of memory, I don’t see why not. Things like the LLVM D or Pascal compilers should be able to target this without much effort.
Yeah seconding this. Having a straightforward CPU arch could do wonders for beginner materials (try figuring out the ESP32/Espressif stack for anything that doesn’t go through C/++)
Espressif licensed the ESP32’s architecture from Tensilica, and as a result the ISA documentation is only available under NDA. That’s kind of a roadblock to implementing new compilers. I’m sure there are reverse-engineered docs on the instruction set, but I would be surprised if they weren’t incomplete and buggy…
I think those other languages are not worth the trouble. They don’t even hold their advantages in the context of things like bit flipping and very limited resources.
Which percentage of people uses mocropython, nodemcu, etc instead of just uploading their own firmware written in c? I would guess very low.
I think this argument can be made for the range of memory Arduino typically targets, (often less than 4kb of ram) but with the Pico’s 264 kb it’s not a very good argument; the benefit of working in a language that actually Has Strings is worth the overhead of a few more kilobytes of space for most use cases.
Still much more powerful that the computer that brought people to the moon.
PIO is interesting, I wonder how it compares to ESP32’s ULP.
Thx for mentioning this. When I glanced over the blog post, I totally missed this important point. The PIO is actually really interesting from what I have read so far.
I was hoping for risc-v instead
Datasheet doesn’t mention max load on GPIO output pins.
Only 3 analog inputs and on a wiggly analog reference.
Personal opinion: GND pins should have been placed at least on pins 1,20,21,40.
Everything else seems perfect.
I wouldn’t mind if it also had WiFi. Maybe there will be a second version like with the Zero.
Arduino are producing the Nano RP2040 Connect using this Raspberry Pi silicon which provides wifi connectivity.
https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-the-world-of-microcontrollers/
Wow. At first glance this thing crushes the ~$30 Teensies I’ve been using for my home brew phone project. Amazing.
I’m not sure how it “crushes” a $20 Teensy 4.0 with five times the clock speed, dual issue full Thumb2, FPU, four times the RAM, …
Cheaper, yes. Better documentation, yes. Better capability – not even close.
Ooh, what’s this phone project?
I wrote up a few updates on this project if you’re still interested in reading about it: http://zacstewart.com/2019/06/17/im-making-a-phone.html
Thanks!