New kid on the block: Raspberry Pico
nutson
Posts: 242
https://www.raspberrypi.org/documentation/pico/getting-started/
Dual core, 8 smartpins, 6 multipled memory blocks, code execution from internal and external memory, $4
Dual core, 8 smartpins, 6 multipled memory blocks, code execution from internal and external memory, $4
Comments
There are plenty of other capable boards around, but the Pi Pico has the advantage of local suppliers, great support, and probably a huge user base. It should do well.
Saw the post, downloaded the data sheet and other info and looked it over. Pretty good bang for the price.
Has anyone seen mention of what volumes that $4 is for ?
Addit: No, wait, that's not the Chip price, that's the Pico-board price ?!
https://www.sparkfun.com/products/17829
Raspberry Pi Pico In stock DEV-17829 ROHS $4.00 Note: We have an order limit of 100 per customer on this product.
Wonder what the chip will cost
I find it rather interesting that SPF has already committed the new processor to their special ideas for boards. This tells me that they expect developers to create and make work their ideas on the Pico, and then take them to the SPF boards.
Very interesting.
---
Mascot arrived yesterday, still has head in box.
Strange.. There's a hoard of robots swimming to California, they plan on taking over a channel island and making it fly.
Hmmm?
You've already quoted them, SPF is the abbreviation for Sparkfun.
---
Mascot arrived yesterday, still has head in box.
Strange.. There's a hoard of robots swimming to California, they plan on taking over a channel island and making it fly.
How can commercial companies compete with a charity that pays no taxes and no profits to owners?
Their sample base board that the Pico board plugs/solders onto...
VGA
If you want VGA, then you need 17 pins! They steal one of the green pins from the 5+6+5 16bit, so it's 5xR + 5xG + 5xB + H + V, and the corresponding series resistors.
Buttons x3
Share the VGA R[0], G[0] and B[0] pins
SD
SD uses 4 or 6 pins if using QSPI.
UART
If you are only using SD in SPI mode then the 2 unused pins can be used for a UART.
Audio
Audio PWM uses 2 pins or I2S with an external chip uses 3 pins.
Available pins remaining
None!
Of course you do have the USB port, the QSPI Flash, and the Debug port on the Pico board too.
This is a designer's choice. The VGA is simply bitbanged, so you can do what you want, for example 222 as in P1 using 8 pins, nobody restrict it to 555 or 565 format
Being far from P2 capabilities it is still a powerful board for its price. If you need something between P1 and P2, this can be a good choice. 2 "cogs", 256k RAM, 8 smart pins, 1 ADC, 26 GPIO.
And in fact Sparkfun saw the writing on a wall someplace, and already have boards out to use when the Pico design idea finishes.
----
Mascot off on a longer weekend.
Swimmer bots on island.
Did you see the pico board comes on an smt reel?
But I expect the Raspberry name will mean that it will sell in huge volumes. And the support is excellent from the outset - something that the ESP32 initially lacked.
Past performance of the Raspberry Pi foundation suggests that there will be a Pico 2, Pico 3, Pico 4, ... coming over the next few years, no doubt fixing many of these shortcomings.
I've bought a couple of them to try out, but they'll have to wait as I'm currently playing with much more primitive 8-bit microcontrollers.
The RPi philosophy: don't add something which costs and only a few people will use. Need Wifi, buy an ESP. Need Wifi and the Pico capability, buy a Pico and an ESP. Want even more and wifi, buy a P2.... and an ESP.
As in P2. They added a fast library in ROM
But there ARE hardware dividers there, one per core, 8 cycles.
I think not only Pico. The Pico is a sandbox for something much bigger: Raspberry Pi 5 without Broadcom stuff onboard.
On the FLiP side you would be picking up 4 ADC ports, a couple of cores, some, possibly accessible extra memory, plus of course all the extra IO pins. The ADC pins, on the Pico, are 0-5V, while on the P2 they are 0-3.3V. It is a lot harder to find 3.3V voltage divider breakout boards, then the 5V ones.
I also think that on the Pico side, because it has micropython available, I think you could set up the Pico cores with multiprocessing, this I think, the Pico cores, would behave more like the P1 cogs.
Now, with all that said, I am not sure how you would get the two to communicate. I would imagine the hard work would have to be done on the Pico side, a master, and the FLiP as a slave, not sure if it could be the other way around.
On one of the P2 videos that I was watching, there were suggestions being made about an Edge card that would hold a FLiP module. I also think that, at some point Parallax will be coming up with an Edge breakout that will have all the IO pins available. Now, with a FLiP Edge card, which could have an RP2040 on it, that would make a heck of a combination.
Ray
I wonder how fast the 2040 ports can shift ?
The std UARTS seem to be limits to SysCLK/16, which means ~ 8MHz upper limit, but the RP2040 State engine PIO can support more bits, so could pair well with P2, for a custom-length interface.
With Xtals on both sides of a P2 <-> RP2040 link, 20b or 32b can be supported.
22b would support 16b payloads into a 64x16b memory array.
It's a real shame the USB side of RP2040 is only Full Speed, as there is room for a useful High Speed USB MCU.
They did HDMI, so hundreds of MHz as a transmitter. I dopn't know what fast it can receive.
Hello!
Back on the Hack-A-Day site concerning the Pico, it's still engendering comments. For my efforts, the state machine behind the I/O connectors did also attract me. But, as with the Pi and certainly the two Propeller chips, the power levels are 3v3 so that would cause some upset to the new user with the Pico.
Whole discussions exist on the Pi website regarding how to safely connect it to Logic. Whereas here we've already surmounted that issue. We shall see what does happen regarding the Pico. It has garnered an interesting following on the Sparkfun site, concerning new boards there. The A** people have made plans to create a new board in their nano form factor.
------
Mascot on tea break.
That would be a case for teensy 4.0 or 4.1 which will both do USB 2.0 for 480Mbps
I have been looking over the RP2040 and noticed a few things of interest...
133MHz and mostly 1 clock per instruction, making a core approx equivalent to a 266MHz P2 core/cog.
Has 2x 32b cores vs 8x 32b in P2.
264MB of SRAM vs 512KB but can be separated to a core vs shared egg-beater.
Boots from Flash vs boot from Flash or SD. Can XIP (execute) from Flash and supports QSPI mode.
30x GPIO including 4x ADC plus 6x for QSPI flash vs 64 GPIO including 64x ADC.
2x PIO programmable state machines for pins plus other in-built peripherals including USB FS vs 64 Smart Pins
On-chip 1V1 voltage regulator from the 3V3 supply and respectable current is a bonus.
QFN56 7x7mm vs QFP100 14x14.
But however...
A severe lack of registers (13 plus SP, LR & PC) are compounded by the fact that many instructions can only address registers 0-7. So nice to have 512 registers and the 512 in LUT can extend these too.
GPIO has registers to read/direction/enable/set/clear/toggle which address the whole 32 GPIO (similar to the DIR/OUT/IN registers on the P!/P2.
But the real downside is the atrocious way they are addressed - They are memory mapped at 0xd000_000 upwards which requires multiple instructions (no specialised instructions) to output to pins, and the lack of registers compounds the problem! Some of this can be overcome with the PIO but there are only two of these.
FWIW RPi has sold 700K Pico's with another 600K being built, and there are many RP2040 chips sold too. Boards and chips have restricted availability.
Last night tested the RPi Pico out with Linux Mint....
6 USB CDC serial ports working
Now to determine their max baud
USB CDC serial port results using TAQOZ as the test at the serial level, and Linux minicom at the PC level...
4MBd to the P2 works nicely
2MBd from the P2 works nicely
Faster to 8MBd works depending on pausing as the data is passed and rendered.
Hello!
Good to know. I've bought several versions, still grepping about for solutions. That after I'd managed to grok what makes the thing so special.
However I still haven't come up with a good project for either the Sparkfun versions or the Adafruit versions. Soon I think. Time is my specialty after all.....
Shame it is an ARM. The instruction set and the pin mapping is terrible compared to P2. But the price is right!
Only 12 registers and I/O has to be done indirectly because the mapping is not in the bottom page, but rather $0D00_0000
Tiny chip and fine pitch QFN
Peter and I both have boards and chips (RP2040).
If the UARTS have HW handshake lines, those could be enabled ?
What size FIFOs does it have, and what is the highest HW baud speed ?
???
8MBd is the highest we can set with minicom.
Don't know about handshake lines - not avail on the tested code.
RP2040 has inbuilt USB hw to help with the sw implementation. This hw+sw emulates a USB mass storage device in boot mode for code downloading code into the RP2040/pico.
For my personal taste it is the other way round: ARM/Pico is designed to be used together with a compiler. All the docu in the datasheet uses C. Even in µpython you can access all the hardware registers directly, while P2 carries the burden, that the customers have to know and use all these special assembler instructions in inline assembler.
What I do miss at the instruction set of ARM M0+ is an easy possibility to load a 32bit constant into a register.
Have you been able to find out, what happens, when both cores of RP2040 are running from flash and both have to fill their cache? At moment I do not dare to trust timing there.
From my point of view, the RP2040 is representing itself as a microcontroller. From this point of view, C is not the best language for this. Assembler IMHO is a requirement for obtaining the determinism. C just doesn’t cut it here. Now, when you look at the real uses of microcontrollers, there is a benefit of having some parts (deterministic) being undertaken in one core, while another (non-deterministic) executing in another core running a HLL eg C. This is why P1 and P2 are great micros. Now we are starting to see other multi core microcontrollers.
So, when you look at ARM for microcontrollers you see they are positioned (forget the ARM roots as that has been lost long ago) for HLL where the programmer is so far removed from the hardware with C that the swapping in and out of registers (by pushing and popping multiple registers) that the understanding of this overhead has been hidden.
So, when you want to do something unusual with the I/O there are just so many instructions being executed behind the scenes just to simply toggle a pin.
This is because you have to
And I don’t think it will be that long before we see another addition adding more memory and cores, and I/O.
It’s a shame it’s not RISC V but RPi has too much invested in ARM to switch, at least for some time.