Once the P2 has been given the all go signal. It's a marketing game to get the word out to engineers and businesses and hopefully get some multi-million unit a year design wins.
Are there ADCs and DACs on every pin? I was under the impression that there were a smaller number of ADCs/DACs that could be mapped to any pin. I'm probably wrong about that since I haven't been following that detail very closely.
A cog can configure 4 pins at a time as ADC/DAC. So if you need the maximum speed ADC/DAC then you can only have 32 (if you have all 8 cogs doing 4).
However, my understanding is that you can switch the configured pins on-the-fly and for example have one cog do 8 DACs at a little less than half maximum speed. I remember talking about this with Chip for DACs, but I'm not sure if it works for ADCs as well. I guess it depends on your usage needs. It's also unknown what issues the config switching might have on the signal.
That is exactly the intent. Speed / number of pins / accuracy trade-off.
I believe Chip mentioned they are latched or buffered. So the COG can give one attention, then switch to another one, return, with whatever state it's in preserved for outputs.
If memory serves me, I read a doc once that mentioned that the P2 would have "signal correction"
on each pin. I don't even know what that means, but am I just imagining things?
A cog can configure 4 pins at a time as ADC/DAC. So if you need the maximum speed ADC/DAC then you can only have 32
Wow, the news about the P2 just keeps getting better and better ! 4 concurrent A/D conversions per cog is phenomenally good throughput. Until recently, most microcontrollers could only convert 1 input at a time (multiplexed over multiple pins); now 2, 3, and even 4 parallel ADCs is becoming more common, but the P2 can do 32 ? The metric [ADC inputs] would apparently be 92, which is also more than any other microcontroller I'm aware of.
My primary application needs a maximum of about 12 ADC inputs, which I'm currently doing with a P1 cog driving an MCP3308 and an NAU7802; it would be nice to have at least 2 conversions in parallel like I have now with the 2 external ADCs.
It appears that in the P2, 1 thread in 1 cog could manage 30 or so inputs (if the thread had its fair share of 128 longs and was not LMM), 4 in parallel, which is as good as any microcontroller out there, and that's just one 1/4 of one cog.
Dave,
I believe most of the "work" is done at the pin, but Beau and Chip would have to give the definitive answer here. The pins have a pretty sizable chunk of transistors in them. I recall Chip saying that the delta-sigma circuitry for the ADC and DAC was in each pin pad.
So for the casual engineer sniffing around for those features, the Prop does not even show up.
What is wrong with saying that the P2 has UARTs, SPI, etc? Because it isn't a hardware implementation? So what! List the maximum number that *can* be supported. Every good engineer is going to take a more detailed look before settling on a processor anyhow. For example, I definitely read Microchip's docs first (e.g. just to make sure that the two SPIs and the 3 ADCs I want to use aren't sharing pins). I certainly don't feel that Microchip is falsely stating a MCU's capability when I can't use all of its features simultaneously.
So, IMHO, those filters should be interpreted as "can support", not "does support".
1) Offer not just a single Propeller chip but a whole range of different ones. Each member of he range will have a different part number.
2) They will have all sorts of different combinations of UARTs, SPI, I2C, ADC, DAC, audio in out, keyboard, mouse, video etc etc etc.
3) Provide different data sheets for each device explaining exactly what features it has and how to use them.
4) Of course all these different devices will actually be the same device with a different number stamped on them and different data sheets. But...
5) When the user gets to his Prop Tool he has to give it the part number of the device he has bought. The tool then automatically includes all the drivers required to create the device the user has bought.
There we go. All of a sudden Parallax has a huge range of devices to fill out the selection filters on distributors web pages and the users are happy as pigs in ... like they are when searching for that perfect PIC or AVR.
I'm fine with a single MCU that indicates what it *can* do. I think people who will be considering the P2 are smart enough to figure out the limitations as it applies to their situation, which is no different than for most other MCUs.
Conversely, it makes little sense to state that the P2 has no UART, SPI, etc just because those capabilities are software-defined. To that end, it would probably make sense for Parallax to have a collection of "official" drivers for each if those functions.
Maybe we need a new classification: There are Microcontroller, there are FPGA's and there are Propeller ;-)
'F' in a Microcontroller, has historically meant Flash, (ask any PIC/SiLabs user ) so it is not a good choice for a non-flash device.
You also lose the common root search that having P8X32 gives, so I would tread that as a Family name, as Chip is doing, and it follows from PIC16F, PIC18F, AT89LP5, C8051F as common family, web part-code sub-string searchable names.
That leaves the suffix to change, and single early-letter changes are used already by many for die-revisions, so they are a poor choice.
I would use the package as the most-obvious-to-everyone, which to me gives P8X32T128 or maybe P8X32MT128 'MT for Multi Threaded'
Seairth, heater, etc:
I have said for a long time that Parallax should indicate all those peripherals are possible. The P1 can support 16 Uarts, so uarts=16, I2C=17, etc, VGA=4 (yes but nothing else!), TV=8 (with 8 pins free!). But the datasheet needs to immediately state the restrictions - ie they are soft and can be on any pins. Parallax really needs to get these facts out there. Perhaps this can be done with the P2 and part of the "blurb" refer to its little cousin, the P1.
I'm fine with a single MCU that indicates what it *can* do. I think people who will be considering the P2 are smart enough to figure out the limitations as it applies to their situation, which is no different than for most other MCUs.
The problem is trying to get the Mouser and Digi-Key behemoths to revamp THEIR systems to account for what is an uncommon feature. I believe Cypress PSOC's have similar capabilities, have to look up how they deal with it.
Bottom line is, it may be nigh on impossible to explain "can" do in a parametric search unless you can get them to buy into the concept. Which the Prop has had very limited ability to do so far.
Conversely, it makes little sense to state that the P2 has no UART, SPI, etc just because those capabilities are software-defined. To that end, it would probably make sense for Parallax to have a collection of "official" drivers for each if those functions.
No, it makes perfect sense from the industry standpoint.
This goes back in part to my suggestion of a few years ago about Parallax creating a Gold Standard for OBEX sotware-defined peripherals. I agree with one of the posters above, and suggest Parallax create several different SKU's with multiple Cogs/Cores pre-programmed with loads of ADC/DAC/Serial/UART/etc.
Imagine if a parametric search turned up a P2 with 4 Serial/4 12bit ADC/ 4 I2C/4 blah,
and then below that was a P2 with 2 Serial/2 12bit ADC/ 2 I2C/2 blah/2 blah/2 blah, etc.
Get 3-4 SKU's with multiple's of items people want, each targeted slightly differently.
And make it clear on the very first page of any technical datasheet that you can add/subtract all of these, and include multiple different 'other' peripherals as well.
The old chestnut that Insanity is doing the same thing over and over again and expecting a different result is pertinent here.
Parallax has to do something radically different to what they've done in the past, if they want to see markedly better uptake on the P2.
I'm still not sure what the power budget is for the P2, however IIRC its significant. Any off the cuff cost benefit is going to look at these and the comparison to the current market leaders is going to be stiff. The ability to morph cores to create peripherals is a sellable point, however it needs to be in context with BOM and alternatives.
I still think there should be consideration of re-branding to a more suitable name. The Prop was an experiment in the market, and only Parallax knows how well its performed. It may have picked up a lot of BS Users, however the Arduino and Pic32 to say nothing of ARM, seem to have engulfed the majority of the air, and I wouldn't naturally expect the P2 to have a similar success rate outside of the current P1 enclave.
I have said for a long time that Parallax should indicate all those peripherals are possible.
Agreed. And the best part is, when some new digital protocol becomes popular and all of those sites add a new search criteria, odds are that the P2 can claim that feature as well! No new part number required!
The problem is trying to get the Mouser and Digi-Key behemoths to revamp THEIR systems to account for what is an uncommon feature. I believe Cypress PSOC's have similar capabilities, have to look up how they deal with it.
Bottom line is, it may be nigh on impossible to explain "can" do in a parametric search unless you can get them to buy into the concept. Which the Prop has had very limited ability to do so far.
I wasn't saying that the search engines should be changed (though that would be nice) or that the searchers need reeducation. Products are *already* listed by what they "can" do, not what they "will" do (e.g. PIC, AVR, etc). So why should P2 be any different?
I agree with one of the posters above, and suggest Parallax create several different SKU's with multiple Cogs/Cores pre-programmed with loads of ADC/DAC/Serial/UART/etc.
Well, the concept of modules would make that discussion interesting. Package the thing up with rock solid driver code / libraries / whatever.
At the core, a Propeller just isn't directly comparable to other devices. This presents an interesting marketing challenge. Many existing norms surrounding how people see value in these things just don't mesh well, given how differentiated a propeller really is.
IMHO, a lot of advocacy work is needed to put alternative value statements out there. In effect, begin to differentiate the competition in ways that favor propellers. I know, that's guerrilla type tactics, but perhaps they are warranted. It wouldn't have to be dishonest, just pointed.
potatohead, I agree, and excellent point that the P* family is very difficult to compare against COTS uC.
I would think that Parallax really needs to make the P2 as or more successful than the P1 if there is ever going to be a P3.
I'd be looking at something that is a bit more brand serious than Propeller still.
Guerilla marketing sounds interesting, however figuring out -how- to do so to Engineer types would likely be an entire project in and of itself. Getting some sort of partnership with HackAday or similar with a uC project challenge with a couple hundred free boards, etc, etc.
Circuit Cellar has then annually for different processors.
Well, the concept of modules would make that discussion interesting. Package the thing up with rock solid driver code / libraries / whatever.
At the core, a Propeller just isn't directly comparable to other devices. This presents an interesting marketing challenge. Many existing norms surrounding how people see value in these things just don't mesh well, given how differentiated a propeller really is.
IMHO, a lot of advocacy work is needed to put alternative value statements out there. In effect, begin to differentiate the competition in ways that favor propellers. I know, that's guerrilla type tactics, but perhaps they are warranted. It wouldn't have to be dishonest, just pointed.
I've had some experience in that area. Mostly mechanical engineers. Agreed, it's a project. One that would require a small team to really dig into those differences. The good news is that process might not take all that long.
Frankly, I would make a process argument. One notable difference with a Propeller ends up being how people work and where the pain points are. The key to a process type argument is identifying how those shifts warrant an investment of some sort. And there are always pain points and there are always investments too. No free lunches and every engineer knows that. What they don't know is how their process could look and perform differently for them, and it's not that they can't or won't, it's more about there isn't much reason to go digging into those things, unless given one, thus the process argument. This kind of approach aligns very well with highly differentiated technology offerings.
re: pointed
This sounds abrasive or abrupt or worse, but it really isn't. Truth is having a compelling offering warrants this kind of activity. Done right, it's not a turn off. Nobody can really blame an effort to get people to think about it a little. The rewards are worth the trouble. Start with that kind of ethic on it, and the results could be something that generate some considerable discussion. If that happens, it's likely a good thing, IMHO.
Here is what drives me to think about process. I have explored other micros. Originally, I got back into this stuff through retro-computing, which kind of let me pick up where I left off many years ago before I took a path into manufacturing and ended up in CAD / product design / CAM type tools, consulting, etc...
Process on older machines can look a lot like it does today, but it doesn't have to. Lots of alternatives exist, and that's due to the nature of those times.
When I picked up a Propeller, I found I could employ a very lean process compared to other devices I had glanced at. The initial investment required to get going was literally a day. Pretty low bar, if you think about it. From there, it soon became apparent that a more traditional process could work, but often wasn't optimal, and a ton of effort has gone into designing that away. And don't get me wrong, those are great efforts. Needed.
But, we still are left without things like JTAG, and on P2, we will have things like C that make a lot of sense. Or at least more sense than they do on P1, and on that note, C makes way more sense now than it did in the past. The work is paying off nicely.
So there are two ways to go about this. One is to design the exceptions away, leaving the superior technology as a selling point. "drop one in, and you won't regret it" and I think that's perfectly valid, though it does lead us right to the discussion here, doesn't it?
The other way to go about this is to talk about lean and what that can mean compared to existing processes. Perhaps they can mesh together in some way, or be complimentary. Both approaches do put the superior technology on the table for consideration, but the context is different. One is a "blend in, but somehow be different" approach and the other is more like, "yeah, it's different, but it makes sense" kind of thing.
Anyway, lean, flexible, powerful, robust are the three words that come to mind on P2. Maybe I would add elegant to that list, depending on perspective. I think it is, and my recent experience coding up a mandelbrot fractal with HDTV / Composite display in assembly language in a couple of hours was notable. All of those resonated. Lean has to do with the fact that the core instructions are seriously potent and not too difficult to use. Flexible was shown by the relative ease with which a display got created and used. Bill Henning added VGA to that in a pinch too. Just not tough to do. Powerful is all about the fact that we are doing amazing things a few COGS down and at a third of the expected clock, and elegant has to do with how the tools, technical features and such appear to be coming together to make an accessible package.
You guys all saw the Space Invaders game right? Are you kidding me?
First, that was a brilliant demonstration of the multi-threading, LMM capability, video generation, and relative capability the chip has in raw assembly language. Lots to learn from that little game frankly. I've been tinkering with it for a while now, and I must say, we really have no idea how freaking great this chip really is yet. Ozpropdev is getting there quickly though.
The same was true for a P1, BTW.
"Take the one COG challenge" rings in my head somehow. Seriously.
So, the process bits. We don't have JTAG, but we do have an on-chip monitor, though a whole batch of younger developers may not even understand what one of those really is. We can get live data out of the chip with relative ease, drive multiple displays, more serial than most people would ever want, DAC/ADC all over the place, and so on... Somebody should ask Ozpropdev about his process. Bet there are some clever bits there to talk about.
One thing about JTAG is that it permits evaluation of what is happening inside while things are running. A Prop does this differently, and the process changes a little. But, the end result is very accessable and useful. It's just a different and arguably leaner process.
When I was working with video related things, I originally started out with the usual cycle. Write something, upload it, see the damage, modify, upload again, and so on... Then, I learned I could just send code to and from the chip while it was running! Went on a several hour stint without ever power cycling my P2. Push code to it, launch it on a COG, push more code to it, launch that, the two connect and something happens. it's ugly, so I kill off one of those, push more code to it, and so on. Maybe tweak a value here, stop a COG, change a few of those values, patch an instruction with a NOP, fire it back up, whatever. When it all ended up running good, I could pull the code back out as a binary image for later too, but I didn't need to.
It's entirely possible to have a program running and just hop in via the serial connection, use the monitor or some other debug facility resident and running and just do stuff while the program is running. Some careful code means even swapping major chunks out, like say an HDTV display being yanked, and replaced with a TV or VGA one, or maybe a module that logs data being redirected to some other storage area, or replaced by something that streams to a terminal, whatever. Nothing out there does this, unless it's a full on computer. (Or running FORTH )
Then again, we can take the standard path too. Setup tool chain, compile, upload, debug through terminal, whatever is needed.
Do all of these make sense? Probably not and definitely not to everybody. But that's the kinds of places one goes with a process discussion. Where are the pain points with other devices now and where do they fall in the process and how can a P2 run differently and compare very favorably, or deliver some gain that warrants a closer look? If it were me, that would be a line of discovery, along with others used to form the value statement advocacy needed to do the guerilla marketing type stuff. It's the kind of thing that people might look at and say, "Oh man! Seriously?"
You know, Cluso brought up something too. That little game runs on a single COG and it doesn't use too many resources. On a real P2, one could very easily drive say 5, 6 instances of it, with controllers, displays, the whole works! Maybe even modify it some to allow the various players to interact somehow, like invaders shot land in the formations of other players, and invaders do not disappear until shot three times or something. Can you imagine that?
Video game party on a chip, multi-player, retro, goodness for 8 on one P2 micro, concurrent, multi-core, multi-tasking, multi-user, multi-display. Nuts! When we get some other works done, who is to say we can't just have a few different titles running? Pick up a controller, hit select, then start, all the while others are doing their thing uninterrupted. I'm serious.
My .02 anyway.
I'm back to work on the P2 video driver that tears on some displays... Gotta get that sorted out. Real chips are sneaking up on me!
I would not say that my multiple SKU's for the same Propeller was serious or sarcastic. It's just an off the wall idea that I have thrown out on the forums a couple of times now. It probably has no value, as most ideas don't, but in may spark a better idea elsewhere.
Personally I don't like it as it seems underhand or dishonest. I'm not sure why I have that feeling though, if all the SKU's are the same price there is no scam in there.
If you think it' crazy listen to this:
There is one other product in the world that is comparable to the Prop II. Multiple cores, hardware scheduled threads. lots' of I/O pins, no standard peripherals cast in silicon. Yes the micro-controllers from XMOS. Sorry I used the name that should go unmentioned.
XMOS chips have multiple cores, up to 4 so far, and each core can support hardware scheduled threads, up to 8. Alternately executing instructions from each thread like the Prop II.
Recently XMOS revamped their marketing and made a stunning move. All of a sudden the "cores" were renamed as "tiles", the threads were renamed as "cores", all be it that that is redefined as "logical cores" somewhere in the small print. So now they could advertise up to 32 cores!!
You can see the motivation here, people are used to the idea of multiple cores and not so much used to the idea of "thread slicing" so some MBA marketing type somewhere obviously had the brilliant idea to rename everything to make it sound better. More "cores" is better.
I was sickened by all this, it's deceptive, it's dishonest, it confuses engineers who are used to calling a spade a spade and know what spades are. It confuses more because last time I checked the bulk of the technical documentation still used the old nomenclature. This move caused a lot of unrest and anger on the XMOS forum.
XMOS must be having the same problems getting their devices under the noses of guys who are looking for MCU with peripherals x, y, z as they also don't have any.
Perhaps it's worth having a peek at how XMOS pushes their product, but I would not like to see such underhand marketing going on.
So technically it's 32 ADC/DAC with 92 analog latches. That's a little different than 92 ADC/DAC.
IIRC you can "digitally" drive max 4 dacs at a time from a cog. If it's an analog latch on the pin or a full DAC is the same. At the end you can output an analog signal from any pin (eg analog presets, analog offsets or biases eg for instrumentation setup) but you can control in real time (eg outputting a signal that require continuous changes like outputting audio or waveform generator ...) max 4 channels from the same cog.
For the analog inputs I am sure I remember them doing sigma-delta at the pin level and IIRC with single pin but I am not sure if the cog counters are involved in this (which sets the limit) or the pins have a simplest counter support circuitry of their own.
What I'd like it can be done in hw is to configure adc as comparators by writing a compare value to a register, still read the actual analog value, and configure the comparator output to another pin. This will offload the cog from the sw comparation gaining in quickness and/or save additional board components. It can be very useful in ac power electronics like light controllers, inverters ... where you drive igbts through a digital output in pwm, you read the current flow as needed by the process control loop and at the same time you have your quick short-circuit protection by the comparator output that is ored to your counter (or sw) output killing its pwm output pulses thus shutting the igbt before the current becomes destructive. The register/couter/latch or whatever it is can be the same, by reading it you read the actual analog value while writing it sets the compare to value.
The calssification problem remains with the P2. Let's say it did make it onto ELFA's selection system.
The only check boxes is satisfies are:
Bit width - 32 - check
RAM - 128K - check
I/O Pins - 96 - check
DAC -96 - may be check
ADC - 96 - maybe check
So far so good but then it goes down hill fast:
FLASH - none
UART - none
SPI - none
I2C - none
USB - none
and so on.
So for the casual engineer sniffing around for those features, the Prop does not even show up. It has nothing to offer aparently that all the others are expected to have (32 bits, 128K RAM, some I/O bits)
There is not check box for number of cores. There is no way to fit in the fact that the Prop can have all those "missing" features quite easily in sofware with a selection of driver objects.
There is not a check box for advanced features like not needing interrupts, being able to drive any pin for any function (Not possible on many chips) and so on.
The Prop has a big advantage in this: all this peripherals cannot be buggy by silicon design. I have used a 8052 variant with a full support circuity for usb which had a bug. Fortunately there was a sw fix and procedure to follow to avoid the issues from the buggy silicon.
Assuming that parallax provides well tested drivers (self-developed or donated by community for uarts, i2c (master/slave possibly multimaster that meets the specs) spi, ... I wouldn't see any lie in the datasheet stating this specs:
eg. for Prop1
- 8 cores
- 8 timers
- 8 counters
- 28 serial ports (assuming the 4 channel serial driver is used and a cog is needed for the main process)
- and so on ...
At the end when you look at the datasheet for 8051/2, pics ... and similar mcus they have many peripherals but at the end by reading the full document you discover that you can't use a timer if you have chosen the second uart (because it's needed for its timebase) you can't read an adc real val because you have chosen to use it as comparator you can't use a interrupt because of ....
So IMHO it's enough to write the above numbers for the peripherals on the first page of the datasheet making it more similar in the look to the traditional(competitor's) mcus in order to give to the potential client the feeling he's comparing apple with apples and thus fulfill all this criteria of the various distributors selection engines. So now to be honest the only thing the Prop lacks is the built-in flash. Since the embedded loader doesn't support any boot media except for spi flash and the silicon build technology used for the P2 doesn't allow for it, perhaps Parallax can package together two dies, their own P2 and one supplied flash die.
Edit: Interrupts: They are not needed, true.
This is a forced concept I have never tried, but what's wrong in saying that the prop have also a "pseudo-interrupt-controller"? Isn't usually interrupt handlers written in assembler even if the main language used is of a higher class like C, Basic or whatever else and the main code processing stops until a return from the interrupt handler? What happens if I use 1, 2, 3 or how many cogs are needed to run my C/spin code and I devote one, written in pasm, looking at IOs, that places a lock trough the hub? Wouldn't this stop the other cogs accessing the hub and thus stopping spin and whatever lmm execution until the lock is released and in this way emulating a sort of interrupt? When than the user becomes more familiar to the prop and understands how easily are the programs to write and manage by exploiting the parallel nature of the prop will for sure change his mind, isn't it?
Interrupt handlers need not be written in assembler. I have produced a few in high level languages, PL/M for example. Linux has interrupt handlers in C.
At the end of the day interrupts are about two or three things (all though in my mind they are all the same thing):
1) Pretending to run multiple threads of code at the same time. Instead of two processors running two threads an interrupt routine runs in the same processor. In a real OS a timer tick interrupt routine is used to actually switch execution of threads that are not themselves part of the interrupt routine.
2) Avoiding having to poll inputs to see if some event has happened. Polling is a waste of CPU cycles.
3) Minimizing latency in response to some external events. Implies interrupts have priorities.
Item 1) the Prop does naturally with multiple cores.
Items 2) and 3) the Prop does with waitpe and friends.
The complexity of priorities is not required as we have totally separate cores for each event.
Essentially the Propeller is event driven rather than interrupt driven.
You interrupt simulation scheme may be made to work, sadly it offers all the bad parts of an interrupt system like stalling your background processing and all other threads whilst not offering the benefits of speed, low latency etc.
Comments
Maybe we need a new classification: There are Microcontroller, there are FPGA's and there are Propeller ;-)
"Blackfin" - http://www.analog.com/en/processors-dsp/blackfin/products/index.html
"Tigersharc" - http://www.analog.com/en/processors-dsp/tigersharc/products/index.html
"Zynq" - http://www.xilinx.com/content/xilinx/en/products/silicon-devices/soc/zynq-7000.html
Use of "z", q, and y in odd ways has been popular to make a name stand out ever since the "Compaq" computer. As that last example shows nicely.
So we could have "Oqtyqor" for the Prop II for example:)
Corrections:
RAM - 126K
I/O pins - 92
ADC/DAC - 92
However, my understanding is that you can switch the configured pins on-the-fly and for example have one cog do 8 DACs at a little less than half maximum speed. I remember talking about this with Chip for DACs, but I'm not sure if it works for ADCs as well. I guess it depends on your usage needs. It's also unknown what issues the config switching might have on the signal.
I believe Chip mentioned they are latched or buffered. So the COG can give one attention, then switch to another one, return, with whatever state it's in preserved for outputs.
very versatile chip :-)
on each pin. I don't even know what that means, but am I just imagining things?
Wow, the news about the P2 just keeps getting better and better ! 4 concurrent A/D conversions per cog is phenomenally good throughput. Until recently, most microcontrollers could only convert 1 input at a time (multiplexed over multiple pins); now 2, 3, and even 4 parallel ADCs is becoming more common, but the P2 can do 32 ? The metric [ADC inputs] would apparently be 92, which is also more than any other microcontroller I'm aware of.
My primary application needs a maximum of about 12 ADC inputs, which I'm currently doing with a P1 cog driving an MCP3308 and an NAU7802; it would be nice to have at least 2 conversions in parallel like I have now with the 2 external ADCs.
It appears that in the P2, 1 thread in 1 cog could manage 30 or so inputs (if the thread had its fair share of 128 longs and was not LMM), 4 in parallel, which is as good as any microcontroller out there, and that's just one 1/4 of one cog.
Chip is going to have to give us more detail on it. There is a lot we don't know yet.
I believe most of the "work" is done at the pin, but Beau and Chip would have to give the definitive answer here. The pins have a pretty sizable chunk of transistors in them. I recall Chip saying that the delta-sigma circuitry for the ADC and DAC was in each pin pad.
What is wrong with saying that the P2 has UARTs, SPI, etc? Because it isn't a hardware implementation? So what! List the maximum number that *can* be supported. Every good engineer is going to take a more detailed look before settling on a processor anyhow. For example, I definitely read Microchip's docs first (e.g. just to make sure that the two SPIs and the 3 ADCs I want to use aren't sharing pins). I certainly don't feel that Microchip is falsely stating a MCU's capability when I can't use all of its features simultaneously.
So, IMHO, those filters should be interpreted as "can support", not "does support".
Sure why not. Here's an idea:
1) Offer not just a single Propeller chip but a whole range of different ones. Each member of he range will have a different part number.
2) They will have all sorts of different combinations of UARTs, SPI, I2C, ADC, DAC, audio in out, keyboard, mouse, video etc etc etc.
3) Provide different data sheets for each device explaining exactly what features it has and how to use them.
4) Of course all these different devices will actually be the same device with a different number stamped on them and different data sheets. But...
5) When the user gets to his Prop Tool he has to give it the part number of the device he has bought. The tool then automatically includes all the drivers required to create the device the user has bought.
There we go. All of a sudden Parallax has a huge range of devices to fill out the selection filters on distributors web pages and the users are happy as pigs in ... like they are when searching for that perfect PIC or AVR.
Conversely, it makes little sense to state that the P2 has no UART, SPI, etc just because those capabilities are software-defined. To that end, it would probably make sense for Parallax to have a collection of "official" drivers for each if those functions.
'F' in a Microcontroller, has historically meant Flash, (ask any PIC/SiLabs user ) so it is not a good choice for a non-flash device.
You also lose the common root search that having P8X32 gives, so I would tread that as a Family name, as Chip is doing, and it follows from PIC16F, PIC18F, AT89LP5, C8051F as common family, web part-code sub-string searchable names.
That leaves the suffix to change, and single early-letter changes are used already by many for die-revisions, so they are a poor choice.
I would use the package as the most-obvious-to-everyone, which to me gives
P8X32T128 or maybe P8X32MT128 'MT for Multi Threaded'
I have said for a long time that Parallax should indicate all those peripherals are possible. The P1 can support 16 Uarts, so uarts=16, I2C=17, etc, VGA=4 (yes but nothing else!), TV=8 (with 8 pins free!). But the datasheet needs to immediately state the restrictions - ie they are soft and can be on any pins. Parallax really needs to get these facts out there. Perhaps this can be done with the P2 and part of the "blurb" refer to its little cousin, the P1.
Bottom line is, it may be nigh on impossible to explain "can" do in a parametric search unless you can get them to buy into the concept. Which the Prop has had very limited ability to do so far.
No, it makes perfect sense from the industry standpoint.
This goes back in part to my suggestion of a few years ago about Parallax creating a Gold Standard for OBEX sotware-defined peripherals. I agree with one of the posters above, and suggest Parallax create several different SKU's with multiple Cogs/Cores pre-programmed with loads of ADC/DAC/Serial/UART/etc.
Imagine if a parametric search turned up a P2 with 4 Serial/4 12bit ADC/ 4 I2C/4 blah,
and then below that was a P2 with 2 Serial/2 12bit ADC/ 2 I2C/2 blah/2 blah/2 blah, etc.
Get 3-4 SKU's with multiple's of items people want, each targeted slightly differently.
And make it clear on the very first page of any technical datasheet that you can add/subtract all of these, and include multiple different 'other' peripherals as well.
The old chestnut that Insanity is doing the same thing over and over again and expecting a different result is pertinent here.
Parallax has to do something radically different to what they've done in the past, if they want to see markedly better uptake on the P2.
I'm still not sure what the power budget is for the P2, however IIRC its significant. Any off the cuff cost benefit is going to look at these and the comparison to the current market leaders is going to be stiff. The ability to morph cores to create peripherals is a sellable point, however it needs to be in context with BOM and alternatives.
I still think there should be consideration of re-branding to a more suitable name. The Prop was an experiment in the market, and only Parallax knows how well its performed. It may have picked up a lot of BS Users, however the Arduino and Pic32 to say nothing of ARM, seem to have engulfed the majority of the air, and I wouldn't naturally expect the P2 to have a similar success rate outside of the current P1 enclave.
Hopefully I'll be forced to eat my hat.
Agreed. And the best part is, when some new digital protocol becomes popular and all of those sites add a new search criteria, odds are that the P2 can claim that feature as well! No new part number required!
I wasn't saying that the search engines should be changed (though that would be nice) or that the searchers need reeducation. Products are *already* listed by what they "can" do, not what they "will" do (e.g. PIC, AVR, etc). So why should P2 be any different?
I think he was being sarcastic.
At the core, a Propeller just isn't directly comparable to other devices. This presents an interesting marketing challenge. Many existing norms surrounding how people see value in these things just don't mesh well, given how differentiated a propeller really is.
IMHO, a lot of advocacy work is needed to put alternative value statements out there. In effect, begin to differentiate the competition in ways that favor propellers. I know, that's guerrilla type tactics, but perhaps they are warranted. It wouldn't have to be dishonest, just pointed.
potatohead, I agree, and excellent point that the P* family is very difficult to compare against COTS uC.
I would think that Parallax really needs to make the P2 as or more successful than the P1 if there is ever going to be a P3.
I'd be looking at something that is a bit more brand serious than Propeller still.
Guerilla marketing sounds interesting, however figuring out -how- to do so to Engineer types would likely be an entire project in and of itself. Getting some sort of partnership with HackAday or similar with a uC project challenge with a couple hundred free boards, etc, etc.
Circuit Cellar has then annually for different processors.
Frankly, I would make a process argument. One notable difference with a Propeller ends up being how people work and where the pain points are. The key to a process type argument is identifying how those shifts warrant an investment of some sort. And there are always pain points and there are always investments too. No free lunches and every engineer knows that. What they don't know is how their process could look and perform differently for them, and it's not that they can't or won't, it's more about there isn't much reason to go digging into those things, unless given one, thus the process argument. This kind of approach aligns very well with highly differentiated technology offerings.
re: pointed
This sounds abrasive or abrupt or worse, but it really isn't. Truth is having a compelling offering warrants this kind of activity. Done right, it's not a turn off. Nobody can really blame an effort to get people to think about it a little. The rewards are worth the trouble. Start with that kind of ethic on it, and the results could be something that generate some considerable discussion. If that happens, it's likely a good thing, IMHO.
Here is what drives me to think about process. I have explored other micros. Originally, I got back into this stuff through retro-computing, which kind of let me pick up where I left off many years ago before I took a path into manufacturing and ended up in CAD / product design / CAM type tools, consulting, etc...
Process on older machines can look a lot like it does today, but it doesn't have to. Lots of alternatives exist, and that's due to the nature of those times.
When I picked up a Propeller, I found I could employ a very lean process compared to other devices I had glanced at. The initial investment required to get going was literally a day. Pretty low bar, if you think about it. From there, it soon became apparent that a more traditional process could work, but often wasn't optimal, and a ton of effort has gone into designing that away. And don't get me wrong, those are great efforts. Needed.
But, we still are left without things like JTAG, and on P2, we will have things like C that make a lot of sense. Or at least more sense than they do on P1, and on that note, C makes way more sense now than it did in the past. The work is paying off nicely.
So there are two ways to go about this. One is to design the exceptions away, leaving the superior technology as a selling point. "drop one in, and you won't regret it" and I think that's perfectly valid, though it does lead us right to the discussion here, doesn't it?
The other way to go about this is to talk about lean and what that can mean compared to existing processes. Perhaps they can mesh together in some way, or be complimentary. Both approaches do put the superior technology on the table for consideration, but the context is different. One is a "blend in, but somehow be different" approach and the other is more like, "yeah, it's different, but it makes sense" kind of thing.
Anyway, lean, flexible, powerful, robust are the three words that come to mind on P2. Maybe I would add elegant to that list, depending on perspective. I think it is, and my recent experience coding up a mandelbrot fractal with HDTV / Composite display in assembly language in a couple of hours was notable. All of those resonated. Lean has to do with the fact that the core instructions are seriously potent and not too difficult to use. Flexible was shown by the relative ease with which a display got created and used. Bill Henning added VGA to that in a pinch too. Just not tough to do. Powerful is all about the fact that we are doing amazing things a few COGS down and at a third of the expected clock, and elegant has to do with how the tools, technical features and such appear to be coming together to make an accessible package.
You guys all saw the Space Invaders game right? Are you kidding me?
First, that was a brilliant demonstration of the multi-threading, LMM capability, video generation, and relative capability the chip has in raw assembly language. Lots to learn from that little game frankly. I've been tinkering with it for a while now, and I must say, we really have no idea how freaking great this chip really is yet. Ozpropdev is getting there quickly though.
The same was true for a P1, BTW.
"Take the one COG challenge" rings in my head somehow. Seriously.
So, the process bits. We don't have JTAG, but we do have an on-chip monitor, though a whole batch of younger developers may not even understand what one of those really is. We can get live data out of the chip with relative ease, drive multiple displays, more serial than most people would ever want, DAC/ADC all over the place, and so on... Somebody should ask Ozpropdev about his process. Bet there are some clever bits there to talk about.
One thing about JTAG is that it permits evaluation of what is happening inside while things are running. A Prop does this differently, and the process changes a little. But, the end result is very accessable and useful. It's just a different and arguably leaner process.
When I was working with video related things, I originally started out with the usual cycle. Write something, upload it, see the damage, modify, upload again, and so on... Then, I learned I could just send code to and from the chip while it was running! Went on a several hour stint without ever power cycling my P2. Push code to it, launch it on a COG, push more code to it, launch that, the two connect and something happens. it's ugly, so I kill off one of those, push more code to it, and so on. Maybe tweak a value here, stop a COG, change a few of those values, patch an instruction with a NOP, fire it back up, whatever. When it all ended up running good, I could pull the code back out as a binary image for later too, but I didn't need to.
It's entirely possible to have a program running and just hop in via the serial connection, use the monitor or some other debug facility resident and running and just do stuff while the program is running. Some careful code means even swapping major chunks out, like say an HDTV display being yanked, and replaced with a TV or VGA one, or maybe a module that logs data being redirected to some other storage area, or replaced by something that streams to a terminal, whatever. Nothing out there does this, unless it's a full on computer. (Or running FORTH
Then again, we can take the standard path too. Setup tool chain, compile, upload, debug through terminal, whatever is needed.
Do all of these make sense? Probably not and definitely not to everybody. But that's the kinds of places one goes with a process discussion. Where are the pain points with other devices now and where do they fall in the process and how can a P2 run differently and compare very favorably, or deliver some gain that warrants a closer look? If it were me, that would be a line of discovery, along with others used to form the value statement advocacy needed to do the guerilla marketing type stuff. It's the kind of thing that people might look at and say, "Oh man! Seriously?"
You know, Cluso brought up something too. That little game runs on a single COG and it doesn't use too many resources. On a real P2, one could very easily drive say 5, 6 instances of it, with controllers, displays, the whole works! Maybe even modify it some to allow the various players to interact somehow, like invaders shot land in the formations of other players, and invaders do not disappear until shot three times or something. Can you imagine that?
Video game party on a chip, multi-player, retro, goodness for 8 on one P2 micro, concurrent, multi-core, multi-tasking, multi-user, multi-display. Nuts! When we get some other works done, who is to say we can't just have a few different titles running? Pick up a controller, hit select, then start, all the while others are doing their thing uninterrupted. I'm serious.
My .02 anyway.
I'm back to work on the P2 video driver that tears on some displays... Gotta get that sorted out. Real chips are sneaking up on me!
Personally I don't like it as it seems underhand or dishonest. I'm not sure why I have that feeling though, if all the SKU's are the same price there is no scam in there.
If you think it' crazy listen to this:
There is one other product in the world that is comparable to the Prop II. Multiple cores, hardware scheduled threads. lots' of I/O pins, no standard peripherals cast in silicon. Yes the micro-controllers from XMOS. Sorry I used the name that should go unmentioned.
XMOS chips have multiple cores, up to 4 so far, and each core can support hardware scheduled threads, up to 8. Alternately executing instructions from each thread like the Prop II.
Recently XMOS revamped their marketing and made a stunning move. All of a sudden the "cores" were renamed as "tiles", the threads were renamed as "cores", all be it that that is redefined as "logical cores" somewhere in the small print. So now they could advertise up to 32 cores!!
You can see the motivation here, people are used to the idea of multiple cores and not so much used to the idea of "thread slicing" so some MBA marketing type somewhere obviously had the brilliant idea to rename everything to make it sound better. More "cores" is better.
I was sickened by all this, it's deceptive, it's dishonest, it confuses engineers who are used to calling a spade a spade and know what spades are. It confuses more because last time I checked the bulk of the technical documentation still used the old nomenclature. This move caused a lot of unrest and anger on the XMOS forum.
XMOS must be having the same problems getting their devices under the noses of guys who are looking for MCU with peripherals x, y, z as they also don't have any.
Perhaps it's worth having a peek at how XMOS pushes their product, but I would not like to see such underhand marketing going on.
IIRC you can "digitally" drive max 4 dacs at a time from a cog. If it's an analog latch on the pin or a full DAC is the same. At the end you can output an analog signal from any pin (eg analog presets, analog offsets or biases eg for instrumentation setup) but you can control in real time (eg outputting a signal that require continuous changes like outputting audio or waveform generator ...) max 4 channels from the same cog.
For the analog inputs I am sure I remember them doing sigma-delta at the pin level and IIRC with single pin but I am not sure if the cog counters are involved in this (which sets the limit) or the pins have a simplest counter support circuitry of their own.
What I'd like it can be done in hw is to configure adc as comparators by writing a compare value to a register, still read the actual analog value, and configure the comparator output to another pin. This will offload the cog from the sw comparation gaining in quickness and/or save additional board components. It can be very useful in ac power electronics like light controllers, inverters ... where you drive igbts through a digital output in pwm, you read the current flow as needed by the process control loop and at the same time you have your quick short-circuit protection by the comparator output that is ored to your counter (or sw) output killing its pwm output pulses thus shutting the igbt before the current becomes destructive. The register/couter/latch or whatever it is can be the same, by reading it you read the actual analog value while writing it sets the compare to value.
The Prop has a big advantage in this: all this peripherals cannot be buggy by silicon design. I have used a 8052 variant with a full support circuity for usb which had a bug. Fortunately there was a sw fix and procedure to follow to avoid the issues from the buggy silicon.
Assuming that parallax provides well tested drivers (self-developed or donated by community for uarts, i2c (master/slave possibly multimaster that meets the specs) spi, ... I wouldn't see any lie in the datasheet stating this specs:
eg. for Prop1
- 8 cores
- 8 timers
- 8 counters
- 28 serial ports (assuming the 4 channel serial driver is used and a cog is needed for the main process)
- and so on ...
At the end when you look at the datasheet for 8051/2, pics ... and similar mcus they have many peripherals but at the end by reading the full document you discover that you can't use a timer if you have chosen the second uart (because it's needed for its timebase) you can't read an adc real val because you have chosen to use it as comparator you can't use a interrupt because of ....
So IMHO it's enough to write the above numbers for the peripherals on the first page of the datasheet making it more similar in the look to the traditional(competitor's) mcus in order to give to the potential client the feeling he's comparing apple with apples and thus fulfill all this criteria of the various distributors selection engines. So now to be honest the only thing the Prop lacks is the built-in flash. Since the embedded loader doesn't support any boot media except for spi flash and the silicon build technology used for the P2 doesn't allow for it, perhaps Parallax can package together two dies, their own P2 and one supplied flash die.
Edit: Interrupts: They are not needed, true.
This is a forced concept I have never tried, but what's wrong in saying that the prop have also a "pseudo-interrupt-controller"? Isn't usually interrupt handlers written in assembler even if the main language used is of a higher class like C, Basic or whatever else and the main code processing stops until a return from the interrupt handler? What happens if I use 1, 2, 3 or how many cogs are needed to run my C/spin code and I devote one, written in pasm, looking at IOs, that places a lock trough the hub? Wouldn't this stop the other cogs accessing the hub and thus stopping spin and whatever lmm execution until the lock is released and in this way emulating a sort of interrupt? When than the user becomes more familiar to the prop and understands how easily are the programs to write and manage by exploiting the parallel nature of the prop will for sure change his mind, isn't it?
At the end of the day interrupts are about two or three things (all though in my mind they are all the same thing):
1) Pretending to run multiple threads of code at the same time. Instead of two processors running two threads an interrupt routine runs in the same processor. In a real OS a timer tick interrupt routine is used to actually switch execution of threads that are not themselves part of the interrupt routine.
2) Avoiding having to poll inputs to see if some event has happened. Polling is a waste of CPU cycles.
3) Minimizing latency in response to some external events. Implies interrupts have priorities.
Item 1) the Prop does naturally with multiple cores.
Items 2) and 3) the Prop does with waitpe and friends.
The complexity of priorities is not required as we have totally separate cores for each event.
Essentially the Propeller is event driven rather than interrupt driven.
You interrupt simulation scheme may be made to work, sadly it offers all the bad parts of an interrupt system like stalling your background processing and all other threads whilst not offering the benefits of speed, low latency etc.