Shop Learn
New kid on the block: Raspberry Pico — Parallax Forums

New kid on the block: Raspberry Pico

https://www.raspberrypi.org/documentation/pico/getting-started/
Dual core, 8 smartpins, 6 multipled memory blocks, code execution from internal and external memory, $4
«1

Comments

  • Only four analog pins, and it only (by default) uses the voltage regulator as a reference for the analog conversions.

    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.
  • kwinnkwinn Posts: 8,693
    nutson wrote: »
    https://www.raspberrypi.org/documentation/pico/getting-started/
    Dual core, 8 smartpins, 6 multipled memory blocks, code execution from internal and external memory, $4

    Saw the post, downloaded the data sheet and other info and looked it over. Pretty good bang for the price.
  • jmgjmg Posts: 14,847
    edited 2021-01-21 21:09
    nutson wrote: »
    https://www.raspberrypi.org/documentation/pico/getting-started/
    Dual core, 8 smartpins, 6 multipled memory blocks, code execution from internal and external memory, $4

    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 :)
  • Hello!
    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.
  • jmgjmg Posts: 14,847
    Hello!
    I find it rather interesting that SPF has already committed the new processor to their special ideas for boards.
    Who is SPF ?

  • jmg wrote: »
    Hello!
    I find it rather interesting that SPF has already committed the new processor to their special ideas for boards.
    Who is SPF ?

    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.
  • Cluso99Cluso99 Posts: 18,012
    Interesting BUT...

    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.

  • pik33pik33 Posts: 1,110
    edited 2021-01-22 13:35
    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.

    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.
  • For what I have seen on their website, it is indeed a powerful board. However, do you want one that's capable of flying your technology someplace? (Both Prop boards make me think of multiple engine aircraft,) Or do you want one that's capable of going into space, their regular Pi boards for example? Or even these Pico boards, who are everything the current family of ARM boards do, but better?

    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.
  • There's an article with someone bit-banging DVI with the pico. https://github.com/Wren6991/picodvi
  • Cluso99Cluso99 Posts: 18,012
    edited 2021-01-22 17:14
    Must be nice to sell in such large volumes...
    Did you see the pico board comes on an smt reel?
  • Compared to the similarly-priced ESP32, it's lacking in many ways: No WiFi, no Bluetooth, no floating point, no hardware integer divide, only a 32-bit hardware integer multiply, ...

    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. :smile:
  • pik33pik33 Posts: 1,110
    edited 2021-01-22 20:11
    No WiFi, no Bluetooth,

    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.
    no floating point

    As in P2. They added a fast library in ROM
    no hardware integer divide

    But there ARE hardware dividers there, one per core, 8 cycles.
    there will be a Pico 2, Pico 3, Pico 4,

    I think not only Pico. The Pico is a sandbox for something much bigger: Raspberry Pi 5 without Broadcom stuff onboard.

  • K2K2 Posts: 684
    The Pico is a sandbox for something much bigger: Raspberry Pi 5 without Broadcom stuff onboard.
    This is fascinating info. If the Pico's programmable I/O state machine is an indication of cleverness to come, I'm all (⌐■_■)
  • RsadeikaRsadeika Posts: 3,631
    After thinking about this RPi Pico, I think this would be a very good companion for the P1 FLiP module.

    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
  • pik33pik33 Posts: 1,110
    Communicate with fast serial. P1 can use video shifter to transmit. Receiving will be slower as it has to be bitbanged in P1. 2040 can use its smart pins to implement a transmit/receive protocol.
  • jmgjmg Posts: 14,847
    pik33 wrote: »
    Communicate with fast serial. P1 can use video shifter to transmit. Receiving will be slower as it has to be bitbanged in P1. 2040 can use its smart pins to implement a transmit/receive protocol.

    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.
  • pik33pik33 Posts: 1,110
    I wonder how fast the 2040 ports can shift ?

    They did HDMI, so hundreds of MHz as a transmitter. I dopn't know what fast it can receive.
  • The programmable state machine for I/O is what really piqued my interest, otherwise I wouldn't have thought too much of it.
  • Buck RogersBuck Rogers Posts: 2,062
    edited 2021-01-25 14:29

    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.

  • hinvhinv Posts: 1,064

    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.

    That would be a case for teensy 4.0 or 4.1 which will both do USB 2.0 for 480Mbps

  • Cluso99Cluso99 Posts: 18,012

    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.

  • Cluso99Cluso99 Posts: 18,012

    Last night tested the RPi Pico out with Linux Mint....

    6 USB CDC serial ports working :)

    Now to determine their max baud :)

  • Cluso99Cluso99 Posts: 18,012

    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.

  • @Cluso99 said:
    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.....

  • Cluso99Cluso99 Posts: 18,012

    @"Buck Rogers" said:

    @Cluso99 said:
    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).

  • jmgjmg Posts: 14,847

    @Cluso99 said:
    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.

    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 ?

  • Cluso99Cluso99 Posts: 18,012

    @jmg said:

    @Cluso99 said:
    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.

    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.

  • @Cluso99 said:

    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 :(

    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.

  • Cluso99Cluso99 Posts: 18,012

    @"Christof Eb." said:

    @Cluso99 said:

    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 :(

    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

    • PUSH R1
    • load the pin base address LDA R1,#$0D
    • shift this with SHL R1,#24
    • now perform the output as H/L/invert/etc instruction
    • POP R1

    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.

Sign In or Register to comment.