Raspberry Pi Pico

[Sudo_apt-get_install_yum]

I recently got a flightradar24 receiver and was a little surprised it came with a Raspberry Pi USB-C power supply.

It turns out it's actually got a Compute Module inside it doing the UI and internet communications duties.

https://www.flightradar24.com/blog/wp-content/uploads/2020/05/IMG_3936-2.jpg

Interesting!
The product looks simple, not sure why you’d need a CMx inside it.
The display seems to be a 480x320 LCD, something you could easily drive from a ESP32-S2 or other low-cost processor. The ESP32-S2 also has a built in Wi-Fi driver, so the system could pretty much be contained within one chip (assuming it fetches all data from the web).

Maybe I’m missing something

[bw2341]

https://www.flightradar24.com/about

As I understand it, Flightradar24 presents flight tracking data from ADS-B receivers in a global volunteer network.

https://www.flightradar24.com/build-your-own

If their build-your-own receiver project (based on a normal Raspberry Pi) came first, it makes perfect sense that their ready-made product would use a Raspberry Pi Compute Module.

Edit: typo...

[JOEBOBSICLE]

I found a freertos port that someone did

https://github.com/PicoCPP/RPI-pico-FreeRTOS

[rstofer]

OK, I finally got my Picos and, while I was at Sparkfun, I also bought the book "Get started with MicroPythonn on Raspberry Pi Pico".  The book is written for an absolute beginner with exceptional eyesight.  Damn the font is small!  These people have no respect for old people!

In any event, I went through a couple of examples including the always-required blinking LED and it all works as described.  The Thonny IDE does a decent job on trivial programs and I suspect it will be more than adequate for these boards.  FWIW, the argument to utime.sleep() can be a fractional real like 0.5 instead of the really slow 5 seconds shown in the example.

So, I have to hold down the 'boot' button while applying power.  That's kind of a PITA so I bought some USB power switches that will install inline with the USB-A to USB-Micro cable.  I won't know if that idea works for a couple of days.

https://www.amazon.com/gp/product/B07CG2VGWG

It all plays, now what?

ETA:  Using these switches, I can't get the board to enumerate.  I wonder if they lack data signals and only deal with power?

[Tagli]

I wonder how we can debug a Pico via SWD. Official documentation shows examples using another RPi (Pico or previous Linux SBC ones). Are there any other debug probes available? It would be great if we could use a ST-Link to debug Picos.

[ataradov]

I have not tried, but it should be possible to debug using any probe and debugger. It is just a standard Cortex-M0+ core. They have a weird switch to pick which core is exposed on the interface, but from a quick reading it looks like core 0 would be selected by default. So overall it should behave like a single core Cortex-M0+ device.

[westfw]

The book is written for an absolute beginner with exceptional eyesight.  Damn the font is small!  These people have no respect for old people!

Heh.  At least they seem to consistently made bad font choices!
See: https://github.com/raspberrypi/pico-feedback/issues/13

[westfw]

have not tried, but it should be possible to debug using any probe and debugger.

They have  SWDIO/SWCLK/GND at their "debug" connector.  The "V_target" that many probes want is ... inconvenient.

[yann]

Two high speed M0+ cores with segmented RAM and bus master / slave without wait cycles. Didn't read datasheet completely, don't know if all peripherals are available for both cores.

The CPUs are identical. The difference between them is only in the mailboxes and IDs. They even start together; the boot ROM (which is open source published on github) uses the ID register to suspend one, making that the secondary core. Some features, the interpolators and dividers, are intended as CPU extensions and have one instance for each CPU. The datasheet also notes that some IRQ routings are nonsensical, like having a CPU wake up when the mailbox has a message for the other CPU, which it can't access. You can also configure them to have different bus priority (equal by default).

Two bus bridges are minor choke points, to the fast (XIP, PIO, USB, DMA) and slow (pretty much the rest) peripherals. And the SIO bus is CPU-only. If I'm not mistaken, this actually means the DMA block has no access to GPIO; if you want DMA to or from IO pins, it will go through the PIO blocks. The PIO blocks are intended as the primary way to get deterministic timing, yet their timing functionality is limited to delays and level waits.

I find the design interesting, but not revolutionary. The PIO is not as good at timing as Xmos XS1 ports, not as good at bit level decisions as LPC804 PLUs, but fairly easy to understand from an assembly programmer's perspective.

[newbrain]

I have not tried, but it should be possible to debug using any probe and debugger. It is just a standard Cortex-M0+ core. They have a weird switch to pick which core is exposed on the interface, but from a quick reading it looks like core 0 would be selected by default. So overall it should behave like a single core Cortex-M0+ device.

Exactly, each core is on a different DP - not the usual configuration - plus there's a "recovery" DP.
See the discussion I started here.

The Picoprobe itself is the simplest probe you could imagine: it can read or write on the SWD lines, and change the SWD clock speed - end of story.
It uses a Vendor Specific USB interface class, instead of the more usual HID, so one needs a driver under Windows.
I just made a PR to at least give them an unique Serial Number on USB, and I'm trying to add support in pyOCD.

[basilskral]

Raspberry Pi Pico are out of stock everywhere
But what if we can make a simulation(virtual) version of RPi Pico? There is a site that allows writing a deep simulation for any electronics. But I don't know JavaScript. Can anyone help me with the simulation code for RPi Pico?
I have already made a circuit design for RPi Pico https://www.flux.ai/vasy_skral/raspberry-pi-pico-rev3-board-schematic. This site flux.ai allows doing this but I don't know, how!
I want to create my project based on RPi Pico WITHOUT real RPi Pico. It's sound crazy but it's worth to try!!

[tszaboo]

I wonder how we can debug a Pico via SWD. Official documentation shows examples using another RPi (Pico or previous Linux SBC ones). Are there any other debug probes available? It would be great if we could use a ST-Link to debug Picos.

Basically any debugger that supports SWD interface.
It is not RPi specific, it is a standard feature on Cortex microcontrollers.
I would suggest getting a Segger Jlink if you are serious about programming.

[exe]

I didn't read the whole thread, I'm here just to say I bought one (actually two) because I'm a Python developer and speaking Python is much easier for me than C/C++. I'm excited (but not too excited) about their programmable pins, but will see .

[exe]

Oh, yesterday I've made an emotional purchase, only to later read this thread and find out there is no internal flash and it requires external clock for usb to work (I hoped it can do usb with clock like some stm32). Anyway, still excited and hope to see discrete ICs and in smaller footprints.

[newbrain]

Oh, yesterday I've made an emotional purchase, only to later read this thread and find out there is no internal flash and it requires external clock for usb to work (I hoped it can do usb with clock like some stm32). Anyway, still excited and hope to see discrete ICs and in smaller footprints.

The pico board has got a 16 Mib QSPI flash and and a quartz.
I don't think you bought the bare chip?

[SiliconWizard]

Thinking of the SPI Flash, as I got it, code can run either from it or from RAM. (But obviously if you're putting code in RAM, it will limit the amount of RAM available for data.)

Even though it's QSPI, and - if I'm not mistaken - using XIP (execute in place), with some cache, running from Flash may cause timing issues? Sure you often have the same problem with similar MCUs with embedded Flash, but Flash access is likely much faster on the latter, so any cache miss on the RP2040 is likely to incur severely longer delays. Time-critical code should probably definitely go into RAM then. If you're using Micropython, I doubt you can control this? (Then again, Micropython is probably not for time-critical stuff?) But if you're using it bare-metal, this is something to think about.

[bogdan2014]

What already gets me excited about the Pico (compared to stm32 which I've been tinkering with):
- the C sdk seems nicely written, simple and not too bloated (unlike stm32's HAL for example)
- micropython support out of the box
- you don't need a programmer to program the thing
- excellent documentation
- huge adoption from the community, which is something that stm32 never had
- doesn't use the arduino IDE, they actually wrote their own C library which is sufficiently low level yet easy to understand

I hope that they'll come up with M3/M4 MCUs in the future, since the Pico is already a success.

[exe]

If you're using Micropython, I doubt you can control this? (Then again, Micropython is probably not for time-critical stuff?)

Good question. For sure micropython is not meant to compete with hard-core real-time OSes. The question is: is there a way to guarantee delays at all? One thing I did in "normal" Python is disabling automatic garbage collection, and run it scheduled. There is also, I think, a possibility to limit how many objects would be cleaned at once to avoid too long delays. But then again, there are no guaranteed deadlines except doing own measurements and hoping for repeatability of the result.

One of projects I have is to read from ADC at rate of 1k-4k samples. I wonder if I can do that with micropython. Another thing to check if I can use both cores in Micropython. Or, at least run python on one core, and simple C routines on another. Need to check on that.

- huge adoption from the community, which is something that stm32 never had

I think stm32 is one of the most adopted arm MCUs. It's just not the same community as Arduino community.

[tszaboo]

Thinking of the SPI Flash, as I got it, code can run either from it or from RAM. (But obviously if you're putting code in RAM, it will limit the amount of RAM available for data.)

Even though it's QSPI, and - if I'm not mistaken - using XIP (execute in place), with some cache, running from Flash may cause timing issues? Sure you often have the same problem with similar MCUs with embedded Flash, but Flash access is likely much faster on the latter, so any cache miss on the RP2040 is likely to incur severely longer delays. Time-critical code should probably definitely go into RAM then. If you're using Micropython, I doubt you can control this? (Then again, Micropython is probably not for time-critical stuff?) But if you're using it bare-metal, this is something to think about.

If you use micropython, you are constantly using the flash. There is a bunch of functions in the flash. Each command gets translated to some sort of byte code, and then it jumps to the already written code. Think of it like your code becomes a bunch of pointers, that tell the PC which function to execute next. For micropython, you pretty much need external flash, as the bare minimum is something like 1MB, without user code. And that's fine, external flash is really cheap nowadays.

[rstofer]

As I mentioned earlier, I bought the book along with the devices.  Today I got an email from Sparkfun stating that Raspberry Pi company had informed them that the book was not up to their standards and would be replaced.  All customers will be getting a revised book some time in February.

I have no idea what is wrong with the book as I haven't finished it.  I hope they fix the font but I expect they will be dealing just with technical problems.  We'll see...

[hamster_nz]

As I mentioned earlier, I bought the book along with the devices.  Today I got an email from Sparkfun stating that Raspberry Pi company had informed them that the book was not up to their standards and would be replaced.  All customers will be getting a revised book some time in February.

I have no idea what is wrong with the book as I haven't finished it.  I hope they fix the font but I expect they will be dealing just with technical problems.  We'll see...

I found this on a review for the book...

Another way to fix the error without changing the book is to update MicroPython for Pico so that machine.Pin.PULL_DOWN is the default value for the third argument (pull) of machine.Pin(pin, direction, pull). After all this is the machine module that you decide over. This would have the advantage of less typing.

I have not seen the book, but it looks like PULL_UP is the default, and the switches/buttons in the book are connected to the + power rail?

[rstofer]

In Reply 162, I linked to some USB power switches.  I can't get the board to enumerate with these switches.  I suppose it is possible they only deal with the power pins and ignore the data.  In any event, my great idea doesn't work.

[MK14]

I have not seen the book, but it looks like PULL_UP is the default, and the switches/buttons in the book are connected to the + power rail?

I guess they tried to write/create the book too quickly, leading to too many silly mistakes. Maybe too little time, to write it to difficult/short time-scales as well. Under these circumstances (Covid), it can also lead to man-power difficulties, in getting things like enough different people to proof read it in time, and things.

As regards the PICO itself, I'm debating, if I should wait until the next version comes out (assuming that happens, at some point), and it is more readily available (which I plan/probably going to end up doing), or going for the first release version ?

Although I'm generally pleased with the PICO, especially its price, and reasonable capabilities at that price point. They could really do with making more than 3 or 4, analogue input pins, available. Since it already has the A2D converter, and at least 3 or 4 pins, I can't really understand why it doesn't have more ?
As there are a number of GPIO pins, that (presumably) could also be added to the A2D's internal analogue multiplexer.
Unless there are special licencing (i.e. Arm Holdings) requirements/limits, or issues with Silicon, that I'm not aware of, making it problematic, expensive or causing supply(manufacturing)/yield problems or something ?

Wild speculation:
I suppose they had set themselves, very exacting chip die size per MCU area limits, in order to get the desired price points, fit in that particular IC package and have enough manufacturing capacity (bigger area = less chips per wafer, and more cost) etc.
Maybe that was part of the functionality that they wanted to fit in, but had to be left out, otherwise the $4 final price point, wasn't going to be met ?

[guenthert]

[..]
As regards the PICO itself, I'm debating, if I should wait until the next version comes out (assuming that happens, at some point), and it is more readily available (which I plan/probably going to end up doing), or going for the first release version ?

     At $4 what's there to debate?  Just skip a coffee at *$ once.  I doubt we'll see the next release this year or even the year thereafter.  The RPi evolved fairly quickly as for its intended use case it still benefits from better hardware.  The PICO can already do much more than most will use it for.  See how fast Arduino developed.

Although I'm generally pleased with the PICO, especially its price, and reasonable capabilities at that price point. They could really do with making more than 3 or 4, analogue input pins, available. Since it already has the A2D converter, and at least 3 or 4 pins, I can't really understand why it doesn't have more ?
As there are a number of GPIO pins, that (presumably) could also be added to the A2D's internal analogue multiplexer.
Unless there are special licencing (i.e. Arm Holdings) requirements/limits, or issues with Silicon, that I'm not aware of, making it problematic, expensive or causing supply(manufacturing)/yield problems or something ?
[..]

     No idea, but I suspect the subset of potential customers who need more than four analog inputs and can't be bothered with an external ADC or multiplexer is fleetingly small.  If you're serious about analog signals, then you'll need a separate ground anyway, as well as a good reference.

[MK14]

     No idea, but I suspect the subset of potential customers who need more than four analog inputs and can't be bothered with an external ADC or multiplexer is fleetingly small.  If you're serious about analog signals, then you'll need a separate ground anyway, as well as a good reference.

I suppose many of the Arduino crowd's projects, use I/O and not much or any analogue as such. So, I suppose it is not used, that often. It would be interesting to know, the percentage of usage of the PICO, who need or would benefit, from more/better analogue to digital capabilities, especially as regards number of available inputs.

The PICOs seem to be available for sale (in stock) again, now. But, there seems to be a max limit of 1 per order, and you have to add almost £3 to the order for postage. As it becomes more available and in-stock, my options for being able to easily buy one, will increase.
There is a supplier, who allow up to 25 and give free postage if order > £25, but they don't have them currently in immediate stock (seems to say >= from 8th February ), but they seem to have partly poor user feedback as sellers, so I'd prefer not to deal with them.

I expect to get at least one, but not at the moment. Ideally, I'm hoping the max of 1 per customer/order limits will be removed and/or more convenient sellers, such as Amazon and ebay, have them economically priced and available for sale. (As with other things, at sky high prices, such as, very approximately £15/£20 each, you can get them from lone individual sellers, on ebay/amazon. Which is a ripoff price.

If the maximum order limit of 1, is NOT removed, later. E.g. It doesn't seem to have been lifted with the Raspberry PI Zero things. That could be problematic, if anyone wants to use it, in a project that gets sold, small scale, and/or needs many boards to work.
E.g. A big LED display controller setup, with 10 or 20 boards, spread around, to control the flash patterns on the various banks of Leds.

I suspect/hope the buying limits, are only temporary.