To heck with the P2, I want the 64-IO P1
localroger
Posts: 3,452
So the P2 is going to be SMT only, very leaky and power hungry, and require external support?
These are not the props I'm looking for.
Give me the 64 I/O Prop I with its current process and power consumption and non-reliance on glue and support·chips, and I will be a very ecstatically happy camper.· Give me DIRB and INB and OUTB not as reserved but actually doing stuff with real pins.· Even make it SMT only; I know some guys who can solder that stuff (protoboard *cough* protoboard).
160 MHz is nice, but not that big a deal.· Tighter CPU timing to 2 cycles instead of 4 is even nicer, but not that big a deal.
MORE I/O IS THE BIG DEAL.· MORE I/O PLZ KTHX.
IO bank B instantly invalidates a bunch of really byzantine projects extant here to bring fast memory to the Prop without using up all its pins that are so useful for, well, all the other stuff we use the Prop for.· I would like 160 MHz but it doesn't set my pants on fire.· I would like better CPU timing on top of that but while that makes my pants smoke a bit, it doesn't set them on fire either.
MORE I/O PLZ KTHX.· With current energy usage verydoubleplusgood.· Will go back to soldering on ucontroller kit boards now.
These are not the props I'm looking for.
Give me the 64 I/O Prop I with its current process and power consumption and non-reliance on glue and support·chips, and I will be a very ecstatically happy camper.· Give me DIRB and INB and OUTB not as reserved but actually doing stuff with real pins.· Even make it SMT only; I know some guys who can solder that stuff (protoboard *cough* protoboard).
160 MHz is nice, but not that big a deal.· Tighter CPU timing to 2 cycles instead of 4 is even nicer, but not that big a deal.
MORE I/O IS THE BIG DEAL.· MORE I/O PLZ KTHX.
IO bank B instantly invalidates a bunch of really byzantine projects extant here to bring fast memory to the Prop without using up all its pins that are so useful for, well, all the other stuff we use the Prop for.· I would like 160 MHz but it doesn't set my pants on fire.· I would like better CPU timing on top of that but while that makes my pants smoke a bit, it doesn't set them on fire either.
MORE I/O PLZ KTHX.· With current energy usage verydoubleplusgood.· Will go back to soldering on ucontroller kit boards now.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
BTW, this chip will be smt. As long as it is 0.65mm pitch PQFP it will be fine. An alternative package could be 84 PLCC as t/hole sockets are available, but they are expensive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
However, with Parallax just having done a new run of Prop I chips, I suspect our timing is a few months too late :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I see the Propeller as best suited intelligent controllers and having 64 I/O would put it in a class totally by itself. No competition. Even the PropI is not second sourced so that leaves it out of the running as a mass market product but having the only chip with 64 discrete programmable I/O pins would certainly make complex controllers much easier to make.
My 2 cents.
Donald
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Actually, TQFP-80 would also work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
for just a few dimes more than the price of 5 Propellers sold in 2007.
And couldn't they also be "160 Mhz" if you clock them out of phase?
Couldn't one Cog make DIRB INB OUTB and other illusions of a "P16X64PIO" work with 2 chips ?
Post Edited (VIRAND) : 9/30/2009 5:58:50 AM GMT
Especially if the designer KNOWS it has to be right, and knows that the software messed up and miscounted somewhere along the line (flaky RAM, power glitch, multi-thread routines never tested on a multi-processor system like the development machine, project files stored on a network drive and subject to dropouts, etc.).
The main problem is that the tool could not resolve the difference when LVSing (Layout verses Schematic testing). There are several factors that can cause such a tool to break or become confused. Since I did not do the layout for this, I don't know, but the likely culprit is when you break hierarchical relationships between the layout and schematic and you don't necessarily have a 1:1 correlation any more. I saw some evidence of this when I reviewed the layout, but generally for the most part the tool does work hierarchical differences out.
There are other weird things that can cause a circular reference within the tool if you don't understand what the tool is expecting to see. This can be triggered by something as simple as improper wire labeling, or a single reversal in a wire name.
I.e. suppose that you have two nets, OUTn and OUTp, and that the labels are accidentally swapped but the electrical connection is correct. In this case the LVS tool will report an ERROR no matter if you leave it alone or swap the electrical connection. At the 'lowest' hierarchical layout blocks, these errors are relatively easy to spot, however if you break the 1:1 Schematic verses Layout correlation, this type of error can propagate into other errors making the actual cause of the problem obscure and very, very difficult to find.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Is there any chance of unrolling the work back to the point the trouble started, then moving forward from there? (Believe me, this is asked in total ignorance of the layout process or the tool used to do it. But, given how much such a tool must surely cost, one would think that there'd be a way out of the corner that "someone" painted themselves into.
Frankly, I'm sympathetic with the OP's position. There's a lot to be said for fleshing out the technology that's available — especially when the fleshing-out part is already designed into the architecture. It's all about leveraging and adding value to an already great product. There's still much to be discovered and exploited with the Prop I, and more I/O pins certainly wouldn't hurt that effort, especially as a way to add more memory.
-Phil
At this point it comes down to the available resources that we have at Parallax and how much more money we want to sink into it. There is plenty of momentum for the Propeller II that I am working on at the moment, and while I was able to help LVS various blocks within the Prop Ib 64 to find some problems, being able to help DRC (Design rule Check <- another set of rules we apply to the layout design) is a different story, because the two processes are different and have completely different sets of rules (350nm verses 180nm)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
sorry for my ignorance but what is the difference between the normal ROM and OTP ROM (in terms of IC design/layout, fab technology, required space on die). It would have been nice if the prop had been equipped just with 2k bootloader ROM and 30K OTP. Parallax can sell both versions (blank or preprogrammed like now) or the PropTool can have a standard rom image to program on the first time. This will give the user many opportunities:
saving a lot of hub ram for program code/data. Maybe is not to late to think about it on PropII (definitely this doesn't change the architecture)
Maybe slightly off topic:
Why is CMP (beside setting Z/C flags) with WR effect behaving like SUB? I would have preferred it acting as MOV: this will eg. increase preformances in search/sort loops. Have anyone a clever example using actual CMP with WR?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
Post Edited (dMajo) : 9/30/2009 10:03:56 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
There is a chip available with 88 I/Os which would compete with it. It is harder to use than a Propeller in some ways, though.
Second-sourcing is very rare these days, although it used to be popular.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 9/30/2009 12:00:41 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I just took a look at them again and at $7.50 per chip for 8 * 50Mhz threads with deterministic timing, 64K of RAM and 36 I/O pins they look like direct competition to the Prop and they are looking very tempting.
My conclusion is that Parallax is right to pass by the Prop Ib and concentrate on getting the Prop II out. As much as we all want those pins it's to late to be competitive.
Now those unmentionable chips only have 64K RAM accessible to a processor which must include code and data space. So my dream single chip Z80 emulation with 64K RAM for CP/M is still out of reach. Without some complicated RAM sharing through the communication links. Prop II is going to do this just fine [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I just had a look.
64kb of RAM, a MAC ..and here I am gluing a dsPIC to the prop to try and get fast DSP maths.. <sigh>
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
heater is absolutely correct. CMP and SUB are the same instruction with different default settings of WR / NR. They set the flags the same.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Nice, but the time frame for the P2 is currently unspecified.. Right now I need to run about 32 biquads and that's an awful lot of multiply.
I think I'll continue down my current path for now anyway, but probably only because I already have a significant investment in Propeller Development tools.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
A lot of eproms used to have two dies side-by-side with the little wires connecting them up. Couldn't an internal bolt on of the extra port drivers be sorted out ?
Even if they were unidirrectional, with no counters.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
None of the circuitry needed for the 2nd 32 bit I/O port exists on the current Prop 1. In particular, the "wires" on the chip are way too small to attach anything to. The little wires you're talking about are huge by comparison. They need a large area set aside with a specially prepared surface for the leads to be welded to. You can't just run the signals off-chip, even to another chip. The signal levels are too small. You would need to beef up the transistors driving the signal since they would have to charge up a relatively large capacitance.
--Rich
* That was where I started, I've gone further from there. [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/build
Post Edited (Dr_Acula) : 10/1/2009 2:21:47 AM GMT