Author Topic: Raspberry Pi Pico  (Read 74654 times)

0 Members and 1 Guest are viewing this topic.

Online tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.

 
The following users thanked this post: MK14, Microdoser

Online tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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 »
 
The following users thanked this post: hans, thm_w, newbrain

Offline kjw

  • Newbie
  • Posts: 4
  • 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

  • Frequent Contributor
  • **
  • Posts: 294
  • 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: 245
  • 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: 245
  • Country: no
Re: Raspberry Pi Pico
« Reply #5 on: January 21, 2021, 12:37:29 pm »
 

Online up8051

  • Frequent Contributor
  • **
  • Posts: 288
  • 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_

Offline aheid

  • Regular Contributor
  • *
  • Posts: 245
  • 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: 245
  • 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: 245
  • 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.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4922
  • 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: 3063
  • 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: 3452
  • 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: 1910
  • 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: 4136
  • 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: 7990
  • 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

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • 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.
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • 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: 11228
  • 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: 117
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.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • 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: 11228
  • 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
 
The following users thanked this post: elecdonia

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • 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: 11228
  • 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

  • Super Contributor
  • ***
  • Posts: 1029
  • 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.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • 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 »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • 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: 4527
  • 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: 11228
  • 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

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • 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: 2803
  • 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: 11228
  • 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: 4527
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.

 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • 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: 1154
  • 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: 218
  • 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

  • Super Contributor
  • ***
  • Posts: 1061
  • 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

  • Super Contributor
  • ***
  • Posts: 1473
  • 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: 4196
  • 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: 4527
  • 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: 11228
  • 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: 2803
  • 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: 4527
  • 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: 4527
  • 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: 245
  • 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: 4527
  • 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: 4
  • 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: 4196
  • 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

  • Super Contributor
  • ***
  • Posts: 1027
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 11228
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 87
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: 3137
  • 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: 11228
  • 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: 149
  • 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: 1198
  • 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: 1198
  • 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.

Online mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • 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

  • Super Contributor
  • ***
  • Posts: 1061
  • 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: 1626
  • 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: 4675
  • Country: nr
  • It's important to try new things..
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: 706
  • Country: de
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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 2616
  • 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: 6877
  • 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: 1198
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 1626
  • 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: 11228
  • 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: 591
  • 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: 11228
  • 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: 221
  • Country: au
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: 591
  • 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: 2616
  • 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: 221
  • Country: au
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: 706
  • Country: de
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: 2803
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 2616
  • 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: 11228
  • 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: 2803
  • 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

  • Newbie
  • 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

  • Frequent Contributor
  • **
  • Posts: 321
  • 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. (:-)

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • 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

Offline cv007

  • Frequent Contributor
  • **
  • Posts: 822
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.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • 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: 1198
  • 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: 1910
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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

  • Regular Contributor
  • *
  • Posts: 63
  • 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.
 

Online mikerj

  • Super Contributor
  • ***
  • Posts: 3233
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 

Offline Jan Audio

  • Frequent Contributor
  • **
  • Posts: 820
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 3137
  • 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: 2616
  • 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: 4196
  • 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: 3452
  • 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: 1198
  • 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: 2803
  • 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: 11228
  • 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: 1198
  • 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: 245
  • 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: 3137
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 

Offline Tagli

  • Contributor
  • Posts: 31
  • 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: 3137
  • 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

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • 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: 3996
  • Country: nz
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: 4196
  • 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: 11228
  • 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: 4196
  • 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: 11228
  • 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
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • 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: 11228
  • 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
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • 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: 2803
  • 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.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • 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: 2803
  • 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

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • 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: 3996
  • Country: nz
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: 2616
  • 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: 2803
  • 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: 149
  • 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: 3996
  • Country: nz
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: 3137
  • 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: 3137
  • 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: 1626
  • 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 »
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • 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: 245
  • 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: 3137
  • 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: 3137
  • 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.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • 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: 3137
  • 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: 2803
  • 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: 4196
  • 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: 4196
  • 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: 2616
  • 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: 3137
  • 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: 3996
  • Country: nz
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: 2616
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 161
  • 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: 3996
  • Country: nz
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: 161
  • 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: 160
  • 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

  • Regular Contributor
  • *
  • Posts: 63
  • 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

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • 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

Offline Tagli

  • Contributor
  • Posts: 31
  • 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: 11228
  • 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: 4196
  • 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: 4196
  • 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

  • Newbie
  • 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.
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • 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: 2559
  • 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.
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • 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.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • 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: 95
  • 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: 2559
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • 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: 2803
  • 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.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • 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: 4527
  • 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: 706
  • Country: de
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: 4527
  • 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: 2559
  • 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: 4527
  • 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: 4527
  • 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: 11228
  • 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: 4527
  • 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 »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • 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: 4527
  • 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: 2559
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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 »
 
The following users thanked this post: thm_w, MK14

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • 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.
 

Offline Tagli

  • Contributor
  • Posts: 31
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 

Offline yann

  • Newbie
  • 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: 2559
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 

Offline yann

  • Newbie
  • 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: 4527
  • 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

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • 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.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • 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: 2559
  • 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: 2559
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 
The following users thanked this post: newbrain

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • 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.)
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • 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: 2559
  • 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: 23
  • 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: 23
  • 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: 3137
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • 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: 3137
  • 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?
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 479
  • 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

  • Super Contributor
  • ***
  • Posts: 1029
  • 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: 2803
  • 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: 2559
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 

Online tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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?
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 2803
  • 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: 4527
  • 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: 2803
  • 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: 4675
  • Country: nr
  • It's important to try new things..
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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 3137
  • 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: 4196
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 3137
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 1198
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 1910
  • 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

  • Super Contributor
  • ***
  • Posts: 1473
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
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

  • Super Contributor
  • ***
  • Posts: 1061
  • 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: 2803
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 2559
  • 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 tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX 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.
 

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: 4675
  • Country: nr
  • It's important to try new things..
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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 149
  • 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

  • Super Contributor
  • ***
  • Posts: 1473
  • 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: 4196
  • 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: 3996
  • Country: nz
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: 3996
  • Country: nz
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: 149
  • 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: 706
  • Country: de
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 »
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • 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

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • 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: 3996
  • Country: nz
Re: Raspberry Pi Pico
« Reply #250 on: February 18, 2021, 08:20:24 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

Yup. That was slow as it used the UART in self-clocking mode. There were 3rd party adaptors that used the same phone cable wiring for 1 Mbps by having actual active circuitry that supplied an external clock to the serial port.

Still, it was 2005 before I had home internet that was faster than 230.4 kbps.

x86 PCs in the late 80s didn't tend to have networking at all. Novell Netware existed from 1983 but that wasn't a peer-to-peer network in the current sense. You got a 68000-based central server and every PC had its own cable to the server with just a simple 1:1 protocol running over that. The server provided file sharing and printing. I don't recall PC to PC messages being possible. Novell introduced a completely different peer to peer networking product in 1991.
 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #251 on: February 18, 2021, 09:27:41 pm »
According to [1] there is newer version of the chip. Also, availability of bare ICs seems to be Q2.

[1] https://www.tomshardware.com/news/raspberry-pi-pico-silicon-heading-to-partners
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Raspberry Pi Pico
« Reply #252 on: February 19, 2021, 12:02:33 am »
Quote
You must be young.
Well, I go back further, but I'm specifically referencing about ~1984 at Stanford, which is about when they were deploying "diskless" Sun-2 Pizza-boxes, expected to do all their file access over the Ethernet.  (16MB RAM seems to be later, according to wikipedia.  The SmallTalk folks needed it.)I guess the price of small disks went down fast enough that "diskless" was a pretty short-lived philosophy.
 

Offline PCB.Wiz

  • Super Contributor
  • ***
  • Posts: 1473
  • Country: au
Re: Raspberry Pi Pico
« Reply #253 on: February 19, 2021, 12:39:03 am »
PL2303HXD is 12Mbps 20 years old FS USB device.

Did you test throughput on that ?

Another thread on here, says this,
"IIRC, PL2303 could transmit well over 2Mb/s and bitrates above 3Mb/s made pretty much no difference to throughput."
which suggests the 12M BAUD setting is nominal (char only), with firmware not able to get anywhere close to sustained speeds.

There is a new PL2303GS family, I'd like to get my hands on to test, but so far, sourcing is not easy. One hopes they improved something on the re-spin.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Raspberry Pi Pico
« Reply #254 on: February 19, 2021, 07:28:38 am »
I found something to complain about!

The RP2040 doesn't use the standard core_m0plus.h CMSIS definitions.  Instead, they've got their own names and values for the m0 core pieces.
For example "systick_hw->csr" instead of "SysTick->CTRL"

There's an "issue" open, but they seem oddly resistant: https://github.com/raspberrypi/pico-sdk/issues/21

Out of curiosity, has anyone run into ANY other CM0 vendor that doesn't use the ARM-provided CMSIS-CORE files?

 
The following users thanked this post: newbrain

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #255 on: February 19, 2021, 04:57:16 pm »
I found something to complain about!

The RP2040 doesn't use the standard core_m0plus.h CMSIS definitions.  Instead, they've got their own names and values for the m0 core pieces.
For example "systick_hw->csr" instead of "SysTick->CTRL"

There's an "issue" open, but they seem oddly resistant: https://github.com/raspberrypi/pico-sdk/issues/21

Out of curiosity, has anyone run into ANY other CM0 vendor that doesn't use the ARM-provided CMSIS-CORE files?

This is odd. I wonder what's RPi's rationale for not using CMSIS.

And no, I've never run into another vendor doing this.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Raspberry Pi Pico
« Reply #256 on: February 19, 2021, 07:29:39 pm »
Quote
I wonder what's RPi's rationale for not using CMSIS.
They seems to have been unaware of its significance?    That's a little odd, but somewhat understandable in the "python computer company builds its first microcontroller" context.
It did make me wonder how Atmel (for example) extracts their symbol definitions EXCEPT FOR the stuff already in the core from their SVD/ATDF/whatever "master" files.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #257 on: February 19, 2021, 07:41:37 pm »
Quote
I wonder what's RPi's rationale for not using CMSIS.
They seems to have been unaware of its significance?    That's a little odd, but somewhat understandable in the "python computer company builds its first microcontroller" context.

Well, the fact they went for an ARM core means they have paid (likely a fair amount) and have gotten support from ARM. I've never directly worked with ARM myself, but I would actually expect to get from ARM a minimal set of CMSIS files for the core I was buying. So choosing not to use those and rewrite my own base support would be odd. Now I'd be curious to have feedback from people who have actually worked with ARM, licensed some ARM core and tell us what kind of support they got.
 

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 #258 on: February 20, 2021, 02:36:07 am »
I found something to complain about!

The RP2040 doesn't use the standard core_m0plus.h CMSIS definitions.  Instead, they've got their own names and values for the m0 core pieces.
For example "systick_hw->csr" instead of "SysTick->CTRL"

There's an "issue" open, but they seem oddly resistant: https://github.com/raspberrypi/pico-sdk/issues/21

Out of curiosity, has anyone run into ANY other CM0 vendor that doesn't use the ARM-provided CMSIS-CORE files?

This is odd. I wonder what's RPi's rationale for not using CMSIS.

And no, I've never run into another vendor doing this.

I transform STM32 SVD's for many Cortex-M's supported by Mecrisp-Stellaris Forth so I have some experience here, especially now that Mecrisp-Stellaris has been ported to the RP2040 by Matthias Koch and Jan Bramkamp.

Nordic vary slightly in that unlike STM who give their bitfield offsets like so:

Code: [Select]
<bitOffset>1</bitOffset>
<bitWidth>1</bitWidth>

Nordic do it this way:

 
Code: [Select]
<lsb>7</lsb>
 <msb>7</msb>

Which meant a little extra computing in the XSLT parser.

However the RP2040 Pico SVD is so different that I had to start again from scratch  writing a totally different set of XLST recipes.

Because of this I have only made a rough and incomplete assembly .equ file for it  so far:

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

There is a TON of information in the RP2040 SVD but it looks to me as though the RPI engineers didn't look at the STM or Nordic SVD's and did their own from scratch . The description fields seem very well done apart from a ton of "\n".

At first I wasn't that impressed by the RP2040, and I still have no use case for it myself, but as I have been talking to the Forth guys using it, and reading the SVD data, I have become very impressed with this chip.

Very clever and inventive minds have worked on the RP2040 and it shows, imho. I now think that it may become a classic in its own right.

Those using it tell me it feels more like a M4 than a M0.

 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #259 on: February 20, 2021, 05:41:17 pm »
I dunno again how the team wrote the support files, but SVD itself is part of the CMSIS spec: https://arm-software.github.io/CMSIS_5/SVD/html/index.html
You can check whether RPi's approach is conforming.
 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #260 on: February 21, 2021, 02:24:42 pm »
I tried to use PIO modules as SPI. Here are some results.

1. I connected "nokia monochrome lcd" display, created SPIPIO instance, it doesn't work :(. Figuring out why, hooked an oscilloscope.

2. The gap between transmissions of each byte is drastically different. If I use machine.SPI, the pause between bytes is 2us. With PIOSPI class it's 40us. The data rate appears to be the same, 1us per bit. Perhaps, that's because feeding buffer in Python loop byte-by-byte is inefficient. The good news is, it probably can be optimized with a bit of C code or something.

3. The example code provided in the datasheet is incorrect, python methods are missing "self" argument: https://github.com/raspberrypi/pico-micropython-examples/blob/master/pio/pio_spi.py .
 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #261 on: February 21, 2021, 03:19:34 pm »
I did a bit of more testing and I found the problem: there is no data from MOSI pin. I had to add `mode=Pin.OUT` to initialization code to MOSI (into PIOSPI class initialization), but it helped only partially: the pin is simply held low when transmitting. That was with state machine' id=0. If I change it to 1 without rebooting device, then it seems I see an interaction of two state machines: I see somewhat interleaved data. Still nothing like SPI output. Hmm...
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Raspberry Pi Pico
« Reply #262 on: February 21, 2021, 04:40:31 pm »
Perhaps, that's because feeding buffer in Python loop byte-by-byte is inefficient. The good news is, it probably can be optimized with a bit of C code or something.

PIO has FIFOs which I think can be fed with DMA. Thus, you should be able to set everything up without any CPU involvement (except for reloading DMA).

PIO can run much faster than 1 MHz, so there shouldn't be any problem eliminating gaps between bytes with 1 MHz SPI.
 
The following users thanked this post: exe

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #263 on: February 21, 2021, 06:10:28 pm »
Oh boy, I think their PIO SPI example for micropython is non-functional. I can't wrap my head what's wrong with it, but I suspect the code expects to automatically lower SS pin, but that was only partially implemented (SS pin is not passed to state machine, but somehow it starts toggling MOSI pin instead). This is the code that I wrote after studying examples for C api. Last two lines are actually the implementation, rest is some initialization code.

Quote
@rp2.asm_pio(
    out_shiftdir=0,
    autopull=True,
    pull_thresh=8,
    autopush=True,
    push_thresh=8,
    sideset_init=rp2.PIO.OUT_LOW,
    out_init=rp2.PIO.OUT_LOW)
def spi_cpha0():
    out(pins, 1)             .side(0x0)
    in_(pins, 1)             .side(0x1) [1]

The code I took "for inspiration" is this: https://github.com/raspberrypi/pico-examples/blob/master/pio/spi/spi.pio .

EDIT the code is not checked for correctness, use at your own risk. I only checked with an oscilloscope that it produces some wiggly lines looking like SPI.
« Last Edit: February 21, 2021, 06:21:20 pm by exe »
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: Raspberry Pi Pico
« Reply #264 on: February 21, 2021, 07:40:13 pm »
Just two little notes:

1. There's one thing they really got right with the Pico board: Pin numbering and GNDs!
Most dev boards have very few GNDs and in awkward places, and GPIO pins are often all over the place, the pinout of Pico really nails it.

2. If you like to live on the edge, there is now preliminary support for both RP2040 and the Picoprobe debugger in a feature fork of pyOCD. I'm guilty for the Picoprobe part. It seems to work well inside VS Code. Picoprobe requires libusb (I use libusb0 (v1.2.6.0) as provided by Zadig) under Windows.
Nandemo wa shiranai wa yo, shitteru koto dake.
 
The following users thanked this post: exe

Offline EasyGoing1

  • Regular Contributor
  • *
  • Posts: 50
  • Country: us
Re: Raspberry Pi Pico
« Reply #265 on: February 25, 2021, 12:03:35 pm »
1. There's one thing they really got right with the Pico board: Pin numbering and GNDs!
Interesting because I felt that the number of ground pins was a bit excessive and what's up with all the replication of I2C channels?

And Python as the touted language of choice for development? Really? Now to be fair, this Pico is my first experience with anything Python, I'm a Java / C++ person myself, but I've already gotten some experience with multithreading using Micropython and I'm still not impressed with this language as a microcontroller development language. I cut my teeth on scripted languages back in the 1980s when I was just a pup and Python has that 80's scripted feel to it ... but I'm still going to keep an open mind and see if I encounter the moment where it all makes sense. I have to believe that it would not be as popular as it is without a good reason, I just need to see what that reason is.
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: Raspberry Pi Pico
« Reply #266 on: February 25, 2021, 01:40:38 pm »
Interesting because I felt that the number of ground pins was a bit excessive and what's up with all the replication of I2C channels?
Ah well, what I usually experience with other boards is that I need to bodge something up to multiply the very limited GND options.
It can also help with signal integrity.

As for the replication, it's just more freedom to use the pins one finds more convenient, so definitely a plus wrt to a stricter pin/function mapping.

I've not yet used python on the Pico (only for the Pico), after all the C toolchain is perfectly fine, though I wonder why they had to go with MS compilers/nmake for their utilities rather than freer alternatives (e.g. ninja/make/gcc).
MC command line compilers + nmake are freely available, but the licensing is not really Ok, unless you are either an hobbyist or own a licensed copy of VS.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #267 on: February 25, 2021, 03:00:10 pm »
I've not yet used python on the Pico (only for the Pico), after all the C toolchain is perfectly fine, though I wonder why they had to go with MS compilers/nmake for their utilities rather than freer alternatives (e.g. ninja/make/gcc).
MC command line compilers + nmake are freely available, but the licensing is not really Ok, unless you are either an hobbyist or own a licensed copy of VS.

I haven't used the Pico so far, so I'm probably missing a lot of details here, but the C Pico SDK is all designed to use CMake and GCC: https://github.com/raspberrypi/pico-sdk

So what would you need MS tools for?
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: Raspberry Pi Pico
« Reply #268 on: February 25, 2021, 03:16:51 pm »
I haven't used the Pico so far, so I'm probably missing a lot of details here, but the C Pico SDK is all designed to use CMake and GCC: https://github.com/raspberrypi/pico-sdk

So what would you need MS tools for?
If you are on Windows, their recommended way is to download the MS command line compiler set, and they use by default the nmake backend for Cmake.
The MS C compiler is used for the u2f utility (maybe some others?).

If one switches the Cmake backend to ninja, you are free from nmake, at least (tried, no problems).

Then, still on Windows, they propose a modified version of OpenOCD to support their Picoprobe - build it yourself (yet another toolchain, msys) or download a binary.

This is the major reason I extended pyOCD to support the Picoprobe...and the Picoprobe itself (added target HW reset, PR just merged), so I could have a better portable toolchain and project settings.

I found their recommendation quite weird, especially for licensing issues.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #269 on: February 25, 2021, 03:32:25 pm »
I found their recommendation quite weird, especially for licensing issues.
If you accept the claim that the Pi Foundation has a deep dislike of everything F/OSS, it makes perfect sense.
 
The following users thanked this post: newbrain, Jacon, techman-001

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #270 on: February 25, 2021, 03:39:06 pm »
You can absolutely use CMake directly. They probably just recommend tools on top of that to make life a bit easier, but for a reasonably seasoned engineer, I can't see a single reason for not using the SDK directly with just CMake and GCC. Heck, you can even use Make if you don't like CMake (which would be my case.) You just need to extract the proper compilation flags and preprocessor macros from the SDK's CMake files. It's relatively straightforward if you're familiar with ARM Cortex development.

I don't know what the u2f utility is. What does it do? Can't you do without it?

As for OpenOCD, that's a minor issue. As you said, either build it from source or download their binary - I doubt the binary was built with anything else than a open source toolchain. Here they really didn't have a choice. The time to get their Pico support to the mainline OpenOCD could be months, so they don't have a choice but maintain a fork in the meantime.

Using 100% open source tools may take a bit more effort but it definitely looks like a minor deal to me. The why they themselves used MS tools, I don't know. Probably just to make their own life easier. As I noted for the RPi itself, the RPi foundation doesn't seem to care that much about open source, we can't say that any of their products actually are. They care about ease of use and low price, something that, contrary to common misconception, is harder to achieve with a 100% open source approach, depending on the context.

 

Offline lucazader

  • Regular Contributor
  • *
  • Posts: 221
  • Country: au
Re: Raspberry Pi Pico
« Reply #271 on: February 25, 2021, 07:16:29 pm »
From what i can see int heir guides, for windows you still have to use gcc to compile.

But you do have to install the Visual studio build tools. And as far as i can see they are only using nmake out of the parts that are installed.
I think because installing standard make or ninja in windows isn't quite as straight forward or as seemingly trustworthy (here have this random binary that you dont install and just plop in some directory"
Compared to installing the official VS tools.

As others have previously mentioned, because the project uses cmake, you can just build with gcc and ninja and not install any of the MS tools they suggest.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Raspberry Pi Pico
« Reply #272 on: February 25, 2021, 08:40:19 pm »
From what i can see int heir guides, for windows you still have to use gcc to compile.

But you do have to install the Visual studio build tools. And as far as i can see they are only using nmake out of the parts that are installed.
I think because installing standard make or ninja in windows isn't quite as straight forward or as seemingly trustworthy (here have this random binary that you dont install and just plop in some directory"
Compared to installing the official VS tools.

As others have previously mentioned, because the project uses cmake, you can just build with gcc and ninja and not install any of the MS tools they suggest.

Oh my... I just opened up Ubuntu under WSL2, and followed the Ubuntu instructions. The resulting binary file can just be copied from the \\WSL$\Ubuntu\home\ to the USB Mass Storage device presented by the Piico...  :-//
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: lucazader

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: Raspberry Pi Pico
« Reply #273 on: February 25, 2021, 09:52:09 pm »
I think because installing standard make or ninja in windows isn't quite as straight forward or as seemingly trustworthy (here have this random binary that you dont install and just plop in some directory"
make, ninja, etc: I use chocolatey.
Code: [Select]
~\Git\pyOCD [LinuxLibUSB ≡]> choco list --local-only
Chocolatey v0.10.15
chocolatey 0.10.15
cmake 3.19.3
cmake.install 3.19.3
make 4.3
ninja 1.10.2
5 packages installed.

Oh my... I just opened up Ubuntu under WSL2, and followed the Ubuntu instructions. The resulting binary file can just be copied from the \\WSL$\Ubuntu\home\ to the USB Mass Storage device presented by the Piico...  :-//
D&D is something that any Nucleo or mBed board supports (with a bonus real debugger thrown in, too), the convenience is undeniable.
No difference here between Windows and Linux, my main objection is that they use the MS C compiler under Windows to compile the utility that transforms the elf or bin file into the u2f format (that you must use for the D&D programming) and nmake when all the rest of the chain is based on gcc and other FOSS tools.
I like, use, contribute and also work with Open Source but I'm not an RMS cultist (I'm really happy that Apache is now the most common FOSS license), but I have nothing in principle against proprietary SW (which I buy, use and send bug reports about).
The inclusion of a toolchain with a non-free license makes the whole more difficult to handle in a context outside hobbyist/enthusiast - nothing more (and as a user of Visual Studio Community, does not really affect me anyway).

But I agree with Nominal Animal, they don't much care about Open Source.



Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #274 on: February 26, 2021, 10:49:30 am »
To be clear, there is nothing wrong in using proprietary tools or licenses; I do, too.  (The reason I use Tux as my mascot is not because I'm a Linux zealot, it is because I happen to like the whimsy involved, and have chosen to use Tux as a (non-exclusive) "brand" of sorts for myself.  For example, I created and use a (plymouth) bootsplash animation of Tux rotating its eyes in opposite directions on my Linux machines.  Drop me a PM if you want the debian package. ;D)

The problems arise when someone ideologically opposed to libre licensing interfaces with libre communities.  It causes useless friction for all involved.

The worst case scenario is when libre software is mixed with non-libre software in the same project or recommended workflow.  The libre users have issues with the non-libre components, and the users coming from the non-libre, vendor-supported side get frustrated with the perceived hostility of the libre side (because the users do not realize they are not paying customers anymore, just participants, and dislike the loss of customer privileges like having the moral grounds for demanding features and fixes).  It just makes a mess where nobody is happy.

I'm a Help Helper at heart, and just want users to have tools that make them efficient and powerful, and not waste resources and time doing their tasks.  I know and understand the benefits of proprietary/vendor products, and the benefits of libre products.  The two aren't exclusive, but when mixed in a workflow, one must understand and accept both to be able to make it work well; and the Raspberry Pi foundation clearly does not.  Which annoys me, because it causes useless and unnecessary friction in the communities I participate in.
« Last Edit: February 26, 2021, 10:53:25 am by Nominal Animal »
 
The following users thanked this post: newbrain

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: Raspberry Pi Pico
« Reply #275 on: February 26, 2021, 12:22:51 pm »
Quote
The worst case scenario is when libre software is mixed with non-libre software in the same project or recommended workflow.
This.
Another example (apart from the Pico stuff, so apologies for the OT):
The DAPlink probe firmware is Apache 2.0 licensed (good!), but the recommended (and until recently the only working one) compiler was Keil (or armcc). The code size exceeds free license limitations - so the liberal licensing was, in practice, nullified by the build setup.
They are now adding real support for gcc, I appreciate the evolution.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #276 on: February 26, 2021, 03:18:31 pm »
Well, back when I had to use Cypress FX1/2 MCUs, I remember the supported compiler was also Keil, and also with a free version with very limited code size (basically unusable except for the most simple projects...) I figured out how to use SDCC - it took only a couple days AFAIR.

As I already said, using purely open source tools with the Pico doesn't look that complicated either if you're a bit experienced. (For the non-experienced ones, proprietary tools are perfectly adequate. They are usually much easier to use and set up. That may be one of the reasons RPi made that choice.)

Even the specific tools can likely be built with gcc on Windows: https://github.com/raspberrypi/pico-sdk/tree/master/tools
(from a quick look, I didn't see anything that would specifically require MS compilers. I'll give it a shot.)

Edit: I can confirm I was able to builld both elf2uf2 and pioasm with just mingw64 gcc using MSYS2. The CMake files seem to want to default to using MS tools on Windows, but I quickly wrote a Makefile instead (both tools are pretty simple with few source files), and they built without issues. I can provide the Makefiles if anyone's interested.


« Last Edit: February 26, 2021, 05:11:28 pm by SiliconWizard »
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: Raspberry Pi Pico
« Reply #277 on: February 26, 2021, 08:22:02 pm »
As I already said, using purely open source tools with the Pico doesn't look that complicated either if you're a bit experienced. (For the non-experienced ones, proprietary tools are perfectly adequate. They are usually much easier to use and set up. That may be one of the reasons RPi made that choice.)
Yes, you (and I) know how to do it, did it, and see no real technical problems.
And that's exactly my point!
There's nothing that requires this kind of 'unholy' mix (exaggerating...).
Why do it this way?

The only sound reason is:
If you accept the claim that the Pi Foundation has a deep dislike of everything F/OSS, it makes perfect sense.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Raspberry Pi Pico
« Reply #278 on: February 26, 2021, 09:59:59 pm »
Why do it this way?
To avoid having to provide a MinGW/MSYS environment for make and related tools? Wanting to provide as close to a "native" experience as you can? Immediately going down some "the Pi foundation hates free software" rabbit hole is just incredibly dumb.

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #279 on: February 26, 2021, 11:03:06 pm »
As I already said, using purely open source tools with the Pico doesn't look that complicated either if you're a bit experienced. (For the non-experienced ones, proprietary tools are perfectly adequate. They are usually much easier to use and set up. That may be one of the reasons RPi made that choice.)
Yes, you (and I) know how to do it, did it, and see no real technical problems.
And that's exactly my point!

My own point was: contrary to what I've read earlier (not saying it was from you), you CAN absolutely use the Pico SDK without any MS tool and with only open-source tools.
Actually, GCC (ARM target) and Make would be the only things needed. If you want to build the two SDK tools (that I mentioned above) yourself, additionally GCC (native target) would be needed. All open. If you want to be able to use CMake, which would make your life easier as this is what the SDK is based on, then just install CMake on top of it. You wouldn't even necessarily need a full MSYS environment, but using one would make installing the other tools easier (GCC, Make, CMake, etc.)

And if you don't know how to do this/or don't want to be bothered, then just use the provided tools untouched. Your choice. Isn't having a choice what matters here? IMHO, the RPi have done everything to make the SDK actually usable with open source tools only, so I can't see what more you could want. Sure that may be less obvious to do as we said, but odds are, if going all open source ever matters to you, then you'll know how to do it. And if it doesn't matter, then why care? Oh, and for the odd ones who would absolutely want to use all open source but who wouldn't know how to install and use all this, they probably would be better off using Linux, likely a straightforward to use distribution such as Ubuntu. Done.

There's nothing that requires this kind of 'unholy' mix (exaggerating...).
Why do it this way?

The only sound reason is:
If you accept the claim that the Pi Foundation has a deep dislike of everything F/OSS, it makes perfect sense.

Now this is largely an exxageration. As andersm just said, and as I mentioned earlier, one of the main reasons is probably that MS tools are much easier/straightforward to set up on Windows than MSYS and other similar environments. There may be other reasons, such as MS possibly pushing their free tools to the masses as much as they can, and maybe they donated cash to the RPi as well, so that could help... but really, it's likely just that it's much easier especially for beginners.

As to them "disliking" open source... as I also said, open source is likely a secondary concern to them compared to ease of use and low cost. But still, their Pico SDK IS open source and CAN be used with only open source tools, so I still don't know what the problem is exactly. It appears they didn't do that bad for people disliking open source.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #280 on: February 27, 2021, 10:48:17 am »
Immediately going down some "the Pi foundation hates free software" rabbit hole is just incredibly dumb.
It is sick and twisted to take a position based on observed behaviour, and tell others that position "is incredibly dumb" because you claim it is based on this one small almost irrelevant detail.  I'm glad I do not have to interact with you in real life; you must be a very difficult person to work with, twisting others positions like that.

I know the Pi foundation is hostile to libre licensing and libre software, based on observation of their behaviour over several years.  It is obvious in everything they do, even down to none of their permanent technical members submitting patches or posing questions to the core libre projects their products are based on.

Even my assertion that the Pi foundation is just the advertising arm of Broadcom is not based on suspicion or single details or conspiracy theories, just Occam's Razor: it is the simplest explanation that fits the observed facts and behaviour.

In practice, it just means one should not treat Pi products as libre, but as only vendor-supported open source.  Meaning, if you have a problem, take it up with the Pi community, not with the upstream projects.  If you do take it up with an upstream project, do not do it as a Pi user, but as an upstream project community member: that means participation, providing details and testing suggestions; trading your own efforts and time to others'.  The attitude/behavioural divide between the 'Pi communities and libre communities is real, and should be observed, to make things work without causing useless friction.

A major sore point seems to be the GNU Public License (GPL).  Broadcom is known (by their behaviour, repeatedly breaking the license) to despise it deeply.  (Their contributions to the Linux kernel are rife with problems, even though the Linux Foundation has sometimes lauded their efforts, as they often include duplicated code (poorly fitting in to the Linux kernel) and worse, binary proprietary blobs.  It looks like only their junior developers are involved in submissions to GPL-licensed products, so that senior developers do not need to sully their hands.)  Basing on BSD, MIT, and Apache (APL) -licensed projects like FreeBSD/OpenBSD would have been a much better fit for the 'Pi foundation.
« Last Edit: February 27, 2021, 11:10:27 am by Nominal Animal »
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Raspberry Pi Pico
« Reply #281 on: February 27, 2021, 01:04:42 pm »
I'm glad I do not have to interact with you in real life; you must be a very difficult person to work with
I can assure you that the feeling is entirely mutual.

Quote
Even my assertion that the Pi foundation is just the advertising arm of Broadcom is not based on suspicion or single details or conspiracy theories, just Occam's Razor: it is the simplest explanation that fits the observed facts and behaviour.
That is still entirely your own interpretation, and you're drawing some very far-reaching, far-fetched conclusions based on that.

Quote
In practice, it just means one should not treat Pi products as libre, but as only vendor-supported open source.  Meaning, if you have a problem, take it up with the Pi community, not with the upstream projects.
Man, Debian, RedHat, Ubuntu, etc. must all really hate open source too. My own observation is that the Pi foundation don't have the ideological attachment to FOSS you would like them to have, and instead take a very pragmatic approach. If there's an open source option, that's good, but if there's a better closed alternative, then that's OK too.

Offline EasyGoing1

  • Regular Contributor
  • *
  • Posts: 50
  • Country: us
Re: Raspberry Pi Pico
« Reply #282 on: February 27, 2021, 01:31:58 pm »
Ah well, what I usually experience with other boards is that I need to bodge something up to multiply the very limited GND options.
It can also help with signal integrity.

As for the replication, it's just more freedom to use the pins one finds more convenient, so definitely a plus wrt to a stricter pin/function mapping.
ON the ground issue, I have always just tied the ground pin from whatever microcontroller I'm working with to the ground rail on my breadboard. I apparently never gave it a second thought and didn't consider having only two ground pins to be an inconvenience because when I first looked at the pinout diagram for the Pico, the very first thing I said to myself was, "What the hell is up with all these ground pins? Why would they even do that?" Then to read your comment on it just hours after having that conversation with myself was amusing.  :)

On the I2C channels, I tend to see all those "options" as points of consideration because to me, a microcontroller simply doesn't do "options" ... they offer a function on a single pin and we are to be thankful that its there in the first place ... lol ... so all of this "flexibility" just feels more like coddling to me ... but that would be MY problem and no one else's.  lol However ... we are talking about a couple of INCHES of real estate here ... do you REALLY need I2C channel 0 two tenth of an inch closer to that sensor that you're connecting? I dunno ... obviously it doesn't hurt to have a bunch of them all throughout the pis other than it clutters up the pinout diagrams :-)

I've not yet used python on the Pico (only for the Pico), after all the C toolchain is perfectly fine, though I wonder why they had to go with MS compilers/nmake for their utilities rather than freer alternatives (e.g. ninja/make/gcc).
MC command line compilers + nmake are freely available, but the licensing is not really Ok, unless you are either an hobbyist or own a licensed copy of VS.

I still have three un-opened Pico's (shipping from the UK was $15 whether I bought one or four so I bought four to justify the shipping cost LOL) ... the next one I bust out I will definitely look at the C++ dev route... though I am curious as to the ease or difficulty of intentionally utilizing each core in the processor with C++. With Python it was a simple matter of calling in a library and defining a separate thread ... at least that's what the famous companion Python book said. I could not attest to whether or not it starts thread sharing in one of the cores or if it actually does start the thread in the other core ... I haven't dug in that far yet to find out.

Mike
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #283 on: February 27, 2021, 04:25:51 pm »
I'm glad I do not have to interact with you in real life; you must be a very difficult person to work with
I can assure you that the feeling is entirely mutual.
I'm on good terms with everybody I've ever worked with, except for a few people who remind me of you.  They, too, had issues with the quality of their own work, and needed to cast shadow on others to shield themselves.

That is still entirely your own interpretation, and you're drawing some very far-reaching, far-fetched conclusions based on that.
I see.  You are one of those people who always claim that situations which others predicted and you did not want to admit were likely or even possible, "were impossible to predict".  Like what happened with Nokia and Stephen Elop, for example.  Or how the "Apotti" system would grow to hundreds of millions and yet be a pile of unusable shit.  Good luck with that attitude; reality does not coddle naïve idealists.

Man, Debian, RedHat, Ubuntu, etc. must all really hate open source too.
Huh?  Package maintainers regularly interact with their upstream projects.  Debian and Ubuntu even have policies in place that core project patches must be submitted upstream before they're accepted.  What the heck are you mumbling about?

My own observation is that the Pi foundation don't have the ideological attachment to FOSS you would like them to have, and instead take a very pragmatic approach.
No.  A pragmatic approach is to ensure the projects whose work product you rely on, also cater to your own needs.  You work with them.  Your leading engineers should be familiar with those core projects, and be willing to allocate resources (at least one developer) to fix the issues found.  You do not hire junior developers for a half-year to a year and have them do that interaction, then fire them, just so that your senior developers do not need to interact with those projects.  (Look at the Raspberry Pi Foundation technical personnel, for example, and try to find their contributions to any libre projects.)

If you care about your products longevity – and note that while commerical concerns are usually against that, according to the Pi Foundations' own goal statements, they should, because that way learning materials stay relevant in the medium to long term, and not just in the very short term  – you also should try to push whatever changes and additions to the core project your product needs, to those upstream core projects.  Like Linux distributions do, for example.  (Except for Oracle, which is another company that just does not understand libre software projects.)

Otherwise you just replicate the current situation with e.g. network routers: the manufacturers fork the projects and have junior devs cobble together something based on Googled guides, with updates provided only until the next model is released.  When the vendor loses interest, the users are left with little to no options, except buy the newer model, or switch to a DIY approach (say via OpenWRT, which can be a steep learning curve).  The problem arises when those users start venting their frustration and "how Linux will never be a true OS" at the libre project developers, because they do not understand that their predicament is due to their vendor, with those projects being completely innocent of the situation frustrating the user.

Regardless of how hard you wish to paint me as a Linux/FOSS zealot, I ain't one; but I am a realist, basing my opinions on behaviour I can observe, not on pretty speeches and wishes and hopes.
« Last Edit: February 27, 2021, 04:28:01 pm by Nominal Animal »
 
The following users thanked this post: newbrain, Jacon, bd139

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #284 on: February 27, 2021, 08:19:02 pm »
I've been working on my first project with rp2040 and so far I'm very pleased with pin flexibility thanks to PIO. No more routing trouble I had with stm32. I just pick any pins that close, say, to ADC and make them bidirectional SPI. How cool is that? :).

I once had a situation on stm32 that a pin couldn't trigger on falling edge, and that was the only free pin left. Don't get me wrong, I think stm32 are cool devices, but rp2040 gives me more satisfaction for digital IO.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Raspberry Pi Pico
« Reply #285 on: February 27, 2021, 09:37:07 pm »
It's a pity they only have FS USB :(
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #286 on: February 28, 2021, 05:50:24 pm »
In another thread, I outlined how one could use one form of pulse density modulation instead of pulse width modulation for e.g. LED intensity control.  Basically, for each output pin, you have a state counter S, and the duty cycle or current modulation value V, both N-bit unsigned integers, and you loop over
    S = S + V      (or in mathematical terms, S = (S + V) modulo 2N)
    pin = (S < V)
where the output pin state is equivalent to the carry/overflow flag of the addition.

In simple terms, if you consider a PWM signal of the same duty cycle V, instead of having all high states at the beginning of the 2N-sample period, and all low states at the end of the period, this distributes them over the entire period with as even intervals as possible.  This means that for example with N=8, using 6% to 94% intensities (V=16..224), the maximum consecutive low or high duration of the output is 16 cycles, instead of the 128 (minimum) to 240 (maximum) with PWM.  The frequency of state changes is much higher with pulse density modulation, and should produce much less flicker and capacitor/coil whine at 1 kHz - 5 MHz clock rates (4 Hz to 20 kHz periods at 256 clock cycles per period).  The period frequency of PDM is also much less apparent than PWM, because of how the "pulses" are spread across the entire period.

I was hoping the Pi Pico PIO could do this.  According to the RP2040 datasheet, it has two PIO units with four state machines each, with each state machine having two scratch registers – so each of the eight state machines available might be able to do this.  Alas, the 9 instructions the PIO state machines support – JMP, WAIT, IN, OUT, PUSH, PULL, MOV, IRQ, and SET – does not include an operation to add one scratch register to another.  (Either scratch register can be incremented or decremented by one, but that isn't sufficient for this.)



Another possible purpose for the PIO would be to interface to various display modules using ILI9341 or similar controllers, with parallel data transfers for higher display refresh rates.  (I happen to really like BuyDisplay/EastRising 2.8" 240x320 displays with an IPS panel.)  Typically, 16 or 18 data I/O lines are needed, five control outputs (chip select, read strobe, write strobe, data/command select, and reset), and one input (tear effect).

The reason the parallel interface is not that common with microcontroller projects (but is with FPGAs!) is those extra control outputs.  There is no clock per se; the display controller latches the data at rising edge of the write strobe.  Commands have the data/command low, and following data words high.  This is not easily handled with DMA (although you can chain DMAs, or use non-DMA for the command word and DMA only for the data; but even then the write strobe handling is a bit complicated).

There are lots of SPI libraries for these display controllers, though; including for Pi Pico.

On the ILI9341 (datasheet), all commands are 8 bits only, and all data values are 8 bit only except for memory reads and writes (0x2C Memory write, 0x3C Memory write continue, 0x2E Memory read, and 0x3E Memory read continue) which use the full 16 or 18 data lines (RGB565 or RGB666 data).  The longest command is 0x2D Color set, which takes 128 data bytes; used in the 16-bit data mode to expand the 5 red bits to 6 bits, 6 green bits to 6 bits (!), and 5 blue bits to 6 bits.  Memory reads and writes use a predefined rectangular area, continue commands continuing where the previous ended, and normal memory reads/writes starting at the beginning of the predefined area.

It seems to me that a state machine that consumes 8-bit data, first byte always being the data length, followed by the command byte, followed by the specified number of data bytes, could implement register/command writes with just a few instructions.  (The problem with RP2040 is that it has so little room for PIO programs, just 32 instructions.)  Memory write could be a separate state machine.

I have considered using a number of different ARM microcontrollers for this – basically as a programmable display unit –, but either their GPIO bus is only 16 bits wide (so 18-bit not being possible at all), DMA triggers (noting the need to strobe the write pin per data word), or something else has made me discard the idea; most recently I've been thinking of using a tiny FPGA, say iCE40HX1K, for this.  Olimex has a nice-looking, affordable OSHW board for testing the idea, too; the BGA and 0.5mm pitch TQFP/VQFP footprint may be outside my current soldering ability to do a board from scratch.

RP2040 sounds like a viable way to implement this – for example an USB 1.1 (12 Mbit/s, about 1 Mbytes/sec in practice) 320×240 external display module for appliances (routers and NASes), perhaps with JPEG or PNG decompression, and/or YCbCr->RGB conversion, perhaps YCbCr DCT to RGB.  Especially if one were to extend the framebuffer (and pixel data RAM) with QSPI PSRAM.  Anyone done that yet?



The reason I mentioned Nokia and Stephen Elop earlier, is because when I and others expressed incredulity on his choice because his career (Macromedia, Adobe, Juniper, Microsoft) shows he has a strictly proprietary software mindset, actively hostile to libre software, and thus would be unable to carry Nokia's Linux-based efforts.  He has never fostered cooperation between companies, rather having the Embrace-Extend-Extinguish mentality Steven Ballmer drove at Microsoft (perhaps the reason why Ballmer approached Elop at Juniper in the first place?), and would likely drive Nokia into the hands of a large software house, like Microsoft.

People like andersm laughed at those like me, claiming we were spouting "conspiracy theories of Bill Gates paying Elop to destroy Nokia from the inside so that it could be bought cheaply by Microsoft".

That is exactly the kind of twisting of opinion to be able to ridicule it, that I rail against.  Instead of acknowledging the reasons for my opinion and arguing them, those reasons are replaced with a ridiculous assertion.  Instead of having the uncomfortable discussion about what extending Elop's policies and approaches to Nokia would likely lead to, we were painted as Linux zealots spreading conspiracy theories.  It still offends me, especially because we were right: Elop may have been the best choice available, but the result of his leadership at Nokia lead to perfectly predictable results.  That does not mean Elop is a horrible person or participated in any conspiracy, just that choosing him as Nokia's CEO lead to entirely predictable results – results that people like andersm still claim "nobody could predict".

This is pertinent in this thread, because of Eben Upton: he is the person responsible for steering the Raspberry Pi community and technical personnel, and while technically adept and probably a very nice person, seems to have an irrational dislike of libre licensing, and that has permeated the way the Foundation works.  Like I said, just look at the Foundation personnel, and try to find their contributions in any major libre projects their products are dependent on!

I do not really care if the Pi products are libre or not; there are valid reasons for and against.  I do care about doing things wrong, with poor results or causing undue friction.  It is hard enough to deal with individuals who consider themselves Paying Customers and have the contract and privileges that entails in libre projects and especially discussions about using libre projects (they just do not understand the cost-benefit calculations at all!); having a Foundation with a good purpose have an internal culture that snubs the libre communities that their own products relies on, is .. stupid.  The only ones that could maybe talk to the Foundation are their own customers; people like me, outsiders, talking to the Foundation, would just aggravate them.  That is why I am talking about this to you.

(Hopefully, the above two examples of projects with the Pico I listed earlier in this post, shows that I am not irrationally hostile to anyone or anything.)
 
The following users thanked this post: thm_w, newbrain, techman-001

Offline DrG

  • Super Contributor
  • ***
  • !
  • Posts: 1199
  • Country: us
Re: Raspberry Pi Pico
« Reply #287 on: February 28, 2021, 06:44:03 pm »
.... shows that I am not irrationally hostile to anyone or anything.)

Not that I think you need to be defended, because I don't, but my experiences with you, to the extent that I remember, have not led me to believe that you are "irrationally hostile".

But, I am only responding because I want to ask you something that is completely off topic of the thread. I know that there are more than 5.5 million people in Finland and I don't expect that you know them all, but from your POV (maybe it was covered more), I am wondering if this (see below) was legit or have I been duped?

- Invest in science - it pays big dividends. -
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #288 on: February 28, 2021, 07:13:01 pm »
I am only responding because I want to ask you something that is completely off topic of the thread. I know that there are more than 5.5 million people in Finland and I don't expect that you know them all, but from your POV (maybe it was covered more), I am wondering if this (see below) was legit or have I been duped?
You're not the first one to ask!  Yes, it is quite legit.

Indeed, traditional Finnish lake and river boats have a prow/bows specifically to allow them to be easily dragged on ice and over capes.  (One of the oldest known fishing nets, a ten thousand year old Antrea net, was found in Karelia, then Finland, in 1919; now near Kamennogorsk, Russia.)  Finns have used rivers and lakes as "motorways", and being able to do so when there is still ice, and to move boats between rivers over small hills and capes, was important.  (Look at e.g. Comb Ceramic culture, four to six thousand years ago: they used lakes and rivers to transport goods, so that ordinary tools contained red slate from Scandic mountains, and flint from Valdai mountains, 2000 km to the South-East.)

The video is on the Baltic Sea, and the row boat is obviously of newer design, but probably either aluminium or sturdy enough fibreglass to do that safely.

The danger, really, is if the wind changes and crushes your boat between ice floes.  Despite their mass and volume (typically 90% underwater), they move surprisingly easily, including driven by even moderate winds.  On an open sea like that, it's pretty safe.  I bet a major reason they had the drone was to keep track of how the floes move, to avoid trouble.

Edited to add: Without the drone in the air to give a wider view, it would be too dangerous to do.  The rower is obviously skilled and in good health, so I'd compare the effort shown in the video to maybe a 20km jog, a half-marathon (but this is just my personal estimate, I haven't actually pushed ice floes on a row boat myself; although I did like rowing as a teenager).  Rowing is very much a skill; especially the way you handle – and the shape of – the blade of the oar.
« Last Edit: February 28, 2021, 07:38:33 pm by Nominal Animal »
 
The following users thanked this post: thm_w, newbrain, DrG, YurkshireLad

Online tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX product design
Re: Raspberry Pi Pico
« Reply #289 on: February 28, 2021, 09:52:31 pm »
I've been working on my first project with rp2040 and so far I'm very pleased with pin flexibility thanks to PIO. No more routing trouble I had with stm32. I just pick any pins that close, say, to ADC and make them bidirectional SPI. How cool is that? :).

I once had a situation on stm32 that a pin couldn't trigger on falling edge, and that was the only free pin left. Don't get me wrong, I think stm32 are cool devices, but rp2040 gives me more satisfaction for digital IO.
You should take a look at silicon labs gecko microcontrollers. It's the dream. Amost any function can be routed to any pin, down to the point that I dont even look at the datasheet  anymore. SPI, I2C, UART, I just route it to the closest pin possible and done.

It's a pity they only have FS USB :(
What are they supposed to do with 480MBit/s data? It is way too much for small micros, and it requires different set of transistors, and process nodes, that guarantee high power consumption.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Raspberry Pi Pico
« Reply #290 on: March 01, 2021, 03:18:40 pm »
What are they supposed to do with 480MBit/s data? It is way too much for small micros, and it requires different set of transistors, and process nodes, that guarantee high power consumption.

PIO can run at 60 MHz. If it's 8-bit wide, you get 480 Mbps. If it's 16-bit wide, it's 960 Mbps. This is about the same order of magnitude as USB HS. USB FS is only 12 MHz, roughly 10 Mbps. This is clearly too low compared to data rates PIO can achieve.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: Raspberry Pi Pico
« Reply #291 on: March 03, 2021, 06:34:08 am »
Sigh.   After playing and poking around a bit, using the CMAKE-based build environment that the Pico SDK implements...  I think I want to take back some of the nasty thoughts I've had about the Arduino build process... :-(
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Raspberry Pi Pico
« Reply #292 on: March 03, 2021, 09:41:10 am »
Arduino is really such an easy on-ramp.

Even if it puts you in the slow lane, you're still on the motorway.
 

Online tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX product design
Re: Raspberry Pi Pico
« Reply #293 on: March 03, 2021, 10:35:52 am »
RPi Pico: 4 EUR
SparkFun MicroMod RP2040 Processor: 12 USD
SparkFun Pro Micro - RP2040: 10 USD
SparkFun Thing Plus - RP2040: 16 USD
Adafruit whatever: Coming soon.
I see where this is heading...

What are they supposed to do with 480MBit/s data? It is way too much for small micros, and it requires different set of transistors, and process nodes, that guarantee high power consumption.

PIO can run at 60 MHz. If it's 8-bit wide, you get 480 Mbps. If it's 16-bit wide, it's 960 Mbps. This is about the same order of magnitude as USB HS. USB FS is only 12 MHz, roughly 10 Mbps. This is clearly too low compared to data rates PIO can achieve.
So, you want to feed an external chipset with so much data? Maybe, you should give it a try, there are plenty of ULPI interface chips out there.
Actually, coming to think of it... It would be interesting to see, wheteror not the USB is implemented in hardware or they just use specific PIO blocks to do a software implementation.
Or if one could implement a second USB on a PIO.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Raspberry Pi Pico
« Reply #294 on: March 03, 2021, 04:21:04 pm »
So, you want to feed an external chipset with so much data?

If it had a built-in HS USB and cost $2, I would definitely consider it.

But I guess $4 for the board is some sort of promotional price, and bare chips won't be as cheap ...
 

Offline Rudolph Riedel

  • Regular Contributor
  • *
  • Posts: 67
  • Country: de
Re: Raspberry Pi Pico
« Reply #295 on: March 07, 2021, 06:27:48 pm »
I looked for it but this appears to be missing from this thread:
https://github.com/Wiz-IO/wizio-pico

This worked right away under Win10.
Going the documented way still does not work for me.

 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #296 on: March 13, 2021, 08:52:04 pm »
Found this excellent video on PIO: https://youtu.be/yYnQYF_Xa8g .

BTW, how to connect rp2040 to usb, but not to use usb for power? Should I just leave +5V pin unconnected, leaving only GND, D+ and D- connected?
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: Raspberry Pi Pico
« Reply #297 on: March 13, 2021, 10:14:28 pm »
See section 4.5 of the Pico datasheet. All explained better than I could when typing on a phone.
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 tunk

  • Frequent Contributor
  • **
  • Posts: 969
  • Country: no
Re: Raspberry Pi Pico
« Reply #298 on: March 15, 2021, 05:29:42 pm »
Cliff Matthews reports in another thread that there's someone
at instructables who's using DMA and PIO to make an AWG:
https://www.instructables.com/Arbitrary-Wave-Generator-With-the-Raspberry-Pi-Pic/
 
The following users thanked this post: MK14

Online tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX product design
Re: Raspberry Pi Pico
« Reply #299 on: March 15, 2021, 06:00:00 pm »
I've been wondering about the PIO for a while.
Can it be used for old-school parallel bus? Like 16 bit address 8 bit data? Or the 16 bit address + data multiplexed?

 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5835
  • Country: es
Re: Raspberry Pi Pico
« Reply #300 on: March 15, 2021, 06:24:58 pm »
I've looking at it since it came out... The dual core really caught my attention.
It's amazing how fast MCUs are getting, multicore, even GHz clocks.

How good are the documentation and libraries vs stm32?
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #301 on: March 15, 2021, 07:38:49 pm »
I've been wondering about the PIO for a while.
Can it be used for old-school parallel bus? Like 16 bit address 8 bit data? Or the 16 bit address + data multiplexed?

I'm no expert, but if you explain in more details may be I can help. PIO can pull/push in one go up to 32 pins.
 

Online tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX product design
Re: Raspberry Pi Pico
« Reply #302 on: March 15, 2021, 08:31:27 pm »
I've been wondering about the PIO for a while.
Can it be used for old-school parallel bus? Like 16 bit address 8 bit data? Or the 16 bit address + data multiplexed?

I'm no expert, but if you explain in more details may be I can help. PIO can pull/push in one go up to 32 pins.
Well, I know that you can write more than 1 GPIO pin at the time. Imagine the bus of a 6502. 16 bit address 8 bit data. R/W. PHI2 , which is a clock input for the bus. Maybe it should be an output for our theoretical system. DBE for external drivers.
All this is possible to do with a 100MHz microcontroller, for a 1MHz speed bus. I'm just wondering if it is possible to move it "one level down" and do it with the PIO, freeing up resources.
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 6272
  • Country: ca
  • Non-expert
Re: Raspberry Pi Pico
« Reply #303 on: March 15, 2021, 10:11:50 pm »
Saw a recent blog on measuring ADC performance of Pico: https://pico-adc.markomo.me/
Very well documented, DG4000 was used.
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 
The following users thanked this post: hamster_nz, Dubbie, exe, aheid, DrG

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: Raspberry Pi Pico
« Reply #304 on: March 16, 2021, 10:24:10 am »
I've been wondering about the PIO for a while.
Can it be used for old-school parallel bus? Like 16 bit address 8 bit data? Or the 16 bit address + data multiplexed?
Multiplexed yes, although I only looked at the PIO details to see if I could experiment with PDM with it (no, the PIO units have no adder).  Do check the datasheet for yourself, though.  The PIO instruction set is on page 341, I recommend reading from page 330 (Chapter 3. PIO) onwards.

The IN and OUT PIO instructions can set/get the state of any number of pins (up to 32), but the set is contiguous and always starts at the same pin (unless the 2040 modifies the PINCTRL register for that state machine).  So, for 16-bit address and 8-bit data, I think you could do it if you push 32-bit words to the FIFO, consisting of the data byte in the least and most significant bytes, sandwiching the address bits.  Writing the address would always write the data bits too (set all 24 pins).

The multiplexed form seems much easier.  Essentially, the PIO "program" will pop off an address, emit it to the PIO pins, and toggle the additional clock/read/write pin.  A read program will then read the PIO pins and push it to the 2040 proper; a write program will pop off the data, and emit it to the PIO pins.  Each instruction has an optional delay (generally, 0-31).  The limit of 32 instruction words per PIO unit (four state machines) might be an issue, but you'll need at least two of the state machines (read and write operations) anyway.  Autopull and wrap will reduce the number of state machine instructions you'll need.

I believe you can also do "block" DMA to the multiplexed bus, with the PIO program autoincrementing (or decrementing) the address.  For example, you supply the PIO program with the length of the data, the initial address, and the data (bytes or words), and it will write the interleaved address-data to the pins as needed, without the DMA'd data having the addresses interleaved.

Obviously, I haven't tried this myself, as I don't have a use for it, so there might be gotchas I haven't seen.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: Raspberry Pi Pico
« Reply #305 on: March 30, 2021, 05:28:04 am »
Did someone try with segger's embedded Studio ? According to their website the latest version (5.42) should have a package for the RP2040. But I do not see this package in the list of available packages. (I clicked on the non commercial license, I have an edu jlink).
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #306 on: March 30, 2021, 04:30:17 pm »
Saw a recent blog on measuring ADC performance of Pico: https://pico-adc.markomo.me/
Very well documented, DG4000 was used.

Thanks. It doesn't look that good, but I'm not very surprised.
 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #307 on: March 31, 2021, 08:50:00 am »
Btw, speaking of overclocking, according to [1], it seems most board can go up to 330MHz, and some go over 400MHz. Unfortunately, external flash stops working at much lower frequencies.

[1] https://www.raspberrypi.org/forums/viewtopic.php?t=301902
 
The following users thanked this post: thm_w, edavid, MK14

Offline Dubbie

  • Supporter
  • ****
  • Posts: 1114
  • Country: nz
Re: Raspberry Pi Pico
« Reply #308 on: March 31, 2021, 09:48:57 am »
Wow that writeup on the ADC was really excellent.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: Raspberry Pi Pico
« Reply #309 on: March 31, 2021, 01:53:10 pm »
Btw, speaking of overclocking, according to [1], it seems most board can go up to 330MHz, and some go over 400MHz. Unfortunately, external flash stops working at much lower frequencies.

[1] https://www.raspberrypi.org/forums/viewtopic.php?t=301902

That's very interesting. That could mean that future releases of the PI Picos, could be at higher maximum clock speeds. It also means that anyone who understands the risks/problems with overclocking, could experiment with overclocking these modules.

It is possible they started out at the current 133 MHz limit, until they could do more tests and optimize the MCU, enough to safely go to higher maximum clock frequencies. Maybe it is the peripherals and/or external flash chip (as already mentioned, faster ones may not be available, are too expensive and/or may be unsuitable for other reasons), which are limiting the maximum reliable clock frequency.

N.B. Overclocking is NOT recommended for serious/professional/production applications/use.
« Last Edit: March 31, 2021, 01:57:59 pm by MK14 »
 

Offline guenthert

  • Frequent Contributor
  • **
  • Posts: 706
  • Country: de
Re: Raspberry Pi Pico
« Reply #310 on: June 01, 2021, 05:04:48 pm »
RP2040 chips (not the Raspberry Pico board) now available for $1.  Well, some 40000 of them at least.  In autumn larger quantities are expected.

https://www.raspberrypi.org/blog/raspberry-pi-rp2040-on-sale/
 
The following users thanked this post: thm_w

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #311 on: June 01, 2021, 05:20:43 pm »
RP2040 chips (not the Raspberry Pico board) now available for $1.  Well, some 40000 of them at least.  In autumn larger quantities are expected.

https://www.raspberrypi.org/blog/raspberry-pi-rp2040-on-sale/

Now that's pretty cheap. I wonder how many of them they'll have to sell before they break even. (I'm also wondering about the licensing deal they got from ARM. Probably a pretty nice deal here.)
 

Offline guenthert

  • Frequent Contributor
  • **
  • Posts: 706
  • Country: de
Re: Raspberry Pi Pico
« Reply #312 on: June 01, 2021, 06:56:05 pm »
RP2040 chips (not the Raspberry Pico board) now available for $1.  Well, some 40000 of them at least.  In autumn larger quantities are expected.

https://www.raspberrypi.org/blog/raspberry-pi-rp2040-on-sale/

Now that's pretty cheap. I wonder how many of them they'll have to sell before they break even. (I'm also wondering about the licensing deal they got from ARM. Probably a pretty nice deal here.)
     I don't know the first thing about finances and have no insight into the details here, but my guess would be that the R. Pi Foundation as a non-profit organisation has written off the development costs and just needs to recoup OpEx.  And it's my (perhaps flawed) understanding, that chips, once developed, can be made fairly cheaply, if existing infrastructure can be utilized (no investment into better machinery needed).
 

Offline lucazader

  • Regular Contributor
  • *
  • Posts: 221
  • Country: au
Re: Raspberry Pi Pico
« Reply #313 on: June 01, 2021, 08:56:53 pm »
Another thing to note here:
They are $1 in qty 1. (and right now discount for volume)

They do expect the per chip price to drop when they start selling full reels later this year.
source: https://www.cnx-software.com/2021/06/01/buy-raspberry-pi-rp2040-one-dollar/
alasdair allan made a comment on this article (he is the Technical Documentation Manager at rpi)
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Raspberry Pi Pico
« Reply #314 on: June 01, 2021, 11:07:22 pm »
     I don't know the first thing about finances and have no insight into the details here, but my guess would be that the R. Pi Foundation as a non-profit organisation has written off the development costs and just needs to recoup OpEx.  And it's my (perhaps flawed) understanding, that chips, once developed, can be made fairly cheaply, if existing infrastructure can be utilized (no investment into better machinery needed).

Once you have the full-reticule mask set made -- which costs $800,000 for the 40nm node the RP2040 uses according to 2019 figures I found -- that stays in the library at the fab and one or more wafers can be run off at any time in the future for according to the same 2019 source $2274 per 40nm wafer

The die is 2 sq mm so a 300 mm wafer would be around 35000 chips. The cost per bare chip is therefore something like 6.5 cents.

Testing and packaging will be the main part of the cost, not the chip, especially if you're not trying to recover NRE costs.
« Last Edit: June 01, 2021, 11:10:11 pm by brucehoult »
 
The following users thanked this post: abraxalito, thm_w, lucazader

Offline lucazader

  • Regular Contributor
  • *
  • Posts: 221
  • Country: au
Re: Raspberry Pi Pico
« Reply #315 on: June 01, 2021, 11:20:10 pm »
The die is 2 sq mm so a 300 mm wafer would be around 35000 chips. The cost per bare chip is therefore something like 6.5 cents.

That makes it sound like for this first batch of chips that were produced, they only needed probably 2 wafers to get the 40k units that they are shipping, assuming a 60% ish yield.
That's pretty interesting.

How does the 2 sq-mm die size compare to similar chips from other manufacturers? (eg STM32G0/F0, ATMEL/PIC, NXP)

Edit: This article from 2014 seems to suggest around a 3.2 sq-mm die size for the KL03 line of chips
https://www.techdesignforums.com/blog/2014/02/27/freescale-kl03-mcu-design-tuning/
and the arm IP page give a bit more about the Die of the m0+ core without peripherals, around 0.006 sq-mm for the 40nm node
https://developer.arm.com/ip-products/processors/cortex-m/cortex-m0-plus
« Last Edit: June 01, 2021, 11:26:31 pm by lucazader »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: Raspberry Pi Pico
« Reply #316 on: June 02, 2021, 04:05:15 am »
The 0.006 mm^2 for a core is of course just the actual size of useful stuff.

I *think* the 2 mm^2 for the chip includes the space around the actual circuitry for the wires to be attached ("pads"), and also the gap for the saw to munch up to cut each chip out from the wafer.
 
The following users thanked this post: lucazader

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #317 on: June 02, 2021, 06:57:57 am »
They are $1 in qty 1. (and right now discount for volume)

where did you get that from?
They are $1 in qty 1 and there are NO volume discounts, in fact it sounded like they prohibited dealers from selling more than 1 per person.
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline lucazader

  • Regular Contributor
  • *
  • Posts: 221
  • Country: au
Re: Raspberry Pi Pico
« Reply #318 on: June 02, 2021, 10:22:29 am »
They are $1 in qty 1. (and right now discount for volume)

where did you get that from?
They are $1 in qty 1 and there are NO volume discounts, in fact it sounded like they prohibited dealers from selling more than 1 per person.

as menioned in the original post:
source: https://www.cnx-software.com/2021/06/01/buy-raspberry-pi-rp2040-one-dollar/
alasdair allan made a comment on this article (he is the Technical Documentation Manager at rpi)
 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #319 on: June 02, 2021, 10:31:13 am »
They are $1 in qty 1 and there are NO volume discounts, in fact it sounded like they prohibited dealers from selling more than 1 per person.

I've seen in one shop that they sell 1 piece max (which is weird), but here you can buy at least 10 if/when it's back in stock: https://www.okdo.com/us/p/raspberry-pi-rp2040-microcontroller-pack-of-10/?src=raspberrypi .

Unfortunately for me, it's not on sale yet in the Netherlands (or I didn't find it). I also bought a few rpi pico modules, so I'm probably still going to transplant ICs from them.
 

Online tszabooTopic starter

  • Super Contributor
  • ***
  • Posts: 7306
  • Country: nl
  • Current job: ATEX product design
Re: Raspberry Pi Pico
« Reply #320 on: June 02, 2021, 11:25:37 am »
They are $1 in qty 1. (and right now discount for volume)

where did you get that from?
They are $1 in qty 1 and there are NO volume discounts, in fact it sounded like they prohibited dealers from selling more than 1 per person.
There might be no volume discount, but here is a reel at farnell that can be ordered.
https://nl.farnell.com/raspberry-pi/rp2040tr13/mcu-32bit-133mhz-qfn-56/dp/3766080?CMP=GRHB-OCTOPART

RPI foundation has their right to set up their pricing policy. If it is "flat 1 USD" than its like that.
I dont mind the pricing, it seems very reasonable. It also doesn't put small players at a disadvantage.
 

Offline gamalot

  • Super Contributor
  • ***
  • Posts: 1300
  • Country: au
  • Correct my English
    • Youtube
Re: Raspberry Pi Pico
« Reply #321 on: June 02, 2021, 11:59:34 am »
I ordered 20 pieces of RP2040 at PiAustralia at a unit price of 1.50 Australian dollars.

Offline phil from seattle

  • Super Contributor
  • ***
  • Posts: 1029
  • Country: us
Re: Raspberry Pi Pico
« Reply #322 on: June 02, 2021, 02:19:24 pm »
They are $1 in qty 1. (and right now discount for volume)

where did you get that from?
They are $1 in qty 1 and there are NO volume discounts, in fact it sounded like they prohibited dealers from selling more than 1 per person.
There might be no volume discount, but here is a reel at farnell that can be ordered.
https://nl.farnell.com/raspberry-pi/rp2040tr13/mcu-32bit-133mhz-qfn-56/dp/3766080?CMP=GRHB-OCTOPART

RPI foundation has their right to set up their pricing policy. If it is "flat 1 USD" than its like that.
I dont mind the pricing, it seems very reasonable. It also doesn't put small players at a disadvantage.
Hoping to get some clarity on volume soon.  I'm not sure how the flat rate thing will play out for distis.  In particular, for far east assemblers like JLCPCB. I think it would be awesome if I could have a RP2040 board assembled by them.
« Last Edit: June 02, 2021, 03:27:39 pm by phil from seattle »
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #323 on: June 02, 2021, 04:12:28 pm »
They are $1 in qty 1 and there are NO volume discounts, in fact it sounded like they prohibited dealers from selling more than 1 per person.

I've seen in one shop that they sell 1 piece max (which is weird), but here you can buy at least 10 if/when it's back in stock: https://www.okdo.com/us/p/raspberry-pi-rp2040-microcontroller-pack-of-10/?src=raspberrypi .

so
-NO volume discount
-not selling more than 1 per person


There might be no volume discount, but here is a reel at farnell that can be ordered.
https://nl.farnell.com/raspberry-pi/rp2040tr13/mcu-32bit-133mhz-qfn-56/dp/3766080?CMP=GRHB-OCTOPART

>Note: this product is not in stock
>You can place a pre-order by clicking on the button, or indicate your interest by clicking on the link

RPI foundation has their right to set up their pricing policy. If it is "flat 1 USD" than its like that.
its 1 usd same way RTX 2080 MSRP is $699

I dont mind the pricing, it seems very reasonable. It also doesn't put small players at a disadvantage.

its the old Soviet trick - the pricing is always very reasonable when there is no merchandise in stock
« Last Edit: June 02, 2021, 04:22:10 pm by Rasz »
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 6272
  • Country: ca
  • Non-expert
Re: Raspberry Pi Pico
« Reply #324 on: June 02, 2021, 09:13:00 pm »
its the old Soviet trick - the pricing is always very reasonable when there is no merchandise in stock

Because they are still producing them  :palm:

"Available to back order for despatch 04/08/2021"
https://uk.rs-online.com/web/p/microcontrollers/2211610/
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #325 on: June 03, 2021, 08:37:11 am »
its the old Soviet trick - the pricing is always very reasonable when there is no merchandise in stock

Because they are still producing them  :palm:

Everyone is "still producing them". GPU vendors, car electronic suppliers, even STMicroelectronics STM32, everyone is on a waiting list and everything is on backlog aka no merchandise in stock. I can offer you $1 AMD Ryzen 9 5950X by the pallet, but its currently out of stock, have some $1000 ones instead in the mean time.

"Available to back order for despatch 04/08/2021"
https://uk.rs-online.com/web/p/microcontrollers/2211610/

$629.11 per reel of 500 and out of stock. You are proving my point  :-//
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline josip

  • Regular Contributor
  • *
  • Posts: 149
  • Country: hr
Re: Raspberry Pi Pico
« Reply #326 on: June 04, 2021, 08:17:25 am »
I didn't found in RP2040 datasheet, is there any way to protect firmware on external flash chip or / and secure SWD interface?
 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #327 on: June 04, 2021, 12:49:33 pm »
I'm not an expert, but since rp2040 doesn't have non-volatile memory, this means it's hard to securely store decryption key. I see there is not even a unique serial key (https://github.com/OpenLightingProject/rp2040-dongle/issues/7).

It's an interesting challenge. I don't see a way how to do it.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #328 on: June 04, 2021, 04:26:10 pm »
I'm not an expert, but since rp2040 doesn't have non-volatile memory, this means it's hard to securely store decryption key. I see there is not even a unique serial key (https://github.com/OpenLightingProject/rp2040-dongle/issues/7).

Yep. The RPi foundation was clearly looking to lower cost as much as possible. Not having any form of NVM is a problem though. As you said, it can be used for storing keys, or for storing configuration bits.
Even a unique ID is an extra process step, and it adds cost.

Whereas this chip is certainly interesting, I still think (as I probably said earlier) it's not made for "professional" use. So we can't whine there is some important - for some use cases - feature missing. The RPi may release a more advanced MCU based on the same architecture later on. Don't know what their plans are.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Raspberry Pi Pico
« Reply #329 on: June 04, 2021, 07:05:28 pm »
I didn't found in RP2040 datasheet, is there any way to protect firmware on external flash chip or / and secure SWD interface?

If you only want the chip to be used by Open Source projects, you don't need firmware protection, do you?
 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #330 on: June 04, 2021, 07:14:45 pm »
I guess some people are interested in closed-source projects and looking for a way to protect their IP :).

I personally would like it support for encryption and protection because that would widen the market for rpi mcus. Better sales can potentially make better pricing, better support, bigger community, etc.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #331 on: June 04, 2021, 08:03:48 pm »
I guess some people are interested in closed-source projects and looking for a way to protect their IP :).

I personally would like it support for encryption and protection because that would widen the market for rpi mcus. Better sales can potentially make better pricing, better support, bigger community, etc.

But there are literally thousands of MCUs on the market for this. Why insist on the RP2040 to be something it's not?
 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #332 on: June 04, 2021, 08:31:34 pm »
I was talking about potential future MCUs from RPI.
 

Offline thm_w

  • Super Contributor
  • ***
  • Posts: 6272
  • Country: ca
  • Non-expert
Re: Raspberry Pi Pico
« Reply #333 on: June 04, 2021, 09:55:38 pm »
$629.11 per reel of 500 and out of stock. You are proving my point  :-//

*$523 per reel of 500.

Its a preorder. Feel free to advertise something below cost as a preorder, let your customers order, and then change the price later. See how many get pissed off and won't order from you again.
Profile -> Modify profile -> Look and Layout ->  Don't show users' signatures
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #334 on: June 05, 2021, 03:54:34 pm »
$629.11 per reel of 500 and out of stock. You are proving my point  :-//

*$523 per reel of 500.

Its a preorder. Feel free to advertise something below cost as a preorder, let your customers order, and then change the price later. See how many get pissed off and won't order from you again.

Merchandise is not available so the price doesnt matter. You might want to read rs-online legalese

>The price for forward orders may be varied by RS after the date of order acceptance

aka its a fake price for a product that doesnt exist at this moment.

What we do learn from this is they are listing reels at above "single quantity prices". Do you want to buy a pallet full of CPU trays at retail single quantity prices?

So either single quantity price is a lie, there are/were only 40K chips send out by the pee foundations so they decide to turn this global shortage into a PR win, or rs-online is trying to gouge on forward orders omitting volume discounts.

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

Offline chickenHeadKnob

  • Super Contributor
  • ***
  • Posts: 1054
  • Country: ca
Re: Raspberry Pi Pico
« Reply #335 on: June 07, 2021, 03:29:31 am »

aka its a fake price for a product that doesnt exist at this moment.

What we do learn from this is they are listing reels at above "single quantity prices". Do you want to buy a pallet full of CPU trays at retail single quantity prices?

So either single quantity price is a lie, there are/were only 40K chips send out by the pee foundations so they decide to turn this global shortage into a PR win, or rs-online is trying to gouge on forward orders omitting volume discounts.

Other possibilities exist. Like we badly misjudged how popular these will be so we will use the pre-orders to gauge how much fab space and time to buy for the next batches.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #336 on: June 07, 2021, 03:29:44 pm »
I was talking about potential future MCUs from RPI.

Yeah, so as I said in the post before, the RPi foundation may release MCUs with more features based on the same architecture, but I for one do not know anything about what their plans actually are.
Who knows if this chip is going to be the first and last of their MCUs, at least their ARM-based MCUs. Who knows if they are not going to switch to RISC-V for their next one. Who knows exactly what they are going to do next. Generally speaking, just don't expect the RPi to act as any commercial company - which they are definitely not.
 

Offline exe

  • Supporter
  • ****
  • Posts: 2559
  • Country: nl
  • self-educated hobbyist
Re: Raspberry Pi Pico
« Reply #337 on: June 07, 2021, 07:00:34 pm »
don't expect the RPi to act as any commercial company - which they are definitely not.

I think their decisions are largely driven by sales (or demand), just like a commercial company. They can go RISC-V in their next MCU, but sticking to ARM makes more sense to me.
 

Offline Rasz

  • Super Contributor
  • ***
  • Posts: 2616
  • Country: 00
    • My random blog.
Re: Raspberry Pi Pico
« Reply #338 on: June 07, 2021, 07:38:27 pm »
Other possibilities exist. Like we badly misjudged how popular these will be so we will use the pre-orders to gauge how much fab space and time to buy for the next batches.

there is no fab space to buy right now, some analyst claim there wont be for another 6-12 months, others predictions are even bleaker
Who logs in to gdm? Not I, said the duck.
My fireplace is on fire, but in all the wrong places.
 

Offline gamalot

  • Super Contributor
  • ***
  • Posts: 1300
  • Country: au
  • Correct my English
    • Youtube
Re: Raspberry Pi Pico
« Reply #339 on: June 08, 2021, 08:10:09 am »
I ordered 20 pieces of RP2040 at PiAustralia at a unit price of 1.50 Australian dollars.

Finally, the 20 pieces of RP2040 I ordered from PiAustralia were delivered. I checked their website again, now they have the same limit of three pieces per order as another Raspberry Pi distributor in Australia (Core).

 
The following users thanked this post: thm_w, lucazader

Offline dave j

  • Regular Contributor
  • *
  • Posts: 127
  • Country: gb
Re: Raspberry Pi Pico
« Reply #340 on: June 25, 2021, 02:41:50 pm »
RP2040's have been added to JLCPCB's parts library. Announcement on the Raspberry Pi site.
I'm not David L Jones. Apparently I actually do have to point this out.
 
The following users thanked this post: thm_w, josip

Offline ChanceTran

  • Newbie
  • Posts: 1
  • Country: us
Re: Raspberry Pi Pico
« Reply #341 on: October 25, 2021, 04:14:46 pm »
Hi....That is particularly nice to think concerning what dialects are smarter to utilize it with - I've not contacted MicroPython previously, and to be straightforward I don't know I would. I've accomplished heaps of work on inserted applications throughout the long term and it's constantly been with C, so that is my go-to language for anything this near the metal.

That being said, I was extremely shocked to understand the thing you said about not being extraordinary for timing-basic stuff! I had completely expected/trusted that the pico would be liberated from the bedlam of multi-strung intrudes on that makes exact planning so shakey on the Raspberry Pi, yet I surmise since it has a multicore/string design we can't anticipate that. Which is a disgrace, on the grounds that there's a wide range of clock and touch banging applications that may require it. Be that as it may, on the in addition to side, with the worked in comms peripherals and a DMA, I'm trusting the vast majority of the circumstance basic stuff can be taken care of by devoted equipment.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: Raspberry Pi Pico
« Reply #342 on: October 26, 2021, 05:16:33 pm »
Not sure I really got what ChanceTran meant overall. So a couple remarks from what I think they might have meant:

- You can absolutely use the RP2040 with C. You can absolutely go 100% bare metal, although the C SDK is not bad, at least for starters! But CMSIS include files are provided, so you can definitely go bare metal right away without the SDK.

- It has only 1 "true" timer, as we said, but has a number of other resources that can be used as such: PWM and PIO. Yes, the PIO is very flexible and you can use its two X and Y registers (per state machine) as 32-bit timer counters, at up to the system clock. So in the end, the fact there's only one dedicated timer is not as limiting as one could initially think. The PIO actually allows to implement cycle-accurate stuff in a fully programmable way, which not a lot of other MCUs allow.

Not sure I got the essence of the rant.

So anyway, curiosity got the best of me, and I finally took the plunge, ordered a couple boards and started evaluating the RP2040 with the C SDK. It confirms that it's an interesting chip with an odd mix of features, but it certainly "beats" most MCUs you can find at this price point, or even at several times the cost in somes cases.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf