@moony said:
I personally think the one big advantage this has over the P2 is C++. They already have the entirety of gcc and clang just ready to use.
Very true - and when that's what's needed, P2 is not the best fit at the moment, and that's IMHO fine. P2 does not need to solve all problems. But for the problems it does solve well, it has no competition. So phrasing it as if P2 really had to "look out" for competition in the form of Pico is disingenuous and misses the point by miles.
For me, P2 is the perfect impedance match between analog and digital. It outshines basically every typical microcontroller in that regard, and Pico is no better here (it wasn't meant to be!). On the products I use P2 in, it takes more than 4 fast ADC channels just to monitor performance of the board (4 is all Pico got), and dozens of channels are needed to for the product's function on top of that. In many applications I'm using 40-50 of P2's pins, and at least 30 of them are analog functions. Only 30 because I haven't thought yet of all the ways I could leverage the goodies P2 bundles within - I won't be surprised if within a year I'll be using all pins, with all non-communications-related pins being analog tightly bound with software that does the rest.
One application I have is rather cost sensitive, and P2 bootstraps all switching regulators in software, including the ones that power the core 1.8V and the 3.3V I/O. When it starts, the core and VCCIO run off a resistor divider from USB VBUS (tweaked to deliver exactly 1.8V and 3.3V under the startup load), with total operating current well under 100mA. After the stage 2 bootloader finishes loading, one cog gets relegated to voltage regulation and supervisory functions that all run on a fixed hard-realtime schedule. The switcher control loops get enabled and switching regulation commences. The crystal oscillator and PLL are then enabled, and once the PLL is stable, the supervisor changes the timing on the switching regulators, and selects the fast clock. Runs rock solid dependably and I have no worries there.
The analog circuitry on that board is powered from a slew-rate-controlled push-pull driving a transformer, in the end producing bipolar supply voltages. 8-bit pin DACs generate the V- and I- slew-limited drive waveforms, and the supervisor code adjusts it so that both voltage and current rates are fully controlled. The waveforms are adapted on each switching cycle, based on current and voltage feedback from the driver transistors. Some more 8-bit DACs and DAC-comparators implement hybrid SAR ADCs that sample the feedbacks (about 10x higher BW than the scope mode). This used LT3439 before (~$6 qty 100), and was not quite as flexible as we needed it - there were also LDOs on the output. By being clever on the driver side, there's no need for LDOs anymore, since the driver waveform can be perfectly synchronized with analog functions and this is tweaked in closed loop to null the "fallout" from it. I could also reduce the decoupling capacitances. Those fast DACs are IMHO a killer feature - you have to constantly remind yourself that P2 has all those plentiful peripherals that used to be limited in number and had to be conserved in classical MCUs or else you'd run out of them. P2 requires a fundamentally different mindset when implementing it.
There is no microcontroller that I'm aware of that can do this in one chip with just a smattering of cheap discrete parts. Sure, a much cheaper MCU would be paired with stand-alone fixed-function ICs like switchers and so on in this application - that's exactly what we did before: it'd cost more than the P2-based solution, baseline performance was a bit worse, and it was not as flexible as we could make use of. P2 enabled us to grow the product and have a wide-open road ahead.
If I wanted something that ran lots of C/C++ code and had excellent analog abilities, I'd use Pico and P2 together perhaps - it doesn't take too many analog I/O pins for P2 to pay for itself, and Pico is somewhat unique among powerful MCUs in that its design is simple enough for a single person to comprehend and memorize in entirety - and I do like knowing what my code runs on from first principles. It has helped me many times.
For the fixed-schedule hard-realtime metrology and controllers I'm doing, P2 is basically a dream come true, and Pico would be a relatively poor fit by itself. I may actually eventually use Pico paired with P2, but there's no need for it yet. We've migrated from a much slower MCU whose peripherals were let's say it "creatively taxed" to do jobs perhaps not envisioned of them.
@kuba,
Thanks for your post and insight to what your using the P2 to do.
I wholeheartedly concur, the P2 is a vastly different animal to every other micro on the market. Only the P1 comes close, and we all know how much better the P2 is for more complex tasks. The P1 still has its' place too.
@brucee said:
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.
I have several products that are in the process of being switched to P2, and there is no silicon out there that we could use to do what P2 is doing for any less than what P2 costs. In fact, I'd say that I've been waiting for something like P2 for a long time.
XMOS came close, but they have no analog peripherals to speak of that I could use in the products. But the core did lots of hard-realtime stuff we could use with simpler external peripherals, and we ended up doing lots of rather fundamental dev work, including software-driven RMII Ethernet and high-speed USB (via a PHY). It wasn't all wasted since the code turned out to be easy to port to PASM - and no, the "C" on XMOS wasn't enough, we had to write the guts in assembly anyway.
So, after all that time invested into XMOS platform, that project got shelved until we could find comparable silicon that would be a better fit for our needs. Another X problem was the atrocious high-level documentation that treats the end user as an idiot too dumb to comprehend the glorious low-level details. So everything is abstracted away, but when push comes to shove you have to reverse engineer it anyway to figure out how to use the silicon to the fullest. Even the P2 manual we got now that most would consider "marginal" is miles better than all the wordy condescending blahblah X considers as suitable "technical documentation".
So, ahem, how many counterexamples does one need to consider the work invested into P2 to be worth it? I'm not any sort of a fanboy - my applications happen to be an extremely good fit for hard-realtime, fast, DSP-capable multicore silicon that is as rich in analog functions as can fit onto the die. Not everyone's application is that way, and I don't need anyone to tell me that: that's obvious. But I'm pretty damn glad that Chip and Ken did undertake P2 development. If there was nothing else, if there was no other use for it - I at least got heaps of joy from learning the architecture and using its analog chops. Sure, that may seem a bit low ROI for most, and entertainment can be had for much less, but technical nerd entertainment at that level of complexity is not exactly something you can just find by browsing google ads. That's my little data point for this whole discussion.
Another application I've found for P2 - with just a bit of sideways thinking - is impedance measurements, even wideband ones. Works great for doing TDR on water pipes (I'm not joking) - the only external components are a driver and receiver transducers and a discrete power stage. Sure, P2 is not somehow special for that, but the way you can drive discrete power stages with a P2 is a whole another piece of cake compared to an average MCU. Most MCUs, even very fast ones, really need an integrated power stage with diagnostics, flag outputs, and ideally a digital interface or else it's lots of effort to make it stress-free to use from high-level software. Highly integrated power stages with good diagnostics are getting cheaper by the minute it seems, but their feature sets are constrained, and they are not exactly long-life products - obsolescence seems to affect those disproportionately. If you need anything they can't do, you are adding lots of active analog stuff that kill cost savings quick.
I've had success using P2 to do parameter estimation of BJTs in power stage applications, with decent estimates of junction temperature and collector current, without any active external components but the BJT itself and some cheap passives to interface with P2 (and some time spent in the IEEEXplore) - fully deterministic thanks to P2's architecture, and that same architecture allows you to put such functions on a dedicated COG that runs without interference. Besides mere control you get as detailed diagnostics as the pipe back to your PC/cloud can consume. Compressing all that data using fancy floating-point heavy algorithms is a much better fit for an Arm with an FPU, and that's fine: each chip then would do what it's good at. It doesn't take much to practically saturate a USB HS diagnostic uplink from a P2, and even for development work after the first few prototypes you often don't need an oscilloscope if you are clever about higher bandwidth data acquisition past what the P2's scope mode can do. P2 is really good at gobbling up analog signals, and the hardware needed for that is often just a few passive parts and a bit of cleverness.
Now recall that you can do sensorless feedback on stepper and BLDC motors in general if you have means of flexibly measuring impedance at several frequencies, doing synchronous detection to extract measured signal, etc. I won't be posting any hardcore details anytime soon as this requires more work on my end, but it looks that it's perhaps a yet another killer application for P2. At least it works for the niche I'm in. There's a bunch of papers from people who did that, with some theory and results, but in every one of them they seem to suffer (even if they don't say it out loud) from having too loose and haphazard a coupling between the analog and digital domains. P2 can do measurements and driving all from one platform, on the same timeline, with the software able to control hardware with no layers of indirection at all: you see it all, you understand it all, no tricks, no megabytes of code just to run a 100kHz update rate control loop. Add to that the compile-run cycle that is orders of magnitude faster than you'd get when doing it the "industry standard way", and the days start on a much brighter note. I've done this stuff the way it's normally peddled - on an FPGA, perhaps with a realtime OS on an embedded core, using beaucoup $$ for Simulink and code generation and all the other niceties. It's a potent "get it done quickly" drug, but in the long run it can be just as harmful - and not only because of the induced dependence. On the other side of this, P2's lean dev environment outclasses everyone else in iteration cycles so much that it's not even funny. Yes, you have to implement all the signal processing and controls that come standard in those other environments, but if you actually know what you're doing that's a one-time expense that can be then used over and over without paying subscription fees Win-win? Why not!
Maybe that's just me? Even so, this is not a popularity contest - for everything that P2 is a good fit for, there's almost infinitely many things it's not a good fit for. But it just so happens that, at least from my vantage point, P2 fits a lot of stuff that's either not done because it's too cumbersome, or is done poorly to keep the cost down - and this stuff is very often at the intersection of analog and digital where tight integration matters, where people resort to custom silicon because it's hard otherwise. Custom silicon, eh? Doesn't that sound familiar? P2 must be opening up some fresh avenues of pursuit, I won't believe otherwise - not after having had the ES silicon in my hands for over half a year (and now some B rev chips too).
Even if we forget sensorless position feedback (and we shouldn't!), P2 can trivially drive steppers with stall detection and lab-grade diagnostics. Running a 3D printer all from a SPIN G-code interpreter and PASM motion planner is infinitely easier than what it took to do it on the Arduino platform. I don't envy all the work the underappreciated Scott Lahteine had to do to make Marlin work as well as it does.
With P2 there's no need for any shortcuts in the implementation necessitated by poor MCU or poor MCU-to-driver interface, and there's exactly zero need for fancy driver chips - that stuff becomes superfluous and just isolates you from the plant in a way that turns counterproductive rather soon. BJTs or mosfets with very basic discrete drivers (cheap!) are all you need, and can easily outclass the most advanced stepper driver chips with just an extremely basic kit of external components - really no ICs other than P2 are needed for a complete 3D printer implementation, and I'm not trying to sound cocky or anything. I've done pretty much just that but for a different application that has nothing to do with CNC nor 3D printing. I imagine that if you made a qty 1000 batch of the boards, you could have the populated boards for <$50 shipped cost that do miles more than the fanciest platform Marlin runs on, and then closed loop sensorless control is mostly a matter of development time and not adding to the BOM - and that's in a highly integrated system with full feedback, deep diagnostic abilities for the motors and system identification, and a very reasonable safety since measuring "everything in sight" nominally costs just some RC interface circuits for cents, so you won't miss transistors getting hot, voltage sags, underperforming switching regulators, etc. Yes, you do need to have some of the know how that the people that developed the bespoke application-specific silicon had in order to write down the control equations and figure out how to get all the parameters right to get it to work, so it's not exactly a "tweak an app note and you're done" sort of an endeavor at the moment. But the effort and the rewards seem commensurate - in my limited experience.
All I see is a bright future for P2 . It'll certainly take many devoted and talented "evangelists" to work out open, advanced application examples - a lot of it is already happening and people make great progress, yet P2 fits applications that nobody has published here on the forums yet. As much as I'd like, I have no time outside of work to play too much with P2, being already involved in other hobby projects. While I can't just take the IP from work and open it up to get other people excited, I can at least describe some of its aspects with such detail as won't make me jobless
If I had any say in it, I'd rather had Chip and Ken do exactly what they did, rather than following some "no, no, do this instead, you fools" mantra that rears its ugly head here occasionally. I don't buy that mantra. What I do can't be so special that I'd be somehow the only beneficiary of all this effort Parallax put into P2. I refuse to believe any of that, period. Yes, a true applications manual for P2, showcasing most areas of pursuit that P2 fits snugly into, would be probably a 1000 page magnum engineering opus, and that's man-years of effort to put together. But just because such a "bible" is absent doesn't make P2 useless. We just need to write it as we work through the problems we're using the P2 to solve, and as we discover new problems it's apt at being a must-have ingredient for.
I don't know if I documented them well-enough, yet, but there are switch-mode power-supply modes in the smart pins, with both current and voltage feedback. Are you using those? You could be doing it in software, too, but if the smart pin modes would work out, it might take some load off your code.
Over the years, many people who I explained this P2 project to would ask if I thought there was going to be a market for it, since so much time had gone by. People are always imagining "six-month" product cycles. I would tell them that I believed there would be a market, because it does things in a different way, even though the world had largely charged off in another direction, long ago, and has been incrementally innovating on that base of work. A lot of good ideas were developed in the 1960's that were forgotten and discarded, in exchange for the way the bulk of ideas were evolving. There's a lot of stuff, concepts, that are timeless and will be valid forever, that are not widely recognized. The limitations of what popularly exists have a reflexive effect on what people wind up imagining, because the established framework sets lots of boundaries on thinking. I think, anyway.
Glad your finding lots of use for the P2. The tools are going to get better and stay very fast, so nobody gets bored and despondent.
Are you using the Goertzel circuit, yet?
Are you coupling the DACs with the A>B comparator mode to make faster ADCs? One guy here, SaucySoliton would be really interested, aside from myself.
Also, some interesting factoid me and @moony dug up on Discord: Cursory research seems to say that RCSLOW mode on P2 is competitive with the RP2040's low power modes. Except that the RP2040 has to shut off all CPUs and DMA to do them while the P2 remains fully operational.
One thing I've thought of in that regard: Could the goertzel mode be used with a microphone to wake from low-power RCSLOW mode when a certain tone is heard?
@Wuerfel_21 said:
Also, some interesting factoid me and @moony dug up on Discord: Cursory research seems to say that RCSLOW mode on P2 is competitive with the RP2040's low power modes. Except that the RP2040 has to shut off all CPUs and DMA to do them while the P2 remains fully operational.
One thing I've thought of in that regard: Could the goertzel mode be used with a microphone to wake from low-power RCSLOW mode when a certain tone is heard?
RCSLOW at 20KHz is probably way too slow for the internal delta-sigma ADCs, as they would internally clip over those long clock periods. If you built an external delta-sigma, using a very high RC combo, you could do ADC that way. Maybe even the 150k drive mode with an external 10uF cap would work. Just have the pin output the opposite of what it sees, on a clocked basis (mode %0001_101_011_011_00_00000_0). The Goertzel would input that pin's IN signal. That might work.
Some more 8-bit DACs and DAC-comparators implement hybrid SAR ADCs that sample the feedbacks (about 10x higher BW than the scope mode).
I would also be very intersted if you describe this in more details, maybe with a schematic and in a new thread.
I have tried many different circuits to get faster ADCs with the P2, but the comparators seems to be limited to about 20 MHz.
Some more 8-bit DACs and DAC-comparators implement hybrid SAR ADCs that sample the feedbacks (about 10x higher BW than the scope mode).
I would also be very intersted if you describe this in more details, maybe with a schematic and in a new thread.
I have tried many different circuits to get faster ADCs with the P2, but the comparators seems to be limited to about 20 MHz.
Andy
Yes, and the tighter you want it to resolve, the longer it takes.
@brucee said:
The CPU architecture wars were over 20 years ago, bigger names than Parallax are no longer around or a shadow (Spark, PowerPC, MIPs)
No, those weren't architectural wars. It was purely commercial dominance. Same as Facebook, Amazon and Google dominate their respective markets now. So did/does the PC. It wasn't ever architectural in nature. x86 won by fate of IBM choosing it for the PC.
@brucee said:
The CPU architecture wars were over 20 years ago, bigger names than Parallax are no longer around or a shadow (Spark, PowerPC, MIPs)
No, those weren't architectural wars. It was purely commercial dominance. Same as Facebook, Amazon and Google dominate their respective markets now. So did/does the PC. It wasn't ever architectural in nature. x86 won by fate of IBM choosing it for the PC.
I'm not sure how you are interpreting the term CPU architecture wars, but it should be in the same way as format wars; think VHS vs Betamax, Bluray vs HD DVD, or even AC vs DC power distribution. All of these boiled down to commercial dominance too.
With that clarified, I'm not sure that the wars can really be called over.
The current obvious contender to the Intel hegemony is ARM, and RISC-V is seen as another potential contender.
I don't think that this is a format war that will ever truly end, as each architecture offers strengths in some areas that address weaknesses in others.
Having used it a little and read more details about this Pico I certainly think for now anyway that it is only really in the next gen "Arduino" class of micros and the P2 is of course still way more powerful and far more versatile in most cases. However capabilities such as tool-less drag-n-drop of flash image downloads directly from the Web makes this Pico thing so easy to get running right away for the beginners, and they don't really have to install/learn any compilation tools if they use an environment like MicroPython. Plus it's flavour of MicroPython is no doubt going to be very well supported given the original author has directly worked to develop it. This particular combination allows easy cut-paste interactive "app" development directly without needing much apart from a terminal console app to talk to it. So it is very cheap and easy to use to get things up and running quickly for those people starting out with simple things (e.g. in education, where you might learn how to blink LEDs, read pin states etc).
The P2 also still offers plenty of advantages in its ease of use particularly when you want to really get down and dirty with the cores at the low level once you're up to speed with the capabilities. It's never going to very be much fun for anyone to wade through a 600+ page ARM pdf full of registers to figure out how to get something coded right on the Pico while the P2 architecture makes things very simple to build something useful once you've figured out how it works because it typically requires fewer dedicated control registers to be configured. And certainly SPIN2 should be a fairly simple language to learn too for the beginners, as with P2 MicroPython. One unfortunate remaining downside right now is still the high cost of entry to the P2 for beginners. For example the P2 Edge+JohnnyMac carrier combo are still rather pricey. It's something that needs to be overcome. Maybe a low cost P2D2 type of board will help make the P2 more accessible/cost effective for the new entrants. Whether that board comes from Parallax or elsewhere hopefully doesn't matter as long as it is continuously available.
Given it's ultra low cost, ease of use, extensive documentation and enormous user base to market to (from all the original Pi users), plus more support from other HW board vendors like Sparkfun/Adafruit etc, I can anticipate that something like a Pico could potentially begin to just dominate by default particularly in hobby/education markets. We know the Arduino guys are going to port over to use it as well so existing applications using their API can be run on it. Once this happens I wonder how many people are going to continue to buy those original $20-30 (authentic/traditional) 32kB Arduino boards when you could get so much more for just $4-5 now. Surely that original market will begin to shrink a bit over time given the cost savings possible now. (EDIT: it already looks like Adafruit has discontinued a whole bunch of these older Arduino boards now, though still at Sparkfun, so it's already happening). I know the ESP guys came along and sort of started this cost reduction trend and yet the original Arduino still remains, but the ESP toolchains/docs were always a bit complicated for a lot of people to play with. If RasPi can now simplify things even more for the masses they could have the edge especially from their sheer production capability if it can match demand. Although sometimes such a low cost product generates so much demand from multiple markets/regions all at once that the products become very hard to obtain (remember their Pi Zero which was scarce after release, now it appears the same with that new compute module v4 too).
Obviously both micros (P2+Pico) are going to carve out their own markets and applications but I do hope the P2 might be found to be well suited for far more areas such that education doesn't always need to be its main focus for sustained revenue. I'm just imagining that education market share could begin to be eaten up a bit more now by the RasPi guys, but only time will tell where things go.
Perhaps this will keep you entertained Roger. I think it demands to be called "Multicore Burger" - ESP32 S2 on the bottom, 8 x P2 cores in the middle, 2 x Rasperberry Pi Pico cores on the top. Special MicroPython sauce all round.
This is one of those rare days where the Pinout Gods are smiling, P0, P1, P14, P15, P16, P17 all directly align between the P2 and GP0/1/14~17 on the Pico. Furthermore the GND tie aligns but is one row over, and VBUS(5v) has a convenient mounting hole beside it to tie down to the P2 board 5v in.
I'll chime-in here with a quick story: A friend of mine posted today on Facebook that he was really intrigued with the Pico. Getting down in the basement and wiggling bits cheaply just fascinates him. This provided me with a useful segue to the P2, so I tossed him a link to Parallax. Two hours later: "OMG. How long has this been brewing? This thing is just KILLER!! Want to buy a lightly-used PICO?".
I think that last comment sums it up nicely.
We are not in a race with anything else. We are in a race to educate the masses that the P2 exists.
Rogloh and I were talking about this. I think the Pico is going to open the awareness of things like
bitbanged DVI,
using little cores as assistants (The little PIO's only take 32 limited instructions, the P2 can have up to 1000 or so)
in a really efficient way, given the established audience. It should really help float the P2 boat
@JRoark said:
We are in a race to educate the masses that the P2 exists.
Yes.
@cgracey said:
This is going to allow the 8080 arcade emulator to run each machine from:
1 cog
1 pin for baseband NTSC video
1 pin for audio
1 pin for four pushbuttons
8 arcade machines will be emulated over just 24 pins, with the P2 running at under 50MHz.
I think one way to achieve it would be to get this octacade game demo Baggers and Chip are doing for the P2 shown on Hackaday. That would be an impressive demo of the P2's capabilities at 50MHz and really help promote it to the masses. Who has seen that done before on any other microcontroller...?
@JRoark said:
We are in a race to educate the masses that the P2 exists.
Yes.
@cgracey said:
This is going to allow the 8080 arcade emulator to run each machine from:
1 cog
1 pin for baseband NTSC video
1 pin for audio
1 pin for four pushbuttons
8 arcade machines will be emulated over just 24 pins, with the P2 running at under 50MHz.
I think one way to achieve it would be to get this octacade game demo Baggers and Chip are doing for the P2 shown on Hackaday. That would be an impressive demo of the P2's capabilities at 50MHz and really help promote it to the masses. Who has seen that done before on any other microcontroller...?
IMHO this is a real demo to pique peoples interest. If P2 can do this at a slow crawl, what else can it do????
Pico: programmed fast digital i/o via its "picoprocessors" on pins
Propeller 2: all kind of analog stuff+realtime processing
Pi Zero (baremetal programmed): RAM, fast coprocessor and framebuffer for P2
@JRoark said:
We are in a race to educate the masses that the P2 exists.
Yes.
@cgracey said:
This is going to allow the 8080 arcade emulator to run each machine from:
1 cog
1 pin for baseband NTSC video
1 pin for audio
1 pin for four pushbuttons
8 arcade machines will be emulated over just 24 pins, with the P2 running at under 50MHz.
I think one way to achieve it would be to get this octacade game demo Baggers and Chip are doing for the P2 shown on Hackaday. That would be an impressive demo of the P2's capabilities at 50MHz and really help promote it to the masses. Who has seen that done before on any other microcontroller...?
I currently have 10 portrait games working on the system with a menu to drive them which you can reset back to at any point in the games and select another.
Edit: I have removed a few of the landscape games that worked, due to the screen needing to stay in portrait mode for the cabinet
I will do a landscape version also after this.
@JonnyMac said:
The great thing is that we have choices. What I find interesting is that so many people CHOOSE to complain about Parallax and its products rather than buzz off and use a product that they claim -- in these forums -- is superior....
$5 says that none of those complainers go to the other guys and whine about them not having eight symmetric cores.
For example; I am looking at a 6-axis anthropomorphic arm on a linear (7th axis) rail. For my standard dual-loop feedback approach, this means 14 quadrature encoders. What MCU, other than the P2 can directly handle this? AFAIK...None
They will sell a million + RPi Picos of which 90% will sit in the drawer!
Probably a handful of 8*SpaceInvader boards will sell. Hopefully they will create P2 interest for more uses. But I doubt anyone really wants a P2 to do 8 video outputs and besides there’s insufficient memory for multiple modern density screens (video, vga, HDMI, lcd). One or two maybe yes. Do we want 64 serial pins? Probably not either. Or 8 sound channels ? Perhaps yes here. Just need some simply smart demos to show of some capabilities of P2 that will capture media attention.
Reminds me of a guy in the 70’s or 80’s. He wanted massive free media coverage. What did he do? He towed an iceberg into Sydney Harbour on April Fools Day. Front page coverage on every media, radio and TV. His name - Dick Smith. Cost... a barge with some white sheets.
I now have a Pico AND a P2... they will land in one box to make a retrocomputer... For a retrocomputer even 64 pins are not enough. Cartridge and PIO ports need pins. A lot of digital pins. Pico has only 26 of them, but it is cheap and can be connected to P2 via fast serial link.
The only problem is I can't use spin to program a Pico. Its IDE is (for me) overengineered.
Comments
Very true - and when that's what's needed, P2 is not the best fit at the moment, and that's IMHO fine. P2 does not need to solve all problems. But for the problems it does solve well, it has no competition. So phrasing it as if P2 really had to "look out" for competition in the form of Pico is disingenuous and misses the point by miles.
For me, P2 is the perfect impedance match between analog and digital. It outshines basically every typical microcontroller in that regard, and Pico is no better here (it wasn't meant to be!). On the products I use P2 in, it takes more than 4 fast ADC channels just to monitor performance of the board (4 is all Pico got), and dozens of channels are needed to for the product's function on top of that. In many applications I'm using 40-50 of P2's pins, and at least 30 of them are analog functions. Only 30 because I haven't thought yet of all the ways I could leverage the goodies P2 bundles within - I won't be surprised if within a year I'll be using all pins, with all non-communications-related pins being analog tightly bound with software that does the rest.
One application I have is rather cost sensitive, and P2 bootstraps all switching regulators in software, including the ones that power the core 1.8V and the 3.3V I/O. When it starts, the core and VCCIO run off a resistor divider from USB VBUS (tweaked to deliver exactly 1.8V and 3.3V under the startup load), with total operating current well under 100mA. After the stage 2 bootloader finishes loading, one cog gets relegated to voltage regulation and supervisory functions that all run on a fixed hard-realtime schedule. The switcher control loops get enabled and switching regulation commences. The crystal oscillator and PLL are then enabled, and once the PLL is stable, the supervisor changes the timing on the switching regulators, and selects the fast clock. Runs rock solid dependably and I have no worries there.
The analog circuitry on that board is powered from a slew-rate-controlled push-pull driving a transformer, in the end producing bipolar supply voltages. 8-bit pin DACs generate the V- and I- slew-limited drive waveforms, and the supervisor code adjusts it so that both voltage and current rates are fully controlled. The waveforms are adapted on each switching cycle, based on current and voltage feedback from the driver transistors. Some more 8-bit DACs and DAC-comparators implement hybrid SAR ADCs that sample the feedbacks (about 10x higher BW than the scope mode). This used LT3439 before (~$6 qty 100), and was not quite as flexible as we needed it - there were also LDOs on the output. By being clever on the driver side, there's no need for LDOs anymore, since the driver waveform can be perfectly synchronized with analog functions and this is tweaked in closed loop to null the "fallout" from it. I could also reduce the decoupling capacitances. Those fast DACs are IMHO a killer feature - you have to constantly remind yourself that P2 has all those plentiful peripherals that used to be limited in number and had to be conserved in classical MCUs or else you'd run out of them. P2 requires a fundamentally different mindset when implementing it.
There is no microcontroller that I'm aware of that can do this in one chip with just a smattering of cheap discrete parts. Sure, a much cheaper MCU would be paired with stand-alone fixed-function ICs like switchers and so on in this application - that's exactly what we did before: it'd cost more than the P2-based solution, baseline performance was a bit worse, and it was not as flexible as we could make use of. P2 enabled us to grow the product and have a wide-open road ahead.
If I wanted something that ran lots of C/C++ code and had excellent analog abilities, I'd use Pico and P2 together perhaps - it doesn't take too many analog I/O pins for P2 to pay for itself, and Pico is somewhat unique among powerful MCUs in that its design is simple enough for a single person to comprehend and memorize in entirety - and I do like knowing what my code runs on from first principles. It has helped me many times.
For the fixed-schedule hard-realtime metrology and controllers I'm doing, P2 is basically a dream come true, and Pico would be a relatively poor fit by itself. I may actually eventually use Pico paired with P2, but there's no need for it yet. We've migrated from a much slower MCU whose peripherals were let's say it "creatively taxed" to do jobs perhaps not envisioned of them.
@kuba,
Thanks for your post and insight to what your using the P2 to do.
I wholeheartedly concur, the P2 is a vastly different animal to every other micro on the market. Only the P1 comes close, and we all know how much better the P2 is for more complex tasks. The P1 still has its' place too.
I have several products that are in the process of being switched to P2, and there is no silicon out there that we could use to do what P2 is doing for any less than what P2 costs. In fact, I'd say that I've been waiting for something like P2 for a long time.
XMOS came close, but they have no analog peripherals to speak of that I could use in the products. But the core did lots of hard-realtime stuff we could use with simpler external peripherals, and we ended up doing lots of rather fundamental dev work, including software-driven RMII Ethernet and high-speed USB (via a PHY). It wasn't all wasted since the code turned out to be easy to port to PASM - and no, the "C" on XMOS wasn't enough, we had to write the guts in assembly anyway.
So, after all that time invested into XMOS platform, that project got shelved until we could find comparable silicon that would be a better fit for our needs. Another X problem was the atrocious high-level documentation that treats the end user as an idiot too dumb to comprehend the glorious low-level details. So everything is abstracted away, but when push comes to shove you have to reverse engineer it anyway to figure out how to use the silicon to the fullest. Even the P2 manual we got now that most would consider "marginal" is miles better than all the wordy condescending blahblah X considers as suitable "technical documentation".
So, ahem, how many counterexamples does one need to consider the work invested into P2 to be worth it? I'm not any sort of a fanboy - my applications happen to be an extremely good fit for hard-realtime, fast, DSP-capable multicore silicon that is as rich in analog functions as can fit onto the die. Not everyone's application is that way, and I don't need anyone to tell me that: that's obvious. But I'm pretty damn glad that Chip and Ken did undertake P2 development. If there was nothing else, if there was no other use for it - I at least got heaps of joy from learning the architecture and using its analog chops. Sure, that may seem a bit low ROI for most, and entertainment can be had for much less, but technical nerd entertainment at that level of complexity is not exactly something you can just find by browsing google ads. That's my little data point for this whole discussion.
Another application I've found for P2 - with just a bit of sideways thinking - is impedance measurements, even wideband ones. Works great for doing TDR on water pipes (I'm not joking) - the only external components are a driver and receiver transducers and a discrete power stage. Sure, P2 is not somehow special for that, but the way you can drive discrete power stages with a P2 is a whole another piece of cake compared to an average MCU. Most MCUs, even very fast ones, really need an integrated power stage with diagnostics, flag outputs, and ideally a digital interface or else it's lots of effort to make it stress-free to use from high-level software. Highly integrated power stages with good diagnostics are getting cheaper by the minute it seems, but their feature sets are constrained, and they are not exactly long-life products - obsolescence seems to affect those disproportionately. If you need anything they can't do, you are adding lots of active analog stuff that kill cost savings quick.
I've had success using P2 to do parameter estimation of BJTs in power stage applications, with decent estimates of junction temperature and collector current, without any active external components but the BJT itself and some cheap passives to interface with P2 (and some time spent in the IEEEXplore) - fully deterministic thanks to P2's architecture, and that same architecture allows you to put such functions on a dedicated COG that runs without interference. Besides mere control you get as detailed diagnostics as the pipe back to your PC/cloud can consume. Compressing all that data using fancy floating-point heavy algorithms is a much better fit for an Arm with an FPU, and that's fine: each chip then would do what it's good at. It doesn't take much to practically saturate a USB HS diagnostic uplink from a P2, and even for development work after the first few prototypes you often don't need an oscilloscope if you are clever about higher bandwidth data acquisition past what the P2's scope mode can do. P2 is really good at gobbling up analog signals, and the hardware needed for that is often just a few passive parts and a bit of cleverness.
Now recall that you can do sensorless feedback on stepper and BLDC motors in general if you have means of flexibly measuring impedance at several frequencies, doing synchronous detection to extract measured signal, etc. I won't be posting any hardcore details anytime soon as this requires more work on my end, but it looks that it's perhaps a yet another killer application for P2. At least it works for the niche I'm in. There's a bunch of papers from people who did that, with some theory and results, but in every one of them they seem to suffer (even if they don't say it out loud) from having too loose and haphazard a coupling between the analog and digital domains. P2 can do measurements and driving all from one platform, on the same timeline, with the software able to control hardware with no layers of indirection at all: you see it all, you understand it all, no tricks, no megabytes of code just to run a 100kHz update rate control loop. Add to that the compile-run cycle that is orders of magnitude faster than you'd get when doing it the "industry standard way", and the days start on a much brighter note. I've done this stuff the way it's normally peddled - on an FPGA, perhaps with a realtime OS on an embedded core, using beaucoup $$ for Simulink and code generation and all the other niceties. It's a potent "get it done quickly" drug, but in the long run it can be just as harmful - and not only because of the induced dependence. On the other side of this, P2's lean dev environment outclasses everyone else in iteration cycles so much that it's not even funny. Yes, you have to implement all the signal processing and controls that come standard in those other environments, but if you actually know what you're doing that's a one-time expense that can be then used over and over without paying subscription fees
Win-win? Why not!
Maybe that's just me? Even so, this is not a popularity contest - for everything that P2 is a good fit for, there's almost infinitely many things it's not a good fit for. But it just so happens that, at least from my vantage point, P2 fits a lot of stuff that's either not done because it's too cumbersome, or is done poorly to keep the cost down - and this stuff is very often at the intersection of analog and digital where tight integration matters, where people resort to custom silicon because it's hard otherwise. Custom silicon, eh? Doesn't that sound familiar?
P2 must be opening up some fresh avenues of pursuit, I won't believe otherwise - not after having had the ES silicon in my hands for over half a year (and now some B rev chips too).
Even if we forget sensorless position feedback (and we shouldn't!), P2 can trivially drive steppers with stall detection and lab-grade diagnostics. Running a 3D printer all from a SPIN G-code interpreter and PASM motion planner is infinitely easier than what it took to do it on the Arduino platform. I don't envy all the work the underappreciated Scott Lahteine had to do to make Marlin work as well as it does.
With P2 there's no need for any shortcuts in the implementation necessitated by poor MCU or poor MCU-to-driver interface, and there's exactly zero need for fancy driver chips - that stuff becomes superfluous and just isolates you from the plant in a way that turns counterproductive rather soon. BJTs or mosfets with very basic discrete drivers (cheap!) are all you need, and can easily outclass the most advanced stepper driver chips with just an extremely basic kit of external components - really no ICs other than P2 are needed for a complete 3D printer implementation, and I'm not trying to sound cocky or anything. I've done pretty much just that but for a different application that has nothing to do with CNC nor 3D printing. I imagine that if you made a qty 1000 batch of the boards, you could have the populated boards for <$50 shipped cost that do miles more than the fanciest platform Marlin runs on, and then closed loop sensorless control is mostly a matter of development time and not adding to the BOM - and that's in a highly integrated system with full feedback, deep diagnostic abilities for the motors and system identification, and a very reasonable safety since measuring "everything in sight" nominally costs just some RC interface circuits for cents, so you won't miss transistors getting hot, voltage sags, underperforming switching regulators, etc. Yes, you do need to have some of the know how that the people that developed the bespoke application-specific silicon had in order to write down the control equations and figure out how to get all the parameters right to get it to work, so it's not exactly a "tweak an app note and you're done" sort of an endeavor at the moment. But the effort and the rewards seem commensurate - in my limited experience.
All I see is a bright future for P2 . It'll certainly take many devoted and talented "evangelists" to work out open, advanced application examples - a lot of it is already happening and people make great progress, yet P2 fits applications that nobody has published here on the forums yet. As much as I'd like, I have no time outside of work to play too much with P2, being already involved in other hobby projects. While I can't just take the IP from work and open it up to get other people excited, I can at least describe some of its aspects with such detail as won't make me jobless
If I had any say in it, I'd rather had Chip and Ken do exactly what they did, rather than following some "no, no, do this instead, you fools" mantra that rears its ugly head here occasionally. I don't buy that mantra. What I do can't be so special that I'd be somehow the only beneficiary of all this effort Parallax put into P2. I refuse to believe any of that, period. Yes, a true applications manual for P2, showcasing most areas of pursuit that P2 fits snugly into, would be probably a 1000 page magnum engineering opus, and that's man-years of effort to put together. But just because such a "bible" is absent doesn't make P2 useless. We just need to write it as we work through the problems we're using the P2 to solve, and as we discover new problems it's apt at being a must-have ingredient for.
Kuba, I just read the book you typed here. Cool!
I don't know if I documented them well-enough, yet, but there are switch-mode power-supply modes in the smart pins, with both current and voltage feedback. Are you using those? You could be doing it in software, too, but if the smart pin modes would work out, it might take some load off your code.
Over the years, many people who I explained this P2 project to would ask if I thought there was going to be a market for it, since so much time had gone by. People are always imagining "six-month" product cycles. I would tell them that I believed there would be a market, because it does things in a different way, even though the world had largely charged off in another direction, long ago, and has been incrementally innovating on that base of work. A lot of good ideas were developed in the 1960's that were forgotten and discarded, in exchange for the way the bulk of ideas were evolving. There's a lot of stuff, concepts, that are timeless and will be valid forever, that are not widely recognized. The limitations of what popularly exists have a reflexive effect on what people wind up imagining, because the established framework sets lots of boundaries on thinking. I think, anyway.
Glad your finding lots of use for the P2. The tools are going to get better and stay very fast, so nobody gets bored and despondent.
Are you using the Goertzel circuit, yet?
Are you coupling the DACs with the A>B comparator mode to make faster ADCs? One guy here, SaucySoliton would be really interested, aside from myself.
Also, some interesting factoid me and @moony dug up on Discord: Cursory research seems to say that RCSLOW mode on P2 is competitive with the RP2040's low power modes. Except that the RP2040 has to shut off all CPUs and DMA to do them while the P2 remains fully operational.
One thing I've thought of in that regard: Could the goertzel mode be used with a microphone to wake from low-power RCSLOW mode when a certain tone is heard?
RCSLOW at 20KHz is probably way too slow for the internal delta-sigma ADCs, as they would internally clip over those long clock periods. If you built an external delta-sigma, using a very high RC combo, you could do ADC that way. Maybe even the 150k drive mode with an external 10uF cap would work. Just have the pin output the opposite of what it sees, on a clocked basis (mode %0001_101_011_011_00_00000_0). The Goertzel would input that pin's IN signal. That might work.
I would also be very intersted if you describe this in more details, maybe with a schematic and in a new thread.
I have tried many different circuits to get faster ADCs with the P2, but the comparators seems to be limited to about 20 MHz.
Andy
Yes, and the tighter you want it to resolve, the longer it takes.
We had a look at those comparators and were able to get up to 49 MHz (just!), some details here https://forums.parallax.com/discussion/comment/1512245/#Comment_1512245
No, those weren't architectural wars. It was purely commercial dominance. Same as Facebook, Amazon and Google dominate their respective markets now. So did/does the PC. It wasn't ever architectural in nature. x86 won by fate of IBM choosing it for the PC.
I'm not sure how you are interpreting the term CPU architecture wars, but it should be in the same way as format wars; think VHS vs Betamax, Bluray vs HD DVD, or even AC vs DC power distribution. All of these boiled down to commercial dominance too.
With that clarified, I'm not sure that the wars can really be called over.
The current obvious contender to the Intel hegemony is ARM, and RISC-V is seen as another potential contender.
I don't think that this is a format war that will ever truly end, as each architecture offers strengths in some areas that address weaknesses in others.
Simple: The architectural merits are never a factor. The only thing that matters is market dominance.
Cynical, and in my experience not true.
I'll word that another way: Whatever IBM chose would've been what got the money and therefore what also came out on top.
Having used it a little and read more details about this Pico I certainly think for now anyway that it is only really in the next gen "Arduino" class of micros and the P2 is of course still way more powerful and far more versatile in most cases. However capabilities such as tool-less drag-n-drop of flash image downloads directly from the Web makes this Pico thing so easy to get running right away for the beginners, and they don't really have to install/learn any compilation tools if they use an environment like MicroPython. Plus it's flavour of MicroPython is no doubt going to be very well supported given the original author has directly worked to develop it. This particular combination allows easy cut-paste interactive "app" development directly without needing much apart from a terminal console app to talk to it. So it is very cheap and easy to use to get things up and running quickly for those people starting out with simple things (e.g. in education, where you might learn how to blink LEDs, read pin states etc).
The P2 also still offers plenty of advantages in its ease of use particularly when you want to really get down and dirty with the cores at the low level once you're up to speed with the capabilities. It's never going to very be much fun for anyone to wade through a 600+ page ARM pdf full of registers to figure out how to get something coded right on the Pico while the P2 architecture makes things very simple to build something useful once you've figured out how it works because it typically requires fewer dedicated control registers to be configured. And certainly SPIN2 should be a fairly simple language to learn too for the beginners, as with P2 MicroPython. One unfortunate remaining downside right now is still the high cost of entry to the P2 for beginners. For example the P2 Edge+JohnnyMac carrier combo are still rather pricey. It's something that needs to be overcome. Maybe a low cost P2D2 type of board will help make the P2 more accessible/cost effective for the new entrants. Whether that board comes from Parallax or elsewhere hopefully doesn't matter as long as it is continuously available.
Given it's ultra low cost, ease of use, extensive documentation and enormous user base to market to (from all the original Pi users), plus more support from other HW board vendors like Sparkfun/Adafruit etc, I can anticipate that something like a Pico could potentially begin to just dominate by default particularly in hobby/education markets. We know the Arduino guys are going to port over to use it as well so existing applications using their API can be run on it. Once this happens I wonder how many people are going to continue to buy those original $20-30 (authentic/traditional) 32kB Arduino boards when you could get so much more for just $4-5 now. Surely that original market will begin to shrink a bit over time given the cost savings possible now. (EDIT: it already looks like Adafruit has discontinued a whole bunch of these older Arduino boards now, though still at Sparkfun, so it's already happening). I know the ESP guys came along and sort of started this cost reduction trend and yet the original Arduino still remains, but the ESP toolchains/docs were always a bit complicated for a lot of people to play with. If RasPi can now simplify things even more for the masses they could have the edge especially from their sheer production capability if it can match demand. Although sometimes such a low cost product generates so much demand from multiple markets/regions all at once that the products become very hard to obtain (remember their Pi Zero which was scarce after release, now it appears the same with that new compute module v4 too).
Obviously both micros (P2+Pico) are going to carve out their own markets and applications but I do hope the P2 might be found to be well suited for far more areas such that education doesn't always need to be its main focus for sustained revenue. I'm just imagining that education market share could begin to be eaten up a bit more now by the RasPi guys, but only time will tell where things go.
Perhaps this will keep you entertained Roger. I think it demands to be called "Multicore Burger" - ESP32 S2 on the bottom, 8 x P2 cores in the middle, 2 x Rasperberry Pi Pico cores on the top. Special MicroPython sauce all round.
This is one of those rare days where the Pinout Gods are smiling, P0, P1, P14, P15, P16, P17 all directly align between the P2 and GP0/1/14~17 on the Pico. Furthermore the GND tie aligns but is one row over, and VBUS(5v) has a convenient mounting hole beside it to tie down to the P2 board 5v in.
Actually prob should post pics in a new thread
Sounds like a total feast Tubular.
I think that last comment sums it up nicely.
We are not in a race with anything else. We are in a race to educate the masses that the P2 exists.
Rogloh and I were talking about this. I think the Pico is going to open the awareness of things like
in a really efficient way, given the established audience. It should really help float the P2 boat
Yes.
I think one way to achieve it would be to get this octacade game demo Baggers and Chip are doing for the P2 shown on Hackaday. That would be an impressive demo of the P2's capabilities at 50MHz and really help promote it to the masses. Who has seen that done before on any other microcontroller...?
IMHO this is a real demo to pique peoples interest. If P2 can do this at a slow crawl, what else can it do????
Doing it at 50 megahertz is way over-the-top. I can't wait!
And we're all going to have to talk that up when he gets done. Nobody's done that on a micro before.
Frankly, when you think about it oh, that's a hard thing to do on any machine. And the P2 doesn't even have to have an OS to manage it all!
And there's all kinds of crazy things possible. One could kill one games and fire up a window with some text editor or maybe Peter's Forth.
People are going to go nuts
Pico: programmed fast digital i/o via its "picoprocessors" on pins
Propeller 2: all kind of analog stuff+realtime processing
Pi Zero (baremetal programmed): RAM, fast coprocessor and framebuffer for P2
That's the plan ;-)
Cheers guys
yeah the plan is to get it shown on hackaday, also another hidden agenda in the mix, but I will explain more on that at a later point!
I currently have 10 portrait games working on the system with a menu to drive them
which you can reset back to at any point in the games and select another.
Edit: I have removed a few of the landscape games that worked, due to the screen needing to stay in portrait mode for the cabinet
I will do a landscape version also after this.
For example; I am looking at a 6-axis anthropomorphic arm on a linear (7th axis) rail. For my standard dual-loop feedback approach, this means 14 quadrature encoders. What MCU, other than the P2 can directly handle this? AFAIK...None
They will sell a million + RPi Picos of which 90% will sit in the drawer!
Probably a handful of 8*SpaceInvader boards will sell. Hopefully they will create P2 interest for more uses. But I doubt anyone really wants a P2 to do 8 video outputs and besides there’s insufficient memory for multiple modern density screens (video, vga, HDMI, lcd). One or two maybe yes. Do we want 64 serial pins? Probably not either. Or 8 sound channels ? Perhaps yes here. Just need some simply smart demos to show of some capabilities of P2 that will capture media attention.
Reminds me of a guy in the 70’s or 80’s. He wanted massive free media coverage. What did he do? He towed an iceberg into Sydney Harbour on April Fools Day. Front page coverage on every media, radio and TV. His name - Dick Smith. Cost... a barge with some white sheets.
I now have a Pico AND a P2... they will land in one box to make a retrocomputer... For a retrocomputer even 64 pins are not enough. Cartridge and PIO ports need pins. A lot of digital pins. Pico has only 26 of them, but it is cheap and can be connected to P2 via fast serial link.
The only problem is I can't use spin to program a Pico. Its IDE is (for me) overengineered.