The Spin interpreter is not in ROM on the P2 so there is no need to run any Spin code if you don't want to. You can boot directly into PASM code on COG 0.
That's great news!
That's easy to do on the Prop1, just restart Cog0 with PASM code.
A 2-cog version would target low part count designs so you would have to have brown-out reset surely. Sure, you could get by without crystal or Flash but reliable reset is essential. Perhaps a watchdog is in order?
I agree reliable reset is vital, but that can be done with PGood regulators.
Crystal/Osc i’d call essential, as rcfast is not calibrated at all.
More important on smaller family parts will be to solve the power issues.
I don't want to make any unnecessary pad-level GDS changes, as it opens an expensive can of worms with ON Semi, in terms of time and money.
Ken had repeatedly said that there is no budget for a Parallax funded C compiler. This new money would be better spent on that than a new chip.
Where is the ROI on a compiler?
Offering smaller variants of the P2 will raise a whole new awareness of the capabilities of the Propeller. The ROI could easily be exponential.
Otherwise we definitely will be stuck with a boutique device that relatively few will appreciate....I don't see any ROI with this scenario.
How will customers program the various flavors of P2 if there are no tools? Sure the tools don't generate any direct revenue but don't they enable customers to use the chips?
Wasn't the lack of a C compiler considered one of the reasons P1 wasn't more successful? I realize we have Dave Hein's p2gcc but it isn't a "professional C/C++ toolchain".
If C is so great then why do other languages exist? I would not be using the P1 were it not for PropBasic.
I guess I never embraced this premise of brevity-is-beautiful...I want performance and readability. To me, the C language is the coding equivalent of The Emperor's New Clothes.
I will never entertain the idea of using this over-hyped language.
This is no place for a language war. There will be all sorts of them for P2, including Spin2/PASM, Forth, C/C++, BASIC, and more.
I will use what I am used to and am productive in, and you can use what you like.
Parallax would like C/C++ because many of their customers want it, simple as that. I'm sure if they had the resources, they would make as many languages/tools available as possible and reasonable.
If C is so great then why do other languages exist? I would not be using the P1 were it not for PropBasic.
I guess I never embraced this premise of brevity-is-beautiful...I want performance and readability. To me, the C language is the coding equivalent of The Emperor's New Clothes.
I will never entertain the idea of using this over-hyped language.
I'm not going to start a language war. I was just trying to suggest that if a big chunk of money is available it might be better to use it for tools development than another variant of the silicon. I could, of course, be wrong about that. And I fully understand that C is not everyone's favorite language and that it is not without its faults. It's just that many potential customers likely use it. I guess the Parallax marketing people would know that for certain and this decision is up to them not us anyway.
...AVR PIC and TI always win out for embedded designs because of cost/size/power/analog.
That is an interesting definition of "embedded" you have there.
In my experience embedded systems have run from custom made computers using bit-slice technology built into 19 inch racks for controlling radars on battle ships, to the Intel 486 and Motorola 68020 used to be the Primary Flight Computers of the Boeing 777, to tiny MCUs encrypting data in police radios.
Now a days embedded system processors include the full up Linux running machines you find in your domestic WiFi routers and the smarts behind Tesla auto-pilots and self-driving cars.
Sure we want our computers to be cheap, small and low power. That is true of all computers all the time. It does not define "embedded".
I love C. I use it all the time on ARM and AVR platforms. I'm writing C code today for a flight controller & autopilot. But I have no personal interest in any C on any Prop. Spin was far too easy to learn, is ideally suited to the Propeller, and interfaces perfectly to PASM (which is what 80% of my Propeller code is written in).
FWIW, if I had a small and inexpensive P2 like Chip has (literally) outlined, I'd be doing today's project on it instead. I think it/they are an absolutely outstanding idea! It is remarkable to own a proven architecture in Verilog that can be tailored quickly to produce a range of family members. The smart pin, cordic, PLL, and I/Q mixing IP are value multipliers to that architecture.
The very blunt fact is that without a commercial quality, manufacturer supported, C/C++ compiler the P2 will not sell enough chips to recover the ROI needed to justify the 10 years it has taken to get here.
A few hundred, or even a few thousand, chips sold here and there are but a drop in the ocean.
In that time, were it not for an endless stream of 'why don't we just add this?', Parallax could have launched a whole range of properly supported chips and be well on their way to earning back their investment.
People making endless suggestions for change need to understand that it is not their money they are playing with. Parallax employ people who depend on their wages getting paid each month.
Stop muddying the waters and let them get the current chip finished, launched, and properly supported. Then, and only then, is it time to think about what comes next.
All this talk about 2 and 4 cog versions is sooooooo painful to watch. We were so close to the finish line with the 8-cog version, and now we've gone off the track to go look at shiny objects. There are lots of other things to do before other versions should even be thought about. Every time I see the project diverted I just wonder why we even bother with spending time with the P2. I realize this is Chip's project, but many of us have been hoping to get our hands on the P2 for years.
PLEASE FINISH THE 8-COG VERSION!!!!!!! (YES, I AM YELLING!)
Dave, please don't be alarmed. The P2 looks to be done with this pending respin. There are only two problems with the current silicon:
1) Sign-extension issue in Verilog. Fixed and tested.
2) Glitch on some I/O's when DIR goes low when OUT is high. Will be investigated and fixed when respin underway.
When ON Semi does this job, it's a good opportunity to get some more work done by them. It doesn't slow down the main chip effort, just closely follows it. My definition work is already done for either a 2-cog or 4-cog variant. Getting this through ON Semi's pipe takes maybe 14 weeks. Might as well get it rolling now. That's how I see it.
OK, I kind of assumed that other people would hammer on the chip before it would be respun. Maybe there aren't any other bugs to be found.
The amount of retraining depends on the low-level drivers provided by the vendor, and whether the customer wants to write their own low-level drivers. I think most industrial customers understand that they need learn the details of the chip if they're going to program it at the lowest level.
OK, I kind of assumed that other people would hammer on the chip before it would be respun. Maybe there aren't any other bugs to be found.
I think Chip has mentioned placing the next packaged parts on boards, and using those for more testing, before hitting the 'go' on RevB, and I'd expect variant parts only have their 'go' buttons hit, after Rev B is back and proven.
ie Some of this is queue stuff, and some is Rev B related.
When I discovered the Prop, I was getting in to it, no matter what, because of its unique deterministic capabilities. I was only aware of Spin and PASM and I am not a programming wizard by any stretch...so be it, a new language is a Monday-Tuesday problem.
The real challenge for me was not a programming syntax, it was handling multiple servo PIDs, involving quadrature decoding and generating motion velocity profiles without resorting to interrupt shenanigans.
The discovery of PropBasic was a bonus that effectively cut PASM code development time dramatically.
... In that time, were it not for an endless stream of 'why don't we just add this?', Parallax could have launched a whole range of properly supported chips and be well on their way to earning back their investment.
People making endless suggestions for change need to understand that it is not their money they are playing with. Parallax employ people who depend on their wages getting paid each month.
Stop muddying the waters and let them get the current chip finished, launched, and properly supported. Then, and only then, is it time to think about what comes next.
+1
It's simply a matter of professional discipline, focus, and doing those vital things that you don't necessarily enjoy, as opposed to scratching the next itch.
People making endless suggestions for change need to understand that it is not their money they are playing with. Parallax employ people who depend on their wages getting paid each month.
Stop muddying the waters...
+1
Did I just step into a parallel universe or is this Chip's thread, wherein he asked, "Do you guys think there would be much of an early market for a reduced version of the P2...?"
The "people" are the owners of Parallax. Isn't it their privilege to ask such questions? Or is it that we are not allowed to voice our opinions, once asked, unless they match yours?
I think the cost issue is that if a second (or third) chip family is done at the same time as the current 8 cog version, that the extra cost will be minimal, compared with doing other parts later, such that now is a cheap offering.
This makes sense to me and may just get more media attention to help get more P2 traction.
What I don't know is how much a 2 cog P2 will really sell for. Chips estimate of $3 just seems too cheap. I do hope he is correct as that could be a real winner but I fear there is not enough meat in it for Parallax.
This makes sense to me and may just get more media attention to help get more P2 traction.
What will give the P2 the most traction is a finished set of docs and dev tools, not more versions. Good documentation is hard, tedious, and unpleasant to produce; and it takes a lot of time to do it right. That's why I think another diversion into spinning derivatives distracts from the real -- and more important -- work that still lies ahead.
A small package low pin count version would be lovely for the majority of products but I can see it would make the P1 completely redundant except for DIP40 designs. On that note it also becomes easier to squeeze a P2 into a 40 pin DIP module and maybe Parallax could then do a FLIP2.
There is quite a range of 64 pin packages at 8x8 or 9x9 for QFN, and 10x10 for TQFP, all of which would fit into a QFP44 courtyard.
Or, a BGA packaged P2 might even allow that too ?
Something I've wanted for ages is a programmable drop-in replacement for a socketed 40-pin IC (CPU, VDP, ULA, etc.) which is why I like the idea of a P2 that could fit between pins 0.6" apart. Barring the 8-cog version in BGA, I prefer 4-cog/256KB/40-I/O as 32 I/O will not be enough for many such applications and only two cogs gives you no leeway, performance-wise. Could there be fewer boot pins in the smaller packages, namely two? This would leave 38 available, to match the IC pin count excluding power.
What will give the P2 the most traction is a finished set of docs and dev tools...
Don't you think Chip can continue to work on Spin2 while the P2 respin works its way through the ON Semi pipeline? And wouldn't a good 95% of all docs and all dev tools for the P2 pertain to all members of the P2 family?
As far as having a family vs a single product, IBM showed a million years ago that customers prefer exactly that. I don't pretend the understand the psychology of it, but we literally had handicapped versions of the same hardware just so customers could feel they had a choice.
Comments
I don't want to make any unnecessary pad-level GDS changes, as it opens an expensive can of worms with ON Semi, in terms of time and money.
We've only got Verilog knobs to turn.
Where is the ROI on a compiler?
Offering smaller variants of the P2 will raise a whole new awareness of the capabilities of the Propeller. The ROI could easily be exponential.
Otherwise we definitely will be stuck with a boutique device that relatively few will appreciate....I don't see any ROI with this scenario.
I guess I never embraced this premise of brevity-is-beautiful...I want performance and readability. To me, the C language is the coding equivalent of The Emperor's New Clothes.
I will never entertain the idea of using this over-hyped language.
I will use what I am used to and am productive in, and you can use what you like.
Parallax would like C/C++ because many of their customers want it, simple as that. I'm sure if they had the resources, they would make as many languages/tools available as possible and reasonable.
Mickster, it's okay. This is a safe space.
Roy is right on this. There will be a lot of them.
This has been on my mind all day and from a commercial perspective I am convinced that you guys need to go for it 👍👍👍👍👍👍👍
In my experience embedded systems have run from custom made computers using bit-slice technology built into 19 inch racks for controlling radars on battle ships, to the Intel 486 and Motorola 68020 used to be the Primary Flight Computers of the Boeing 777, to tiny MCUs encrypting data in police radios.
Now a days embedded system processors include the full up Linux running machines you find in your domestic WiFi routers and the smarts behind Tesla auto-pilots and self-driving cars.
Sure we want our computers to be cheap, small and low power. That is true of all computers all the time. It does not define "embedded".
FWIW, if I had a small and inexpensive P2 like Chip has (literally) outlined, I'd be doing today's project on it instead. I think it/they are an absolutely outstanding idea! It is remarkable to own a proven architecture in Verilog that can be tailored quickly to produce a range of family members. The smart pin, cordic, PLL, and I/Q mixing IP are value multipliers to that architecture.
A few hundred, or even a few thousand, chips sold here and there are but a drop in the ocean.
In that time, were it not for an endless stream of 'why don't we just add this?', Parallax could have launched a whole range of properly supported chips and be well on their way to earning back their investment.
People making endless suggestions for change need to understand that it is not their money they are playing with. Parallax employ people who depend on their wages getting paid each month.
Stop muddying the waters and let them get the current chip finished, launched, and properly supported. Then, and only then, is it time to think about what comes next.
Is that true? Not fully... but perception drives business more than reality.
I think Chip has mentioned placing the next packaged parts on boards, and using those for more testing, before hitting the 'go' on RevB, and I'd expect variant parts only have their 'go' buttons hit, after Rev B is back and proven.
ie Some of this is queue stuff, and some is Rev B related.
The real challenge for me was not a programming syntax, it was handling multiple servo PIDs, involving quadrature decoding and generating motion velocity profiles without resorting to interrupt shenanigans.
The discovery of PropBasic was a bonus that effectively cut PASM code development time dramatically.
It's simply a matter of professional discipline, focus, and doing those vital things that you don't necessarily enjoy, as opposed to scratching the next itch.
-Phil
The "people" are the owners of Parallax. Isn't it their privilege to ask such questions? Or is it that we are not allowed to voice our opinions, once asked, unless they match yours?
This makes sense to me and may just get more media attention to help get more P2 traction.
What I don't know is how much a 2 cog P2 will really sell for. Chips estimate of $3 just seems too cheap. I do hope he is correct as that could be a real winner but I fear there is not enough meat in it for Parallax.
Might sell better than big one...
What will give the P2 the most traction is a finished set of docs and dev tools, not more versions. Good documentation is hard, tedious, and unpleasant to produce; and it takes a lot of time to do it right. That's why I think another diversion into spinning derivatives distracts from the real -- and more important -- work that still lies ahead.
-Phil
Something I've wanted for ages is a programmable drop-in replacement for a socketed 40-pin IC (CPU, VDP, ULA, etc.) which is why I like the idea of a P2 that could fit between pins 0.6" apart. Barring the 8-cog version in BGA, I prefer 4-cog/256KB/40-I/O as 32 I/O will not be enough for many such applications and only two cogs gives you no leeway, performance-wise. Could there be fewer boot pins in the smaller packages, namely two? This would leave 38 available, to match the IC pin count excluding power.
4-Cog, 256KB, 40-I/O and 2-Cog, 128KB, 32-I/O P2 ?
Don't you think Chip can continue to work on Spin2 while the P2 respin works its way through the ON Semi pipeline? And wouldn't a good 95% of all docs and all dev tools for the P2 pertain to all members of the P2 family?
As far as having a family vs a single product, IBM showed a million years ago that customers prefer exactly that. I don't pretend the understand the psychology of it, but we literally had handicapped versions of the same hardware just so customers could feel they had a choice.