Is P1 a safe investment ? (already solved and the answer is YES)
Maciek
Posts: 668
As a newcomer to the Propeller, I am throwing this provocative question out into the wild:
Is investing in the P1 based commercial system a viable option now, when the P2 is due to be officially introduced in a few weeks time ? Or should I rather consider a P2 from the very start ?
On the surface of it, the answer doesn't seem to be too difficult to figure it out but when you factor in the life cycle of such a system, that stretches for more than a decade (more like two decades) from now, the possible (un)availability of P1 chips in the future might strike back and hard.
But, the P1 is a mature product with, quite possibly, all bugs and limitations already known while the P2, on the other hand is a novelty and we are on an uncharted territory here in this respect.
And I am not talking the chips alone but the development and maintenance costs as well. This is serious. I'm not fooling around.
Is investing in the P1 based commercial system a viable option now, when the P2 is due to be officially introduced in a few weeks time ? Or should I rather consider a P2 from the very start ?
On the surface of it, the answer doesn't seem to be too difficult to figure it out but when you factor in the life cycle of such a system, that stretches for more than a decade (more like two decades) from now, the possible (un)availability of P1 chips in the future might strike back and hard.
But, the P1 is a mature product with, quite possibly, all bugs and limitations already known while the P2, on the other hand is a novelty and we are on an uncharted territory here in this respect.
And I am not talking the chips alone but the development and maintenance costs as well. This is serious. I'm not fooling around.
Comments
If you're a night owl, I hope you'll sit in on my presentation for Parallax tomorrow.
@Wuerfel_21 Good to know but as I'm not to be fooled by statements like this one I'd better start thinking of the more legally binding agreement with the Parallax when I'm ready. I'm not there yet but must plan accordingly.
@JonnyMac A firm yes. I like that. I will not be needing thousands of chips which is all the better
Furthermore, the P1 core was open sourced, and worst case should Parallax fold, the P1 core can live on indefinitely inside an FPGA (or an ASIC if you've got that volume).
But the P1, although very capable and speedy, is very much memory constrained. If your project needs lots of fast internal memory, you're at a dead end. If you need large amounts of slow memory, obviously use SD cards or serial SPI memory-- that's a no brainier.
Do you need the extra I/O pin count, features, memory, and raw speed of the P2? Well then you'd better start learning because it's a lot of ground to cover and by then it'll be officially released. The P2s potential has been barely unlocked.
And with the P2, Parallax tried their best to be hacker friendly by using the largest pin spacing IC package available, but there's a dearth of inexpensive carrier or demo boards and a real risk of not hitting critical mass in terms of user base.
Parallax still sells the BASIC STAMP. That is older than dirt.
The P1 has a rock solid base of user support, company support, OPEN SOURCED CODE AND EVEN THE CHIP INTERNALS WERE OPEN SOURCED.
Not many companies can say they open sourced their internal DIE design. That is unheard of, and revolutionary.
The p1 requires very little support hardware.
I would caution that you should attempt to protect it with TVS devices and fuses, as the PLL and some internal circuitry is sensitive to esd and 6v and up impulses.
But all chips need esd and impulse protections so the p1 isn't any different, and its even a bit tougher, it has protection diodes on its pins.
The only thing some developers don't like about the P1 is that it contains no direct way to encrypt the eeprom code. Reverse engineering the code wouldn't be super easy though. However the data in the eeprom can be easily copied and uploaded into another eeprom to make a "rogue clone" of your device. One does not need to reverse engineer the code to copy the eeprom and circuit.
If you want to make rapid progress (fast development time) with a micro-controller, choose the P1.
In comparison to the P2 I love the P1 for all its hardware simplicity, only one supply, and even only one cap if done right etc. I still yearn for the P1+ though, a P1 with more RAM at least, I/O and speed second, or a P1 in a QFN20 with 16 I/O
+1
All I ever wanted from a new Propeller was to fill in the empty slots in the instruction set (esp. multiply), add more counter modes, and add programmable loop filters in the PLLs to help reduce phase jitter. I never wanted 64 I/O. Just the same simple, elegant P1, fleshed out a little bit. We could've had that 10 or more years ago.
As far as the P1 being a safe investment, I cannot imagine a safer one. And if you want a great systems-integration-level module, the FLiP module wins hands-down, IMO.
-Phil
I've had it figured out myself and coming to think of it I should not even bother you with this post. And as Peter rightly observed I'm a no match for Parallax, legally speaking.
The answer to my question is very simple, when the actual system I have in mind and its purpose is factored in and that is to keep the reasonable stock of the chips.
Even at a few kpcs, and especially at that level, the cost of buying and keeping this stock for say, 20 years, is peanuts compared to the cost of the system and all the legal stuff that would've needed to be done to even enter whatever legal agreement necessary.
I already have a P1 DIP24 16xI/O solution
While Tachyon code is very compact I still keep the public part of the dictionary in RAM taking up memory since I found the EEPROM way to slow to search. However I do store the cog images in upper EEPROM as a named set of "ROMs" because normally if you had 7 cogs running non-Spin code, that could take up to 14k of RAM that could be left behind once the cog was loaded, and wasted. When I need a cog to become a serial port for instance, I just load it by name into a cog at runtime via a 2k buffer I keep for files. There are lots of different ROMs I have loaded into EEPROM as standard, such as various serial cogs, VGA, WAV, SIDCOG, F32 etc. But for most things I don't need to fire up a cog just to do SPI or WS2812 LEDs etc since Tachyon is very fast. Even bit-bashed serial in Tachyon can work up to a few hundred kilobaud easily.
What's interesting is that Spin uses bytecode as did the first versions of Tachyon (in a different fashion), and you would think that it is very compact. Yet I found that while it is great for smaller programs, however that as the code grows it becomes more awkward especially with addressing. Since I made the change to 16-bit wordcode in V4 that can specify a 15-bit address or a 15-bit literal in the instruction itself, as well as some encoded branching operations etc, that it is even more compact and faster.
In summary, P1 is a good investment and will handle a wide range of tasks, even with the limited memory, if it is done wisely. Unless there is a particular need for P2 memory, or speed, or I/O, then I would always use the simpler P1.
Now, that is quite a recommendation. I need nothing more. Thanks, Peter.
-Phil
We still make the BASIC Stamp 1 from 1992, and will continue to do so until there are no customers.
P1/P2 design is entirely owned by Parallax with no agreements or obligations externally which could threaten supply.
Ken Gracey
Parallax Inc.
The main risks around P1 are
* Parallax gets hit by a meteorite
* Their FAB gets hit by a meteorite
* Their FAB equipment breaks, and no one makes it anymore.
I think Ken has mentioned they have qualified 2 FABs so that helps reduce the risk.
Of course, the FPGA alternatives keep improving, and there are proven designs of P1 cores in FPGAs already.
eg I notice Lattice have new FPGAs in QFN72 which seem to have enough resource to run 'a better P1'
https://www.latticesemi.com/Products/FPGAandCPLD/CrossLink-NX
That has a 450MHz Oscillator, with /N and a 125kHz oscillator for sleep
32-Bit Counter Typ 303 MHz
32K x 32 True-Dual Port RAM using same clock, with EBR Output Registers typ 340 MHz
36 x 36 Multiplier with Input/Output Registers typ 190 MHz
Lattice, yes. Some nice, capable and not too expensive parts suitable for the task there plus open source tools for some of these. I;m not there yet. One thing at a time. And that thing is P1. For now.