Raspberry Pi Pico

B

bigpilot

Well-known member
https://www.raspberrypi.org/products/raspberry-pi-pico/

I will be switching because I absolutely hate working with the Arduino IDE on the Teensy 3.X and haven't been able to rig up my own ARM command line dev environment. I find it sad that PJRC hasn't been able to rig up a simple dev environment for power C / C++ users that's wholly seperate from the Arduino IDE.

The only thing the Pico lacks is an I2S interface which I need for a digital music player I've been wanting to build, but for all other uses the Pico is a perfect drop in replacement and much cheaper than Teensy.
 
Last edited:
Pico does indeed look really interesting. I've only just learned about it minutes ago. So far I don't know much about it. At only $4, it certainly is much cheaper! It's said to be Cortex-M0 at 133 MHz, so you can probably expect performance similar to Teensy LC but with ~3X the clock speed. It claims to have large RAM, but no mention of caching (M0 generally doesn't do caches) so my guess is that RAM gets used if you want code to run fast (much like ITCM on Teensy 4).

Regarding building code for Teensy using only command line, if you've already got the Arduino IDE and Teensyduino installed, all you need to do is go the {Arduino}/hardware/tools/avr/cores/teensy3 folder and run "make". If you hate Arduino and want to delete all the IDE's files, just look at the comments in the Makefile about which folders you need to keep.
 
Why did they do it so powerless
There is already so many similar mcu:s already.

I would see a raspberry pi zero based one with the same formfactor.
 
Marketing. Economy.
We will see better models someday.
Users will buy the better model. So they buy two, then.
Then the next model. etc etc etc.
You have to get customers hooked. With a simple to use thingy.

Of course they can do it better, but they start with a low end model. Perhaps because of the reason above.
Customers won't mind that the thing is slow. Because most of them don't know anything else.

Anyway - they have Python and c++, so both worlds - together with a API (which is needed because of the 2nd core, I guess).
Not too bad, for beginners.

That's another point. It is compatible to nothing. They use their own chip. The API is compatible to nothing.
So.. you have to buy Picos, if you want to keep your old things running. There is then no competition.



I bet if the release had been a little earlier, the board would have been under many Christmas trees.
 
I mean the raspberry pi zero is approx the same price but with 512MB ram which is very good when having large wavetables.

Then what it needs is just a easy to install non GUI Linux that boots in less than 2sec
 
@Paul: Maybe we should create an API for the 1176, that is compatible to this thingy.


.."Run your Pico programs with 1GHZ" :)

Or just now for T4.x?
Its early. The documented API is not that big. That will change, so its easier to start now, than later.
 
Last edited:
SparkFun has it and three Pre-Order variations: $10 Micro, $12 MMOD, $16 Thing+ using the RP2040 MCU.

Interesting speed but M0+, and "264 kB of embedded SRAM in 6 banks"

Shared code style might be nice - but their M0+ core likely symmetric and fully interchangeable with fewer shared or unique hardware blocks to contend with, though 6 RAM banks sounds awkward

The PICO can run code to SWD another PICO.
 
From their examples, an I2C Scanner:
Code: 
// These are any addresses of the form 000 0xxx or 111 1xxx
 bool reserved_addr(uint8_t addr) {
     return (addr & 0x78) == 0 || (addr & 0x78) == 0x78;
 }
  
 int main() {
     // Enable UART so we can print status output
     [URL="https://raspberrypi.github.io/pico-sdk-doxygen/group__pico__stdio.html#gaa4b8259ad78ad80831698fe027460364"]stdio_init_all[/URL]();
  
     // This example will use I2C0 on GPIO4 (SDA) and GPIO5 (SCL)
     [URL="https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__i2c.html#gad31793849a130033e94fa5b8e98a30a8"]i2c_init[/URL]([URL="https://raspberrypi.github.io/pico-sdk-doxygen/rp2__common_2hardware__i2c_2include_2hardware_2i2c_8h.html#a46204d38a512926541fd8bac2b62c720"]i2c0[/URL], 100 * 1000);
     [URL="https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__gpio.html#gaacde9174277ca40aa7b6fdd341bb2b8c"]gpio_set_function[/URL](4, GPIO_FUNC_I2C);
     [URL="https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__gpio.html#gaacde9174277ca40aa7b6fdd341bb2b8c"]gpio_set_function[/URL](5, GPIO_FUNC_I2C);
     [URL="https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__gpio.html#ga30a6733240f3d2e25e6b579b6c3902da"]gpio_pull_up[/URL](4);
     [URL="https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__gpio.html#ga30a6733240f3d2e25e6b579b6c3902da"]gpio_pull_up[/URL](5);
  
     printf("\nI2C Bus Scan\n");
     printf("   0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F\n");
  
     for (int addr = 0; addr < (1 << 7); ++addr) {
         if (addr % 16 == 0) {
             printf("%02x ", addr);
         }
  
         // Perform a 1-byte dummy read from the probe address. If a slave
         // acknowledges this address, the function returns the number of bytes
         // transferred. If the address byte is ignored, the function returns
         // -1.
  
         // Skip over any reserved addresses.
         int ret;
         uint8_t rxdata;
         if (reserved_addr(addr))
             ret = PICO_ERROR_GENERIC;
         else
             ret = [URL="https://raspberrypi.github.io/pico-sdk-doxygen/group__hardware__i2c.html#gaba4ea440285edec58eba507308c568c6"]i2c_read_blocking[/URL]([URL="https://raspberrypi.github.io/pico-sdk-doxygen/rp2__common_2hardware__i2c_2include_2hardware_2i2c_8h.html#a46204d38a512926541fd8bac2b62c720"]i2c0[/URL], addr, &rxdata, 1, false);
  
         printf(ret < 0 ? "." : "@");
         printf(addr % 16 == 15 ? "\n" : "  ");
     }
     printf("Done.\n");
     return 0;
 }

Does not look too far away ;)
 
I spent a couple hours reading parts of the datasheet. It's refreshing how well written it is, much nicer that what we get from NXP, Atmel/Microchip and ST. I probably read & skimmed less than 100 of the 636 pages.

My first impression is this is absolutely a SAMD21 killer.

I believe the best way to think about the memory is each Cortex-M0 processor gets 64K code and 64K data. Or if you use only 1 of the M0 cores, you can use the 4 banks of 64K for things like 64K code and 192K data, 128K code, 128K data, etc...

Looks like there is a 16K cache between the flash and processors. Maybe the flash can be usable for executing at some code?
 
manicksan said:
Why did they do it so powerless
There is already so many similar mcu:s already.

I would see a raspberry pi zero based one with the same formfactor.
Click to expand...

I'm actually the reason the Raspberry Pi foundation is releasing the Pi Pico.

A long time ago (two years IIRC) I wrote to the RPF that I wanted a DIL-format Pi for easier breadboarding. This in response to the release of the Rasperry Pi Zero.
 
Last edited:
I'd says it's just a firmware on the first pico that makes it a hardware-debugger-dongle.
Just as all the other dongles.
 
But it's sad that they did not actually put a "real" raspberry pi on that DIL.
And if the width was to narrow they could just make it 0.1inch wider as the 0.6inch don't really fit symmetrical on a breadboard anyway.

edit. this is a response to post#12
 
manicksan said:
But it's sad that they did not actually put a "real" raspberry pi on that DIL.
And if the width was to narrow they could just make it 0.1inch wider as the 0.6inch don't really fit symmetrical on a breadboard anyway.
Click to expand...

I was hoping for a full-fledged Linux DIL board, but it would've been much pricier and include superfluous overhead such as extra RAM and a MMU. Also, things like IPX (in place execution) would be more difficult to archieve.

What do you mean? In the picture on their website it's shown on a standard solderless breadboard.
 
bigpilot said:
https://www.raspberrypi.org/products/raspberry-pi-pico/

I will be switching because I absolutely hate working with the Arduino IDE on the Teensy 3.X and haven't been able to rig up my own ARM command line dev environment. I find it sad that PJRC hasn't been able to rig up a simple dev environment for power C / C++ users that's wholly seperate from the Arduino IDE.
Click to expand...

I also hate Arduino IDE, but there is a solution already. I strongly recommend taking a look at PlatformIO (Visual Studio Code addon). It is night and day compared to Arduino. I used various IDEs for various families (STM32, ESP32, Arduino, Teensy) but today I do all the work on ALL microcontrollers using PlatformIO.

With regards to Raspberry Pico I don't consider it competitive to Teensy 4, as RPico is terribly underpowered for today standards. If I wanted something so slow I would use STM32F103 blue pill that you can get for $1.50. Or new black pill STM32F411 for $2.5 - it is WAY better than Pico as it has FPU AND I2S.
 
On the picture it's symmetrical with two holes outside on each side but its really hard to find what width they are using.
I have looked at one of the PDF and on their demo board they are using a I2S device so it's possible in some way to connect a I2s device (maybe by using the programmable state machine unit)
16PWM is also good (if they are HW) to make a fan controller, or some robot using 16servos
 
Taken from the data sheet

The programmable input/output block (PIO) is a versatile hardware interface.
It can support a variety of IO standards, including:

• 8080 and 6800 parallel bus
• I2C
• 3-pin I2S
• SDIO
• SPI, DSPI, QSPI
• UART
• DPI or VGA (via resistor DAC)

PIO is programmable in the same sense as a processor. There are two PIO blocks with four state machines each, that can independently execute sequential programs to manipulate GPIOs and transfer data.
Unlike a general purpose processor, PIO state machines are highly specialised for IO, with a focus on determinism, precise timing, and close integration with fixed-function hardware.
Each state machine is equipped with:
• Two 32-bit shift registers – either direction, any shift count
• Two 32-bit scratch registers
• 4× 32-bit bus FIFO in each direction (TX/RX), reconfigurable as 8× 32 in a single direction
• Fractional clock divider (16 integer, 8 fractional bits)
 
Yup, was about to write the same :)
The PIO is quite interesting.
But at the end of the day it's just a replacement for real devices - and there are only two PIOs.
 
If their marketing will be as good as for Respber Pi #1,
it will not just be a SAMD killer, it probably will be a Arduino killer.. the pushiment for standstill.
The API looks very good and easy to use, and then, there is Python..
 
I didn't see any mention of flash encryption, firmware authentication, or other code security features. Kinda makes me wonder if they'll be able to sell these microcontrollers to traditional commercial users, or if it's just going to be for the hobby electronics market?

EDIT: as you can imagine... I've been thinking quite a lot these last couple weeks about how Teensy 4 will eventually support these security features while working on the stand-alone bootloader chip release.
 
You must log in or register to reply here.
Back
Top