Author Topic: Raspberry Pi Pico  (Read 36363 times)

0 Members and 1 Guest are viewing this topic.

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Raspberry Pi Pico
« on: January 21, 2021, 10:32:51 am »
The new flexible $4 microcontroller board from Raspberry Pi
https://www.raspberrypi.org/products/raspberry-pi-pico/
Quote
Designed by Raspberry Pi, RP2040 features a dual-core Arm Cortex-M0+ processor with 264KB internal RAM and support for up to 16MB of off-chip Flash. A wide range of flexible I/O options includes I2C, SPI, and — uniquely — Programmable I/O (PIO). These support endless possible applications for this small and affordable package.

Former username: NANDBlog
 
The following users thanked this post: MK14, Microdoser

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #1 on: January 21, 2021, 10:51:11 am »
What I like:
- Castellations for SMD mounting
- Micropython
- price, if it is not waporware like the zero
- Doesn't use that terrible Italian IDE
- Not just an LDO, but an SMPS
- Based on the model number, other types/memories are coming
- Remap of the communication ports
- Recovery mode with USB, no matter what you do

What I dont like:
- Microusb instead of USB C
- Sleep current is more than 1 mA for the board, and 180uA for the micro alone <- This should be 10 uA max for the micro, and 100 for the board.
- No wireless
- No RTC
- Only 4 ADC pins, only 3 on the board

Probably it will be insanely popular.
« Last Edit: January 21, 2021, 11:06:17 am by NANDBlog »
Former username: NANDBlog
 
The following users thanked this post: hans, thm_w, newbrain

Offline kjw

  • Newbie
  • Posts: 3
  • Country: gb
Re: Raspberry Pi Pico
« Reply #2 on: January 21, 2021, 11:04:46 am »
There's a lot on this new board in HackSpace Issue 39.

I'm still reading about it but so far I observe:

  • Amazing price which makes it very accessible.
  • Likely to have a huge amount of supporting material, there's already a MicroPython book for it.
  • Not much on the Pico board so needs extras unlike say the BBC micro:bit.
  • Pimoroni already have a huge range of interesting looking products to work with it.
  • Two M0 cores - curious decision as that means no hardware floating point, limited language support, hard to use both of them especially for beginners.
  • PIO look very useful.
  • ADC is limited to three pins on Pico (four on the RP2040) - that's a bit of a shame if it's used on existing boards.
  • No DACs (an incaccessible one tucked away inside the SAR ADC)
  • Interesting concept of using one board to debug another using SWD known as "the Picoprobe".
  • Unintentionally fragments the microcontroller-for-beginners world.
  • Thankfully does not maintain the Raspberry Pi tradtion of unlabelled pins, the underside of the Pico board has the pin names on!
  • May not be available with headers pre-soldered onto the board.

We could all add the usual I'd like it to have A, B, C features but most of those are expensive and they've clearly tried to keep this around 4 USD.
« Last Edit: January 21, 2021, 11:55:20 am by kjw »
 
The following users thanked this post: newbrain

Offline gmb42

  • Regular Contributor
  • *
  • Posts: 222
  • Country: gb
Re: Raspberry Pi Pico
« Reply #3 on: January 21, 2021, 11:05:35 am »
And other vendors doing their own boards\systems with the RP2040:

Arduino:

AdaFruit Feather: https://www.adafruit.com/feather2040
AdaFruit ItsyBitsy: https://www.adafruit.com/itsybitsy2040

SparkFun Micromod:
SparkFun Thing Plus: https://www.sparkfun.com/products/17745
SparkFun Pro Micro: https://www.sparkfun.com/products/17717

Pimoroni PicoSystem: https://shop.pimoroni.com/products/picosystem
Pimoroni other pico products: https://shop.pimoroni.com/?q=pico

Cytron Maker Pi Pico: https://www.cytron.io/p-maker-pi-pico

h/t to CNX Software
 
The following users thanked this post: Fred27, aheid, kjw

Offline aheid

  • Regular Contributor
  • *
  • Posts: 236
  • Country: no
Re: Raspberry Pi Pico
« Reply #4 on: January 21, 2021, 12:35:40 pm »
FFS an 133MHz CM0+, with off chip flash.
The specifications[1] says it has 2MB on-board QSPI Flash.

[1]: https://www.raspberrypi.org/products/raspberry-pi-pico/specifications/
« Last Edit: January 21, 2021, 12:38:00 pm by aheid »
 

Offline aheid

  • Regular Contributor
  • *
  • Posts: 236
  • Country: no
Re: Raspberry Pi Pico
« Reply #5 on: January 21, 2021, 12:37:29 pm »
 

Offline up8051

  • Regular Contributor
  • *
  • Posts: 167
  • Country: pl
Re: Raspberry Pi Pico
« Reply #6 on: January 21, 2021, 12:38:39 pm »
Also the price :palm:. $4 in China gets you an FPGA board or a Linux-capable MPU board.

If I buy from China, I have to wait 3-4 weeks or longer, or the package does not arrive at all
I never know what I will really get (counterfeit BluePill, Atmega328PB ...), often lack of description and documentation.
I can buy Rasspebry Pi Pico locally with good support.
Price is not always the most important thing.
 
The following users thanked this post: Warhawk, tim_, LennertP

Offline aheid

  • Regular Contributor
  • *
  • Posts: 236
  • Country: no
Re: Raspberry Pi Pico
« Reply #7 on: January 21, 2021, 12:51:13 pm »
Hence the "off chip" part.

:palm: clearly I need more sleep!
 

Offline aheid

  • Regular Contributor
  • *
  • Posts: 236
  • Country: no
Re: Raspberry Pi Pico
« Reply #8 on: January 21, 2021, 12:56:45 pm »
in order not to choke the cache-less CPU
Reading the datasheet it says
Quote
2.6.3.1. XIP Cache
The cache is 16 kB, two way set-associative, 1 cycle hit. It is internal to the XIP subsystem, and only affects accesses to
XIP flash, so software does not have to consider cache coherence, unless performing flash programming operations

So it's not entirely cache-less, though I have no idea how far it'll get ya.
 
The following users thanked this post: blueskull, newbrain

Offline aheid

  • Regular Contributor
  • *
  • Posts: 236
  • Country: no
Re: Raspberry Pi Pico
« Reply #9 on: January 21, 2021, 01:28:20 pm »
- Sleep current is more than 1 mA for the board, and 180uA for the micro alone
The chip datasheet says
Quote
Note also that DORMANT does not halt PLLs. To avoid unnecessary power dissipation, software should power down PLLs before entering the DORMANT state, and power up and reconfigure the PLLs again after exiting.
However from what I can see the "hello_dormant" example used for the 180uA number in the power consumption table does not power down the PLLs?

So maybe potential for a bit better deep sleep performance.
 

Online Berni

  • Super Contributor
  • ***
  • Posts: 3602
  • Country: si
Re: Raspberry Pi Pico
« Reply #10 on: January 21, 2021, 01:32:38 pm »
It is internal to the XIP subsystem, and only affects accesses to
XIP flash, so software does not have to consider cache coherence, unless performing flash programming operations
Um, there goes your timing determinism.

The timing determinism is already out the window in the "main thread" as soon as you use interrupts anyway, just stick the interrupt service routines into RAM and its sorted. Those typically have a minimum of code in it, so they tend to also result in not that much machine code to store.

This sort of execution directly from external flash has gotten popular with other vendors too, for example NXP has whole lines of micro-controllers with no internal flash. They claim they are doing this because doing large amounts of flash on a fab process optimized for making CPUs is not very efficient and ends up taking up a lot of die area.

 

Offline Ice-Tea

  • Super Contributor
  • ***
  • Posts: 2433
  • Country: be
    • Freelance Hardware Engineer
Re: Raspberry Pi Pico
« Reply #11 on: January 21, 2021, 02:15:51 pm »
Would have been 100% more awesome if it had even the poorest possible WiFi capability...

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 2781
  • Country: it
Re: Raspberry Pi Pico
« Reply #12 on: January 21, 2021, 02:17:47 pm »
"daul core cortex M0+"
why?
why?
WHY?

also HOW?
 
The following users thanked this post: HB9EVI

Offline Cliff Matthews

  • Supporter
  • ****
  • Posts: 1877
  • Country: ca
    • General Repair and Support
Re: Raspberry Pi Pico
« Reply #13 on: January 21, 2021, 03:42:01 pm »
Cheap! Just ordered one  :popcorn:  Perhaps I'll try running the built-in MCU's as a dual channel ARB..
 

Offline CJay

  • Super Contributor
  • ***
  • Posts: 3881
  • Country: gb
Re: Raspberry Pi Pico
« Reply #14 on: January 21, 2021, 03:42:59 pm »
Would have been 100% more awesome if it had even the poorest possible WiFi capability...

Given the Pi foundation's history I'd suspect there's a WiFi version in the works.

Have ordered two to play with but not exactly enamoured of the idea of a Pi dev environment and I'm hopeful there'll be a version that works on a 'larger' machine
 

Online Monkeh

  • Super Contributor
  • ***
  • Posts: 7140
  • Country: gb
Re: Raspberry Pi Pico
« Reply #15 on: January 21, 2021, 03:46:02 pm »
Would have been 100% more awesome if it had even the poorest possible WiFi capability...

Given the Pi foundation's history I'd suspect there's a WiFi version in the works.

Complete with awkward, half-documented, likely full of security holes Broadcom firmware.
 
The following users thanked this post: hans, newbrain, bd139, HB9EVI, I wanted a rude username

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 6846
  • Country: fr
Re: Raspberry Pi Pico
« Reply #16 on: January 21, 2021, 04:29:05 pm »
The new flexible $4 microcontroller board from Raspberry Pi
https://www.raspberrypi.org/products/raspberry-pi-pico/
Quote
Designed by Raspberry Pi, RP2040 features a dual-core Arm Cortex-M0+ processor with 264KB internal RAM and support for up to 16MB of off-chip Flash. A wide range of flexible I/O options includes I2C, SPI, and — uniquely — Programmable I/O (PIO). These support endless possible applications for this small and affordable package.

Yeah, saw that as well.

I'm not sure this product really makes sense.
Looks like the Raspberry foundation wants to get into the microcontroller territory... but given the absolutely HUGE offering in that market, I don't see the point. Really. It has nothing to offer compared to what already exists, not even the price.

IMO, the RPis are powerful but are not adapted for the kind of low-level tasks a MCU allows, so a smarter product IMHO would have been a new RPi with an associated MCU, a decent SDK and good linux drivers to communicate between the main SOC and the additional MCU. Alternatively, it could be a new RPi with an associated FPGA on board.

Another smart move would be to finally design a product that is fully open, with either an open-source (we can dream) SOC, or at least a SOC that is fully documented and doesn't require to sign with your blood to get access to the docs.

Just my 2 cents.
 

Online ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 405
  • Country: gb
    • Me
Re: Raspberry Pi Pico
« Reply #17 on: January 21, 2021, 04:54:50 pm »
I don't get the point of this (unless its to make money off the RPi name, and I doubt that given their charitable aims).
There are any number of small boards similar to this, of one kind and another, that already run micropython, or beat this price, or have better peripherals, or better processors, or are better in some other way. There are boards from manufacturers or Ardiuno if you want brand names, or anonymous ones if you want a very low price. In short, I dont see what perceived gap in the market (or educational space, if you are coming from a charitable rather than commercial angle) this is trying to fill.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #18 on: January 21, 2021, 05:25:04 pm »
Guys, calm down. This is the same things as SiFive FE310. They did a test chip and decided to release it to public to make some R&D money back. Normal vendors do this all the time, but don't release half baked stuff.

It is a cool toy, nobody expects anyone to use it in real projects. But hobbyists, as usual, will find a way to use the device to its fullest performance level. And those projects will show the bottlenecks that could be improved in the next design.

The next iterations would improve on the design, not everything at once.

And for the first product, they are doing everything right. Out of the gate, they have great documentation. I really wish "real" part datasheets looked like this.
« Last Edit: January 21, 2021, 05:26:56 pm by ataradov »
Alex
 
The following users thanked this post: newbrain, I wanted a rude username

Offline dcarr

  • Regular Contributor
  • *
  • Posts: 110
Re: Raspberry Pi Pico
« Reply #19 on: January 21, 2021, 05:31:50 pm »
Speculation on the dual cores:

Many wireless ICs have dual cores---one for application code and the other for the wireless side of the house.

Seems to fit in nicely with the theory that this is/was a test chip on the road to a wireless MCU product.
 

Offline Syntax Error

  • Frequent Contributor
  • **
  • Posts: 584
  • Country: gb
Re: Raspberry Pi Pico
« Reply #20 on: January 21, 2021, 05:49:26 pm »
My jury is out on this... Maybe they slashed costs so far, all they built was a Microbit with one LED? Harsh? This segment of the microcontroller maker market is so over saturated right now. Not one brand is able to deliver a knock out product. Instead, the market is a PacMan like maze of look-alikes and their clones. (zigbees are the ghosts btw)

So how are we meant to mount this; on a breadboard, on a veroboard, on a custom breakout motherboard? Nice they put the GPIO silks on the under-side then. So which way is up? And 2MB of flash not 4? That would double the price.

However, being able to use as a USB host might just edge this into my shopping basket. WTF it's cheaper than a decent quality USB lead. Sold.

In future, pehaps sacrifice one spi channel for use with an ESPxxxx. There is certainly space where that big Pi logo is for a Wifi or BLE subsystem, plus aerial. But then it might start to look like a NodeMCU. Or a Yun. Or a Zigbee.
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 8305
  • Country: us
Re: Raspberry Pi Pico
« Reply #21 on: January 21, 2021, 06:05:58 pm »
I have no idea why I ordered 4 Pico's and the book but it should be entertaining.

I don't know if the board/chip has a future but look at the ATmega328P.  Who would have thought that chip would become as popular as it has.  It really has nothing special to recommend it.
 
The following users thanked this post: hans, newbrain, Jacon

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #22 on: January 21, 2021, 06:08:59 pm »
I have no idea why I ordered 4 Pico's and the book but it should be entertaining.
I ordered a few before they run out, as typical for RPi. I have no real use for them, but hey, it is a new part from a new vendor, let's check it out.

I also  expect that programmable I/O controller may be used in some creative ways.

And unlike new cool parts I want to try from Chinese vendors, this one has a real datasheet that is already better than anything else in the industry.
« Last Edit: January 21, 2021, 06:10:59 pm by ataradov »
Alex
 

Online ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 405
  • Country: gb
    • Me
Re: Raspberry Pi Pico
« Reply #23 on: January 21, 2021, 06:18:06 pm »
The next iterations would improve on the design, not everything at once.

As they say, you don't get a second chance to make a first impression.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #24 on: January 21, 2021, 06:22:55 pm »
As they say, you don't get a second chance to make a first impression.
Yes, but I personally am very impressed by this thing. It is a functional MCU (apparently, we'll have to see, of course) with excellent documentation. Sure, it lacks some peripherals, but so are many other MCUs on the market. There is nothing exceptional about it, but it is not bad, which is something you can only hope for for your first part.

Off-chip flash will be a more common approach in the future. It may be stacked dies without an external flash IC, of course. Flash is a pain to manufacture on the same die as the logic. And QSPI/Octal flash can be as fast as internal one, given wait states.
Alex
 
The following users thanked this post: Jacon

Offline phil from seattle

  • Frequent Contributor
  • **
  • Posts: 934
  • Country: us
Re: Raspberry Pi Pico
« Reply #25 on: January 21, 2021, 06:27:49 pm »
Yeah, a lot to like right off the bat. Perhaps the biggest loser is all the blue/black pill vendors.  Now we can get a cheap AND very consistent product.  I expect wifi coming soon so Espressif should be feeling the need to accelerate what ever they have next.

I ordered 3.  I also ordered the SFE Micromod version.  Uh, well, actually I pre-ordered it - Mid-Feb delivery.

My biggest complaint is I wish they had used ARM M3 instead of M0.  FP matters for my applications.
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 8305
  • Country: us
Re: Raspberry Pi Pico
« Reply #26 on: January 21, 2021, 06:39:22 pm »
I know next to nothing about Python and even less about microPython.  This is as good an opportunity to learn as any other.

As stated above, the documentation is amazing!
« Last Edit: January 21, 2021, 06:44:02 pm by rstofer »
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2719
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #27 on: January 21, 2021, 07:58:02 pm »
Maybe they needed two Cortex-M0 cores, because the Broadcom cores occasionally skip instructions due to hardware limitations? :-DD
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #28 on: January 21, 2021, 08:38:10 pm »
Apparently, it comes for free on the front cover of the magazine (HackSpace). Available locally (Not sure if they mean UK, EU or Worldwide, local).

https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-now-on-sale/

Also, a PDF (direct download without needing to supply email, is possible), of the magazine.

Which includes an article (by the boss, himself  https://en.wikipedia.org/wiki/Eben_Upton  ) on why the product was produced, and who it was designed for. It even says how much the design cost to make (approx).

Direct PDF link (web page comes up initially, link on page):
https://hackspace.raspberrypi.org/issues/39/pdf

(FULLY direct link not supplied, scroll down, to see direct link on the above page).
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #29 on: January 21, 2021, 08:48:00 pm »
I'm so glad that traditional magazines are mostly dead. Who needs that 116 pages of full page pictures of random nonsense? Just print the damn article text in one coherent block. This could have been a regular blog post and the value would have been much higher. But no, we have to fish out information from random blobs of text randomly sprinkled around.

For the curious, the chip cost 3-4 million GBP to design. This is about what you expect for a design like this. You could probably make it a bit cheaper, but at much higher risks.
Alex
 
The following users thanked this post: bd139

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1141
  • Country: se
Re: Raspberry Pi Pico
« Reply #30 on: January 21, 2021, 09:30:57 pm »
Yes, but I personally am very impressed by this thing. It is a functional MCU (apparently, we'll have to see, of course) with excellent documentation. Sure, it lacks some peripherals, but so are many other MCUs on the market. There is nothing exceptional about it, but it is not bad, which is something you can only hope for for your first part.

Off-chip flash will be a more common approach in the future. It may be stacked dies without an external flash IC, of course. Flash is a pain to manufacture on the same die as the logic. And QSPI/Octal flash can be as fast as internal one, given wait states.
I have ordered four from a local distributor (electrokit), two for me and two for a friend of mine. But I'm a sucker for arm dev boards... :palm:
About the documentation I would like to object:
In the datasheet, the timing characteristics (max clocks, rise and fall times etc.) are either missing or buried in text...

The ADC is quite meh, but I do not care much.
This chip has some interesting features, which I find quite unique:
E.G.the SIO:
  • HW spinlocks
  • Fifos
  • Divide coprocessor (8 cycles!)
  • Interpolators!
A strange programmable PIO, can proabably cobble out an I2S from it.
Bit Set/reset/XOR register aliases (more useful than bitbanding, probably).

My major complaint would be  that (apart from Systick) there's only one other timer, with a fixed 1 MHz clock (and 64 bit, so with a rollover time of more than half million years!).
Really a bummer, partly compensated by presence of a number of PWM channels and a fractional counter linked to systick in the DMA engine for periodic transfers.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #31 on: January 21, 2021, 09:55:58 pm »
I too ordered one - at least the price is good. However:

- No WiFi

- Shipped without headers is a big mistake

- The stacking scheme for 'packs' sucks. What if you need two packs? Should have used through-headers, with User I/O on top and system I/O below.

- Poor low power performance

- Minimal I/O - not even a few buttons?

- It's ARM - I know the Pi history, but I think RaspPi and ARM need to start to part ways.

Not sure who the target market is for a naked board focused on running MicroPython. I think the BBC micro:bit does it better for education & recreational use, and the ESP32 and STM32 does it better for 'makers'.

It is hard to think that anybody making anything but an MVP prototype use it as a module...
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #32 on: January 21, 2021, 10:15:41 pm »
Low power is something you address with iteration. A lot of it relies on the process, which requires cooperation of the fab. And for the first device, I guess they did not have much pull.

Number of timers is strange indeed. Timers are the most trivial peripheral, so not clear why save them. If anything bus matrix to accommodate more slaves would take more die area than the timer itself. But that is solved by making a multi-channel timer peripherals.

My CanaKit order just shipped out, so they are indeed in stock.

I would like to see how soon (if ever) they plan to make the ICs available and at what price. At this point I assume all the supply goes to the various board makers.
Alex
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #33 on: January 21, 2021, 10:32:14 pm »
Its specification is confusing. Unless it is already planned for some application already, with defined I/O needs. But the article I linked to above, seems to say it was purpose designed for their own use.

Why only 3 (or 4) A 2 D converter pins ?
3 is such a small number. They went to all the trouble to give it a 12 bit 500KHz version, why not have more I/O pins, configurable to use it. Maybe at least 8 if not 12 or 16 ?

Because they were determined to make it for a selling price of $4, I suppose it limited their development budget, the number of pins on the device package, and whatever chip foundry requirements and/or pricing deals, applied.

(Speculation) Because the M0 core is the 'free' arm core (if I remember correctly, I know there are others, such as M3), its licencing requirements, may limit the chip features, so it doesn't compete too badly with the paid licence, better arm chips, or they would have had to pay higher licence fees, or something, maybe.

The guaranteed availability, until at least 2028, is a very big deal to some people. Because it means they can design with it, without needing to worry about the MCU disappearing, and a very expensive and time-consuming hardware change, and software rewrite.

That point alone, could allow it to be used in all sorts of manufactured items.

tl;dr
I agree, it does seem to have too few I/O pins, timers and some other stuff. Even in its lowly entry level segment.
But it still seems an interesting device, especially at that price point.

I also wonder why it is dual cored. I bet most people won't bother to use the second core. But maybe some tricky embedded applications, can benefit from a second core, to make the timing/interrupt management easier.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #34 on: January 21, 2021, 10:33:51 pm »
- No RTC
Datasheet[1] for the chip says it has a RTC, section 4.8.

[1]: https://datasheets.raspberrypi.org/rp2040/rp2040_datasheet.pdf

I mean no RTC on the board. A MCU without RTC would be really 1990.

- Sleep current is more than 1 mA for the board, and 180uA for the micro alone
The chip datasheet says
Quote
Note also that DORMANT does not halt PLLs. To avoid unnecessary power dissipation, software should power down PLLs before entering the DORMANT state, and power up and reconfigure the PLLs again after exiting.
However from what I can see the "hello_dormant" example used for the 180uA number in the power consumption table does not power down the PLLs?

So maybe potential for a bit better deep sleep performance.

The datasheet is not very clear about the power consumption of the part, I'm also missing the current vs voltage charts.
The datasheet looks like the typical crap that is done by programmers. They write all the registers states and spend 1000 pages on digital crap that nobody cares about, and they dont even measured the ADC's performance. It's 9 bit "simulated". What a joke.

I'm not sure this product really makes sense.
I think it does. It's now the cheapest micropython development board. It is in the price range, even if it gets copied, it won't matter. Because maybe you can get a copy of it from Aliexpress for 2.5 or the original from Amazon for 4. And it has a brand recognition with hobbyist. And they are a serious company, unlike Adafruit or Sparkfun.
Like try to do a business presentation for investors. Try telling them: I built a smart meter based on the Feather Huzzah itsy bitsy, I would like you to invest into my company.

If I buy from China, I have to wait 3-4 weeks or longer, or the package does not arrive at all
I never know what I will really get (counterfeit BluePill, Atmega328PB ...), often lack of description and documentation.
I can buy Rasspebry Pi Pico locally with good support.
Price is not always the most important thing.

Quite some products from SeeedStudio are available from Mouser. Not $4 though, but still considerably cheaper than their Western counterparts.
Took you 3 posts, to turn a microcontroller release into a political discussion. What is wrong with you, seriously.

Former username: NANDBlog
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #35 on: January 21, 2021, 10:51:56 pm »
Unfortunately ADC and generally analog characteristics even in "grown up" devices often based on simulation. Fully characterizing a device is no small task, so they may simply not have complete characterization data. Have you seen real datasheets for brand new devices (not iterations of the same family)? They often have information missing. And those are done by companies that released hundreds of devices before that.

I just opened a datasheet for STM32G031x4/x6/x8, a relatively new device. Entire ADC section is under a footnote "1. Guaranteed by design". This is the same exact thing as "based on simulation", just different wording. Although accuracy characteristics are indeed "1. Based on characterization results, not tested in production."

Dual cores is to debug the dual core process. As was mentioned before, possibly for the second core running a wireless stack.

Again, people are missing the point. This type of device is typically not released by regular vendors, it just remain internal. And I for one want to encourage this behaviour. If anything this lets more community feedback into the final design. Imagine if ST released preliminary versions of their parts with crazy pinouts and then changed the design based on the feedback? We may end up with parts where all bits of the parallel bus are at least on the same side of the package. Imagine how great that would be.

Will I ever design that into a real product? No, I'm not crazy. Is it good enough to test drive on Arduino and other product that ultimately don't matter? Sure, why not?

For a big company it makes no sense to release this kind of product, as it will require a lot of support. RPi basically relies on community support, so it works. Nobody is forcing you to use that chip. Having one more vendor on the market is a good thing.

I would give this at least a year. If after a year the datasheet is not expanded to contain a whole lot more characterization data, then yes, we can safely say that they are not serious about it.
« Last Edit: January 21, 2021, 11:05:04 pm by ataradov »
Alex
 
The following users thanked this post: hans, Dagon, newbrain, MK14, Jacon, I wanted a rude username

Offline JohnnyMalaria

  • Super Contributor
  • ***
  • Posts: 1147
  • Country: us
    • Enlighten Scientific LLC
Re: Raspberry Pi Pico
« Reply #36 on: January 21, 2021, 11:19:35 pm »
FFS an 133MHz CM0+, with off chip flash. That deceptively large SRAM is probably going to store all the program code in order not to choke the cache-less CPU.

Also the price :palm:. $4 in China gets you an FPGA board or a Linux-capable MPU board.

Yeah, but it's available from a US supplier immediately which means I can get it in a couple of days instead of <random number if at all> days and, unlike most complex electronic items I've bought from China, actually come with instructions and *support*.
 
The following users thanked this post: Jacon

Offline mairo

  • Supporter
  • ****
  • Posts: 180
  • Country: au
Re: Raspberry Pi Pico
« Reply #37 on: January 21, 2021, 11:49:25 pm »
Any one knows what would be the price of the RP2040 IC itself?
 

Offline artag

  • Frequent Contributor
  • **
  • Posts: 657
  • Country: gb
Re: Raspberry Pi Pico
« Reply #38 on: January 21, 2021, 11:52:29 pm »
Have ordered two to play with but not exactly enamoured of the idea of a Pi dev environment and I'm hopeful there'll be a version that works on a 'larger' machine

I had no problem installing their SDK on my desktop machine. In fact it was much smaller and faster than many recent toolchains.
 

Offline PCB.Wiz

  • Frequent Contributor
  • **
  • Posts: 462
  • Country: au
Re: Raspberry Pi Pico
« Reply #39 on: January 22, 2021, 01:58:56 am »
The MCU side is somewhat limited.

Looking into timer capture, there seems to be after-thought modes in PWM, but very vague if that data can flow back up the DMA ?
It is also annoying to see a 32b MCU with 16b timers in 2021 !!!
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #40 on: January 22, 2021, 08:32:56 am »
Quote
Not sure who the target market is for a naked board focused on running MicroPython.
Adafruit sells about a dozen different boards that fit that description...

Quote
133MHz CM0+, with off chip flash. [it will] choke the cache-less CPU.
It apparently has 16k of cache.  Just because the ARM M0 spec doesn't include cache, doesn't mean a vendor can't add it to their memory systems.  Especially if it's essentially read-only memory...  Performance tests will tell, I guess.
ESPxxx chips have been running from QSPI flash for quite a while now, with few complaints about performance loss.

Quote
Number of timers is strange indeed. Timers are the most trivial peripheral, so not clear why save them.
It does sound strange.  Perhaps they've observed that vendors have so many vastly different timers, usually of several types on a single chip (SAMD has TC and TCC, each with a bunch of modes, RTC, PIT, SysTick), that few people actually use.  (Look at all the Arduino users that pretty much use a Systick and PWM only...)

A 64bit 1MHz timer meshes well with Python requirements, I guess.

I found the "USB 1.1 port" particularly confusing.  Granted that most "USB 2" peripherals in microcontrollers don't go any faster than 12Mbps (USB 1.1 "Full Speed") anyway, I don't even recall what other differences there are between 1.1 and 2.0...


 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #41 on: January 22, 2021, 08:42:04 am »
It does sound strange.  Perhaps they've observed that vendors have so many vastly different timers, usually of several types on a single chip (SAMD has TC and TCC, each with a bunch of modes, RTC, PIT, SysTick), that few people actually use.  (Look at all the Arduino users that pretty much use a Systick and PWM only...)

A 64bit 1MHz timer meshes well with Python requirements, I guess.

On reflection, and because of what you just said. Maybe they went for a simplified timer system, to make it much easier for their target market (Hobbyists, makers and the education sector), to use and easily/quickly understand the timer system.
If it was given 24 timers, of a very complicated type, with many different modes of operation, and a 2,000 page technical manual, just to explain the timer subsystem, and how to generate PWM waveforms. It would tend to NOT be so easy to use/understand etc.

So, maybe it was an intentional design decision ?
 
The following users thanked this post: YurkshireLad

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #42 on: January 22, 2021, 08:53:26 am »
This is a wrong way to approach this. If you see that others are having issues with complexity of the timers, you don't remove the timers, you remove the complexity. Even having having 5-6 SysTick-like timers with literally 3 registers each (control/compare/count) would be great. And everyone would be able to understand that.
Alex
 
The following users thanked this post: newbrain, MK14, Jacon

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #43 on: January 22, 2021, 08:59:16 am »
I've been reading up on the PIO (Programmable I/O), which can have fractional clock dividers.

The Pico has four 9-intruction state machines, with a shared 32-instruction program space, FIFOs fed/feeding DMA and a few other little tricks.

My guess it was in reaction to how un-ideal the Raspberry Pi was as driving smart LEDs, which seem to be it's major use  ;D
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 
The following users thanked this post: MK14, Jacon

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #44 on: January 22, 2021, 09:00:37 am »
This is a wrong way to approach this. If you see that others are having issues with complexity of the timers, you don't remove the timers, you remove the complexity. Even having having 5-6 SysTick-like timers with literally 3 registers each (control/compare/count) would be great. And everyone would be able to understand that.

I agree with you. But I was just speculating on why they may have gone that route.
Really, I think 32 bit timers, make it easier than 16 bit ones. Because you don't have to mess with clock divider chains, shared between multiple timers, or worry about timer overflows, for most applications.
Although even a 32 bit timer, runs out (overflows), after around 5 or 6 minutes, if it can toggle at the full 133MHz clock rate.

Another possibility (far fetched), is that it has got much more complicated timers, but they haven't worked properly (or weren't finished in time). So, in the first revision of the silicon, they have been left out and/or disabled, until they can be fixed in a later mask/revision of the chip.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #45 on: January 22, 2021, 09:32:33 am »
I've been reading up on the PIO (Programmable I/O), which can have fractional clock dividers.

The Pico has four 9-intruction state machines, with a shared 32-instruction program space, FIFOs fed/feeding DMA and a few other little tricks.

My guess it was in reaction to how un-ideal the Raspberry Pi was as driving smart LEDs, which seem to be it's major use  ;D

I presume the intention is for library code/functions to be created/released, so that although it sounds like it is too complicated for outright beginners to use directly themselves. They can use those library code/functions, to perform tasks, such as interfacing to a particular type of programmable Led, or whatever needs a complicated driving pattern, at somewhat high speed.

A bit like the extensive Arduino eco-system, which includes things like various LCD display driver routines, and all sorts of other stuff. Hence allowing beginners, who probably wouldn't know how to write such complicated software, can just use the appropriate library (calls), in their code.
 

Offline aheid

  • Regular Contributor
  • *
  • Posts: 236
  • Country: no
Re: Raspberry Pi Pico
« Reply #46 on: January 22, 2021, 10:12:30 am »
I presume the intention is for library code/functions to be created/released
Well yeah they've already done a few examples, surely there will be more.

https://github.com/raspberrypi/pico-examples/tree/master/pio
 
The following users thanked this post: MK14

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #47 on: January 22, 2021, 10:21:25 am »
I presume the intention is for library code/functions to be created/released
Well yeah they've already done a few examples, surely there will be more.

https://github.com/raspberrypi/pico-examples/tree/master/pio

I hadn't looked at their software/library releases, just some of the documentation and one or more reviews. But that is really good, if they have already released such code. As it can be used as-is, or used as examples, to write your own 'drivers' for that new hardware feature.
I suspect, some people may use it to do a number of weird and wonderful projects, with it.

One already demonstrated, is a complete working (emulated) BBC microcomputer (it even does the later/improved 'master' version), complete with graphics output, all done by this new Pico thing (and the available expansion hardware bits, like SD card readers or whatever their setup needed).
It is amazing that it can do it, especially the real time graphics output to a screen. Here is a video of it in operation:

 
The following users thanked this post: cdev, thm_w, aheid

Offline kjw

  • Newbie
  • Posts: 3
  • Country: gb
Re: Raspberry Pi Pico
« Reply #48 on: January 22, 2021, 11:01:37 am »
The CircuitPython examples for PIO, so far, are in https://github.com/adafruit/Adafruit_CircuitPython_PIOASM/tree/main/examples

I'm still a bit puzzled as to where the Pico board and RP2040 fit in but time will tell. The BBC micro:bit V2 is cheap, easy to use and very capable for beginners.

The HackSpace interview with Eben Upton is commendable for not shying away from a difficult question at the end.

Quote
HS: But why? You can buy a bunch of chips off the shelf and design a board and have a great product.

EU: You want to make something perfect, and in this space, there's no way to make a perfect thing without making your own silicon. There's a reason why the other fruit company does this, right? It's not that they want to save money. They have margin to burn. If they thought they could make great Macs using Intel chips, they wouldn't make their own silicon just for the vanity. They do it because it's what it takes to make a great product, and this is the same thing.

That's the privilege of working at Raspberry Pi. You get to watch a great team do great engineering. And they've done it again with the Pico!

Readers can judge for themselves whether that comparison with and analysis of Apple's approach is accurate and complete.

It would have been interesting if the interview covered whether the RPxxxx series will be profitable over time. If it isn't then a vald question is whether the millions spent on development could have been better used in other directions to fulfill the Foundation's mission. If it is then it could be useful to support the Foundation in the future.

Does anyone have any thoughts on whether they would have considered RISC-V as the basis for the chips?
 
The following users thanked this post: MK14

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #49 on: January 22, 2021, 11:09:18 am »


Quote>we have commissioned optimised floating-point functions from Mark Owen, author of the popular Qfplib libraries; these are substantially faster than their GCC library equivalents



I’m happy to see Mark’s code get some more traction, especially since the gcc m0 code is so sucky (non-existent, afaik, causing the generic C floating point code to be used instead...)
 

Offline Ultrapurple

  • Frequent Contributor
  • **
  • Posts: 946
  • Country: gb
  • Just zis guy, you know?
    • Therm-App Users on Flickr
Re: Raspberry Pi Pico
« Reply #50 on: January 22, 2021, 11:27:21 am »
Here's a hi-res X-Ray I made of the Pico board. Licence for re-use: CC BY-SA 2.0.
« Last Edit: January 22, 2021, 11:32:25 am by Ultrapurple »
Rubber bands bridge the gap between WD40 and duct tape.
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #51 on: January 22, 2021, 04:43:50 pm »
You would think that by now I would understand the allure of a shiny new penny. You would be wrong. Just picked up three of them at a US electronics chain store.

No shipping charge and no wait. Plus, they were $1.99 each (limit 5 then they are $3.99). What could I do? ;D

« Last Edit: January 22, 2021, 05:06:14 pm by DrG »
- Invest in science - it pays big dividends. -
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #52 on: January 22, 2021, 06:02:28 pm »
What chain store? Not that I need them, I can wait for 3 days for mail to arrive. But if the store does something good, some advertising will not hurt.
Alex
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #53 on: January 22, 2021, 06:18:06 pm »
What chain store? Not that I need them, I can wait for 3 days for mail to arrive. But if the store does something good, some advertising will not hurt.

Microcenter. They are listed here https://www.raspberrypi.org/products/raspberry-pi-pico/

Edit: This has come up before and I have touted them. I don't know where else to go if I want some component NOW. It may vary by store, but the ones I have been in have a pretty good selection of basic components (all standard brands and retail prices). It is probably a small part of their sales, but I do like to support them.

This is only my second visit since covid. The first was to get a wireless board for a PC that was giving me heartaches and headaches. Also picked up a pack of printer paper ($2.49) and 2, 8 oz. cans of air duster ($4.99 for the two). Ten min. in and out. I am big on convenience and want to see them stay around.

EDIT: when I went to get them, the online inventory said 25+. One day later (today), they are sold out - as I expected, but did not know for sure.
« Last Edit: January 23, 2021, 05:53:20 pm by DrG »
- Invest in science - it pays big dividends. -
 
The following users thanked this post: cdev

Offline benSTmax

  • Regular Contributor
  • *
  • Posts: 64
Re: Raspberry Pi Pico
« Reply #54 on: January 22, 2021, 07:27:50 pm »
I think in the near future we'll see a lot of cool projects made using the PIO. To me, it seems this subsystem is very flexible and sort of unique when compared with other microcontrollers (from other manufacturers)
 
The following users thanked this post: MK14

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #55 on: January 22, 2021, 07:57:40 pm »
It is a cool toy, nobody expects anyone to use it in real projects.

They have a picture of these things in a reel on the re-seller sites. If it's not intended for real projects, why pack them into a reel?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #56 on: January 22, 2021, 08:02:18 pm »
They have a picture of these things in a reel on the re-seller sites. If it's not intended for real projects, why pack them into a reel?
Probably was just the cheapest way to mass produce.

If the MCU itself may be usable depending on a price, the board is just nonsense for mass produced device. In order to reasonably use it, you have to design a base board. And there is nothing special on the Pico that could not just be placed on that main board.

I really want to see the pricing and availability of the MCU itself. If they commit to selling the Pico until 2028, they surely will make bare devices available.

But also, this commitment makes no sense to me personally. It sounds like a huge mistake.

But also, I'm not sure how to interpret the promise of 2028 supply in the document that at the beginning reserved the right to make any changes without further notice.
« Last Edit: January 22, 2021, 08:06:43 pm by ataradov »
Alex
 

Offline josip

  • Regular Contributor
  • *
  • Posts: 84
  • Country: hr
Re: Raspberry Pi Pico
« Reply #57 on: January 23, 2021, 09:56:00 am »
"daul core cortex M0+"
why?
why?
WHY?

I don't have any problem with this. 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.

For me is very important for device to have dedicated IOVDD pin, and not only one supply shared with USB that limit device to minimum 3.0V if USB is used.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: fi
Re: Raspberry Pi Pico
« Reply #58 on: January 23, 2021, 12:28:09 pm »
I'm still a bit puzzled as to where the Pico board and RP2040 fit in but time will tell.
As the default board for Raspberry Pi users who want a microcontroller. And now everyone who's been whining about Pis being used for blinking LEDs can start whining about Picos being used for blinking LEDs, and not their favourite Chinese half-cent MCU that you can only buy from shady resellers, has no compiler, no documentation, and no support.

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: fi
Re: Raspberry Pi Pico
« Reply #59 on: January 23, 2021, 01:21:23 pm »
GD32 is fully licensed by all IP licensors it uses.
And if you like them, keep using them. It affects me exactly as much as anyone else using the Pico affects you, ie. not at all.

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2757
  • Country: gb
Re: Raspberry Pi Pico
« Reply #60 on: January 23, 2021, 02:50:39 pm »
"daul core cortex M0+"
why?
why?
WHY?

also HOW?

I agree, the M0+core is optimised for low cost and low power, so shoving two of them into a micro instead of one of the more powerful variants (e.g. M33) doesn't make a lot of sense.  I guess it's possible they intended to have one core running something like a TCP stack to remove the complexity/overhead from a users program running in the other one.

The lack of semi-decent analog peripherals is a major omission if they are targeting this to an educational or hobby market.
 

Offline artag

  • Frequent Contributor
  • **
  • Posts: 657
  • Country: gb
Re: Raspberry Pi Pico
« Reply #61 on: January 23, 2021, 03:04:10 pm »
If it really is that powerful, expect clones to the PIO on GitHub with full Verilog code in a few days.

It's the most appealing aspect of the chip to me - makes it very hacky, with clever things you can do by abusing these flexible peripherals.

A PIO state machine isn't a new idea, there are several such micros (though not as cheap). But I don't see it as something you'd implement with an fpga, because if you have an fpga in the system you can just do those programmable operations in fpga code. There's only occasional use for an fpga that is customised so far, but then has the last few bits tailored in software.
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1146
  • Country: nl
Re: Raspberry Pi Pico
« Reply #62 on: January 23, 2021, 03:52:30 pm »
I'm actually really interested in the PIO state machine, especially if you're emulating data protocols with timers, SPI, DMA, etc. just to make a differential Manchester go pretty over an AC coupled data line. It's all a mess. Having some if-this-then-that capability running inside the peripheral without CPU intervention could be very interesting.

I wouldn't expect this micro to be a bigseller. No onboard flash sounds like a hassle. But it could be an educational tool, as having 2 cores is not "(as) easy to program", and these experimental I/O features may be very useful to see in other microcontrollers.

Considering the FLASH/SRAM situation I would look at it this way: you can get a STM32L431 with 64kB RAM. With a few lines of linker & assembly code you can segment the SRAM into 16kB of data and 48kB of code, and save 1/3 power (energy). Depending on what you're doing, 48kB of code is still plenty for low power IoT stuff.
With 264kB of SRAM you could provision 64kB code for each core and have a shared 136kB for data. Or do 128K/64K code + 64K data. Optionally you can still run large libraries from FLASH. etc. That still sounds like plenty of memory for such a small and relatively slow core. It's not like this MCU has on-chip peripherals for Ethernet, camera, USB2.0HS, high resolution LCD controllers etc. that can easily chew up all the memory for assets.

I will probably order one too whenever I get around to it.

"daul core cortex M0+"
why?
why?
WHY?

also HOW?

I agree, the M0+core is optimised for low cost and low power, so shoving two of them into a micro instead of one of the more powerful variants (e.g. M33) doesn't make a lot of sense.  I guess it's possible they intended to have one core running something like a TCP stack to remove the complexity/overhead from a users program running in the other one.

The lack of semi-decent analog peripherals is a major omission if they are targeting this to an educational or hobby market.

I think we take great ADC's/DAC's/comparators/opamps for granted from large MCU vendors. I was looking to use the ESP32 ADC lately and I was shocked what I saw. I was almost contemplating just putting an external I2C or SPI ADC just so I don't have to crunch my brain over calibration data, non-FS ranges and large sampling capacitor values.
Still this part is amazingly popular. Of course for it's WiFi/BLE capability.. but still.

I think it goes to show that designing digital systems can be facilitated/prepared very well with modern & free (as in free beer) FPGA tools. Yet analog is still much of a craft that requires a lot of knowledge to get right.
« Last Edit: January 23, 2021, 04:00:15 pm by hans »
 
The following users thanked this post: Jacon

Offline imo

  • Super Contributor
  • ***
  • Posts: 2766
  • Country: li
Re: Raspberry Pi Pico
« Reply #63 on: January 23, 2021, 05:11:40 pm »
..For the curious, the chip cost 3-4 million GBP to design. This is about what you expect for a design like this. You could probably make it a bit cheaper, but at much higher risks.
Not today and with this chip.. 1/6 of that incl. set of masks..  EDIT: 1/4 -> 1/6
And it needs to be arduino compatible as that made other chips great :)
« Last Edit: January 23, 2021, 05:24:17 pm by imo »
 

Offline guenthert

  • Frequent Contributor
  • **
  • Posts: 496
  • Country: us
Re: Raspberry Pi Pico
« Reply #64 on: January 23, 2021, 06:16:35 pm »
The lack of semi-decent analog peripherals is a major omission if they are targeting this to an educational or hobby market.
    Is it?  The Parallax P8X32A has, other then built-in RAM, counters and a boot ROM, no peripherals at all (not even built-in E(E)PROM or UART) and Parallax expressively caters to the educational and hobby market.  Sure, they are a small player, but are around for more than 30 years now.  Guess, it depends on whether you want to teach how to fade a LED or how PWM works.

     The new (still fairly expensive) P2X8C4M64 has a number built-in 'peripherials', ADCs, DACs, UARTs and filters.  So maybe they did see a need.
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #65 on: January 23, 2021, 06:46:25 pm »
I think predicting the success, in the sense of having an impact, of a new product like this is fraught with difficulties. I am not going to bother with an Arduino comparison, but want to make two points from my perspective (not an EE) and my personal experience.

I got back into small controllers on a whim when I purchased an Intel Galileo I. I had only heard about 'Arduino' and was drawn to 'Intel' more than anything else. This board was, in my opinion, a disaster from a performance and "arduino compatability" point of view. They came out with the II which was not much better, and then it faded away.

I later bought an 'Intel' Quark D2000 board (hey, maybe Intel would get it right this time :)). I really liked that board because the source code was available. I could go look at the firmware code and learn how to do what I wanted to do and I thought Eclipse was a fine platform (and still do). This sounds odd but I appreciated that it did not have the plethora of "libraries" that allowed users to do something, which they didn't understand at all, far too easily. There is a balance there, although I am not certain I can operationally define it very well. Sadly, the board was slower than a Republican accepting election results and it too (along with the Quark) faded away without having much impact.

Seems to me that the hardware is one part of the equation and the support is the other. Both are needed for impact. The ""EE brain" values the former more than the latter, which makes sense because their onboard KSAs (knowledge, skills and abilities) are well suited to make use of the hardware with limited support. The "non-EE brain" values the latter more than the former, which makes sense because their on board KSAs may not be of much use using the hardware with little support. 

RPI has a brand that is steeped in support (documentation as well as user community). Is that enough to overcome the limitations of this $4 board? I have no freaking idea :) But, reading this thread suggests to me that, for a $4 piece of hardware, it "aint" too bad....so far.
- Invest in science - it pays big dividends. -
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2538
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #66 on: January 23, 2021, 07:50:51 pm »
PIO allow it to bitbang DVI 720@30 https://github.com/Wren6991/picodvi should be able to bitbang a ton of slower stuff with ease. 1Gbit (RGMII) ethernet, IDE PATA, SCSI, all kinds of parallel camera and display interfaces.
Too bad there are no fast serializers/deserializers on board, and hardware USB is only 1.1


I purchased an Intel Galileo I. I had only heard about 'Arduino' and was drawn to 'Intel' more than anything else. This board was ...
I later bought an 'Intel' Quark D2000 board ...

Did you own a Zune by any chance? https://www.inc.com/jessica-stillman/customers-of-doom-who-you-dont-want-to-buy-your-product.html https://journals.sagepub.com/doi/abs/10.1177/0022243719867935
Just browsing their joke datasheets was a clue enough it wasnt a serious attempt at anything (few GPIO with KHz speeds etc). Intel wont enter a market with less than $1B of profit potential, they passed on iPhones, they sold StrongArm. What did you expect?
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 
The following users thanked this post: hans

Offline Bud

  • Super Contributor
  • ***
  • Posts: 4821
  • Country: ca
Re: Raspberry Pi Pico
« Reply #67 on: January 23, 2021, 08:54:44 pm »
Quote from: andersm link=topic=267516.msg3427682#msg3427682
And now everyone who's been whining about Pis being used for blinking LEDs can start whining about Picos being used for blinking LEDs

It seems you've not been around for long enough to remember that blinking LED was the EXACT way the PI was marketed.
Facebook-free life and Rigol-free shack.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: fi
Re: Raspberry Pi Pico
« Reply #68 on: January 23, 2021, 09:48:09 pm »
And now everyone who's been whining about Pis being used for blinking LEDs can start whining about Picos being used for blinking LEDs
It seems you've not been around for long enough to remember that blinking LED was the EXACT way the PI was marketed.
I've been around for long enough to grow tired of the constant whinging about how awful and terrible and wasteful that is. Well congratulations, now you have something new to complain about.
 
The following users thanked this post: Jacon

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #69 on: January 23, 2021, 09:53:27 pm »
PIO allow it to bitbang DVI 720@30 https://github.com/Wren6991/picodvi should be able to bitbang a ton of slower stuff with ease. 1Gbit (RGMII) ethernet, IDE PATA, SCSI, all kinds of parallel camera and display interfaces.
Too bad there are no fast serializers/deserializers on board, and hardware USB is only 1.1


I purchased an Intel Galileo I. I had only heard about 'Arduino' and was drawn to 'Intel' more than anything else. This board was ...
I later bought an 'Intel' Quark D2000 board ...

Did you own a Zune by any chance?/--/ What did you expect?

I did, in fact, own a Zune for about 12 hours and returned it for a full refund and the clerk understood and showed me a pile of returns. Subsequently, I bought a cheap Sandisk and I still use it today.

I did not know what to expect from the Galileo. Since you obviously did, you should have no problem at all predicting the future and making large sums of money - maybe you could email a few bucks to "make me whole".
- Invest in science - it pays big dividends. -
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1146
  • Country: nl
Re: Raspberry Pi Pico
« Reply #70 on: January 23, 2021, 10:54:10 pm »
PIO allow it to bitbang DVI 720@30 https://github.com/Wren6991/picodvi should be able to bitbang a ton of slower stuff with ease. 1Gbit (RGMII) ethernet, IDE PATA, SCSI, all kinds of parallel camera and display interfaces.
Too bad there are no fast serializers/deserializers on board, and hardware USB is only 1.1

That's a really cool demo of the hardware while only a tiny bit outside the normal spec. But I think this is where it gets tricky. A few posts back I commented that no one is going to use this micro to use it with high bandwidth peripherals such as USB2.0HS or Ethernet, because they are not on-chip, and therefore the perhaps a small SRAM after segmentation is not a problem.
Okay, obviously people are going to implement them using PIO and explore the limits. But similar to how you can bitbang VGA from a STM32F4, you probably can make something to work and create a cool demo for the aforementioned peripherals. But to then actually have the CPU and memory subsystem remain useful enough to do something else..

Like, I was amazed when Microchip launched the PIC24FJ GC006 series. A 10MSPS 12-bit ADC in a hand-solderable MCU! Yet the MCU only has 8KB SRAM, runs at 16MIPS andPMP as high bandwidth peripheral (which can't really interface with much, maybe a FPGA). So good luck doing anything with that data, especially for prolonged periods of time. The ADC can fill the entire MCU SRAM in under 400us. Talking about a bursty workload..

In that regard I'm still interested in the concept of PIO on the other side of the spectrum: namely in ultra-low power operation without CPU intervention. MSP430 can intelligently clock gate peripherals in bursts to perform short workloads. EFM32 has a 'peripheral' reflex/event system that works even when no HF clocks are running. I think it would be awesome to see a MCU that could combine several of these concepts (e.g. PIO that can also run using LF clocks, perhaps with gated oscillators/clocks that can chain/generate events or IRQs) for ultra low power operation. Sometimes only a few gates or flip-flops of logic is all you need...
 

Offline jonroger

  • Regular Contributor
  • *
  • Posts: 72
  • Country: us
Re: Raspberry Pi Pico
« Reply #71 on: January 23, 2021, 11:20:27 pm »
Not clear to me why they didn't just support bare metal programming on the Zero and Zero W.    Performance is so much better.
I am available for custom hardware/firmware development.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #72 on: January 23, 2021, 11:31:38 pm »
They wanted to grow their business and enter a new market. Nothing wrong with that. And this gives them ability to release better peripheral sets in the future, since current vendors are dropping the ball on this hard.

MCU market is not that easy to enter, but they have huge customer base out of the box, so that helps.

If you judge the performance of this chip on its own, it sucks. But if you look at what possibilities it can open in the future, it is great.
Alex
 

Offline luiHS

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: es
Re: Raspberry Pi Pico
« Reply #73 on: January 24, 2021, 01:42:56 am »
 
I have no interest in this product.
I am not going to stop using the NXP Kinetis, i.MX or the STM32 from ST, to replace it with an unknown product, Cortex M0 (I use a minimum of Cortex M4). And worst of all, without a serious IDE like the ones based on Eclipse (MCUxpresso, STM32CubeIde).

What IDE does Raspberry offer for their microcontroller? They talk about Arduino, which seems like a terrible option.

A good IDE and a good sample source code package is the least I ask of a microcontroller to decide to use it. That's what NXP with MCUXpresso offers me, that's why it's my main product, and I sometimes turn to STM32s for special things like MIPI and hardware JPEG decoding.

I'm not going to buy these Raspberry microcontrollers, no matter how cheap they are, I already have Teensy to play with, and for professional development I make my own PCB using NXP or ST microcontrollers.
« Last Edit: January 24, 2021, 01:45:30 am by luiHS »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #74 on: January 24, 2021, 01:48:46 am »
Again, what makes you think they will not build up this infrastructure. Nobody just develops things for decades and then releases it all at once.

The exact same thing was said about esp8266 when it came out. Now that thing is in commercial products shipping millions.
Alex
 
The following users thanked this post: Jacon

Offline lucazader

  • Regular Contributor
  • *
  • Posts: 185
  • Country: nz
Re: Raspberry Pi Pico
« Reply #75 on: January 24, 2021, 01:54:54 am »
I am not going to stop using the NXP Kinetis, i.MX or the STM32 from ST, to replace it with an unknown product, Cortex M0 (I use a minimum of Cortex M4). And worst of all, without a serious IDE like the ones based on Eclipse (MCUxpresso, STM32CubeIde).

What IDE does Raspberry offer for their microcontroller? They talk about Arduino, which seems like a terrible option.

They are offering VScode with a c/c++ sdk. seems fine to me.
 
The following users thanked this post: thm_w, newbrain, Jacon

Offline luiHS

  • Frequent Contributor
  • **
  • Posts: 458
  • Country: es
Re: Raspberry Pi Pico
« Reply #76 on: January 24, 2021, 02:49:22 am »
I am not going to stop using the NXP Kinetis, i.MX or the STM32 from ST, to replace it with an unknown product, Cortex M0 (I use a minimum of Cortex M4). And worst of all, without a serious IDE like the ones based on Eclipse (MCUxpresso, STM32CubeIde).

What IDE does Raspberry offer for their microcontroller? They talk about Arduino, which seems like a terrible option.

They are offering VScode with a c/c++ sdk. seems fine to me.


Yes, I already saw it. What is annoying is that all the installation instructions are for Linux, nothing for Windows.

Just because Raspberry Pi works with Linux doesn't mean that you have to program a microcontroller from Linux or using a Raspberry Pi. I installed VSCode and there I stopped, I wanted to try it but from my main computer in Windows.

 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2538
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #77 on: January 24, 2021, 02:55:15 am »
I did, in fact, own a Zune

What else, Betamax? xD card digital camera? anything using Sony memory sticks? HDDVD? Segway? Nook? Google+? ;-) seriously read the links on "harbingers of failure"

I did not know what to expect from the Galileo. Since you obviously did

anyone who looked at their non documentation did, why double down with follow up product?

But similar to how you can bitbang VGA from a STM32F4, you probably can make something to work and create a cool demo for the aforementioned peripherals. But to then actually have the CPU and memory subsystem remain useful enough to do something else..

bitbanging fullhd 60Hz VGA with enough spare cpu to play animation

Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline John_L

  • Contributor
  • Posts: 25
  • Country: au
Re: Raspberry Pi Pico
« Reply #78 on: January 24, 2021, 03:43:31 am »
Quote
Just because Raspberry Pi works with Linux doesn't mean that you have to program a microcontroller from Linux or using a Raspberry Pi

Don't need Pi. No big deal to set up Ubuntu in VM box on Windows machine.
Toolchain install is as per Raspberry Pi instructions, I didn't use their auto-install script.
 

Offline lucazader

  • Regular Contributor
  • *
  • Posts: 185
  • Country: nz
Re: Raspberry Pi Pico
« Reply #79 on: January 24, 2021, 04:16:09 am »

Yes, I already saw it. What is annoying is that all the installation instructions are for Linux, nothing for Windows.

https://datasheets.raspberrypi.org/pico/getting_started_with_pico.pdf
Quote
8.2. Building on MS Windows
Pg.34
 
The following users thanked this post: thm_w, newbrain, Jacon

Offline guenthert

  • Frequent Contributor
  • **
  • Posts: 496
  • Country: us
Re: Raspberry Pi Pico
« Reply #80 on: January 24, 2021, 05:23:28 am »
     A buddy of mine just pointed out that the original ARM (or the first commercial available ARM?) CPU was already used to emulate the BBC micro.  Not meaning to belittle the feat (particularly given the time frame), more a reminder on how much CPU performance has progressed in the past three+ decades.

[..]
bitbanging fullhd 60Hz VGA with enough spare cpu to play animation


     And that's how the RPi Pico demo scene got a jump-start  ;D
« Last Edit: January 24, 2021, 05:38:07 am by guenthert »
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #81 on: January 24, 2021, 05:44:03 am »
     A buddy of mine just pointed out that the original ARM (or the first commercial available ARM?) CPU was already used to emulate the BBC micro.  Not meaning to belittle the feat (particularly given the time frame), more a reminder on how much CPU performance has progressed in the past three+ decades.

[..]
bitbanging fullhd 60Hz VGA with enough spare cpu to play animation


     And that's how the RPi Pico demo scene got a jump-start  ;D

That video is a nice demo of the PIO, but why not pay the extra US$1.50 for a Pi Zero, and have a real display...  :)
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #82 on: January 24, 2021, 05:56:15 am »

Yes, I already saw it. What is annoying is that all the installation instructions are for Linux, nothing for Windows.

https://datasheets.raspberrypi.org/pico/getting_started_with_pico.pdf
Quote
8.2. Building on MS Windows
Pg.34

Yep. Did that tonight. Took a long time - downloading VS2019 and the rest of the tool chain, but basically no big problems. I had to mess around with cmake... had to edit cmake-tools-kits.json and put the preferredGenerator VS2019 stuff on top and that seemed to do it. Everything in the examples directory built. Only ran blink so far because it is getting late, but so far, so good.
- Invest in science - it pays big dividends. -
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2538
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #83 on: January 24, 2021, 08:25:03 am »
That video is a nice demo of the PIO, but why not pay the extra US$1.50 for a Pi Zero, and have a real display...  :)

Zero is a virtual product, even ZeroW is limited to 1 per user now

oh man the number of IO sucks on Pico. Just enough to emulate IDE interface (24 pins), but you are left with 2 pins and usb 1.1 for external storage :/ could maybe squeeze SD interface if its possible to reclaim GPIO23/24/25/29 dedicated to power sensing/switching and the led. 8bit scsi on the other hand should be a breeze, say hello to $4 SCSI disk emulators for vintage computers.
« Last Edit: January 24, 2021, 08:27:13 am by Rasz »
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #84 on: January 24, 2021, 08:30:10 am »
I'm waiting for bare chips before I even consider using it in something real. I don't get the idea of using a ready made board like this for a device in an easy to solder package and not requiring a ton of support components.
Alex
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #85 on: January 24, 2021, 09:11:16 am »
I'm waiting for bare chips before I even consider using it in something real. I don't get the idea of using a ready made board like this for a device in an easy to solder package and not requiring a ton of support components.

My feeling is that it's for hobbyists who can use KiCad/Eagle to lay out boards, get them at JLCPCB for $5, but can't solder high-density packages..

I am waiting for somebody to decap one, to see if there is any hidden RF stuff on there.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline Kangurito

  • Contributor
  • Posts: 9
Re: Raspberry Pi Pico
« Reply #86 on: January 24, 2021, 10:08:58 am »
Not impressed by this product. Nothing new or innovative here. It's 20 year old ARM tech that's commonly available from other vendors.

I'd love to see PI make a low cost 5ghz WiFi enabled ARM device... that would be a step in the right direction.
 

Offline woofy

  • Regular Contributor
  • *
  • Posts: 82
  • Country: gb
    • Woofys Place
Re: Raspberry Pi Pico
« Reply #87 on: January 24, 2021, 12:34:52 pm »
Just about everything I make these days involves connectivity, the pi zero-w and esp32 are regular goto's, so my first reaction to the pico was "no wifi, no ethernet".
Comparing price/performance against the ESP32 disappoints a bit as well.
Price - ESP32 1.98, pico 3.00 - PICO is 50% more.
Performance - ESP32 dual core Xtensa @ 240MHz (600DMIPS), PICO dual core M0+ @ 133MHz (248 DMIPS) - ESP is 240% faster
And the ESP includes wifi.

That said, I think the PICO will be a massive success.
And yes, I've ordered one to play with. (:-)

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1141
  • Country: se
Re: Raspberry Pi Pico
« Reply #88 on: January 24, 2021, 02:28:40 pm »
Yep. Did that tonight. Took a long time - downloading VS2019 and the rest of the tool chain, but basically no big problems. I had to mess around with cmake... had to edit cmake-tools-kits.json and put the preferredGenerator VS2019 stuff on top and that seemed to do it. Everything in the examples directory built. Only ran blink so far because it is getting late, but so far, so good.
I'm really puzzled by their choice of going the VS 2019 buildtools and NMake way, I don't see any particular benefit and it carries along a shitload of unrelated stuff.
Moreover, if used in a commercial environment, there are a number of quite serious license limitations*, so it's a bit of a dumb decision.

Python, Cmake and regular (gnu) make - and of course VS Code - work perfectly on Windows, I have many projects using the same set of cmakelists and makefiles on Linux and Windows, with just some different build conf in VS Code.

Another available option on Windows is always to use WSL remoting in VS Code, it's easy to set up a build environment where compilation is carried on in WSL, with Windows native debugging.

Maybe they could prepare a prebuilt Windows openocd package, instead of having to go through the pain to also install MSYS and compile it.

BTW, chocolatey will painless install Cmake, make, ninja and the likes.

OT:
And worst of all, without a serious IDE like the ones based on Eclipse (MCUxpresso, STM32CubeIde).
Ugh - probably we live in different universes, I took this as an extremely positive choice.
Rant follows: :blah:
Every time I accost one of those (or anything Eclipse based) I feel like this.
I have an ever-growing list of swearword laced grievances with MCUxpresso, I use it as way to let out some steam almost every time I use it.
Gimme VS Code, emacs or real VS anytime. Even vim in a pinch. cat > main.c. Wax tablets.
I'll put in a good remark on MCUxpresso, though: its projects work perfectly in Linux and Windows and Mac, with no changes at all, allowing to store them in a repo and work from your preferred (or available) environment.  :blah:

*In practice, you need a Visual Studio license, and you are bound by its limits (e.g. simplifying, VS Community in an enterprise = only Open Source projects or education).
Nandemo wa shiranai wa yo, shitteru koto dake.
 
The following users thanked this post: lucazader

Online cv007

  • Frequent Contributor
  • **
  • Posts: 610
Re: Raspberry Pi Pico
« Reply #89 on: January 24, 2021, 03:32:27 pm »
>I'm waiting for bare chips before I even consider using it in something real

I wouldn't know, but it seems to me they are in the 'business' of promoting their brand. That doesn't happen when you sell silicon that hides in a black box, and basically lose control of the whole 'ecosystem' surrounding it. I would settle for being able to buy a pico board at digikey/mouser in singles or any quantity you wish (and it normally being in stock) instead of always hunting around for any of their distributors to have them in stock. I'm guessing they are mostly out of stock already.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 6846
  • Country: fr
Re: Raspberry Pi Pico
« Reply #90 on: January 24, 2021, 03:38:07 pm »
The only interesting feature I have seen is the PIO thing, although some other vendors also have MCUs with something similar (but maybe not quite as generic.)

I'm still thinking this venture looks like a bit of waste of time, whereas many of us are still waiting for a truly "open" RPi. Oh well.

As to purely doing business for the heck of it, that would be fine for any company, but this is not what the RP foundation is meant to be:
https://en.wikipedia.org/wiki/Raspberry_Pi_Foundation
"The Raspberry Pi Foundation is a charity (...)"

Let's keep in mind their main goal is to "promote the study of basic computer science in schools", and not to provide seasoned engineers and industrial companies with parts.
In that regard, the Pico seems to fit the bill (even though that was already largely fulfilled with Arduino), so that's fine.
« Last Edit: January 24, 2021, 03:45:40 pm by SiliconWizard »
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: fi
Re: Raspberry Pi Pico
« Reply #91 on: January 24, 2021, 04:10:40 pm »
I wouldn't know, but it seems to me they are in the 'business' of promoting their brand. That doesn't happen when you sell silicon that hides in a black box, and basically lose control of the whole 'ecosystem' surrounding it.
Adafruit have launched two boards based on the RP2040 (ItsyBitsy RP2040, Feather 2040), and Arduino announced they're making one, so they're not that precious about their chip. It remains to be seen if they'll sell the bare chips, but right now they're completely supply-constrained.

Edit: The fact that they've published a Hardware design with RP2040 manual rather strongly suggests that the bare chips will be available for sale.
« Last Edit: January 24, 2021, 11:02:13 pm by andersm »
 

Offline Cliff Matthews

  • Supporter
  • ****
  • Posts: 1877
  • Country: ca
    • General Repair and Support
Re: Raspberry Pi Pico
« Reply #92 on: January 24, 2021, 04:23:49 pm »
I suppose arduino cc took a look at it and started quaking in their boots (we have to get in on that!!  :scared: )
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #93 on: January 24, 2021, 04:38:11 pm »
I did, in fact, own a Zune

What else, Betamax? xD card digital camera? anything using Sony memory sticks? HDDVD? Segway? Nook? Google+? ;-) seriously read the links on "harbingers of failure"

I did not know what to expect from the Galileo. Since you obviously did

anyone who looked at their non documentation did, why double down with follow up product?

Really? You really want to fight over this? Well I don't. Your arrogance is noted, your expertise without commensurate accomplishments is also noted...plus, in my country, your name means "pleaser of many goats".  :-DD
- Invest in science - it pays big dividends. -
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #94 on: January 24, 2021, 04:42:13 pm »
Yep. Did that tonight. Took a long time - downloading VS2019 and the rest of the tool chain, but basically no big problems. I had to mess around with cmake... had to edit cmake-tools-kits.json and put the preferredGenerator VS2019 stuff on top and that seemed to do it. Everything in the examples directory built. Only ran blink so far because it is getting late, but so far, so good.
I'm really puzzled by their choice of going the VS 2019 buildtools and NMake way, I don't see any particular benefit and it carries along a shitload of unrelated stuff.
Moreover, if used in a commercial environment, there are a number of quite serious license limitations*, so it's a bit of a dumb decision.
/---/

I agree (especially about the unrelated stuff). I don't know why, I suppose to address the non-Linux Windowites. I suppose one test of popularity could be whether we see a streamlined Windows IDE that gets traction.

Edit: Also, you reminded me that I had to put "NMake Makefiles" as the default build generator in the CMake plugin settings, although I had some PATH issues that might have been the problem as well.
« Last Edit: January 24, 2021, 04:47:57 pm by DrG »
- Invest in science - it pays big dividends. -
 

Offline JOEBOBSICLE

  • Contributor
  • Posts: 43
  • Country: gb
Re: Raspberry Pi Pico
« Reply #95 on: January 25, 2021, 08:24:43 am »
Vscode plus the cortex debug extension is perfectly good enough even for most professionals.

There's enough very good ide's out there for ARM. We don't need another one.
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2757
  • Country: gb
Re: Raspberry Pi Pico
« Reply #96 on: January 25, 2021, 04:27:56 pm »
The lack of semi-decent analog peripherals is a major omission if they are targeting this to an educational or hobby market.
    Is it?  The Parallax P8X32A has, other then built-in RAM, counters and a boot ROM, no peripherals at all (not even built-in E(E)PROM or UART) and Parallax expressively caters to the educational and hobby market.  Sure, they are a small player, but are around for more than 30 years now.  Guess, it depends on whether you want to teach how to fade a LED or how PWM works.

     The new (still fairly expensive) P2X8C4M64 has a number built-in 'peripherials', ADCs, DACs, UARTs and filters.  So maybe they did see a need.

And Parallax are also quite a small player in a fairly niche market, just look how rarely they get mentioned on here for example compared to the manufacturers making more conventional micros.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #97 on: January 25, 2021, 04:48:51 pm »
I wouldn't know, but it seems to me they are in the 'business' of promoting their brand. That doesn't happen when you sell silicon that hides in a black box, and basically lose control of the whole 'ecosystem' surrounding it.
Adafruit have launched two boards based on the RP2040 (ItsyBitsy RP2040, Feather 2040), and Arduino announced they're making one, so they're not that precious about their chip. It remains to be seen if they'll sell the bare chips, but right now they're completely supply-constrained.

Edit: The fact that they've published a Hardware design with RP2040 manual rather strongly suggests that the bare chips will be available for sale.
I'm curious to see what these companies are actually thinking about this.
I mean the Arduino.cc nano costs 20EUR excluding tax. They absolutely undercut them with price, and the M0+ (while not a very fast core) has absolutely higher performance. 
So what are they going to to? Sell their boards for inflated price, and hope that extra features will attract people? I doubt someone wants to pay extra 16 EUR for charger+battery connector.
Former username: NANDBlog
 

Offline Jan Audio

  • Frequent Contributor
  • **
  • Posts: 713
  • Country: nl
Re: Raspberry Pi Pico
« Reply #98 on: January 25, 2021, 05:00:08 pm »
Can you use this in your products ?, or is it just for fun ?
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #99 on: January 25, 2021, 05:03:47 pm »
/--/I'm curious to see what these companies are actually thinking about this.
I mean the Arduino.cc nano costs 20EUR excluding tax. They absolutely undercut them with price, and the M0+ (while not a very fast core) has absolutely higher performance.
So what are they going to to? Sell their boards for inflated price, and hope that extra features will attract people? I doubt someone wants to pay extra 16 EUR for charger+battery connector.

The "classic" nano is probably not the right comparison. The Nano 33 IoT, US$18.40, also an M0+ (48 MHz) but with BLE/WiFi - been around for a while now. Granted, still a huge price difference, but maybe a better comparison.
« Last Edit: January 25, 2021, 05:05:43 pm by DrG »
- Invest in science - it pays big dividends. -
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #100 on: January 25, 2021, 05:08:29 pm »
I have read some docs. PIO are nice. They let you bit-bang practically anything and fast too.
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2538
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #101 on: January 26, 2021, 02:57:46 am »
I have read some docs. PIO are nice. They let you bit-bang practically anything and fast too.

Not that fast actually :( 1/2 main clock, about 150MHz after heavy overclocking. Would be great to have at least a couple fast(1GHz) serdes blocks to do USB 2.0/MIPI in software etc.
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #102 on: January 26, 2021, 03:43:17 am »
Quote
So presumably we will see the next generation of Chinese MCUs to come with a PIO controller.

Ideally (in my mind) this will be a triple die SiP, with one RF SDR die, one die with dual core RV32/64GC and a PIO controller with some LUTs, and one external FLASH die to keep the cost down.   
So you haven't actually looked at how the PIO works on the RPi chip, right?

What you describe is similar to the CCL or CLC logic added to some existing chips, that offer small GAL-like functionality (3 input LUTs, one flipflop, connected to various peripheral-side signals (pins, timer status, "events", etc.)

The PIOs are significantly different, with dedicated 32bit-wide FIFO connections to a main AHB bus, and 2 32bit scratch registers for each State Machine (and there are 8 of them on the chip.)   That's MUCH more powerful than the AVR/PIC/SAMD versions.  It might be up there with the Cypress PSoC UDBs, but easier for SW types to manipulate, with "programs" rather than VHDL.)
(There were (briefly?) some PAL-like devices aimed at implementing state machines rather than normal logic; they had some significant internal state that wasn't connected to pins...)

You couldn't do what the RPi PIOs do by connecting an FPGA to a "conventional" ARM chip.

(OTOH, with only 32 instructions for each state machine, you also won't be able to use them very much as the sort of "general purpose co-processor" that some people have been talking about, either.)
« Last Edit: January 26, 2021, 03:45:03 am by westfw »
 
The following users thanked this post: techman-001

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 2781
  • Country: it
Re: Raspberry Pi Pico
« Reply #103 on: January 26, 2021, 05:19:18 am »
I haven't read the docs for the PIO but what you describe is simillar to the PTG on earlier dsPIC33E.
But that was veeery complex to program and most of the use cases (such as ADC trigger from PWM module conditions) were added as trigger signals from the peripheral themselves
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: fi
Re: Raspberry Pi Pico
« Reply #104 on: January 26, 2021, 07:03:58 am »
(OTOH, with only 32 instructions for each state machine, you also won't be able to use them very much as the sort of "general purpose co-processor" that some people have been talking about, either.)
32 instructions per PIO block, shared between the four state machines.

I would liken the PIO units more to other specialized real-time coprocessors, like TI's PRU, or Freescale/NXP's (e)TPU, though obviously far more limited. For comparison, here's the documentation for the configurable logic implemented in some Microchip 16-bit MCUs.
 
The following users thanked this post: techman-001

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #105 on: January 26, 2021, 08:18:22 am »
(OTOH, with only 32 instructions for each state machine, you also won't be able to use them very much as the sort of "general purpose co-processor" that some people have been talking about, either.)
32 instructions per PIO block, shared between the four state machines.

I would liken the PIO units more to other specialized real-time coprocessors, like TI's PRU, or Freescale/NXP's (e)TPU, though obviously far more limited. For comparison, here's the documentation for the configurable logic implemented in some Microchip 16-bit MCUs.

I am getting the feeling that those who say "Oh that Pi Pico PIO is new and offers exciting possibilities." actually means "Oh that Pi Pico PIO is new [to me] and offers exciting possibilities [because I haven't been exposed to this stuff much]."
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #106 on: January 26, 2021, 08:20:35 am »
It is about a combination of things. I personally have zero interest in 16-bit (and 8-bit) devices, so even if they have the most excellent peripherals, I just don't care. The rest of it is not worth my time.
Alex
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: fi
Re: Raspberry Pi Pico
« Reply #107 on: January 26, 2021, 08:50:13 am »
The datasheet makes a lot of deterministic timing, something which is nearly impossible to achieve with the Pis. So that's obviously the value proposition for their user base. I expect the next iteration of the Pi SoC to integrate if not a full microcontroller then at least some version of the PIO blocks. It won't fully solve all determinism issues, but would make the Pis a lot better at bit banging.

Offline aheid

  • Regular Contributor
  • *
  • Posts: 236
  • Country: no
Re: Raspberry Pi Pico
« Reply #108 on: January 26, 2021, 09:09:11 am »
Would be great to have at least a couple fast(1GHz) serdes blocks to do USB 2.0/MIPI in software etc.
1GHz SERDES bolted to a 48MHz M0+ core... yeah that makes perfect sense.
 
The following users thanked this post: Bassman59, mikerj, phil from seattle

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #109 on: January 26, 2021, 02:24:43 pm »
You couldn't do what the RPi PIOs do by connecting an FPGA to a "conventional" ARM chip.

PIO is a CPU, not logic - 32 16-bit words of instruction memory and lots of programmable configuration registers which affect what the commands do. There are 2 general registers (X and Y) and 8 (or 9?) instructions. There's no ALU, except for counters. It also has a set of FIFOs which can be used to communicate with the main cores. UART or SPI can be implemented with just a handful of instructions.

It wouldn't be hard to generate such core in FPGA, but it probably would be easier to do things directly in fabric.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #110 on: January 26, 2021, 05:20:32 pm »
(OTOH, with only 32 instructions for each state machine, you also won't be able to use them very much as the sort of "general purpose co-processor" that some people have been talking about, either.)
32 instructions per PIO block, shared between the four state machines.

I would liken the PIO units more to other specialized real-time coprocessors, like TI's PRU, or Freescale/NXP's (e)TPU, though obviously far more limited. For comparison, here's the documentation for the configurable logic implemented in some Microchip 16-bit MCUs.

I am getting the feeling that those who say "Oh that Pi Pico PIO is new and offers exciting possibilities." actually means "Oh that Pi Pico PIO is new [to me] and offers exciting possibilities [because I haven't been exposed to this stuff much]."
The microchip CLC is more like dedicating some GPIO pins to do core independent logic functions. For example, you can configure 3 pins to do make an OR gate. This one is more like creating unsupported communication ports. I believe some of the Beaglebones had this sort of functionality, but I never dived deep into those boards.
 For example, I2S is not supported, but a good programmer can write the functionality for 4 pins. Or that bastard WS2812 interface can be written, without bitbanging it, or using a timer. I like it, and it doesnt need to be revolutionary new technology.
Former username: NANDBlog
 

Online Tagli

  • Contributor
  • Posts: 27
  • Country: tr
Re: Raspberry Pi Pico
« Reply #111 on: January 26, 2021, 05:40:10 pm »
As far as I understand, PIO is similar to the GPIF hardware of Cypress FX2LP series. But Cypress provides some GUI based PC program instead of an assembly language. I think assembly is a better method for programing such a hardware.
Gokce Taglioglu
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #112 on: January 26, 2021, 05:57:01 pm »
The microchip CLC is more like dedicating some GPIO pins to do core independent logic functions. For example, you can configure 3 pins to do make an OR gate. This one is more like creating unsupported communication ports.

The Microchips CLCs can be connected to just about any periphery, so you can create/process various custom signals. Say, you can OR a PWM with SPI and produce a waveform which is otherwise unobtainable. They also have flops, so you can produce delays, sync different signals etc. They can do a lot. It's just not that many of them, so the capabilities are limited. It's like a built-in nano CPLD/FPGA. Microchip has an app note with design which uses logic cells to drive WS2812 using a signal produced by the SPI module.

Perhaps, the purpose of PIO is the same as Microchip's CLC - to do something non-standard. However, the implementation is completely different. Also, PIO is certainly much more powerful.
 
The following users thanked this post: tszaboo

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 6846
  • Country: fr
Re: Raspberry Pi Pico
« Reply #113 on: January 26, 2021, 05:58:49 pm »
As far as I understand, PIO is similar to the GPIF hardware of Cypress FX2LP series. But Cypress provides some GUI based PC program instead of an assembly language. I think assembly is a better method for programing such a hardware.

AFAIR, the GPIF in FX2 MCUs was essentially a programmable interface. Not nearly as versatile (but probably more efficient for what it did) as the RP's PIO.

Something closer to PIO would likely be found at Microchip:
https://www.microchip.com/design-centers/8-bit/pic-mcus/device-selection/pic18-q43-product-family
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 2223
  • Country: nz
  • Formerly SiFive, Samsung R&D
Re: Raspberry Pi Pico
« Reply #114 on: January 26, 2021, 10:07:29 pm »
You couldn't do what the RPi PIOs do by connecting an FPGA to a "conventional" ARM chip.

PIO is a CPU, not logic - 32 16-bit words of instruction memory and lots of programmable configuration registers which affect what the commands do. There are 2 general registers (X and Y) and 8 (or 9?) instructions. There's no ALU, except for counters. It also has a set of FIFOs which can be used to communicate with the main cores. UART or SPI can be implemented with just a handful of instructions.

It wouldn't be hard to generate such core in FPGA, but it probably would be easier to do things directly in fabric.

What I don't get is if you're going as far as that, why *not* add a proper ALU and general purpose but simple instruction set?
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #115 on: January 26, 2021, 11:18:08 pm »
Quote
There's no ALU, except for counters.
And shifters, right?
Quote
The Microchips CLCs can be connected to just about any periphery
But not to the data memory or bus.

Quote
why *not* add a proper ALU and general purpose but simple instruction set?
Why add that complexity?  They've already got two M0 cores...

Quote
Microchip has an app note with design which uses logic cells to drive WS2812 using a signal produced by the SPI module.
All you need is two (carefully selected from ~4) CLCs, the SPI interface, and a PWM timer.
Whereas the RPi chip can do it all with one PIO (of 8) (~6 lines of code!), without sacrificing the other peripherals.

Quote
It wouldn't be hard to generate such core in FPGA
An FPGA implementation of a "simple" thing like this would be interesting to see; mid-way between trivial examples and full CPUs.  For each PIO, you'd need 32 words of "program memory", at least 8 words of FIFO (make expandable, for extra points), some bus to access them (and distinguish accessing the program mem vs the FIFOs), the "core", some sort of clock system, and a bunch of IO pins.  I'd think that in theory you could fit "a couple" on a relatively small FPGA, and "many" on a big FPGA.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #116 on: January 26, 2021, 11:33:09 pm »
An FPGA implementation of a "simple" thing like this would be interesting to see; mid-way between trivial examples and full CPUs.
This is what Xilinx PicoBlaze is. It started as a state machine generated based on the "program" code. Then it evolved into a simple control and I/O core.
Alex
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #117 on: January 27, 2021, 12:52:52 am »
Oooh.  32 USB Endpoints!  That's nice.(Compares to 16 endpoints on SAMDxx, 7 endpoints on ATmega32u4)

I've never quite understood why there can't be a buffer bucket for "some other endpoint; deal with it in SW." (like IP "protocol" or TCP "port", or ethernet multicast...)
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #118 on: January 27, 2021, 12:57:02 am »
Because USB controller has to respond immediately to request. Even if it is just a NAK. So you need to have hardware to support that.

It is not a lot of hardware, but it is not nothing.
Alex
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2719
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #119 on: January 27, 2021, 04:04:03 am »
Oooh.  32 USB Endpoints!  That's nice.(Compares to 16 endpoints on SAMDxx, 7 endpoints on ATmega32u4)
The more important question is, whether this is the first Raspberry Pi device that actually implements USB correctly.

Thus far, all Raspberry Pis have suffered from the Broadcom hardware bug, that in certain situations causes USB packets to be dropped on the floor.
This should never be allowed to happen.

They have tried to work around it in software, and I hear that "it works pretty well now", but until they actually implement a working USB hardware, I would not use a Pi for anything more important than controlling LEDs, or as a cheap-but-not-very-reliable webcam.

(Even then, knowing the Raspberry Pi Foundations' attitude towards Linux developers – much like Broadcom "you fuckers deserve nothing, and we'll just take this stuff, you ugly long-haired smelly hippies" – I would not be pushing any of my bugfixes etc. upstream.)
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #120 on: January 27, 2021, 04:14:13 am »
This device has nothing to do with Broadcom. Why would it be affected by that issue.

Is it possible that there are some issues? Sure. But unlike with the situation where you buy readily available chips, that would be on RPi people to fix.
Alex
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2719
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #121 on: January 27, 2021, 04:41:41 am »
This device has nothing to do with Broadcom.
Eh? The Raspberry Pi Foundation is really just the PR arm of Broadcom, with Eben Upton the glue.

(In legalese: the Foundation is supported by Broadcom and the University of Cambridge Computer Laboratory.)
« Last Edit: January 27, 2021, 04:43:59 am by Nominal Animal »
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #122 on: January 27, 2021, 04:48:30 am »
This device has nothing to do with Broadcom.
Eh? The Raspberry Pi Foundation is really just the PR arm of Broadcom, with Eben Upton the glue.  (Not legally, sure, but in every other way.)

I've been following the Pi since before it was released, and to me it seems the truth is somewhere in the middle.

The relationship offers different things to each of the partner, and seems to achieve both of their goals.

The only people who a freeloaders seem to be the semi-professionals, who get the platform but give little to the wider ecosystem, then moan that the can't order in quantity and that broadcom doesn't offer technical support for free...
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2719
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #123 on: January 27, 2021, 05:45:32 am »
This device has nothing to do with Broadcom.
Eh? The Raspberry Pi Foundation is really just the PR arm of Broadcom, with Eben Upton the glue.  (Not legally, sure, but in every other way.)

I've been following the Pi since before it was released, and to me it seems the truth is somewhere in the middle.

The relationship offers different things to each of the partner, and seems to achieve both of their goals.

The only people who a freeloaders seem to be the semi-professionals, who get the platform but give little to the wider ecosystem, then moan that the can't order in quantity and that broadcom doesn't offer technical support for free...
Who are you referring to?  The Pi folks themselves are very loathe to interact with FOSS developers, and instead just grab whatever they use.  Isn't that exactly "getting the platform but giv[ing] little to the wider ecosystem"?

It's not like they provide basically anything back to Debian, despite their "Raspberry Pi OS" being derived from Debian, for example.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #124 on: January 27, 2021, 07:44:13 am »
This device has nothing to do with Broadcom.
Eh? The Raspberry Pi Foundation is really just the PR arm of Broadcom, with Eben Upton the glue.  (Not legally, sure, but in every other way.)

I've been following the Pi since before it was released, and to me it seems the truth is somewhere in the middle.

The relationship offers different things to each of the partner, and seems to achieve both of their goals.

The only people who a freeloaders seem to be the semi-professionals, who get the platform but give little to the wider ecosystem, then moan that the can't order in quantity and that broadcom doesn't offer technical support for free...
Who are you referring to?  The Pi folks themselves are very loathe to interact with FOSS developers, and instead just grab whatever they use.  Isn't that exactly "getting the platform but giv[ing] little to the wider ecosystem"?

It's not like they provide basically anything back to Debian, despite their "Raspberry Pi OS" being derived from Debian, for example.
The use of the RaspPi in commercial or semi-commercial products isn't of much interest to them, they are quite open that they would prefer to sell them such that they not only make money for Raspberry Pi, but also work towards the Foundation's aims. I can't blame them for that.

The original Raspberry Pi was the Raspberry Pi Foundation's attempt at a "Saved pocket Money/Birthday gift" computer, aimed at allowing keen people to experience and learn more of Computer Technology outside of the "This is Word, Excel, PowerPoint and Email on Windows XP" world of the school IT curriculum in the early-to-mid 2000s.

The Raspberry Pi Foundation is a UK charity, with the aim of:

Quote
The object of the charity is to further the advancement of education of adults and children, particularly in the field of Computers, Computer Science and related subjects

As a charity, I understand it is would be legally questionable if they were to donate their money or resources to others that is not directly supporting their efforts as a charity (e.g sponsoring the Debian project) - that's not how charities work.

And they are under no obligation to do so either. After all, aren't the freedoms of Free Software Definition:

Freedom 0 - the freedom to use the work

Freedom 1 - the freedom to study the work

Freedom 2 - the freedom to copy and share the work with others

Freedom 3 - the freedom to modify the work, and the freedom to distribute modified and therefore derivative works

An the GPU even includes such phases as:

Quote
freedom to distribute copies of free software (and charge for them if you wish).

The Pi foundation are doing exactly what Free Software is about. It is what authors sign up for when they give their code that license.

Now some might not like that they Pi's design isn't fully open (e.g. binary firmware blobs, no schematics) but the Pi never pretended to be an "open platform" nirvana, just a platform you could run software on, that a computer-mad kid could buy using pocket money.

I also think many do not know that a prototype for the Pi was an ATmega644 with 512K SRAM - it wasn't an Broadcom conspiracy from day 0, it was a case of the right people in the right place at the right time.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 
The following users thanked this post: cdev, MK14, Jacon

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2719
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #125 on: January 27, 2021, 08:19:36 am »
The Raspberry Pi Foundation is a UK charity, with the aim of:
I see, they are exempt from being a contributor to the software ecosystem they exploit, because one government has decided they are a charity.

Right.  Only human individuals can be "freeloaders" (your term, not mine).  :-DD

Like I said, I don't really care.  It is you who brought it up:
The only people who a freeloaders seem to be the semi-professionals, who get the platform but give little to the wider ecosystem, then moan that the can't order in quantity and that broadcom doesn't offer technical support for free...
My point is that that is exactly what the Raspberry Pi Foundation itself is doing.

Perhaps you should examine why you feel so strongly that being a company or a charity is sufficient to deflect any criticism of their behaviour?

I repeat, I am not the one claiming there are freeloaders.  You did that yourself.  I know and understand various licenses, and use a lot of them for my own work (from Creative Commons to GPL to proprietary licensing).  I don't think anyone is being a "freeloader", not even the semi-professional people you mentioned, nor the Pi Foundation.  What I don't like, is when people like you spend a lot of effort in using arbitrary definitions and positions (of being Important Commercial Company, or Good Charity I Swear) as shields against criticism of observed behaviour.

All I have done here, is claim that 1) The Raspberry Pi Foundation is hostile to FOSS developers, including to developers whose work they rely on in the "products" they provide, that 2) The Raspberry Pi Foundation is in real life a PR arm of Broadcom (in legal-speak, supported by Broadcom and University of Cambridge Computer Laboratory), and that 3) because of their history with their hardware products, I would be surprised if the Pico did not have similar hardware faults as previous Pi products.

(I am more than a bit angry, because a lot of Raspberry Pi users believe Linux/FOSS is at the root of the hardware/software problems.  This is incorrect; the Pi hardware is utter crap compared to say Samsung Exynos or Amlogic Meson based Linux SBCs.)

I mock them, and their hardware, because that hostility is unworkable in the long term.  It is damaging, because it leads to actions like RedHat did to counter Oracle's (license-abiding) exploitation, which leads to general losses to the entire community.  It is also completely unreasonable, and seems to stem from Broadcom corporate culture and Eben Upton's personal dislike of everything FOSS.

I really wish they'd picked FreeBSD instead of Linux.  It would have fit their model and culture much better.
« Last Edit: January 27, 2021, 08:21:47 am by Nominal Animal »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 2223
  • Country: nz
  • Formerly SiFive, Samsung R&D
Re: Raspberry Pi Pico
« Reply #126 on: January 27, 2021, 08:37:33 am »
The only people who a freeloaders seem to be the semi-professionals, who get the platform but give little to the wider ecosystem, then moan that the can't order in quantity and that broadcom doesn't offer technical support for free...

"can't order in quantity" is a huge red flag.

"Profit" is not a dirty word the the education aims of the Raspberry Pi Foundation would be served a lot better by making a $1 profit on every unit sold than by making a $1 loss on it. If they don't care about getting their NRE back because of their charitable aims and that's covered by donors then that it up to them. But they need to make a small profit on every unit sold so that if someone says "We want a thousand Pi Zeros" then they say "Coming right up! And thank you!". Or a million.

Production needs to ramp of course, on new products, but not on a product that is now over five years old.
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2538
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #127 on: January 27, 2021, 09:54:08 am »
I am getting the feeling that those who say "Oh that Pi Pico PIO is new and offers exciting possibilities." actually means "Oh that Pi Pico PIO is new [to me] and offers exciting possibilities [because I haven't been exposed to this stuff much]."

Sure, but how many people are interested in using obscure things like Xmos. This being rpi it will expose a ton of people to the idea of software programmable peripherals.
What a lovely thing to have a modern day Amiga Copper, or Atari ANTIC display list :-)

Would be great to have at least a couple fast(1GHz) serdes blocks to do USB 2.0/MIPI in software etc.
1GHz SERDES bolted to a 48MHz M0+ core... yeah that makes perfect sense.

it would if you actually read the datasheed to learn PIO block can have exclusive access to 500MB/s of DMA bw (maybe even 1GB/s out of 2GB/s available overal). It can be fed internally at least >2x faster than its capability to operate GPIOs. Serdes would complement it nicely.
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #128 on: January 27, 2021, 10:17:06 am »
The only people who a freeloaders seem to be the semi-professionals, who get the platform but give little to the wider ecosystem, then moan that the can't order in quantity and that broadcom doesn't offer technical support for free...

"can't order in quantity" is a huge red flag.

In what context? as a hobbyist tinkering? a student learning? or as somebody trying to design a commercial product around a chip or module produced by a not-for-profit charity aimed at education? If it is the latter, then they are sending the correct signal IMO.

Quote
"Profit" is not a dirty word the the education aims of the Raspberry Pi Foundation would be served a lot better by making a $1 profit on every unit sold than by making a $1 loss on it. If they don't care about getting their NRE back because of their charitable aims and that's covered by donors then that it up to them. But they need to make a small profit on every unit sold so that if someone says "We want a thousand Pi Zeros" then they say "Coming right up! And thank you!". Or a million.

Production needs to ramp of course, on new products, but not on a product that is now over five years old.

Of course profit is not a dirty word. They are making physical things and everybody has families to feed and need to make a dollar along the way, and cover NRE. But if somebody rocks up and says "We want a Thousand Pi Zeros" they are not obliged to sell them in bulk - they can say "no, we would rather keep our stock going to hobbyists and students, so we will sell one per person through our established channels". If they have done the math, they end up netting a few percent per piece then its all good by me.

If the foundation believes that getting thousands of boards to kids and hobbyists is more important than having thousands of Pis integrated in the back of some 3D printer or a retro arcade cabinet then I am fine with that, even if they are passing up on a few extra $ along the way.

However, if kids or hobbyists can't get boards because they have sold all their stock to a bulk customers for a few extra $ that would suck bigtime, and not be in line with their aims.

I still remember the great Beagleboard shortage of 2015...
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline josip

  • Regular Contributor
  • *
  • Posts: 84
  • Country: hr
Re: Raspberry Pi Pico
« Reply #129 on: January 27, 2021, 10:26:16 am »
Oooh.  32 USB Endpoints!  That's nice.(Compares to 16 endpoints on SAMDxx, 7 endpoints on ATmega32u4)

I've never quite understood why there can't be a buffer bucket for "some other endpoint; deal with it in SW." (like IP "protocol" or TCP "port", or ethernet multicast...)

Kinetis M0+ are with 16 bidirectional EP's. So if this 32 are not bidirectional, than this is the same thing. BTW, this is one of the reason (up to 15 CDC's virtual ports on PC with newer OS's like Win10) why I use Kinetis.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 2223
  • Country: nz
  • Formerly SiFive, Samsung R&D
Re: Raspberry Pi Pico
« Reply #130 on: January 27, 2021, 11:15:11 am »
You're talking as if there is some fixed supply and when they are sold no one else can get one.

That's just wrong.

There won't be anyone in the supply chain, from chips to boards, to assembly, to distribution, who wouldn't prefer to be doing 10x the current volume if they're making a profit doing it.

If anything, ramping up the production volume by 2x or 10x or 100x because they're integrated in the back of some arcade game or industrial equipment would allow dropping the price for everyone, including the students.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #131 on: January 27, 2021, 02:23:52 pm »
Serdes would complement it nicely.

It is a SERDES. It reads parallel from the FIFO and outputs serially (or vice versa).

I couldn't find in the PIO docs anything about how fast its input clock can be and where it can come from (may be I haven't looked well enough). The input clock may be divided, sort of a built-in NCO, but this only can only make it slower. One instruction requires two NCO clock cycles to execute. Hence, a bit can be shifted in or out every second NCO cycle.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #132 on: January 27, 2021, 02:32:31 pm »
However, if kids or hobbyists can't get boards because they have sold all their stock to a bulk customers for a few extra $ that would suck bigtime, and not be in line with their aims.

You sound just like Canada Post - "we're living through difficult times because people send too many parcels". Customers are good for any business, the more the merrier.
 

Offline hans

  • Super Contributor
  • ***
  • Posts: 1146
  • Country: nl
Re: Raspberry Pi Pico
« Reply #133 on: January 27, 2021, 02:44:46 pm »
Oooh.  32 USB Endpoints!  That's nice.(Compares to 16 endpoints on SAMDxx, 7 endpoints on ATmega32u4)

I've never quite understood why there can't be a buffer bucket for "some other endpoint; deal with it in SW." (like IP "protocol" or TCP "port", or ethernet multicast...)

Because the endpoint field is only up 4 bits, 2^4=16 numbers possible. Then OUT and IN tokens determine data direction, for up to 16 bidir or '32' unidir endpoints: https://beyondlogic.org/usbnutshell/usb3.shtml

Hardware must handle IN/OUT tokens immediately (e.g. real-time paced by the host), which is why it's handled in hardware. Software prepares buffers and signals them to hardware they are ready for the host to be read or written into. Having an 'other' endpoint logic handled by SW must then mean it must handle this IRQ incredibly quickly (much faster than 400k or 1Mbit/s I2C slaves with no clock-stretching possible). Perhaps possible on fast chips.. but really not convenient to the user(=programmer).
« Last Edit: January 27, 2021, 02:47:42 pm by hans »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 6846
  • Country: fr
Re: Raspberry Pi Pico
« Reply #134 on: January 27, 2021, 02:46:33 pm »
However, if kids or hobbyists can't get boards because they have sold all their stock to a bulk customers for a few extra $ that would suck bigtime, and not be in line with their aims.

You sound just like Canada Post - "we're living through difficult times because people send too many parcels". Customers are good for any business, the more the merrier.

As at least two of us said so far, the RP foundation is a CHARITY. It's not just "any business". Their goal is not just to have customers.

Of course, making money in itself allows them to invest more for future projects, so they have to make money, but not if it actually prevents them from fulfilling their stated goal.

And yes, for most of us westerners, $4 or $10 or $20 may not make a big difference even for kids, but for, say, schools in many parts of Africa, a single dollar makes a difference.
 

Offline aheid

  • Regular Contributor
  • *
  • Posts: 236
  • Country: no
Re: Raspberry Pi Pico
« Reply #135 on: January 27, 2021, 03:08:22 pm »
I couldn't find in the PIO docs anything about how fast its input clock can be and where it can come from

From the datasheet "3.2.2. Control Flow":
Quote
On every system clock cycle, each state machine fetches, decodes and executes one instruction
And in "2.15.3.1. Instances" clk_sys is listed at nominal 125MHz.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #136 on: January 27, 2021, 04:26:34 pm »
And in "2.15.3.1. Instances" clk_sys is listed at nominal 125MHz.

So, if it runs from the system clock, it's 62.5 MHz highest bit rate it can achive. It's 500 Mb/s for 8-GPIO parallel port. Would be 2Gb/s if it could use 32 GPIO, but only 30 is available, and you would need some GPIOs for clock and control.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #137 on: January 27, 2021, 07:16:47 pm »
As at least two of us said so far, the RP foundation is a CHARITY. It's not just "any business". Their goal is not just to have customers.

So, you're suggesting they selling it at dumping (below cost) prices? Then the more they sell the more they lose, and therefore they don't want commercial entities to buy it. This actually makes sense and explains the low price.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 6846
  • Country: fr
Re: Raspberry Pi Pico
« Reply #138 on: January 27, 2021, 08:17:09 pm »
As at least two of us said so far, the RP foundation is a CHARITY. It's not just "any business". Their goal is not just to have customers.

So, you're suggesting they selling it at dumping (below cost) prices? Then the more they sell the more they lose, and therefore they don't want commercial entities to buy it. This actually makes sense and explains the low price.

No quite, I'm just saying that their goal is to "promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing.", whereas a regular business's goal is to make profits.

Selling chips to Adafruit, for instance, still fulfills that goal IMHO, since this is also the main 'market' Adafruit is serving. Now selling chips or boards to companies that would make products out of them not related to the above goal whatsoever would not. It's OK if it's a minor part of their activities, as I said, to make some cash - which they can further invest in new projects - but probably not OK if it became more than this.

Then, as a charity, they get significant funding through donations and subsidies, so they can afford to sell their products at what would be a loss for a regular commercial company. They also get very good deals with Broadcom and all their other suppliers. So that explains the low prices.

 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #139 on: January 27, 2021, 08:36:58 pm »
Then, as a charity, they get significant funding through donations and subsidies, so they can afford to sell their products at what would be a loss for a regular commercial company. They also get very good deals with Broadcom and all their other suppliers. So that explains the low prices.

Makes sense. Fortunately I didn't buy it. I wouldn't feel right if my purchase was subsidized by donations designed to help deprived children to get into computing.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #140 on: January 27, 2021, 09:58:00 pm »
Then, as a charity, they get significant funding through donations and subsidies, so they can afford to sell their products at what would be a loss for a regular commercial company. They also get very good deals with Broadcom and all their other suppliers. So that explains the low prices.

Makes sense. Fortunately I didn't buy it. I wouldn't feel right if my purchase was subsidized by donations designed to help deprived children to get into computing.

A little over 2% of the charities funding come donations,, another 3% from other sources (maybe including sponsorship?) , the rest (approx £40M) is funded from their trading activities. .As they are a charity you can look up their accounts on the UK charities register.

... and it isn't for deprived children, it has always been open for all who want to tinker. It was a large part founded in response to the IT circiulum being focused on using applications, not learning about actual computing.


Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #141 on: January 28, 2021, 12:33:12 am »
Quote
subsidized by donations
Rarely has a "charitable" organization had such successful products.
Your purchase doesn't have to "subsidize" product give-aways, but then the company probably doesn't need to charge the normal "5x parts cost" MSRP, either.

It's an interestingly different model for this sort of thing (unlike OLPC, for example.)  I wonder if RPi gets commented on as much from charitable organization folk, as it does from technical folk?
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #142 on: January 28, 2021, 01:16:26 am »
Quote
Quote
I've never quite understood why there can't be a buffer bucket for "some other endpoint; deal with it in SW."
Because the endpoint field is only up 4 bits, 2^4=16 numbers possible. Then OUT and IN tokens determine data direction, for up to 16 bidir or '32' unidir endpoints: https://beyondlogic.org/usbnutshell/usb3.shtml
Oh.  I hadn't realized that 16 (*2) was the limit of the protocol.   I guess that makes my point less of an issue.


Quote
Hardware must handle IN/OUT tokens immediately (e.g. real-time paced by the host), which is why it's handled in hardware.
I figured it was something like that.Still, I was imagining something like the way ethernet interfaces handle multicast or promiscuous modes.  Handle the hardware needs immediately as necessary, and count on SW to process the actual data quickly enough...
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2538
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #143 on: January 28, 2021, 03:20:41 am »
And in "2.15.3.1. Instances" clk_sys is listed at nominal 125MHz.

So, if it runs from the system clock, it's 62.5 MHz highest bit rate it can achive. It's 500 Mb/s for 8-GPIO parallel port. Would be 2Gb/s if it could use 32 GPIO, but only 30 is available, and you would need some GPIOs for clock and control.

your keyboard SHIFT key is broken, you kept typing Mb/s instead of MB/s. Makes you only one order of magnitude off.
 62.5 MHz * 30 pins = ~230MB/s, half the available bandwidth
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #144 on: January 28, 2021, 04:05:03 am »
So, if it runs from the system clock, it's 62.5 MHz highest bit rate it can achive. It's 500 Mb/s for 8-GPIO parallel port. Would be 2Gb/s if it could use 32 GPIO, but only 30 is available, and you would need some GPIOs for clock and control.

your keyboard SHIFT key is broken, you kept typing Mb/s instead of MB/s. Makes you only one order of magnitude off.
 62.5 MHz * 30 pins = ~230MB/s, half the available bandwidth

30 pins * 62.5 MHz is roughly 2Gb/s (would be 2 Gb/s with 32 pins), isn't it?
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 2223
  • Country: nz
  • Formerly SiFive, Samsung R&D
Re: Raspberry Pi Pico
« Reply #145 on: January 28, 2021, 04:30:57 am »
So, if it runs from the system clock, it's 62.5 MHz highest bit rate it can achive. It's 500 Mb/s for 8-GPIO parallel port. Would be 2Gb/s if it could use 32 GPIO, but only 30 is available, and you would need some GPIOs for clock and control.

your keyboard SHIFT key is broken, you kept typing Mb/s instead of MB/s. Makes you only one order of magnitude off.
 62.5 MHz * 30 pins = ~230MB/s, half the available bandwidth

30 pins * 62.5 MHz is roughly 2Gb/s (would be 2 Gb/s with 32 pins), isn't it?

1.875 Gb/s, which is 234 MB/s.

Rasz perhaps does not understand that b (bits) vs B (bytes) is a deliberate distinction?
« Last Edit: January 28, 2021, 05:03:00 am by brucehoult »
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2538
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #146 on: January 28, 2021, 04:38:49 am »
So, if it runs from the system clock, it's 62.5 MHz highest bit rate it can achive. It's 500 Mb/s for 8-GPIO parallel port. Would be 2Gb/s if it could use 32 GPIO, but only 30 is available, and you would need some GPIOs for clock and control.

your keyboard SHIFT key is broken, you kept typing Mb/s instead of MB/s. Makes you only one order of magnitude off.
 62.5 MHz * 30 pins = ~230MB/s, half the available bandwidth

30 pins * 62.5 MHz is roughly 2Gb/s (would be 2 Gb/s with 32 pins), isn't it?

1.875 Gb/s, which is 234 GB/s.

Rasz perhaps does not understand that b (bits) vs B (bytes) is a deliberate distinction?

I can somewhat understand broken SHIFT key, but m+Shift combination resulting in capital G is really bizarre.
1.875 Gb/s is in fact 234, but MB/s.
http://letmegooglethat.com/?q=1.875+Gb%2Fs+to+Megabytes%2Fs
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #147 on: January 28, 2021, 05:51:55 pm »
For those who might be interested....

From a few days ago:


and from yesterday (much ESP32-S2 but also RP2040:


- Invest in science - it pays big dividends. -
 

Offline Sudo_apt-get_install_yum

  • Regular Contributor
  • *
  • Posts: 132
  • Country: se
Re: Raspberry Pi Pico
« Reply #148 on: January 29, 2021, 09:18:02 am »
I think this is an obvious attempt at entering the manufacturing world similar to the raspberry pi compute-module. It is based on a platform with millions of examples and community support, shortening the development time of a "real" embedded system.
 
It would also function as an entry point for students who will keep it in the back of their head when going into the work force.

The Raspberry pi foundation is a hobby-oriented company so the sales volumes are a fraction of what they could be if they could work there way into the manufacturing/large volume manufacturing world.

I don’t se any other explanation for the PICO and compute modules, the modules kind of flopped and I think that they might believe that it is doe to the cost ~35USD so they released the PICO a more "cost effective" solution.

The module is also designed to be soldered directly to carrier boards.

These are just my thought :)


 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 2223
  • Country: nz
  • Formerly SiFive, Samsung R&D
Re: Raspberry Pi Pico
« Reply #149 on: January 29, 2021, 10:29:12 am »
I think this is an obvious attempt at entering the manufacturing world similar to the raspberry pi compute-module. It is based on a platform with millions of examples and community support, shortening the development time of a "real" embedded system.

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
 

Offline Sudo_apt-get_install_yum

  • Regular Contributor
  • *
  • Posts: 132
  • Country: se
Re: Raspberry Pi Pico
« Reply #150 on: January 29, 2021, 10:52:28 am »
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 :P
 

Offline bw2341

  • Regular Contributor
  • *
  • Posts: 87
  • Country: ca
Re: Raspberry Pi Pico
« Reply #151 on: January 29, 2021, 05:30:35 pm »
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...
« Last Edit: January 29, 2021, 09:32:43 pm by bw2341 »
 
The following users thanked this post: Sudo_apt-get_install_yum

Offline JOEBOBSICLE

  • Contributor
  • Posts: 43
  • Country: gb
Re: Raspberry Pi Pico
« Reply #152 on: January 31, 2021, 11:56:40 am »
I found a freertos port that someone did

https://github.com/PicoCPP/RPI-pico-FreeRTOS
 
The following users thanked this post: Cliff Matthews, imo

Online rstofer

  • Super Contributor
  • ***
  • Posts: 8305
  • Country: us
Re: Raspberry Pi Pico
« Reply #153 on: February 02, 2021, 07:56:49 pm »
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?
« Last Edit: February 04, 2021, 10:34:07 pm by rstofer »
 
The following users thanked this post: westfw, Jacon

Online Tagli

  • Contributor
  • Posts: 27
  • Country: tr
Re: Raspberry Pi Pico
« Reply #154 on: February 02, 2021, 08:45:18 pm »
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.
Gokce Taglioglu
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #155 on: February 02, 2021, 08:48:41 pm »
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.
Alex
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #156 on: February 02, 2021, 10:03:05 pm »
Quote
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
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #157 on: February 02, 2021, 10:05:01 pm »
Quote
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 "Vtarget" that many probes want is ... inconvenient.
 

Offline yann

  • Contributor
  • Posts: 6
Re: Raspberry Pi Pico
« Reply #158 on: February 02, 2021, 11:34:53 pm »
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.
 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1141
  • Country: se
Re: Raspberry Pi Pico
« Reply #159 on: February 03, 2021, 08:16:43 am »
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.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline basilskral

  • Newbie
  • Posts: 1
  • Country: ua
Re: Raspberry Pi Pico
« Reply #160 on: February 03, 2021, 11:46:44 am »
Raspberry Pi Pico are out of stock everywhere |O
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!!
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #161 on: February 03, 2021, 03:26:56 pm »
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.
Former username: NANDBlog
 

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #162 on: February 03, 2021, 08:47:01 pm »
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 :).
 

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #163 on: February 04, 2021, 03:49:52 pm »
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.
 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1141
  • Country: se
Re: Raspberry Pi Pico
« Reply #164 on: February 04, 2021, 04:03:44 pm »
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?
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 6846
  • Country: fr
Re: Raspberry Pi Pico
« Reply #165 on: February 04, 2021, 05:05:19 pm »
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.
 

Offline bogdan2014

  • Regular Contributor
  • *
  • Posts: 65
  • Country: ro
Re: Raspberry Pi Pico
« Reply #166 on: February 04, 2021, 05:19:48 pm »
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.
 

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #167 on: February 04, 2021, 05:56:30 pm »
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.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #168 on: February 04, 2021, 09:00:01 pm »
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.
Former username: NANDBlog
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 8305
  • Country: us
Re: Raspberry Pi Pico
« Reply #169 on: February 04, 2021, 09:48:56 pm »
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...
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #170 on: February 04, 2021, 10:04:20 pm »
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...

Quote
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?

Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 8305
  • Country: us
Re: Raspberry Pi Pico
« Reply #171 on: February 04, 2021, 10:35:59 pm »
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.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #172 on: February 04, 2021, 10:49:11 pm »
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 ?
« Last Edit: February 04, 2021, 11:03:34 pm by MK14 »
 

Offline guenthert

  • Frequent Contributor
  • **
  • Posts: 496
  • Country: us
Re: Raspberry Pi Pico
« Reply #173 on: February 04, 2021, 11:29:13 pm »
[..]
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.
« Last Edit: February 04, 2021, 11:31:07 pm by guenthert »
 
The following users thanked this post: MK14

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #174 on: February 05, 2021, 12:12:44 am »
     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.
 

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #175 on: February 05, 2021, 12:28:10 am »
I suspect/hope the buying limits, are only temporary.

Is buying from Europe still an option? I bought two from here, they claim to have enough stock: https://www.kiwi-electronics.nl/raspberry-pi-pico-single-board?search=rp2040&description=true

One thing about rp2040 I don't get is their target market. Anyway, I'll be happy to use if their software is better than all that stm32 HALs. The only one that I liked was from Chibios, all the rest seemed to be unneccessary complex to comprehend. I think many libs try to make generic interfaces accommodating multiple MCU ranges, but at the end it becomes a very long reading with lots of trial-and-error even for a simple task, not to say something more complex like setting up peripherial clocks and DMA transfers (or may be I simply lack skills). CubeMX was very helpful when it worked, but it had bugs.
« Last Edit: February 05, 2021, 12:30:15 am by exe »
 
The following users thanked this post: MK14

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #176 on: February 05, 2021, 01:01:35 am »
I suspect/hope the buying limits, are only temporary.

Is buying from Europe still an option? I bought two from here, they claim to have enough stock: https://www.kiwi-electronics.nl/raspberry-pi-pico-single-board?search=rp2040&description=true

One thing about rp2040 I don't get is their target market. Anyway, I'll be happy to use if their software is better than all that stm32 HALs. The only one that I liked was from Chibios, all the rest seemed to be unneccessary complex to comprehend. I think many libs try to make generic interfaces accommodating multiple MCU ranges, but at the end it becomes a very long reading with lots of trial-and-error even for a simple task, not to say something more complex like setting up peripherial clocks and DMA transfers (or may be I simply lack skills). CubeMX was very helpful when it worked, but it had bugs.

Thanks for the link!

Sadly, because of Brexit, and the simultaneous introduction of new import laws (EVERYTHING, even very cheap things have to have VAT added to them, even if from the EU). I'm trying to avoid buying from abroad, until the situation settles, and we know more accurately what happens, when we import things, and if they get hit with extra charges, even when VAT has already been paid.

I suspect, I will add PICO(s), to my next electronics (or similar) order (when possible(i.e. that supplier sells PICOs)/needed). Hopefully some of the suppliers, e.g. Digikey. Will sell PICO's. In the future and/or Amazon and/or others.

In the near future, I suspect availability/stock will be much better, and hopefully a bigger range of suppliers will have them. So, whenever I am already buying an order from them (hypothetically Digikey), I can get my first PICO(s).

« Last Edit: February 05, 2021, 01:21:29 am by MK14 »
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #177 on: February 05, 2021, 01:12:56 am »
There are still some big apparently unanswered question(s) surrounding the PICO. Do they intend to sell the individual chips, to consumers and small businesses ?
If so, will it be at a competitive price ?
I.e. Like STM32's and other MCUs, which you can buy relatively cheaply, and even cheaper, in slightly larger quantities.

Who will sell those chips ?
Will it just be the limited number of approved suppliers, who can put on idiosyncratic requirements, such as you can't buy more than 1, and/or you have to pay a relatively expensive delivery charge, even for just one small/tiny chip ?

To me, and maybe others. They are important questions. Because if the answers are mainly/fully NO. It makes the PICO unsuitable, for various applications. I.e. our own custom PCBs, if we don't want to put a custom module onto our PCBs.

The module is not the end of the world, but would make it unsuitable for very small projects and/or large scale ones (probably) and/or other problems, if you can't get/buy the bare chips.
I.e. Will the likes of Mouser/Digikey/LCSC etc, start selling them ?
« Last Edit: February 05, 2021, 01:16:58 am by MK14 »
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 7822
  • Country: us
    • Personal site
Re: Raspberry Pi Pico
« Reply #178 on: February 05, 2021, 01:21:38 am »
There is no way they do not sell bare chips. They will have to, otherwise there is no real point to any of this. You don't just design a chip and not sell it.

It takes time to setup distribution channels and build up inventory.
Alex
 
The following users thanked this post: MK14

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #179 on: February 05, 2021, 01:30:09 am »
There is no way they do not sell bare chips. They will have to, otherwise there is no real point to any of this. You don't just design a chip and not sell it.

It takes time to setup distribution channels and build up inventory.

That makes a lot of sense, and it can/does take a long time to sort out new distributors. $3,000,000 to $4,000,000 (mentioned in earlier post(s) ) development cost, plus lots of hard work, blood, sweat, tears and hassle, plus a degree of business risk, I would guess.

The raspberry PI 4, loses out on a lot of application areas, because you would have to install and pay for, such a relatively large and expensive module, in your project. Many of which couldn't cope with the size or the cost.

So a massively cut down, but tiny IC chip version of the Raspberry PIs, does kind of make sense.
« Last Edit: February 05, 2021, 01:32:52 am by MK14 »
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 8305
  • Country: us
Re: Raspberry Pi Pico
« Reply #180 on: February 05, 2021, 02:09:28 am »
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.

Wrong country, I know, but there didn't seem to be a limit at Sparkfun so I ordered 4.  They are sold out until late February when they expect to get 5000+.  Sadly, there is going to be a limit of 100 per customer on this batch.  Maybe I'll have my wife place a second order...

https://www.sparkfun.com/products/17829

I have no intention of buying 100.  I'm still trying to figure out what to do with the first four.


 
The following users thanked this post: MK14

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #181 on: February 05, 2021, 10:09:00 am »
There is no way they do not sell bare chips. They will have to, otherwise there is no real point to any of this. You don't just design a chip and not sell it.

It takes time to setup distribution channels and build up inventory.
The only fear that I have for the ICs, is that they might be more expensive than the modules.
We've seen this for the rPi foundation. The compute module is (was?) more expensive than the regular pi. Significantly more expensive. While the manufacturing cost is less, It doesnt have the IO, and the ethernet controller (some models). It's SMD only.
I hope I'm wrong.
Former username: NANDBlog
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #182 on: February 05, 2021, 10:17:54 am »
Quote
There are still some big apparently unanswered question(s) surrounding the PICO.Do they intend to sell the individual chips, to consumers and small businesses ?
They have said YES to this one; repeatedly.https://www.raspberrypi.org/forums/viewtopic.php?t=299523

Quote
If so, will it be at a competitive price ?
Pricing, and distributor arrangements, have not been disclosed.
What do you consider "competitively priced"?  If it's $4, would that be awful?  (It's approximately similar to a SAMD21G18.  It'd also be similar to the Arduino vs bare AVR situation we have now, where you can buy Arduino pro-mini clones-from-China for only slightly more than you can buy bare ATmega328p chips...)
 
The following users thanked this post: MK14

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #183 on: February 05, 2021, 11:02:57 am »
Wrong country, I know, but there didn't seem to be a limit at Sparkfun so I ordered 4.  They are sold out until late February when they expect to get 5000+.  Sadly, there is going to be a limit of 100 per customer on this batch.  Maybe I'll have my wife place a second order...

https://www.sparkfun.com/products/17829

I have no intention of buying 100.  I'm still trying to figure out what to do with the first four.

I think you are right, across other countries as well. I think by delaying my order for a few days (but it could be weeks). The supplier(s), will both have stock and allow the purchase of more than 1. It is only the initial shortage, that has caused the out of stock situation (and my hesitancy at buying into the first batch of them), that is causing this situation.

tl;dr
Hopefully shortly, more suppliers will have stock and allow >1 to by purchased. Then I can get some.

If so, will it be at a competitive price ?
Pricing, and distributor arrangements, have not been disclosed.
What do you consider "competitively priced"?  If it's $4, would that be awful?  (It's approximately similar to a SAMD21G18.  It'd also be similar to the Arduino vs bare AVR situation we have now, where you can buy Arduino pro-mini clones-from-China for only slightly more than you can buy bare ATmega328p chips...)

There were too many nested quotes, so I may have changed your post a bit, when I tidied it. Hopefully NOT.

I agree, even $4 (for the chip), would not be too bad. Unless we are talking about bigger volumes and/or very cost sensitive applications. Hopefully it will be cheaper in practice, and even better if they have discounted volume purchase quantities, as well. Especially if the volume discount points, are not too big, either. I.e. x100 and x1,000. Rather than needing to be hundreds of thousands or millions, which it is rumored to be, for some MCUs. Otherwise the MCU manufacturer doesn't want to deal with you.



Anyway, overnight (and a result of what has been said in this thread). I'm planning to get some (I'm patient), and will wait until the supply situation gets better.

Also, I think I've had the WRONG attitude about the PICO. The issue isn't exactly what you get for your $4, or me complaining about some missing features, such as > 3 or 4 A2D inputs.
Because SOFTWARE really is a massive thing. This product is likely to be VERY popular, and have a big and very significant following.
So, various pre-made hardware things are likely to become available (such as plug in mini push switch sets, with 4 to 8 buttons), Led panels with 10 (very approx quantity) RGB Leds, plug in speakers, etc etc.

Also a big software eco system.

Those are the really big factors. Not the exact price or functionality.

I.e. I could (the prices seem to have gone up hugely, recently) 6+ months ago, get a complete STM8 microcontroller board, assembled with header pins (loose/not-fitted) and mini USB power connector, for around 85p, if buying in multi packs of x2, x5 or x10.
E.g. x10 pack, for around £8.50 (including delivery), from China.

But it lacked a proper/full software eco system, information (although there was some, and more still if you searched for it), and wouldn't really work 100% properly, and could be cloned chips, etc etc.

So, $4 for a proper working, non-fake/cloned chip, with huge amounts of accurate information available for it. Many hardware devices (as upgrades) and software, such as multiple programming languages and example projects. Makes it a sort of 'Arduino on steroids', kind of system.

tl;dr
On reflection, this is looking more and more like a real bargain.
« Last Edit: February 05, 2021, 12:40:30 pm by MK14 »
 

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #184 on: February 05, 2021, 11:29:47 am »
I wonder if they already decided on the price of bare ICs, or they are looking for reception. I'd also love to see the roadmap, but I expect it to be top secret for the company. On the other hand, it's been only two weeks or so since they launched their very first MCU, but we already comparing them with bigger and more established players on the market. Isn't it amazing?

Concerning the price, I've seen some estimations on reddit how much a bare die would cost (based on speculation that one 40nm waffer from TSMC costs $2500 and they got 20k dies with very low defect rate), but this doesn't include packaging and distribution. Distributors love big margins (I think), but I hope it will be in $1-2 final "retail" price in single qty. It makes little sense to sell chips for more than the board with xtal and flash :).
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #185 on: February 05, 2021, 01:29:31 pm »
So I just got my boards, here is a short review:
- Board is only 1mm thick, I expected normal 1.6
- Setup to micropython was very easy and painless. You plug in the board, it has a link, download the file, write to Pi. It automatically reboots, and pops up as serial port. REPL connect with any speed. 1 minute and done. Good user experience
- LED on the board doesn't come on while doing this.
- Uses 0201 capacitors, for 99% of users there is not a chance to repair this. Not sure why, there is space on the board. Feels fragile.
- Board date code is 5020, middle of December
- There are no silkscreen on the top for the GPIO pins
- Board is tiny bit longer than 50mm, so you cannot place them into those handy 50mm long boxes.
- Help() on modules seems OK, help on functions is somewhat short and cryptic. I think we still need the reference guide. It is fair, since this all takes space from the flash. Maybe there should be different versions of the firmware for different levels of help
- Tab while typing works
- Command memory is 8 commands long
- There is no upip. This is somewhat bugging me.
« Last Edit: February 05, 2021, 02:05:29 pm by NANDBlog »
Former username: NANDBlog
 
The following users thanked this post: thm_w, MK14

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #186 on: February 05, 2021, 01:48:12 pm »
Coincidentally, I just got mine as well :). Pin labels are at the bottom, which is a strange decision to me. Nonetheless, I got a very smooth start, connected with with thonny (IDE for beginners), works flawlessly. I think for a small project such as blinking led this is is ideal. Their micropython book is also available for free download.

A bit of a bummer is maximum SPI rate. It's only 1.8432Mbps (according to datasheet), which might not be enough to refresh my display.  For comparison, esp32 can clock spi up to 80MHz (not sure what is useful bandwidth). I have micropython fork from loboris with custom spi module, it drives my 320x480 display at quite good rate. Refresh is visible, but not too annoying. I was hoping to get similar experience with rp2040, but probably it won't be as good.
 

Online Tagli

  • Contributor
  • Posts: 27
  • Country: tr
Re: Raspberry Pi Pico
« Reply #187 on: February 05, 2021, 01:58:03 pm »
- Board is only 1mm thick, I expected normal 1.6
The official "Hardware design with RP2040" document mentions that this is due to USB signal integrity.
Quote
The board is nominally 1mm thick, but it could be manufactured with a thicker PCB, for example 1.6mm is very common, but you might run into difficulties with the USB characteristic impedance (discussed below).
Gokce Taglioglu
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #188 on: February 05, 2021, 02:37:01 pm »
- Board is only 1mm thick, I expected normal 1.6
The official "Hardware design with RP2040" document mentions that this is due to USB signal integrity.
Quote
The board is nominally 1mm thick, but it could be manufactured with a thicker PCB, for example 1.6mm is very common, but you might run into difficulties with the USB characteristic impedance (discussed below).
I'm quite sure they described it, and it is just something that was surprising for the first 10 seconds.
It is due to the two layer construction that results such wide traces for USB. They are also not taking any chances with the USB after failing with it.
I must say it is somewhat disappointing that they dont have a composite USB device, where you could access the file system and REPL at the same time.
Former username: NANDBlog
 
The following users thanked this post: bron84

Offline yann

  • Contributor
  • Posts: 6
Re: Raspberry Pi Pico
« Reply #189 on: February 05, 2021, 03:03:23 pm »
A bit of a bummer is maximum SPI rate. It's only 1.8432Mbps (according to datasheet), which might not be enough to refresh my display.
You should be able to get at least 40MHz out of the PIO state machines. Also, I think you misread an example describing the required input clock for a particular baud rate as the limit; the datasheet also says "Bit rates are supported to 2MHz and higher" for the SPI.

The SPI block is fed from clk_peri, which can run at 12-125MHz. It divides the clock by 2-65024 (254*256) to generate SSPCLKOUT. So that gets us a max SPI clock rate of 62.5MHz (only in master mode). What actually works may be a different matter.

The PIO can run as fast as sysclk (nominal 125MHz, supposedly limited to 133MHz for CPUs if run through pll_sys), but SPI still involves the clock going up and down, so that only pushes it to 66MHz. DDR SPI can work around that limit.

The I/O buffers have configurable drive power which might help you if you need to push it (SLEWFAST and DRIVE in GPIOn registers).

https://github.com/raspberrypi/pico-micropython-examples/blob/master/pio/pio_spi.py
 
The following users thanked this post: edavid, exe

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #190 on: February 05, 2021, 03:20:08 pm »
I must say it is somewhat disappointing that they dont have a composite USB device, where you could access the file system and REPL at the same time.

I'll prove technical details why this is a bit unreliable below, but before that let me ask what's your workflow? May be thonny may help. It allows working with files stored on rp2040, as well having repl. The way it works is it uses repl to work with "remote filesystem". I used to have scripts to automate that on esp32 (upload new version of files, then run code), but I think I'll be fine with thonny for now.

Simultaneous access may also lead to concurrency issues when code tries to access half-written data. Most filesystems are not designed to be simultaneously used (unless in read-only mode). I think that was the reason why android devices stopped exposing their storage as mass storage. Instead, they use higher-level protocol such as MTP. Anyway, I did that in the past with filesystems, I either explicitly flushed caches after each write operation, or open filesystem in synchronous mode .

You should be able to get at least 40MHz out of the PIO state machines. Also, I think you misread an example describing the required input clock for a particular baud rate as the limit; the datasheet also says "Bit rates are supported to 2MHz and higher" for the SPI.
[...]
https://github.com/raspberrypi/pico-micropython-examples/blob/master/pio/pio_spi.py

This is fantastic, thank you! Going to give it a try. I find it fascinating that I can write asm code from python and have it automatically compiled for me. All that on an Arm Cortex-M0+ MCU!
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #191 on: February 05, 2021, 03:49:28 pm »
I must say it is somewhat disappointing that they dont have a composite USB device, where you could access the file system and REPL at the same time.

I'll prove technical details why this is a bit unreliable below, but before that let me ask what's your workflow? May be thonny may help. It allows working with files stored on rp2040, as well having repl. The way it works is it uses repl to work with "remote filesystem". I used to have scripts to automate that on esp32 (upload new version of files, then run code), but I think I'll be fine with thonny for now.

Simultaneous access may also lead to concurrency issues when code tries to access half-written data. Most filesystems are not designed to be simultaneously used (unless in read-only mode). I think that was the reason why android devices stopped exposing their storage as mass storage. Instead, they use higher-level protocol such as MTP. Anyway, I did that in the past with filesystems, I either explicitly flushed caches after each write operation, or open filesystem in synchronous mode .

You should be able to get at least 40MHz out of the PIO state machines. Also, I think you misread an example describing the required input clock for a particular baud rate as the limit; the datasheet also says "Bit rates are supported to 2MHz and higher" for the SPI.
[...]
https://github.com/raspberrypi/pico-micropython-examples/blob/master/pio/pio_spi.py

This is fantastic, thank you! Going to give it a try. I find it fascinating that I can write asm code from python and have it automatically compiled for me. All that on an Arm Cortex-M0+ MCU!
I don't have a workflow yet for micropython.
Usually I work with notepad++ and putty. Or Jupyter notebook. on regular python.
I briefly tried it last year, on an ESP32 board. I liked the simplicity of python, but it was limited by the hardware. Namely it only had the serial port. I've tried this Thonny, but honestly, this looks like a janky thrown together software, that was written by 1 guy who really likes linux.
For now, I'm testing Circuitpython. This seems to enumerate as a drive, serial port and (as a test) HID device at the same time. I kinda like it.
It blows my mind, that with two cores, I can just upload a script to the flash drive, and un it on the second core, and keep using the interpreter at the same time, and (for example if it is a logging task) I can just read the results with a standard text editor.
Former username: NANDBlog
 

Offline yann

  • Contributor
  • Posts: 6
Re: Raspberry Pi Pico
« Reply #192 on: February 05, 2021, 04:06:04 pm »
That's not because of the two cores - CircuitPython only uses one. It's MicroPython's async threading. On the ESP32, MicroPython can use both cores and talk to serial ports and network simultaneously. It just shares the same REPL.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #193 on: February 05, 2021, 05:54:00 pm »
Digikey, seem to have announced that they will be stocking it, for around $4, it appears on their system, already. They seem to be just waiting for stock to arrive.

https://www.digikey.com/en/products/detail/raspberry-pi/SC0915/13624793

Perfect solution for me. As I buy stuff from them, from time to time, so I can add PI PICO(s), to the order, and buy anything else I need for the PI PICO, at the same time.

UK Digikey link:
https://www.digikey.co.uk/product-detail/en/raspberry-pi/SC0915/2648-SC0915CT-ND/13684020
« Last Edit: February 05, 2021, 05:58:50 pm by MK14 »
 
The following users thanked this post: edavid

Online ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 405
  • Country: gb
    • Me
Re: Raspberry Pi Pico
« Reply #194 on: February 06, 2021, 04:41:46 pm »
What seems to be missing here: libraries. I think one main reason for Arduino's success in general is the huge range of libraries. You can get code for driving an LCD, or reading a temperature sensor, and so on, without having to worry about details of I2C or other low level stuff. ARM's mBed also goes quite a way in offering libraries for a range of hardware. Raspberry Pi Pico doesn't have this by itself.

Now, it seems Arduino will be bringing out a Pico based board, and supporting the Raspberry Pi Pico. I suspect that may be the thing which actually makes the Raspberry Pi Pico take off. So, this seems llike a smargt move for the Raspberry Pi guys. But what's in it for the Arduino guys? Just hoping to take advantage of the RPi name? I can't see it being because of any technical advantage of the (current) Pico chip.
 

Online rstofer

  • Super Contributor
  • ***
  • Posts: 8305
  • Country: us
Re: Raspberry Pi Pico
« Reply #195 on: February 06, 2021, 05:27:55 pm »
Think about the Teensy 4.1 - a 600 MHz Cortex M7 with a bazillion features:
https://www.pjrc.com/store/teensy41.html

The first thing PJRC did was recreate the Arduino library functions so that the device can be programmed from the Arduino IDE and use existing source code (more or less).  The point was to have the same library features as the standard Arduino.  Those who want to move beyond can certainly do so but at least the base Arduino functionality is present from day one.

Clearly, this requires a different version of gcc (AVR vs ARM) but that stuff is all taken care of when Teensyduino is installed.  Afterwards it is as simple as choosing a 'board' to have the IDE choose the proper compiler tools.

It would be worthwhile for the RPi folks to recreate the Arduino library functions if they think their market is with beginning hobbyists.  I would suggest integrating the Pico with mbed but since mbed itself is owned by ARM, that may not happen.

Notice how there are several options for programming software.
 

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #196 on: February 06, 2021, 06:17:08 pm »
What seems to be missing here: libraries.

They support micropython, so they support micropython libraries. I was able to find all the code for popular display controllers, etc. Also, porting is not that difficult, if needed. I was able to port an arduino display driver (hardcoded with avr-specific optimizations) into stm32.
 

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #197 on: February 06, 2021, 10:02:56 pm »
I just ran ili9341 (this driver: https://github.com/jeffmer/micropython-ili9341), and did memory test. It shows 156kb after gc after I draw a full-screen rectangle. Disabling some fonts got me 170KB of RAM. Huh, now I remember why I wanted esp32 with 8MB* PSRAM...

I ran current test using standard SPI interface (machine.SPI), next time I'll try PIO as suggested earlier.

* several sources claim esp32 can directly address only 4MB of PSRAM.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #198 on: February 06, 2021, 10:55:23 pm »
What seems to be missing here: libraries. I think one main reason for Arduino's success in general is the huge range of libraries. You can get code for driving an LCD, or reading a temperature sensor, and so on, without having to worry about details of I2C or other low level stuff. ARM's mBed also goes quite a way in offering libraries for a range of hardware. Raspberry Pi Pico doesn't have this by itself.

Now, it seems Arduino will be bringing out a Pico based board, and supporting the Raspberry Pi Pico. I suspect that may be the thing which actually makes the Raspberry Pi Pico take off. So, this seems llike a smargt move for the Raspberry Pi guys. But what's in it for the Arduino guys? Just hoping to take advantage of the RPi name? I can't see it being because of any technical advantage of the (current) Pico chip.
I dont know what your experience was with libraries, but mine wasn't that great. Either you stick to the mainstream boards, and then you end up with an abundance of libraries. Then you spend time finding he one that actually does what you want. There are 17 libraries for SSD1306 OLEDs, that I can see. The description of the packages are cryptic help is non existent, and coding stile is all over the place. Are you supposed to call a function with a pointer? Create a class item? Call an init? Who knows.

Or you use a part which is not mainstream, and you end up with a library, written by someone in 2013, who didn't really understand programming, and there have been a dozen breaking changes since then. And it is only written to work on another board, not the one you have.

So no, it's not just plug and play.

For this, you should search for modules or packages,  they aren't called libraries.
Former username: NANDBlog
 
The following users thanked this post: newbrain

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #199 on: February 07, 2021, 01:59:27 am »
Quote
It would be worthwhile for the RPi folks to recreate the Arduino library functions
Yeah, probably.  The Pico seems to have a pretty complete "SDK", but I'm essentially pretty tired of having a NEW SDK (HAL, Framework, etc) to learn for each new chip vendor. :-(  (this goes beyond the "many vendor HALs really suck", which we also tend to believe.  Even if they didn't suck, it would still be annoying to no COMMON abstraction.)
 

Online ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 405
  • Country: gb
    • Me
Re: Raspberry Pi Pico
« Reply #200 on: February 07, 2021, 07:58:22 am »
Some good comments there, and yes, clearly the Teensy guys got the importance of libraries. Perhaps I should have said "Libraries easily downloaded and used from within a supporting IDE". My remarks were also intended in the context of this being an educational tool for beginners (vis-a-vis the RPi Foundation's aims).

Yes, Arduino libraries often have many alternatives, and some are broken / badly written / outdated / only work for certain boards. But generally, it's still quicker to try a few and find one that works than to e.g. write a graphics library from scratch.

Yes, Micropython has some useful modules, but those are more for things like stacks and queues than hardware drivers. Yes, if you search for e.g. Micropython BME280, you do find things (and again plenty of alternatives), but users still have to figure out how to install them into whatever development system they are using. It's not the easy learner experience that the Arduino IDE has of: from within the IDE, search for a library, press download, and in one click, it's there complete with examples, ready to use. (And if Micropython is your thing - why prefer this board over say a cheaper ESP32 board with added Wifi?)

The SDK and documentation are well done, I agree, but target a sophisticated audience, rather than providing a painless experience for first time hardware users. There are no examples at the level of "my first hardware project - hook up a temperature sensor and LCD and make an electronic max-min thermometer" for example - the libraries are not there to support such projects.

« Last Edit: February 07, 2021, 08:16:18 am by ralphrmartin »
 

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #201 on: February 07, 2021, 09:44:35 am »
Even if they didn't suck, it would still be annoying to no COMMON abstraction.)

I think trying to get a common abstraction is what made most hals suck. I've seen a lot of hals with "opaque" arguments that are hardware-specific. There is often no validation of arguments at all. Like, it won't check if clock configuration for ADC is incorrect, or some buffer settings. I started to see why people prefer LL drivers over, say, stm32's hal.

Here I'd rant how slow and resource-consuming mbed was for me, but we are discussing micropython, which is probably not the fastest thing out there :).

users still have to figure out how to install them into whatever development system they are using.

We are getting there: there is upip for network-enabled devices. And there is adafruit's library that includes tons of libraries: https://circuitpython.org/libraries . I've never used circuitpython myself, but I assume it does what you are asking for. I guess circuitpython is the tool aimed at very beginners.
 

Offline jeremy0

  • Contributor
  • Posts: 9
  • Country: es
Re: Raspberry Pi Pico
« Reply #202 on: February 08, 2021, 01:59:47 pm »
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.

Segger's latest JLink Beta (6.95c) supports RP2040, which worked out of the box (with VTref connected to 3V3) running from flash under VS Code with cortex-debug extension.
https://www.segger.com/downloads/jlink/#J-LinkSoftwareAndDocumentationPackBeta
https://forum.segger.com/index.php/Thread/7762-RP2040-Support/

So far I've only flashed the code manually (UF2 file via USB, outside the debugger).
My minimal attempts to load code to flash or RAM from the debugger didn't work, but I didn't try for long.
 
The following users thanked this post: thm_w, newbrain, Tagli

Offline jeremy0

  • Contributor
  • Posts: 9
  • Country: es
Re: Raspberry Pi Pico
« Reply #203 on: February 08, 2021, 05:01:11 pm »
Coincidentally, I just got mine as well :). Pin labels are at the bottom, which is a strange decision to me. Nonetheless, I got a very smooth start, connected with with thonny (IDE for beginners), works flawlessly. I think for a small project such as blinking led this is is ideal. Their micropython book is also available for free download.

A bit of a bummer is maximum SPI rate. It's only 1.8432Mbps (according to datasheet), which might not be enough to refresh my display.  For comparison, esp32 can clock spi up to 80MHz (not sure what is useful bandwidth). I have micropython fork from loboris with custom spi module, it drives my 320x480 display at quite good rate. Refresh is visible, but not too annoying. I was hoping to get similar experience with rp2040, but probably it won't be as good.

The SPI can run up to half the system clock speed.

Clarified here: https://github.com/raspberrypi/pico-feedback/issues/39

"Since the maximum frequency for clk_peri on RP2040 (and hence the maximum frequency for SSPCLK) is 133MHz, the maximum SCK output frequency is 133MHz / 2 = 66.5MHz, and the maximum SCK input frequency is 133 / 12 ~11.083MHz."
 
The following users thanked this post: exe

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #204 on: February 08, 2021, 11:58:46 pm »
A bit of a bummer is maximum SPI rate. It's only 1.8432Mbps (according to datasheet), which might not be enough to refresh my display.

Use PIO. It can go much faster.
 
The following users thanked this post: exe

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #205 on: February 09, 2021, 02:53:40 pm »
Yes, Micropython has some useful modules, but those are more for things like stacks and queues than hardware drivers.
This might interest you:
https://learn.adafruit.com/adafruit-circuit-playground-express/circuitpython-libraries
I'm sure there is some source code of it somewhere.

why prefer this board over say a cheaper ESP32 board with added Wifi?)
It has native USB, with circuitpython I have UART + Storage at the same time. I can set up a logger into internal flash, plug in the board somewhere else, and read out a complete CSV file after the logging is done. Without installing any software other than a text editor or compiling anything.
Former username: NANDBlog
 

Online ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 405
  • Country: gb
    • Me
Re: Raspberry Pi Pico
« Reply #206 on: February 09, 2021, 05:31:35 pm »
Sure, if you dig around you can find some libraries, but that is not very beginner friendly, and I'm not sure how "without installing any software" squares with "use circuitpython". Circuitpython runs on the ESP32, too, so it too could be used  for your example (I think?).

Anyway, my main point was, and is, I still don't see why this chip / board were developed; I also note that it doesn't come with any new development ecosystem. What were the perceived shortcomings of boards and chips already out there? I've not seen any statement from the RPi folks along the lines of
"We developed this chip / board because...", or 
"This makes for a better learning experience because... "
I would love for someone to enlighten me.
Apart from perhaps the PIO, there seems to be nothing new here that takes things a step forward.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #207 on: February 09, 2021, 05:44:12 pm »
... that is not very beginner friendly ...

What is that "beginner friendly" anyway?
 

Online ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 405
  • Country: gb
    • Me
Re: Raspberry Pi Pico
« Reply #208 on: February 09, 2021, 05:58:03 pm »
Beginner friendly: it's a bit like getting a new toy for Xmas, and the batteries are included.
 

Offline phil from seattle

  • Frequent Contributor
  • **
  • Posts: 934
  • Country: us
Re: Raspberry Pi Pico
« Reply #209 on: February 09, 2021, 07:11:35 pm »
... that is not very beginner friendly ...

What is that "beginner friendly" anyway?
Well, it is a bit subjective but friendly to me is when the new user doesn't have to download and configure all sorts of libraries and tools and also make a lot of decisions to just get a simple program, like blinking an LED, to work. As pointed out earlier, Teensyduino is a great example of friendly.  Install Arduino - easy. Install Teensyduino (which pulls in a lot of good quality libraries) - easy. Build the sketch - done. There are lot of Tom's HW tutorials that run on and on and are good examples of beginner unfriendly - way too many places to go astray.  There was one that had something like 27 steps - I would call that hostile, not unfriendly, though.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #210 on: February 09, 2021, 09:15:36 pm »
With MicroPython the Pico is relatively beginner friendly. Just open a GUI and code.

For C/C++ development is has quite a few beginner firendly features:

The drag the file to a USB Mass Storage Device to program is very beginner friendly. No cables and wires to hook up, no cable drivers. Seems almost impossible to brick. However it's not unique - seen it before on the BBC micro:bit.

The Cmake magic in the SDK is pretty beginner friendly. Much more so than ESP32's ESP-IDF. Took a bit of tinkering to get a standalone project to build but is great.

However, writing raw C/C++ on a micro is never that beginner friendly though, even with a nice HAL.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #211 on: February 09, 2021, 09:54:09 pm »
Any news/rumors about bare IC and stuff? I wonder about plans releasing it in smaller packages and with flash inside the same package, like, afaik, gd32f103. I don't mind if they use the same bare die in different packages and leave some pins unconnected :).
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #212 on: February 09, 2021, 10:48:08 pm »
Sure, if you dig around you can find some libraries, but that is not very beginner friendly, and I'm not sure how "without installing any software" squares with "use circuitpython". Circuitpython runs on the ESP32, too, so it too could be used  for your example (I think?).

Anyway, my main point was, and is, I still don't see why this chip / board were developed; I also note that it doesn't come with any new development ecosystem. What were the perceived shortcomings of boards and chips already out there? I've not seen any statement from the RPi folks along the lines of
"We developed this chip / board because...", or 
"This makes for a better learning experience because... "
I would love for someone to enlighten me.
Apart from perhaps the PIO, there seems to be nothing new here that takes things a step forward.
Last time I tried to run micropython on ESP, I had to identify and download a flashing tool for it (1), which was a python script(2), the binaries were really difficult to identify, you need a serial port application (3) if you want to up/download files, you need Thonny (4).
For Pi pico, it's windows explorer and notepad. Or the equivalent of your choice. It all comes with an operating system, you know how it works, there is 0 learning curve. The built in ROM bootloader even has a link to the website where you can download the binaries. It's a nice touch.
Former username: NANDBlog
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #213 on: February 10, 2021, 10:33:38 am »
Ah great. So I was working on Pi Pico yesterday, trying to connect it to something with CP. For the life of me, I couldn't get the UART working.
Then  I realized that theCP implementation of UART is different than the uP. Ok, no problem, rewrote the code for that.
I get an error.
UART is not implemented  :palm:  :scared:
How the hell did this ever got released, it feels like a pre alpha build?
Former username: NANDBlog
 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1141
  • Country: se
Re: Raspberry Pi Pico
« Reply #214 on: February 10, 2021, 11:17:58 am »
The drag the file to a USB Mass Storage Device to program is very beginner friendly. No cables and wires to hook up, no cable drivers. Seems almost impossible to brick. However it's not unique - seen it before on the BBC micro:bit.
And on every ST Nucleo board, and I think all of the mBed supported HW.
Without the need to restart board in a special mode (thanks to the integrated debug probe).
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #215 on: February 11, 2021, 02:28:22 am »
A decent (IMO) "Working with the Raspberry Pi Pico with Windows and C/C++" article/tutorial
https://www.element14.com/community/community/raspberry-pi/blog/2021/01/24/working-with-the-raspberry-pi-pico-with-windows

I particularly liked the Project template, including the CMakeLists.txt information.

I agree with the author's summary statements: "For those used to Arduino, the process may seem long-winded (which it is in comparison) but it only needs to be done once to get familiarity with it. These tools and all sorts of scripts are used by organizations to develop real products, so the knowledge gained is directly transferrable to engineering work environments"

BTW: I did download and install the project1.zip file and it worked fine and all from within vscode.
- Invest in science - it pays big dividends. -
 
The following users thanked this post: edavid, Cliff Matthews

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #216 on: February 11, 2021, 05:07:11 am »
A decent (IMO) "Working with the Raspberry Pi Pico with Windows and C/C++" article/tutorial
https://www.element14.com/community/community/raspberry-pi/blog/2021/01/24/working-with-the-raspberry-pi-pico-with-windows

I might have to give that a try - believe it or not I'm using 'vim' under Windows Subsystem for Linux and it is working fine.  :-DD

I've got my little I2S testing 'Drum machine' working with no resistance at all - https://github.com/hamsternz/PiPico_Drummer

I would like to try using a Pico as a debug interface for another Pico. That seems pretty worthwhile and inexpensive.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 
The following users thanked this post: exe

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2921
  • Country: gb
Re: Raspberry Pi Pico
« Reply #217 on: February 12, 2021, 12:45:22 am »
As time has gone on, recently. Some of the suppliers (UK, as recommended via official Raspberry PI PICO website links), which limited you to only buy a maximum of 1, and had run out of stock. Both had stock, again and increased the limit to 3.

So I've bought my first PICOs, they should be arriving soon.

At £3 + VAT (£3.60) each, plus £3 shipping (depending on which supplier, some offer free shipping, if order total is above a limit). It is not bad, for a reasonable spec'd development board(s), with decent quality, and which is well documented and supported.
Also, orderable to arrive within a day or so, rather than having to wait many weeks (potentially), if ordering from China.

I like the look of the Teensy 4.1, which has a much better specification, than the PICO. But at around £27 each (I sometimes seem to see them from around £20, upwards), it is arguably too expensive, to use in small Led flashing experiments/projects and all sorts of miscellaneous things, that need/want MCU capabilities.

It is difficult these days, to do much better than the £3.60/$4 a throw. Especially if you like/want the quick delivery, good documentation and build quality of it, compared to some of the cheap Chinese MCU development boards.

Although on paper (in theory), the cheap Chinese MCU development boards (such as the blue pills), look good. When you look at honest/detailed/accurate reviews. They seem to describe various technical difficulties, such as incorrect USB resistors, rather old cpu technology and peripheral sets, fake/clone cpus being used, which can cause incompatibilities, differences with documentation and other niggles.
Also, the USB connector, may NOT work as planned. E.g. It isn't ready to program the device (until you install a boot loader, which may need special debugging hardware connection things, although clone versions, are cheaply available on ebay, apparently), or NOT even act as a USB at all (except as a power connector).
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #218 on: February 12, 2021, 04:28:20 am »
One nice thing I saw in the Pico datasheet:

Quote
Pico uses an on-board buck-boost SMPS which is able to generate the required 3.3 volts (to power RP2040 and external
circuitry) from a wide range of input voltages (~1.8 to 5.5V). This allows significant flexibility in powering the unit from
various sources such as a single Lithium-Ion cell, or 3 AA cells in series. Battery chargers can also be very easily
integrated with the Pico powerchain.

That's a pretty nice feature not found on most small+cheap dev boards that can be USB powered - they usually have just an AM1117 or similar LDO .
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 
The following users thanked this post: thm_w, MK14

Offline imo

  • Super Contributor
  • ***
  • Posts: 2766
  • Country: li
Re: Raspberry Pi Pico
« Reply #219 on: February 12, 2021, 07:51:30 am »
One nice thing I saw in the Pico datasheet:

Quote
Pico uses an on-board buck-boost SMPS which is able to generate the required 3.3 volts (to power RP2040 and external
circuitry) from a wide range of input voltages (~1.8 to 5.5V). This allows significant flexibility in powering the unit from
various sources such as a single Lithium-Ion cell, or 3 AA cells in series. Battery chargers can also be very easily
integrated with the Pico powerchain.

That's a pretty nice feature not found on most small+cheap dev boards that can be USB powered - they usually have just an AM1117 or similar LDO .
FYI - this small not cheap :) pic32mz dev board I've been playing with uses a switcher (the TI's TPS82130 with integrated inductor) too - up to 17V in, 3.3V out and up to 3A (!) output current..
« Last Edit: February 12, 2021, 08:12:57 am by imo »
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #220 on: February 12, 2021, 07:11:31 pm »
I have been playing around a bit with the Pico as a USB device. There are a couple of programs in the examples. I do not have much experience programming USB devices and HID specifically. I am wondering if you have any thoughts/guidanc eon this particular issue....

I would like the Pico to send/receive packets (e.g., 256 bytes) to a Windows machine running a visual C (or BASIC) program. Ideally, the Pico would appear as a com port to the Visual Studio program. Something like a Human Interface Device to Com port since some of the sample USB device code is recognized by Windows.

I have been reading up and investigating, but again, I have not done this kind of thing before. Let me put it another way: take a look at this device:
https://store.ncd.io/product/usb-to-i2c-converter-adapter/

I can see a PIC12F1840 which is likely being used as an I2C interface (I have done that). Also I see an FTDI chip, which is obviously used for the Com port that windows sees. So, I am not interested in copying that board, but I am wondering if I can get that functionality using only a Pico.
 

- Invest in science - it pays big dividends. -
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #221 on: February 12, 2021, 07:34:45 pm »
I can see a PIC12F1840 which is likely being used as an I2C interface (I have done that). Also I see an FTDI chip, which is obviously used for the Com port that windows sees.

Could've been done with a single PIC16F1454 chip.

So, I am not interested in copying that board, but I am wondering if I can get that functionality using only a Pico.

I think so. Their USB controller seems very generic. You can use either CDC (serial port emulation) class or HID class.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #222 on: February 12, 2021, 08:56:33 pm »
Quote
Ideally, the Pico would appear as a com port to the Visual Studio program. Something like a Human Interface Device to Com port since some of the sample USB device code is recognized by Windows.
To appear as a COM port, without writing windows-side drivers, the Pico should implement a CDC/ACM "device."  The Pico folks have already implemented this; it shows up somewhere in the build process as "use USB as STDIO" or something like that.  Note that a COM port implements a byte stream, so it doesn't preserver "packetization."
The other common thing is a HID interface, which does preserver "messages", and can be accessed with one of several PC-side application-level libraries (libusb.)  However, the maximum message size for a HID device is 64 bytes.
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #223 on: February 12, 2021, 09:14:45 pm »
Quote
Ideally, the Pico would appear as a com port to the Visual Studio program. Something like a Human Interface Device to Com port since some of the sample USB device code is recognized by Windows.
To appear as a COM port, without writing windows-side drivers, the Pico should implement a CDC/ACM "device."  The Pico folks have already implemented this; it shows up somewhere in the build process as "use USB as STDIO" or something like that.  Note that a COM port implements a byte stream, so it doesn't preserver "packetization."
The other common thing is a HID interface, which does preserver "messages", and can be accessed with one of several PC-side application-level libraries (libusb.)  However, the maximum message size for a HID device is 64 bytes.

So, I am dealing with those issues as we speak. On a Win 7-64 if I run USB-Hello_world it (win 7) will recognize it and load usbser.sys EDIT: It will NOT automagically load USBser.sys, it sees it as a device and doesn't know what to do., but you, apparently need to do some virtual com port crap and such and such with Win. https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-driver-installation-based-on-compatible-ids

So, based on that minimal experience, I am thinking that a CDC device would not be as good as a legitimate HID dev. I can run the example dev_hid_composite and muck a bit with a mouse - no additional window-side coaxing needed.


I don't know, I need to do more studying and experimenting, but I appreciate anyone's help on the issues.

Edited again: I think I will try forcing it to do what I want with an .inf file. - will report results.
« Last Edit: February 12, 2021, 10:00:33 pm by DrG »
- Invest in science - it pays big dividends. -
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2491
  • Country: ca
Re: Raspberry Pi Pico
« Reply #224 on: February 12, 2021, 11:24:39 pm »
So, I am dealing with those issues as we speak. On a Win 7-64 if I run USB-Hello_world it (win 7) will recognize it and load usbser.sys EDIT: It will NOT automagically load USBser.sys, it sees it as a device and doesn't know what to do., but you, apparently need to do some virtual com port crap and such and such with Win. https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-driver-installation-based-on-compatible-ids

Newer versions of Windows have built-in CDC drivers. HID is more universal, but communicating with a HID device requires a little bit more work on the PC side.
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #225 on: February 12, 2021, 11:57:03 pm »
Here is where I am at (and if I don't get it solved soon, I should probably make it a separate thread).

I successfully build hello_usb, - you can see the code here https://github.com/raspberrypi/pico-examples/blob/master/hello_world/usb/hello_usb.c it simply prints out "Hello World" repeatedly. Win 7-64.

I drop hello_usb.uf2 into the Pico it shows up in Device manager as Board CDC - and the all-to-common yellow exclamation point of doom.

Working from here, I made an .inf file from the Microchip COM driver by substituting lines as the thread messages discuss https://www.raspberrypi.org/forums/viewtopic.php?t=300633

But, when I try to update the driver manually and point to the directory containing the modified .inf, there is no joy - it simply says it can't install.

I made the changes carefully and did it twice.

I have tried mucking around a bit with the [Strings] section to match Board CDC to no avail. I have forgotten what little I ever knew about the internals of device drivers on win 7.

Presence or absence of usbser.sys in the directory containing the .inf makes no difference.

Turning off av makes no difference.

Not sure what I am missing.
« Last Edit: February 13, 2021, 12:00:28 am by DrG »
- Invest in science - it pays big dividends. -
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1199
  • Country: fi
Re: Raspberry Pi Pico
« Reply #226 on: February 13, 2021, 12:19:14 am »
I haven't done much Windows driver work, but IIRC from some version (Vista?) onwards, it will refuse to load unsigned drivers (including .infs), unless it's disabled in the boot options.

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #227 on: February 13, 2021, 01:01:16 am »
I haven't done much Windows driver work, but IIRC from some version (Vista?) onwards, it will refuse to load unsigned drivers (including .infs), unless it's disabled in the boot options.

True and that would have been nice  :) but alas, no joy (disabled in boot long ago).
- Invest in science - it pays big dividends. -
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #228 on: February 13, 2021, 01:37:12 am »
Joy!




I ended up selecting the driver from a list of all of them on the drive. Found Microchip's USB serial Port - and it worked.



Not sure why exactly. Maybe the .inf needed a default section to find stuff or some such thing - or maybe I just missed something very basic.
« Last Edit: February 13, 2021, 03:24:24 pm by DrG »
- Invest in science - it pays big dividends. -
 

Offline Cliff Matthews

  • Supporter
  • ****
  • Posts: 1877
  • Country: ca
    • General Repair and Support
Re: Raspberry Pi Pico
« Reply #229 on: February 13, 2021, 04:26:45 am »
Cough.. Mine is working too. Well at least I got the LED working.. But there's no end to the weirdness in device manager..
 

Offline PCB.Wiz

  • Frequent Contributor
  • **
  • Posts: 462
  • Country: au
Re: Raspberry Pi Pico
« Reply #230 on: February 16, 2021, 10:38:47 pm »
I don't know, I need to do more studying and experimenting, but I appreciate anyone's help on the issues.

google finds this, which maybe of use to you ?
https://github.com/Noltari/pico-uart-bridge


Raspberry Pi Pico USB-UART Bridge
This program bridges the Raspberry Pi Pico HW UARTs to two independent USB CDC serial devices in order to behave like any other USB-to-UART Bridge controllers.


and a thread here
https://www.raspberrypi.org/forums/viewtopic.php?t=302684

However, I do not see mention of any test results, covering tested baud ranges and actual throughputs ?
It would be nice to see a FT232H or FT2232H connected to a Pico, and then things pushed, to see where they break :)

With only USB-FS speeds, the UARTS are likely to only be good for low-MBd region speeds, but Pico may be nice as a more-flexible-than-FTDI type solution.

 
« Last Edit: February 18, 2021, 01:38:33 am by PCB.Wiz »
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #231 on: February 16, 2021, 11:03:06 pm »
So in the last few days I took it out for a spin and tested the board. I used it to test an I2C sensor, and I used the Circuitpython implementation.
It was super fast to test or debug code. I had the script open in Notepad++ and putty was monitoring the serial port. Every time I saved the notepad++ file, the pi rebooted and run the script and it spit out the result into the terminal. If I wanted some help or run some other command, I just used REPL for it.
Once a code was modified, it was running on the microcontroller in less than a second. Less than a second! In C if you press compile, and upload it takes quite some time to test your code, I guess every code change takes well over a minute. Not to mention I could write statements, like print( "0x34 register: "+ str(readI2C(0x34))) and it would just spit the value to the terminal. No worries about pointers, easy casting of data types. If you ever have to  write code with the itoa function with a buffer created manually, you know what I mean.
I really felt like concentrating on the sensor, and the physical arrangement and the engineering. Instead of writing code, worrying about pointers and looking up ways to solve trivial programming problems.
Former username: NANDBlog
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 2223
  • Country: nz
  • Formerly SiFive, Samsung R&D
Re: Raspberry Pi Pico
« Reply #232 on: February 16, 2021, 11:35:58 pm »
How on earth do you get C program turn-around to be "well over a minute"?

Using, for example, the Arduino IDE with an AVR Arduino, a Hifive1, a Teensy 4.0 ... in every case it's more than a second from hitting "Compiler & Run" to having it running on the board, but for typical sized programs well under 5 seconds. I've never actually thought to time it, because it's just no big deal.

It's the same using command line tools such as gcc and avrdude or openocd -- which, after all, is what the IDE uses under the hood anyway.
 

Offline artag

  • Frequent Contributor
  • **
  • Posts: 657
  • Country: gb
Re: Raspberry Pi Pico
« Reply #233 on: February 17, 2021, 01:16:18 am »
Maybe he's not using AVR?
ESP devices are painfully slow to compile, and Teensies can be fairly slow (perhaps partially because they can hold a lot of code).
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2475
  • Country: nz
Re: Raspberry Pi Pico
« Reply #234 on: February 17, 2021, 01:30:11 am »
The Pico C/C++ SDK is quite nice, in that through cmake magic it only builds the bits you need, and it does do minimal incremental builds.

Last time I used ESP32's ESP-IDF it was pretty slow for the first build..

I haven't set up the Pico to use a H/W debugger yet. Even without one it takes longer for me to reset the Pico into programming mode than it does to build after a trivial code change.
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #235 on: February 17, 2021, 01:50:08 am »
I don't know, I need to do more studying and experimenting, but I appreciate anyone's help on the issues.

google finds this, which maybe of use to you ?
https://github.com/Noltari/pico-uart-bridge


Raspberry Pi Pico USB-UART Bridge
This program bridges the Raspberry Pi Pico HW UARTs to two independent USB CDC serial devices in order to behave like any other USB-to-UART Bridge controllers.


and a thread here
https://www.raspberrypi.org/forums/viewtopic.php?t=302684

However, I do not see mention of any test results, covering tested baud ranges and actual throughputs ?
It would be nice to see a FT232H or FT2232H connected to a Pico, and then things pushed, to see where they break :)

With only USB-FS speeds, the UARTS are likely to only be good for low-Md region speeds, but Pico may be nice as a more-flexible-than-FTDI type solution.

Thanks, I took a look, bookmarked it and wandered through the thread. The problem I was having was simply gettimg WIN 7 to load up usbser and eventually I got that to work.

When I get something like this (I have no RPi experience), I like to think about some project that is worthwhile that I can get into. So, basically, I just want the Pico on a board that contains, for example, an I2C sensor. The board with sensor is attached to a PC. A nice, easy to use, program running on the PC allows you to set the sensor's memory/variables. Take, for example, some of the Honeywell T/H sensors where you can set alarm levels- that sort of thing.

You plug the board in (with the sensor in a socket), do whatever you need to do, pop the sensor out, and your done. Once you have a VS program working, they work rather nicely, I think.

The Pico plugs into the PC, communicating as a serial port (with no additional board). User reads and writes settings, which the Pico programs into the sensor using its I2C interface. All you need is the socket and a couple of simple components (a couple of resistors and capacitors).

Makes it pretty attractive for only a few bucks, I think. In fact, at the sale price of US$2, they are about as cheap as any FTDI USB/serial board alone.

That guy's program that you linked to makes multiple USB serial ports, which as mentioned in the thread, has some uses as well.
« Last Edit: February 17, 2021, 04:28:00 am by DrG »
- Invest in science - it pays big dividends. -
 

Offline exe

  • Supporter
  • ****
  • Posts: 2303
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #236 on: February 17, 2021, 09:06:17 am »
Does anyone have rp2040 as a component that I could use in diptrace? I can surely draw it myself, but I'd prefer not to take risks.
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 5480
  • Country: nl
  • Current job: ATEX certified product design
Re: Raspberry Pi Pico
« Reply #237 on: February 17, 2021, 09:36:53 am »
How on earth do you get C program turn-around to be "well over a minute"?

Using, for example, the Arduino IDE with an AVR Arduino, a Hifive1, a Teensy 4.0 ... in every case it's more than a second from hitting "Compiler & Run" to having it running on the board, but for typical sized programs well under 5 seconds. I've never actually thought to time it, because it's just no big deal.

It's the same using command line tools such as gcc and avrdude or openocd -- which, after all, is what the IDE uses under the hood anyway.
I took an example project with similar complexity (LIS3DSH Fifoexample) of 10 seconds to compile to an Arduino Due (which is an M0). Upload in my experience takes at least a few seconds. Then you need to manually close the serial terminal and try the upload again, because  before uploading it, open it again, it defaults to 9600 baud, you change the baudrate, and then your code is running.
Maybe not an entire minute, but compare all this with just pressing Ctrl+s -> code is running.
Former username: NANDBlog
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Raspberry Pi Pico
« Reply #238 on: February 17, 2021, 09:41:03 am »
A very preliminary release of the new Mecrisp-Stellaris-Pico Forth has been released for Forth fans:
https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/Mecrisp-Stellaris-Pico-17feb2001.tar.gz

Plus an Assembly .equ file (transformed from the rp2040 SVD) is here:-
https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/RP2040.svd.equates.s.gz

https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/RP2040.svd.equates-with-descriptions.s.gz

I don't have a Pico myself, so haven't tried it but I believe this runs on one cpu and uses a USART for terminal comms. I expect that terminal comms over SWD won't be long coming.

This release has s31.32 fixed point numbers as with all Mecrisp-Stellaris Forths.

The obligatory Blinky:

Code: [Select]
$40014000 constant IO_BANK0_BASE
$4001c000 constant PADS_BANK0_BASE
$d0000000 constant SIO_BASE

\ Already configured in core for SIO (Software IO), function 5:

\ IO_BANK0_BASE 0 8 * +     constant GPIO_0_STATUS
\ IO_BANK0_BASE 0 8 * + 4 + constant GPIO_0_CTRL
\ IO_BANK0_BASE 1 8 * +     constant GPIO_1_STATUS
\ IO_BANK0_BASE 1 8 * + 4 + constant GPIO_1_CTRL
\ ...

SIO_BASE $004 + constant GPIO_IN       \ Input value for GPIO pins
SIO_BASE $010 + constant GPIO_OUT      \ GPIO output value
SIO_BASE $014 + constant GPIO_OUT_SET  \ GPIO output value set
SIO_BASE $018 + constant GPIO_OUT_CLR  \ GPIO output value clear
SIO_BASE $01c + constant GPIO_OUT_XOR  \ GPIO output value XOR
SIO_BASE $020 + constant GPIO_OE       \ GPIO output enable
SIO_BASE $024 + constant GPIO_OE_SET   \ GPIO output enable set
SIO_BASE $028 + constant GPIO_OE_CLR   \ GPIO output enable clear
SIO_BASE $02c + constant GPIO_OE_XOR   \ GPIO output enable XOR

: blinky ( -- )

  1 25 lshift GPIO_OE !

  begin
    1 25 lshift GPIO_OUT_XOR !
    10000000 0 do loop
  key? until
;
 
The following users thanked this post: newbrain, imo

Offline imo

  • Super Contributor
  • ***
  • Posts: 2766
  • Country: li
Re: Raspberry Pi Pico
« Reply #239 on: February 17, 2021, 09:41:19 am »
I took an example project with similar complexity (LIS3DSH Fifoexample) of 10 seconds to compile to an Arduino Due (which is an M0)..
M3
 
The following users thanked this post: tszaboo

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #240 on: February 17, 2021, 03:27:10 pm »
Arduino Nano RP2040 Connect

https://blog.arduino.cc/2021/01/20/welcome-raspberry-pi-to-the-world-of-microcontrollers/

Apparently, a few are out there https://www.tomshardware.com/news/first-pi-silicon-arduino-nano-rp2040-connect-spotted

I don't see what the price is/will be, but I wonder how it compares with their Nano 33 IOT https://store.arduino.cc/usa/nano-33-iot
« Last Edit: February 17, 2021, 03:29:26 pm by DrG »
- Invest in science - it pays big dividends. -
 

Offline josip

  • Regular Contributor
  • *
  • Posts: 84
  • Country: hr
Re: Raspberry Pi Pico
« Reply #241 on: February 17, 2021, 03:53:49 pm »

However, I do not see mention of any test results, covering tested baud ranges and actual throughputs ?
It would be nice to see a FT232H or FT2232H connected to a Pico, and then things pushed, to see where they break :)

With only USB-FS speeds, the UARTS are likely to only be good for low-Md region speeds, but Pico may be nice as a more-flexible-than-FTDI type solution.

I made dual CDC UART bridge based on MSP430F5510, that was able to reach 4 Mbps (in parallel). I am not sure that this belong to "low-Md region speeds". And pico with dual 100MHz core can eat 25MHz MSP for breakfast.

And again, USB-FS is not a problem. Bloated code is.

« Last Edit: February 17, 2021, 03:58:28 pm by josip »
 

Offline PCB.Wiz

  • Frequent Contributor
  • **
  • Posts: 462
  • Country: au
Re: Raspberry Pi Pico
« Reply #242 on: February 18, 2021, 01:44:27 am »
I made dual CDC UART bridge based on MSP430F5510, that was able to reach 4 Mbps (in parallel).

Was that sustained 4Mbd in both channels, and both duplex, (impossible, as that's 16M of data flow),  or peak speeds of 4MBd going one way, in one channel (possible) ?

.... And pico with dual 100MHz core can eat 25MHz MSP for breakfast.
And again, USB-FS is not a problem. Bloated code is.

Hmm... not sure how you can so easily ignore a 12MB limit on the FS-USB so easily, Best numbers I've seen/tested for USB bridges on FS-USB come in around 9MBd one way tops, as that's the USB bandwidth limit. 
Even a 1GHz processor, does not make that 12MHz FS-USB ceiling vanish :)
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 3454
  • Country: us
Re: Raspberry Pi Pico
« Reply #243 on: February 18, 2021, 02:26:41 am »
Quote
not sure how you can so easily ignore a 12MB limit on the FS-USB so easily
When I was a lad... we ran FILESYSTEM STORAGE over 10Mb Ethernet.  And 16MB of RAM was heavenly (and expensive!)

What is it you want to do with your Pico that the 12Mbps ceiling is a problem?  That'd fill up the RAM in 0.2s, and the flash in less than 2s...
 
The following users thanked this post: JPortici, Jacon

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 2223
  • Country: nz
  • Formerly SiFive, Samsung R&D
Re: Raspberry Pi Pico
« Reply #244 on: February 18, 2021, 09:08:49 am »
You must be young.

When I started university the computer 1st year students programmed on was an 11/34 with 256 KB RAM, with 22 VT52 terminals and 2 LA120 printers. And two 5 MB disks.

A couple of years later the main university computer was an 11/780 with 2 MB RAM and up to 50 people logged on during working hours. That sucked, but it went quite well at 2 AM with 10 or fewer people on it.

My first job had a similarly spec'd DG MV10000 with a similar number of users.

As soon as it was possible, I got all my own users (analysts writing research reports on companies) onto Mac Plus with 1 MB and a LaserWriter instead of output going via an IBM DisplayWriter system to a daisywheel printer and then hand pasting graphs and charts from an HP plotter. I got them upgraded to 2.5 MB as soon as 1 MB DIMMs were available, and to 4 MB once the accountant recovered from the heart attack. Custom app development went *much* faster once I was able to do it on a Mac II, even though I only had 4 MB for quite some time -- that machine was a real beast for the time.

I don't think I had anything with as much as 16 MB RAM until either the Quadra 700 in late 1991, or the PowerMac 6100 in 1994 -- I actually can't remember which one now. 4 MB was standard on the Quadra and the 6100  came with 8 MB soldered on the motherboard and 2 empty slots. Both could theoretically upgraded to a lot more -- even 1989's Mac IIx, IIcx, SE/30 could be theoretically upgraded to 128 MB, but that would cost as much as a cheap BMW.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 2223
  • Country: nz
  • Formerly SiFive, Samsung R&D
Re: Raspberry Pi Pico
« Reply #245 on: February 18, 2021, 09:15:50 am »
Oh and we kept documents on a fileserver with a 230.4 kbps network at first, with 10baseT a very welcome upgrade when it arrived.
 

Offline josip

  • Regular Contributor
  • *
  • Posts: 84
  • Country: hr
Re: Raspberry Pi Pico
« Reply #246 on: February 18, 2021, 09:20:08 am »

Was that sustained 4Mbd in both channels, and both duplex, (impossible, as that's 16M of data flow),  or peak speeds of 4MBd going one way, in one channel (possible) ?

Hmm... not sure how you can so easily ignore a 12MB limit on the FS-USB so easily, Best numbers I've seen/tested for USB bridges on FS-USB come in around 9MBd one way tops, as that's the USB bandwidth limit. 
Even a 1GHz processor, does not make that 12MHz FS-USB ceiling vanish :)

I am using bridges only for fast log from free running micro's. My target was half duplex, from free running micro to PC over my MSP430 bridge. For testing both micros was firing at highest possible speed (4Mbps) ASCII incremented characters, and on PC side there was checking what was received. I left it for more than 10 minutes, and there was no errors. Both bridges active in half duplex.

I don't remember if I test it (on the same way) for full duplex, but I guess that 2Mbps with both active bridges shouldn't be a problem, Because transfer from PC to micro's need less micro power (instruction cycles) with DMA firing 64 byte CDC packet to UART, byte by byte.

PL2303HXD is 12Mbps 20 years old FS USB device.
 

Offline guenthert

  • Frequent Contributor
  • **
  • Posts: 496
  • Country: us
Re: Raspberry Pi Pico
« Reply #247 on: February 18, 2021, 04:47:57 pm »
Oh and we kept documents on a fileserver with a 230.4 kbps network at first, with 10baseT a very welcome upgrade when it arrived.
     Let me guess, Macs connected via AppleTalk?  That must have been mid to late eighties.  LANs existed earlier, but were uncommon.  Sneakernet across PCs and terminals connected to minis/mainframes more typical then.  But we digress  :-DD

     Yeah, I too like to know, what problem the Pico is supposed to solve with USB HS, which it can't with FS.  That we don't get Guinness records breaking bleeding edge technology for $4 shouldn't be much a surprise.
« Last Edit: February 19, 2021, 12:42:08 am by guenthert »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 6846
  • Country: fr
Re: Raspberry Pi Pico
« Reply #248 on: February 18, 2021, 05:06:31 pm »
I'm not as old, but at Uni in the 90's we were still using coax ethernet.
 

Offline DrG

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: us
Re: Raspberry Pi Pico
« Reply #249 on: February 18, 2021, 05:31:47 pm »

 

:)
« Last Edit: February 18, 2021, 05:35:23 pm by DrG »
- Invest in science - it pays big dividends. -
 
The following users thanked this post: exe, newbrain, MK14, Jacon

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 2223
  • Country: nz
  • Formerly SiFive, Samsung R&D