Sorry to disagree, but placing BGAs by hotplate is prone to failure.
Placing BGAs uses very expensive equipment that requires accurate temperature profiles and pressures. And even then Xray inspection is done after it is placed. There are also a lot of tuning depending on what is surrounding the BGA. However the process does scale well when things are dialed in.
But placing by hand and hot plate, yields would be basically 0. I do know of people being able to mod edge balls with microscopes, very fine wire and a hand steadier than most brain surgeons.
So if a BGA is aimed at a hobbyist audience, a breakout board would be necessary, it could use a finer pin pitch than 0.1"
option 3: 2K or 4K cog memory, a brute force bulk memory move from hub to cog, and opcodes·that·can·auto increment and auto decrement (byte, word, long versions). Yeah! Stacks· that really work!
I think a single-cycle RD* or WR* that posts the operation but doesn't wait for it to complete would already help a lot
with putting variables into hub memory. (We'd still need a variant that does wait, or else it would be hard to synchronize
with the hub.) Then add auto-increment with sizes 1, 2, and 4, and we'd have a pretty efficient solution for all the usual
pointer operations.
But let's wait and see what Parallax are cooking up for us
Hi, I'm not experienced with props, but I had to pass the prop over for a different chip because of lack of memory, so I'd say (much) more ram would be good, especially when the C compiler is released, because i assume that C will use more code space that the interpreted spin language. And 8x 160 MIPS WOW!
EDIT: BTW Fred Hawkins Idea sounds GREAT, more memory to the cog to allow each one to function more independently, again, this would be a boon for C. But is it feasable? (I hope that's how you spell it.)
(1) The architecture is squeezing out a lot of bit fields at the moment - thus I doubt the Propeller II can be bit compatible, but I should appreciate that very much
(2) I should like a 16x16-multiplication, to bridge the gap to low cost DSPs.
(3) Video is a mess at the moment - to put it kindly.... I should like at least a 256 colour VGA model, thus dedicated video memory of at least 32 kB. This could also be an escape from some addressing issues as expected cf. (1)
(4) To reduce the chip count for a "minimal configuration", integration of USB and 64 KB Flash memory would be really nice
(5) The pricing should be more competitive; a minimal configuration e.g. SpinStamp + USB is at the moment the same as an ARM9 Chips including Ehternet support...
(6) Memory bandwidth is probably an issue, as COG as well es HUB static RAM is accesssed every 12,5 ns. Adding more COGs (which would be fine anyway) and higher speed thus would not improve throughput between HUB and COG. Static (!) HUB Memory is expensive as it is used 8-fold in the worst case. However I can imagine that the effective bandwidth use is MUCH less.... I don't know exactly what to make out of these last considerations... May be changed COG-access strategy?
Do look at the earlier portion of this thread ... it's full of good information on the Prop II ... as much as been made public already.
1) As far as I can tell (as an observer ... not a Parallax employee) the Prop II is supposed to be upwardly compatible.
2) There is to be a 16 x 16 multiply instruction
3)·You're not going to see any kind of dedicated memory like a video buffer.· There will be more RAM.· Whether it's a total of 64K or 128K, I'm not sure.· If your application requires it, you can devote more RAM to video as opposed to some other use.· I don't know whether there will be an expansion of the video generator.· With the use of multiple cogs, you can already handle more colors than a single video generator is designed for.· The problem has always been that of memory for the screen buffer.· The Hydra Xtreme Memory card already provides for an external SRAM that can be used for video output, but the Hydra uses the same pins for VGA output as the expansion bus.· It would be possible to use the same or a similar external RAM with the Protoboard as a VGA screen buffer.· The drivers would still have to be written.
4) The process used to make the Propeller chip is incompatible with flash memory.· You also won't see any internal USB interface.· It's too easy and too cheap to incorporate someone else's USB to serial converter.· There may also be a process issue due to the voltages that have to be handled (like +5V).
5) Parallax·has been·aggressive with pricing for large enough quantities for things like the SX series.· I'm sure they could do the same for the Propeller, again in large quantities.· For small quantities, the cost of support overwhelms anything else.
6) Again, look at the previous discussions of various hub/cog access options.
Thanks for your kind answers, Mike! As this thread is "old", I think all decisions have already been made by Parallax I just wanted to address some obstacles I noticed during the short time I am examining some Propellers...
The "hybrid" technology used with the stamps is a very appropriate approach to the fast prototyping need of minimum chip count.
Since you mention the use of hybrid substrates, do have a look at the USB Propstick and the Spin Stamp. The former includes a USB to serial converter while the latter does have a 64K EEPROM. Both provide a 3.3V regulator, crystal clock, and even a reset pushbutton. With the Propeller 2, any hybrid substrate version would have to have limited access to I/O because of the impracticality of the number of pins needed for access. Much like the Spin Stamp, there will likely be a 32 pin hybrid substrate version, but the "workhorse" version will probably be something like the Protoboard.
That's an interesting point Mike, it seems using propeller 2 will be much more like the situation currently faced if you want to use the bigger FPGAs, until you go to production you will probably stick to the Protoboard type solutions, I can only hope Parallax can do good things on the price as they have with the current protoboards which are fantastic.
something similar to the attached photo might be appropriate as a carrier board for the Prop 2. It would scale to 72 pins with out getting TOO large, and most components could be placed under the module on the board it plugs into. Stacking headers like in the second photo would also be cool.
I was thinking about backwards compatibility, and looking at some of the previous routines, if the prop2 had >64k that would break backward compatibility on graphics.spin as when it gets a new command it doesn't clear the top word in par
since par has cmd << 16 + argptr this would cause it to read from memory at >64K.
Just my 2p's worth. not that ALL prop apps use graphics.spin, but since quite a few do. keep a lookout for things like that when changing your code to work with the new chip. ( although I'm sure Parallax will have newer graphics.spin this is for other's modifications on drivers. )
PS, can't wait to have a play, but I guess it's still over a year away? [noparse]:([/noparse]
Baggers said...
I was thinking about backwards compatibility, and looking at some of the previous routines, if the prop2 had >64k that would break backward compatibility on graphics.spin as when it gets a new command it doesn't clear the top word in par
since par has cmd << 16 + argptr this would cause it to read from memory at >64K.
Just my 2p's worth. not that ALL prop apps use graphics.spin, but since quite a few do. keep a lookout for things like that when changing your code to work with the new chip. ( although I'm sure Parallax will have newer graphics.spin this is for other's modifications on drivers. )
PS, can't wait to have a play, but I guess it's still over a year away? [noparse]:([/noparse]
Well... It's too early to say what's going to be different (and whose code will break), but I'm quite sure that Ain't the first one to hit. Some examples given in Asm level, I don't know how Spin interpreter handles these.
a) Considering that some asm instructions (IIRC Waitpeq Waitpne) will in future to use Carry flag to select which 32-bit IO they wait (pins 0-31 or 32-63). Current version of chip apparently Ignores C flag at this point, so all code that does IO.waiting need to be checked
b) More Cog:s will lead to different (extended) structure on HUBOP ... Thus affecting Cognew, Cogstop etc.. (not likely real issue)
c) More Cogs (and pipelining) will affect the timing of Hubops
d) Pipelining differences most likely change way indirect-incemented addressing will be done.
Most important of these (now) is the a), cause it will hit quite soon with 64-IO version of current propeller. All other are going to be upon Net major version (p2) and thus not so critical now.
JoannaK,
I was refering to P2 and it's backward compatibility functionality, not 64-IO version of current prop,
also, there isn't going to be more cogs, if I've read this thread correctly, last I read was it being still 8 cogs, but more memory, ( since the faster speed would remove some need for duplicating tasks on multiple cogs, eg tv & vga display renderers. )
Baggers said...
also, there isn't going to be more cogs, if I've read this thread correctly, last I read was it being still 8 cogs, but more memory, ( since the faster speed would remove some need for duplicating tasks on multiple cogs, eg tv & vga display renderers. )
You have misread the thread, check my post on page 17, Posted 5/24/2007 11:12 AM (GMT -7)
Will their eventually be a built-in video buffer on a future propellor? It would really be nice if when the propellor 3 comes out that it had a 10 bit color video buffer built in the chip or so.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Realize that I am really a mad scientist··· and
This information has been accumulating for some time and may be USEFUL to others. I found it difficult to follow all the gyrations of what the 2nd generation Propeller might be.
Propeller, gen.2 info - rev: 28 Jun.2007
Feature Quantity comments Forum pg/date/time
--------------+-------------------+-----------------------------------+------------------
Cogs 16 ? 160 MHz, pipelined instr. /clock pg1/25Nov06/12:32a
(2 clocks for Hub instr. pg1/25Jun06/12:52a
512 longs/cog pg7/30Nov06/12:39p
pg17/24May07/11:12a
pg19/28Jun07/9:26a
--------------+-------------------+-----------------------------------+------------------
RAM on-chip 128KB ? pg17/24May07/11:12a
--------------+-------------------+-----------------------------------+------------------
I/Os 64 ? pg17/24May07/12:50p
--------------+-------------------+-----------------------------------+------------------
Clock input min - max freq ?
--------------+-------------------+-----------------------------------+------------------
PLL speed 160 MHz max ?
--------------+-------------------+-----------------------------------+------------------
Packaging QFP preferred pg19/19Jun07/6:03p
QFN ?
LQFP ?
BGA ?
thru-hole DIP NO ?
--------------+-------------------+-----------------------------------+------------------
Other pins 3.3v (I/O) 4 ? 64 I/Os plus these pg2/25Nov06/11:26a
1.8v (I/O) 4 ? totals 80 pins
Gnd 4 ?
Rst/ 1
BOE/ 1 ?
Clock 2
--------------+-------------------+-----------------------------------+------------------
16x16 multiply 1 ? pg19/23Jun07/3:59p
--------------+-------------------+-----------------------------------+------------------
Availability probably a year away p3/25Nov06/1:10p
2 yrs, conservative pg5/7Mar07/12:00p
between 1 - 2 years pg15/7Mar07/12:08p
--------------+-------------------+-----------------------------------+------------------
Longevity most likely for pg8/5Dec06/6:01a
next 15-20 years
--------------+-------------------+-----------------------------------+------------------
'code name' P-Chip 2 p15/7Mar07/12:08p
--------------+-------------------+-----------------------------------+------------------
legend: '?' = not yet defined by Parallax
Beau Schwabe - IC layout engineer, Parallax pg15/7Mar07/9:53p
For some reason, my nicely monospaced table lost its formatting bringing it into this editor! This has NOT been verified as lacking errors. Parallax, if there are untruths, please inform.
(EDIT) Oh, s**t. Now I see the result is even worse than it appeared while creating/previewing. Hope it is of use.
Baggers: Yep.. you talked about P2 .. but it does not make my point about 64-IO wait issues any less valid. I just tried to point out that since IIRC there will be 64 IO version of this current 80MHz and 8_cog core before they make P2 it'll be among use a lot sooner than ram size related issues (that are P2 as far as I had understood...)
Harley : Thanks for the update. this thread is huge as would be expected from it's topic [noparse]:)[/noparse]
JoannaK : yeah, true [noparse]:)[/noparse] that's a very valid point. but personally I'll most likely wait and get the prop2 before getting a propB [noparse]:)[/noparse] ·
Lawson said...
something similar to the attached photo might be appropriate as a carrier board for the Prop 2. It would scale to 72 pins with out getting TOO large, and most components could be placed under the module on the board it plugs into. Stacking headers like in the second photo would also be cool.
my Log(100) cents,
Marty
STACKING HEADERS - YES PLEASE!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Jamesx, JoanaK, Baggers, and really all who 'dwell' on this topic:
At over 470 replies and 22800 views, it is a very long 'read'.
And there has been a bit of 'thrashing' talk beyond what features Parallax can/will include in generation 2 Propeller.
So my messy, paper and pen list on the new Prop finally had to be keyed in to be usable. I was surprised how poorly my file formatted after copying it into the forum editor. I used the Code option, but it was almost impossible to correct the mis-formatting that occured. Apologies; couldn't find any solution to prevent the lines from breaking.
But if this helps anyone beyond myself, it was worth it.
Your table (however formatted) is a HUGE help I've not been visiting this thread for ages; the thought of having to read it all kept me away.
Thanks Harley.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-) BTW: I type as I'm thinking, so please don't take any offense at my writing style
Just an idea:
more cogs means longer hub cycles. There could be an inter-cog protocol by using buried I/O. Outb could start communication between cogs, which are i.e. waiting for set/reset of bit patterns at the I/O-pins
Don't know about you all - but I think I am going to burst waiting for 'TurboProp' ! - or at least more details.
It'd be nice to know prelim package details,specs(no matter how vague at the moment) and possible considerations etc.
At this stage it must be fair to say that it must have moved on from concept to prototyping ? What kind of issues are being encountered ? Point of failure, robustness, unexpected results albeit good or bad, possible limitations of production equipment found, any key features included as a result of experience gained from launch of prop 1 ?
Obviously, the Propeller was a milestone not just in terms of the time and resources spent to design,develop,test and launch -then after launch hoping for positive feedback - was the atmosphere tense after initial launch ?- or was everybody certain that it would be received as well as it was ? - From that - What are the 'gut' feelings for 'TurboProp'.
On a side note:
Has the speed of proliferation of the prop exceeded that of the Basic Stamp and others after launch ? -That is to say 'has it exceeded your own expectations' ?
Sorry for all the Q's ....
Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 'Necessity is the mother of invention'
If the boys at Parallax could blow our minds with the Gen1, i think they have something that'll blow our minds again, i mean look at the prop, it's beautiful, resiliant, fast, versital, cake to program in either level. It's damn near perfection after we all ran it throught the mill, and I think bettering something that is already awesome and easy to use would be an acomplishment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"
QuattroRS4 said...
Don't know about you all - but I think I am going to burst waiting for 'TurboProp' ! - or at least more details.
It'd be nice to know prelim package details,specs(no matter how vague at the moment) and possible considerations etc.
At this stage it must be fair to say that it must have moved on from concept to prototyping ? What kind of issues are being encountered ? Point of failure, robustness, unexpected results albeit good or bad, possible limitations of production equipment found, any key features included as a result of experience gained from launch of prop 1 ?
We are doing the mask layout now. We hope to run a test chip within several months. Roughly, here is what we are making: 16 cogs (single-clock instructions), 256KB RAM, 128KB ROM, with 8-contiguous-long accesses per hub read/write. We've got to get this version done, then later we can add analog functions to I/O pins.
Obviously, the Propeller was a milestone not just in terms of the time and resources spent to design,develop,test and launch -then after launch hoping for positive feedback - was the atmosphere tense after initial launch ?- or was everybody certain that it would be received as well as it was ? - From that - What are the 'gut' feelings for 'TurboProp'.
On a side note:
Has the speed of proliferation of the prop exceeded that of the Basic Stamp and others after launch ? -That is to say 'has it exceeded your own expectations' ?
I'm pretty sure we're ahead of the BASIC Stamp curve, but things are still nascent in terms of potential. We have learned from three past experiences (selling PIC tools from 1990, selling BASIC Stamps from 1993, and·selling SX·tools from 1997) that it takes five whole years to get traction for a new product line. We are just over a year into this process with the Propeller now. We don't have any appreciable volume yet, though people are starting to make those inquiries. Our main metric of success, at this point,·is seeing customers·embrace it enthusiastically. This is the most satisfying phase of things, anyway.
Sorry for all the Q's ....
Comments
I also wonder about some sort of hot air hood that could be placed over the part, the main issue is probably aligning the component.
Graham
Placing BGAs uses very expensive equipment that requires accurate temperature profiles and pressures. And even then Xray inspection is done after it is placed. There are also a lot of tuning depending on what is surrounding the BGA. However the process does scale well when things are dialed in.
But placing by hand and hot plate, yields would be basically 0. I do know of people being able to mod edge balls with microscopes, very fine wire and a hand steadier than most brain surgeons.
So if a BGA is aimed at a hobbyist audience, a breakout board would be necessary, it could use a finer pin pitch than 0.1"
with putting variables into hub memory. (We'd still need a variant that does wait, or else it would be hard to synchronize
with the hub.) Then add auto-increment with sizes 1, 2, and 4, and we'd have a pretty efficient solution for all the usual
pointer operations.
But let's wait and see what Parallax are cooking up for us
- Werner
EDIT: BTW Fred Hawkins Idea sounds GREAT, more memory to the cog to allow each one to function more independently, again, this would be a boon for C. But is it feasable? (I hope that's how you spell it.)
Post Edited (PointDog) : 6/23/2007 2:42:03 PM GMT
Graham
(1) The architecture is squeezing out a lot of bit fields at the moment - thus I doubt the Propeller II can be bit compatible, but I should appreciate that very much
(2) I should like a 16x16-multiplication, to bridge the gap to low cost DSPs.
(3) Video is a mess at the moment - to put it kindly.... I should like at least a 256 colour VGA model, thus dedicated video memory of at least 32 kB. This could also be an escape from some addressing issues as expected cf. (1)
(4) To reduce the chip count for a "minimal configuration", integration of USB and 64 KB Flash memory would be really nice
(5) The pricing should be more competitive; a minimal configuration e.g. SpinStamp + USB is at the moment the same as an ARM9 Chips including Ehternet support...
(6) Memory bandwidth is probably an issue, as COG as well es HUB static RAM is accesssed every 12,5 ns. Adding more COGs (which would be fine anyway) and higher speed thus would not improve throughput between HUB and COG. Static (!) HUB Memory is expensive as it is used 8-fold in the worst case. However I can imagine that the effective bandwidth use is MUCH less.... I don't know exactly what to make out of these last considerations... May be changed COG-access strategy?
1) As far as I can tell (as an observer ... not a Parallax employee) the Prop II is supposed to be upwardly compatible.
2) There is to be a 16 x 16 multiply instruction
3)·You're not going to see any kind of dedicated memory like a video buffer.· There will be more RAM.· Whether it's a total of 64K or 128K, I'm not sure.· If your application requires it, you can devote more RAM to video as opposed to some other use.· I don't know whether there will be an expansion of the video generator.· With the use of multiple cogs, you can already handle more colors than a single video generator is designed for.· The problem has always been that of memory for the screen buffer.· The Hydra Xtreme Memory card already provides for an external SRAM that can be used for video output, but the Hydra uses the same pins for VGA output as the expansion bus.· It would be possible to use the same or a similar external RAM with the Protoboard as a VGA screen buffer.· The drivers would still have to be written.
4) The process used to make the Propeller chip is incompatible with flash memory.· You also won't see any internal USB interface.· It's too easy and too cheap to incorporate someone else's USB to serial converter.· There may also be a process issue due to the voltages that have to be handled (like +5V).
5) Parallax·has been·aggressive with pricing for large enough quantities for things like the SX series.· I'm sure they could do the same for the Propeller, again in large quantities.· For small quantities, the cost of support overwhelms anything else.
6) Again, look at the previous discussions of various hub/cog access options.
·
The "hybrid" technology used with the stamps is a very appropriate approach to the fast prototyping need of minimum chip count.
Graham
I should like to add, that the times of expensive prototype boards and development tools are gone forever! (Most likely thanks to ATMEL
www.hitex.com/str9-comstick/ (50$)
www.embedded-developer.com/tools/545/Atmel/ATNGW100.htm (90 $)
my Log(100) cents,
Marty
loop rdlong t1,par wz 'wait for command
if_z jmp #loop movd :arg,#arg0 'get 8 arguments
mov t2,t1
mov t3,#8
:arg rdlong arg0,t2
add :arg,d0
add t2,#4
djnz t3,#:arg
since par has cmd << 16 + argptr this would cause it to read from memory at >64K.
Just my 2p's worth. not that ALL prop apps use graphics.spin, but since quite a few do. keep a lookout for things like that when changing your code to work with the new chip. ( although I'm sure Parallax will have newer graphics.spin this is for other's modifications on drivers. )
PS, can't wait to have a play, but I guess it's still over a year away? [noparse]:([/noparse]
Well... It's too early to say what's going to be different (and whose code will break), but I'm quite sure that Ain't the first one to hit. Some examples given in Asm level, I don't know how Spin interpreter handles these.
a) Considering that some asm instructions (IIRC Waitpeq Waitpne) will in future to use Carry flag to select which 32-bit IO they wait (pins 0-31 or 32-63). Current version of chip apparently Ignores C flag at this point, so all code that does IO.waiting need to be checked
b) More Cog:s will lead to different (extended) structure on HUBOP ... Thus affecting Cognew, Cogstop etc.. (not likely real issue)
c) More Cogs (and pipelining) will affect the timing of Hubops
d) Pipelining differences most likely change way indirect-incemented addressing will be done.
Most important of these (now) is the a), cause it will hit quite soon with 64-IO version of current propeller. All other are going to be upon Net major version (p2) and thus not so critical now.
I was refering to P2 and it's backward compatibility functionality, not 64-IO version of current prop,
also, there isn't going to be more cogs, if I've read this thread correctly, last I read was it being still 8 cogs, but more memory, ( since the faster speed would remove some need for duplicating tasks on multiple cogs, eg tv & vga display renderers. )
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·
Propeller, gen.2 info - rev: 28 Jun.2007 Feature Quantity comments Forum pg/date/time --------------+-------------------+-----------------------------------+------------------ Cogs 16 ? 160 MHz, pipelined instr. /clock pg1/25Nov06/12:32a (2 clocks for Hub instr. pg1/25Jun06/12:52a 512 longs/cog pg7/30Nov06/12:39p pg17/24May07/11:12a pg19/28Jun07/9:26a --------------+-------------------+-----------------------------------+------------------ RAM on-chip 128KB ? pg17/24May07/11:12a --------------+-------------------+-----------------------------------+------------------ I/Os 64 ? pg17/24May07/12:50p --------------+-------------------+-----------------------------------+------------------ Clock input min - max freq ? --------------+-------------------+-----------------------------------+------------------ PLL speed 160 MHz max ? --------------+-------------------+-----------------------------------+------------------ Packaging QFP preferred pg19/19Jun07/6:03p QFN ? LQFP ? BGA ? thru-hole DIP NO ? --------------+-------------------+-----------------------------------+------------------ Other pins 3.3v (I/O) 4 ? 64 I/Os plus these pg2/25Nov06/11:26a 1.8v (I/O) 4 ? totals 80 pins Gnd 4 ? Rst/ 1 BOE/ 1 ? Clock 2 --------------+-------------------+-----------------------------------+------------------ 16x16 multiply 1 ? pg19/23Jun07/3:59p --------------+-------------------+-----------------------------------+------------------ Availability probably a year away p3/25Nov06/1:10p 2 yrs, conservative pg5/7Mar07/12:00p between 1 - 2 years pg15/7Mar07/12:08p --------------+-------------------+-----------------------------------+------------------ Longevity most likely for pg8/5Dec06/6:01a next 15-20 years --------------+-------------------+-----------------------------------+------------------ 'code name' P-Chip 2 p15/7Mar07/12:08p --------------+-------------------+-----------------------------------+------------------ legend: '?' = not yet defined by Parallax Beau Schwabe - IC layout engineer, Parallax pg15/7Mar07/9:53pFor some reason, my nicely monospaced table lost its formatting bringing it into this editor! This has NOT been verified as lacking errors. Parallax, if there are untruths, please inform.
(EDIT) Oh, s**t. Now I see the result is even worse than it appeared while creating/previewing. Hope it is of use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Post Edited (Harley) : 6/29/2007 5:03:17 PM GMT
Thanks for the review. I had stopped following the thread, for just the mere size of it. Your synopsis helps catch up quickly.
Jim C
Baggers: Yep.. you talked about P2 .. but it does not make my point about 64-IO wait issues any less valid. I just tried to point out that since IIRC there will be 64 IO version of this current 80MHz and 8_cog core before they make P2 it'll be among use a lot sooner than ram size related issues (that are P2 as far as I had understood...)
JoannaK : yeah, true [noparse]:)[/noparse] that's a very valid point. but personally I'll most likely wait and get the prop2 before getting a propB [noparse]:)[/noparse]
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
At over 470 replies and 22800 views, it is a very long 'read'.
And there has been a bit of 'thrashing' talk beyond what features Parallax can/will include in generation 2 Propeller.
So my messy, paper and pen list on the new Prop finally had to be keyed in to be usable. I was surprised how poorly my file formatted after copying it into the forum editor. I used the Code option, but it was almost impossible to correct the mis-formatting that occured. Apologies; couldn't find any solution to prevent the lines from breaking.
But if this helps anyone beyond myself, it was worth it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Thanks Harley.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
more cogs means longer hub cycles. There could be an inter-cog protocol by using buried I/O. Outb could start communication between cogs, which are i.e. waiting for set/reset of bit patterns at the I/O-pins
It'd be nice to know prelim package details,specs(no matter how vague at the moment) and possible considerations etc.
At this stage it must be fair to say that it must have moved on from concept to prototyping ? What kind of issues are being encountered ? Point of failure, robustness, unexpected results albeit good or bad, possible limitations of production equipment found, any key features included as a result of experience gained from launch of prop 1 ?
Obviously, the Propeller was a milestone not just in terms of the time and resources spent to design,develop,test and launch -then after launch hoping for positive feedback - was the atmosphere tense after initial launch ?- or was everybody certain that it would be received as well as it was ? - From that - What are the 'gut' feelings for 'TurboProp'.
On a side note:
Has the speed of proliferation of the prop exceeded that of the Basic Stamp and others after launch ? -That is to say 'has it exceeded your own expectations' ?
Sorry for all the Q's ....
Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Definetly a E3 (Electronics Engineer Extrodinare!)
"I laugh in the face of imposible,... not because i know it all, ... but because I don't know well enough!"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.