Look out - RasPi now doing their own microcontroller
rogloh
Posts: 5,786
Just read about this today:
https://www.raspberrypi.org/documentation/pico/getting-started/
It appears that the RasPi guys also want a piece of the action now too. Interestingly this device already appears to support MicroPython as well as C/C++ for development and their documentation looks really good, so it could be somewhat of a rival to the P2 in the education market unless/until the P2 can show off all its other goodies there.
It even has a bit banged DVI video output application too which also sort of piqued my interest.
BTW, it's also mentioned in this discussion which I just found:
http://forums.parallax.com/discussion/172784/new-kid-on-the-block-raspberry-pico#latest
https://www.raspberrypi.org/documentation/pico/getting-started/
It appears that the RasPi guys also want a piece of the action now too. Interestingly this device already appears to support MicroPython as well as C/C++ for development and their documentation looks really good, so it could be somewhat of a rival to the P2 in the education market unless/until the P2 can show off all its other goodies there.
It even has a bit banged DVI video output application too which also sort of piqued my interest.
BTW, it's also mentioned in this discussion which I just found:
http://forums.parallax.com/discussion/172784/new-kid-on-the-block-raspberry-pico#latest
Comments
One thing it will do is legitimize bitbanged DVI and its usefulness. That will in fact help the P2
The MCU is interesting, and looks to have ROM area for boot and floating point - quite similar to what NXP has in their MCUs I think.
An eye diagram for P2, like they show here for the Pi : https://github.com/Wren6991/picodvi would help the P2 too.
https://hackaday.com/2021/01/20/raspberry-pi-enters-microcontroller-game-with-4-pico/
They overclocked it to 372 MHz to get 720p30 out of this small chip - OMG!!!
Wonder if there should be P2-Edge style module that is just a carrier for PICO.
Or, a carrier board with four of the P2-Eval style headers on it...
Nothing special about 372 MHz Pik33, we managed that (just) on the P2 way back in 2018!
https://forums.parallax.com/discussion/comment/1453982/#Comment_1453982
Yep. It's a big advantage to have these tools all available on day one. I've just ordered a couple of boards to see what they are like. Should arrive in a few days after our long weekend here in Aus.
"The output voltage can be set in the range 0.80V to 1.30V in 50mV steps, but is set to a nominal 1.1V at initial power-on, or after a reset event.
The voltage regulator can supply up to 100mA."
When overclocking so much, I wonder how much that little LDO is pushed, and it may need an external regulator ?
Well, that and being a lot cheaper.
I guess P2 has much more pins and significantly higher CPU throughput though. Not per-core probably, but there's 4x more. Slow QMUL though. Also low-latency interrupts? Video without wasting most of the chip resources? (the Pi seems to cheat by re-using the same TMDS data over two lines)
Definitely a tough one.
Seems Sparkfun is already making a module (and some associated carrier boards) with this new micro that appears a bit like a P2-Edge thingy....
https://www.sparkfun.com/products/17720
Interesting they chose the M.2 connector format. Should help that it uses a low cost/readily available connector that is also low profile. Though any prototyping and hand soldering such a beast with its 0.5mm pitch gets very difficult for most hobbyists (at least speaking from my own experience). SMD oven/toaster/frypan is the way to go there if you make up your own boards.
Ahem...
Sparkfun has a lot of cards using the m.2 connector footprint, so it's not unexpected they would use this format.
There is only one ADC in 2040
Well, I took a deeper look and it turns out the Cortex M0+ is not actually a full ARM CPU, it only supports (a subset of) the 16 bit thumb instructions, no full ARM instructions. So no single cycle shift+add madness, not a lot of opcodes. At least it doesn't make you want to claw your brain out like SuperH. Some of them still are 3-operand, but those can only use a limited register set. Conditional ops can be encoded, but the CPU doesn't support them on anything but branches. The "single-cycle 32x32 multiplier" (MULS instruction) is a bit of a lie/misunderstanding, it does not give out the top half of the result (which makes it effectively 16x16, same as P2's MUL actually, I'm stupid, it will handle stuff like 0x10000 * 2, but not, say 16.16 fixed point multiplication). So I guess it's not as much faster per-core as I initially thought. Still a good bit though. Obviously if the task at hand involves something the P2 happens to have a fast instruction for (see: bit twiddling (REV,SPLIT/MERGE ops, MUXQ, parity, ONES, etc), CORDIC ops, CRC, pixel mixer..) it's going to win (per-core). If it needs lots of random memory R/W and lots of simple add/sub the ARM will win (per-core).
The RP2040 also has the ability to directly map SPI flash into the memory space, which is a really big win, I think. It seems to only work with read-only flash though, which makes it a lot less useful (as opposed to doing it with flash+RAM)
There's actually 4. Claimed res is 12 bits (9.5 effective) at 0.5MS/s. I think P2 ADC is more powerful.
Price to get started $4, prop2 - $50
Power 300 mW, prop2 - 3W +
C, C++, MicroPython, BASIC, + many others , prop2 - C, spin, BASIC
full data sheet, prop2 ??
growth path - 20K alternate parts, prop2 - right
$5 says that none of those complainers go to the other guys and whine about them not having eight symmetric cores.
Raspberry Pi org is a charity so pays no taxes, no returns to investors. Pretty hard for a commercial company to compete!
Did you note...
If you want VGA that uses 17 pins
If you want SD that uses 4 or 6 pins
A serial can use the 2 pins from the SD if only 4 are used
Audio uses 2 for stereo or 3 plus a chip for I2S
Flash uses 6 pins
USB uses 2 pins
No pins left
A brief scan leads me to think VGA that uses RGB as 5+6+5 but actually outputs 5+5+5 +HS +VS requires the whole 15 RGB pins with series resistors. P2 uses 5 pins and no resistors.
Apparently no HDMI.
Of course if you only need a small number of I/O then you’re fine but then there are other $1 micros that might do the job.
Doesn’t look like the two M0 cores work together as nice as the 8 P2 cores. And they appear to be reduced M0 cores too.
The CPU architecture wars were over 20 years ago, bigger names than Parallax are no longer around or a shadow (Spark, PowerPC, MIPs)
Parallax does great work in education, and that is where their expertise lies. Maybe they should focus on that, just think what $10 million spent on that product line would have brought.
Yes go ahead a strike my comments, ban me, whatever. This is not a new comment, I made them to Ken 16 years ago.
Hopefully, a P2 product will happen. We are working on that.
What we like, is capability and both ease of development and how robust the end product is.
I am not sure CPU wars are over. We are about to see another round.
With that, the pendulum will swing back to custom silicon too. The P2 is well aligned with coming trends, if you ask me.
For our kind of products, the BOM cost is not a significant factor. Proto, dev, test cycles being short and productive, flexible are a big deal. Anything we can do to make making the thing inexpensive is a big help.
Once it is production, the price is the price. Over time, more margin can be had through cost reductions. So far, those opportunities have been much more than the change of MCU and board, all of which takes another proto, dev, test cycle that we would much rather be put to use on another product altogether.
For Parallax, it is more about their share, whatever it is being enough to exist, put some in the bank and take care of everyone.
Comparing to mass market does not make a lot of sense to me.
Same with products. There are many niches where people are willing to pay for great solutions. Will never be mass market, and that is fine. Good money to be made and room for Parallax type products too.
To me, P2 is pretty usable right now. It is not yet all that discoverable. Better docs will improve on all that as will those of us getting things done talking those things up.
I personally think variety and competition is very important, so having multiple options for CPU architecture is a good thing. I find the tech community has a bit of a weakness for trying to conform to one way of doing things too often. This has positives, but it also means we miss out on some potentially good ideas due to everyone's focus being on one way of doing things. It also means we are constantly putting all our eggs in one basket, which comes back to bite us time and time again.
Anyway, sorry, I don't mean to pull the thread off topic. I think Parallax producing an alternative to things like Arduinos and the plethora of ARM boards is important, especially since the Propeller introduces some very real differences compared to the others.
One, multiplexed. P2 ADC is WAY more powerful and there are 64 of them
However...code to make a 2MB frame buffer and DVI display generator out of a Pico would be most excellent! All sorts of wonders may appear in time.
They already did HDMI on RPi Pico. Using about half of its resources
They did a very good work there. You have 4 banks @ 64 kB each and another 2 banks 4 kB each. You can attach a bank to a core, so they can work without messing with multicore access to the same RAM. But you can also make a bank available to both CPUs (with all the known problems). There are also two one-way fifos, which can be only written by one core and only read by another one.
I think they did these 4 kB banks as something to make communication between cores and maybe something like a LUT/temporary buffer for DMA (for example: for audio buffers) Attach a bank to a core, fill it, detach it from a core and attach it to DMA hardware, repeat. This means no mullti-device access to a RAM bank.
Of course it is. But then you have to have one. USPS keeps my P2 boards somewhere, or maybe they threw them into the ocean? - seven weeks passed since they were sent and the last tracking was January 8, Chicago, IL.
P2 and RPi Pico are different beasts. Massive analog capabilities of P2 are not similar to anything I know. The very strange P2 asm with its skipf, indirections, xbyte and self-modifying code are not similar to anything I know... except, partially, P1. The RPi Pico is simply ARM C-programmable microcontroler. What makes it more interesting than the rest of similar microcontrollers are those fancy RPi designed additions: banked RAM, direct Flash execution, cores, which can run independent with their own bank of RAM, programmable pins and massive overclocking possibility.
They did an retroemulator with one of these things:
IMHO we’re likely to start seeing more micro cpu designs rather than fewer and here’s why...
Apple have just blown the industry away when you stop designing with “blinkers” on. That is, design as it’s always been done eg x86. Now, Apples’ M1 is NOT traditional ARM cpus. They are in-house cpus designed to run the ARM ISA (instruction set).
RP2040 appears to be modified ARM M0 cores that run a subset? of one of the ARM ISA sets.
While cutting edge chip design is extremely expensive, lower end design using pre-designed IP blocks looks to me to be on the cusp of becoming mainstream, and hence cheaper as more foundries look to expand that cheaper business, and bringing prices down. This allows new designs to be tried.
The P2 will not compete with RP2040. It’s a different animal with extreme flexibility. If you want to design a lot of different products that are not price conscious but time to market is, the P2 might just fit nicely. RP2040 might just help the P2 because of its’ limited version of the new smart pin concept plus lack of many peripherals.
@brucee your enthusiasm isn't contagious
There's room for everybody and Parallax needn't dominate a market to serve our loyal customers/community.
Ken Gracey
So I just received my Pico boards today and one of the first things I did was to load Pico MicroPython v1.13 to see how it compared to our P2 native MicroPython v1.13 in a quick performance test.
I believe the ARM Pico is probably operating at up to 1MIPS/MHz with its pipeline (I need to confirm that) while the P2 is 0.5MIPS/MHz. The reported Pico CPU speed was 125MHz using this:
>>> machine.freq()
125000000
while the P2 defaults to run at 252MHz in my build so they should be roughly comparable in terms of peak instruction rate at least.
This was the simple test code that I ran on both boards.
import utime def perfTest(): millis = utime.ticks_ms endTime = millis() + 10000 count = 0 while millis() < endTime: count += 1 print("Count: ", count) def perfTest2(): millis = utime.ticks_ms endTime = millis() + 10000 count = 0 count2 = 0 while millis() < endTime: count += 1 count2 += 1 print("Count: ", count) def perfTest3(): millis = utime.ticks_ms endTime = millis() + 10000 count = 0 count2 = 0 count3 = 0 while millis() < endTime: count += 1 count2 += 1 count3 += 1 print("Count: ", count) def test(iterations, testfn): for i in range(iterations): testfn() def run(): print("Testing 1 additions per loop over 10s") test(3,perfTest) print("Testing 2 additions per loop over 10s") test(3,perfTest2) print("Testing 3 additions per loop over 10s") test(3,perfTest3)RasPi Pico results @125MHz
Testing 1 additions per loop over 10s
Count: 1483917
Count: 1483957
Count: 1483965
Testing 2 additions per loop over 10s
Count: 1130892
Count: 1130865
Count: 1130855
Testing 3 additions per loop over 10s
Count: 913526
Count: 913502
Count: 913505
>>>
P2 results @252MHz:
>>> run()
Testing 1 additions per loop over 10s
Count: 641525
Count: 641505
Count: 641504
Testing 2 additions per loop over 10s
Count: 469446
Count: 469417
Count: 469416
Testing 3 additions per loop over 10s
Count: 378149
Count: 378126
Count: 378125
So from this it looks like the RasPi board is about ~2.3x faster than the P2 or so. Some of this is because the P2 compiled output is based on P1 code (p2gcc) and doesn't take full advantage of what the P2 can offer. Also the P2 has slower memory accesses of variables in HUB plus significant branch penalties when running hub-exec mode. If a better GCC port for P2 could be developed to optimize things for the P2 (eg, more registers, indexed memory reads instead of computing address offsets repeatedly, better stack frame call/return sequence etc) this gap could shrink a bit. It would be optimistic but possibly something in the 1.5x range might be a goal?
The GCC port for ARM Cortex-M0 is obviously going to be very well optimized compared to anything done for P1/P2 so it's unlikely to be possible to achieve the same level of performance but I'd love to be proven wrong.
Update: Based on the fact that there is about 190kB heap free, MicroPython on the Pico is probably running from flash via XIP. I don't know what rate it can sustain but there is a 16kB XIP instruction cache so perhaps that peak 1MIPS/MHz rate I assumed above is still valid if the hit rate is very high.