I might point out that the "padding" we have added pushing the 1 year to 2 years is directly proportional to the careful considerations we have been observing from the feedback received in this very forum.
That said, you will just have to wait and see what goodies we have decided to incorporate into the next Propeller chip from each of your suggestions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
change the cog disable to either 1. disable but keep timing deterministic, or 2. disable and adjust all other cog speeds (e.g the fewer cogs running the faster it goes) - thats not really needed if theres some method of shifting data in and out of the ports under dma/instruction control, faster than what the native instruction set can do, e.g hardware port read/write, or at least a barrel shifter to write or read to / from the ports. I can guestimate the video generator is doing this partly at least for output?
Also more documentation for the video registers to see the structure or design is AN002 in the works?
This way DMA "like" reading and writing to ports may be possible, even if dependent on the waitvid instruction, or new instruction if one is crafted to load the shifter...
Will the new Prop have 40 pins as well, IE. we can design a 40 pin IC socket into our products and get a "free" upgrade when the new one comes out by popping the new chip in?
There were packages with 'double rows' of pins. One 'normal' set at the usual .1" spacing, and another set placed between those pins, and reaching further out.
Not that I've seen any of them for many years now...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
There's no way to make a 'DIP with pins on both the top and bottom' without major retooling at the factory.
And no, there's no way that a 'TurboProp' in that format will sell in large enough quantities to make it economically feasible.
In fact, I'm not certain that it's practically feasible, even.
Ball-grid is the best we can hope for, I think.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
There will very likely be a Quad Flat Pack, whether the industry version will be Quad Flat No-lead or Ball Grid Array hasn't been determined, Pin Grid Array is an option but is quite expensive. We will be releasing some sort of product that the average hobbist can use in thier projects that doesn't involve·soldering SMT.
Releasing a hobbled DIP version is tricky business because we would have to charge the same amount as the non-hobbled version. This is because it's the same silicon die and DIP packaging is actually more expensive pin for pin when compared to surface mount packages and a 40 pin dip package will run·about the same cost as the full package SMT.
as long as we can get an affordable protoboard so we can all build our own Proptop portable computers for programming all the Propeller based equipment we will have by then, maybe even a "Propeller powered PCB producer"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.
Paul Baker (Parallax) said...
No, because the new process will have a 1.8V core and 3.3V I/O, so it isn't possible to create a backwards compatible pinout.
Though this wouldn't stop anyone from making a Prop2 dip-40 MODULE. Put the smallest Prop2 package on a dip-40 sized pcb with a tiny 1.8v switching power supply and now a drop in replacement is quite reasonable. (this module could also include the program storage if the Prop2 wouldn't work with a 32k I2C EEPROM)
Marty
P.S. I'd also love to see a "Prop-PSU" for the Prop2. A really small switching power supply with 5v 3.3v and 1.8v output would be convient for battery operated applications. Alternatively separate 5v and 3.3v plus 1.8v switchers would be more versatile. www.firmtronics.com makes a dang small switching power supply (the sBEC) that i'm using right now for 5v on a combat robot.
i feel important a dedicated & indipendent·i2c hardware port
for bios eprom and other 126 user devices
(also on pdip version, maybe in place of one ground and one vdd pin)
about cogs i think that·eight is enough... like the sit-com !!
just more powerfull and more ram
Don't forget IP protection this time please [noparse]:)[/noparse]
A unique (or fuse programmable) serial in the Prop2 and a no-readback fuse should do it... the Prop2 could encrypt the code into the EEPROM so that it would not make sense if it was read back other than by the same chip [noparse]:)[/noparse]
Dedicated I2C hardware - No thanks. Then it's straight back to trying to get the board nicely laid out. I think it's fantastic that any pin can be basically any function. I guess the desire for dedicated I2C/SPI/UART hardware is really the desire for more cogs.
I'd like more memory, and more I/O. I'm already thinking of hooking two propellers together, with the second being essentially an I/O expander. Except that because the I/O expander is doing serial ports and PWM measurement the extra ports are not able to be "dumb".
Having 32(64) pins of general IO at this speed buys a
lot of options. It might take a cog to do the I2C, but
its' I2C with options. Think of a cog as a single Thread
that needs no Semaphores because of the hub.
64 Analog/Digital I/O pins would make a lot of sense,
we live in an analog world. Of course then its a math
issue.
Hello,
Why is there a spin interpreter into the Propeller ?
I hope that in the Propeller II, the spin language will be compiled. In this way, the Propeller will not waste any more its time to remake the work already made by the compiler. I does not understand yet why Parallax with implemented such an architecture in Propeller I ?
Thank you in Parallax (or/and Mike Green) to explain me that.
dro,
Hub memory is not cog memory, if there was no interpreter then we would be limited to 512 words per cog and yes it would be possible to compile if you had a compiler but what can you do in 512 words? Well, you could have an interpreter sitting in those 512 words and execute tokens from hub memory which is fine for many of the higher level functions and you still have all those other cogs doing what they do for the real-time functions too. This is the reasoning behind the Spin interpreter and it does an admirable job of it too.
Also, it is not practical to give each cog more than 512 words of memory because the cog instruction only uses 9-bit source and destination addresses for local cog memory, that's all it can handle. It's not a limitation it's actually a powerful feature for this design.
I have much admiration for the splendid work completed by engineers of Parallax.
I understands the problems of memory well.
Now about the interpreter:
What is the job of an interpreter ? I know only one answer to this question: The interpret translated a program written into high level language (like the language SPIN) towards the native language of the processor. Can you assure me that the native propeller's language is well the assembler ?
In all the programmings environments which I used a compiled program was all time more compact and more fast than the interpreted or tokenized equivalent !
Then why not load directly assembler into hub and cog memory ? (what an interpreter can do, a compiler must can do too)
A long time ago, I wrote programs out of Z80 assembler and 8086 but, the high levels languages save so much time that I do not want to learn any more from assembler. Especially when that a compiled language ( like C ) offers acceptable performances compared to the assembler.
Is that why i am very disappointed to note that the SPIN language is about 20 time slower than the assembler.
An interpreter is not a compiler. A compiler is a program that translates some language like Spin into instructions for a particular machine like the Propeller's native instructions. An interpreter is a program that executes instructions for a particular machine, usually an "artificial" or "virtual" machine that may not exist in hardware. The Java interpreter is an example of this. Java is usually interpreted by a program, but there have been some Java machines implemented in hardware. Just to complicate things, some interpreters use a "Just-in-time compiler" technology where they actually compile short sequences of native instructions into a buffer for the current interpretive opcodes being executed, then call these sequences to do the actual work.
The process of executing Spin programs consists of two parts: 1) The Propeller Tool running on a PC compiles the Spin program into instructions for a stack-based machine and these get downloaded to a Propeller. 2) An interpreter program runs in a cog processor's memory and "executes" the compiled interpretive code.
The 20 times difference in speed is due to the number of native instructions it takes to perform basic operations like addition, setting a register, etc. On the other hand, the Spin interpreter has built-in many operations that are not native to the hardware like multiplication, division, array subscripting, a stack-based call mechanism, etc. and the interpretive code is much more compact than the native instruction set. The interpreter makes the Propeller's 32K main memory look like the main memory of the processor rather than an I/O device with limited access which it essentially is.
At the heart of this is the observation that, in all programs, a very small portion (usually less than 10%) of the program accounts for perhaps 90% of the execution time. For greatest efficiency, this 10% needs to be carefully optimized in the native instruction set. In a processor with limited memory like the Propeller, the other 90% should be optimized for storage space since execution speed doesn't really matter. Spin was designed with this in mind so that the crucial 10% could be hand written and optimized in assembly language and combined with a very compact interpretive code for the other 90% that executes at a reasonable speed.
Comments
That said, you will just have to wait and see what goodies we have decided to incorporate into the next Propeller chip from each of your suggestions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
James L
dro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
Also more documentation for the video registers to see the structure or design is AN002 in the works?
This way DMA "like" reading and writing to ports may be possible, even if dependent on the waitvid instruction, or new instruction if one is crafted to load the shifter...
-Mike.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I stand on the shoulders of giants
Which leads one to guess it might be in a 84 lead SMD. Probably no DIP version, guys.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
h.a.s. designn
Doug
Not that I've seen any of them for many years now...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
There's no way to make a 'DIP with pins on both the top and bottom' without major retooling at the factory.
And no, there's no way that a 'TurboProp' in that format will sell in large enough quantities to make it economically feasible.
In fact, I'm not certain that it's practically feasible, even.
Ball-grid is the best we can hope for, I think.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
Releasing a hobbled DIP version is tricky business because we would have to charge the same amount as the non-hobbled version. This is because it's the same silicon die and DIP packaging is actually more expensive pin for pin when compared to surface mount packages and a 40 pin dip package will run·about the same cost as the full package SMT.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 3/9/2007 10:42:46 PM GMT
Has it been desided what V2 will look like ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*.*
Ibsen
" It's nice to be important, but
·· more important to be nice... "
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.
Though this wouldn't stop anyone from making a Prop2 dip-40 MODULE. Put the smallest Prop2 package on a dip-40 sized pcb with a tiny 1.8v switching power supply and now a drop in replacement is quite reasonable. (this module could also include the program storage if the Prop2 wouldn't work with a 32k I2C EEPROM)
Marty
P.S. I'd also love to see a "Prop-PSU" for the Prop2. A really small switching power supply with 5v 3.3v and 1.8v output would be convient for battery operated applications. Alternatively separate 5v and 3.3v plus 1.8v switchers would be more versatile. www.firmtronics.com makes a dang small switching power supply (the sBEC) that i'm using right now for 5v on a combat robot.
i feel important a dedicated & indipendent·i2c hardware port
for bios eprom and other 126 user devices
(also on pdip version, maybe in place of one ground and one vdd pin)
about cogs i think that·eight is enough... like the sit-com !!
just more powerfull and more ram
·
A unique (or fuse programmable) serial in the Prop2 and a no-readback fuse should do it... the Prop2 could encrypt the code into the EEPROM so that it would not make sense if it was read back other than by the same chip [noparse]:)[/noparse]
I'd plump for 8 cogs and more RAM too.
But in the long run, I think I want both..
Oldbit
I'd like more memory, and more I/O. I'm already thinking of hooking two propellers together, with the second being essentially an I/O expander. Except that because the I/O expander is doing serial ports and PWM measurement the extra ports are not able to be "dumb".
Having 32(64) pins of general IO at this speed buys a
lot of options. It might take a cog to do the I2C, but
its' I2C with options. Think of a cog as a single Thread
that needs no Semaphores because of the hub.
64 Analog/Digital I/O pins would make a lot of sense,
we live in an analog world. Of course then its a math
issue.
Scott
Why is there a spin interpreter into the Propeller ?
I hope that in the Propeller II, the spin language will be compiled. In this way, the Propeller will not waste any more its time to remake the work already made by the compiler. I does not understand yet why Parallax with implemented such an architecture in Propeller I ?
Thank you in Parallax (or/and Mike Green) to explain me that.
dro.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
But if you want, it can be loaded into all 8 COGS of the propeller.
But it doesn't have to be - you can write assembly to make the critical bits faster.
But spin generally is more compact overall and with a quicker development time.
Thanks Parallax - you actually gave *us* the choice about how to write our code.
Hub memory is not cog memory, if there was no interpreter then we would be limited to 512 words per cog and yes it would be possible to compile if you had a compiler but what can you do in 512 words? Well, you could have an interpreter sitting in those 512 words and execute tokens from hub memory which is fine for many of the higher level functions and you still have all those other cogs doing what they do for the real-time functions too. This is the reasoning behind the Spin interpreter and it does an admirable job of it too.
Also, it is not practical to give each cog more than 512 words of memory because the cog instruction only uses 9-bit source and destination addresses for local cog memory, that's all it can handle. It's not a limitation it's actually a powerful feature for this design.
*Peter*
* More RAM
* Much more RAM
* More cogs
* More I/O
Nick
I have much admiration for the splendid work completed by engineers of Parallax.
I understands the problems of memory well.
Now about the interpreter:
What is the job of an interpreter ? I know only one answer to this question: The interpret translated a program written into high level language (like the language SPIN) towards the native language of the processor. Can you assure me that the native propeller's language is well the assembler ?
In all the programmings environments which I used a compiled program was all time more compact and more fast than the interpreted or tokenized equivalent !
Then why not load directly assembler into hub and cog memory ? (what an interpreter can do, a compiler must can do too)
A long time ago, I wrote programs out of Z80 assembler and 8086 but, the high levels languages save so much time that I do not want to learn any more from assembler. Especially when that a compiled language ( like C ) offers acceptable performances compared to the assembler.
Is that why i am very disappointed to note that the SPIN language is about 20 time slower than the assembler.
I'm sure that it is possible to do better !
(Sorry for my bad English.)
dro.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
The process of executing Spin programs consists of two parts: 1) The Propeller Tool running on a PC compiles the Spin program into instructions for a stack-based machine and these get downloaded to a Propeller. 2) An interpreter program runs in a cog processor's memory and "executes" the compiled interpretive code.
The 20 times difference in speed is due to the number of native instructions it takes to perform basic operations like addition, setting a register, etc. On the other hand, the Spin interpreter has built-in many operations that are not native to the hardware like multiplication, division, array subscripting, a stack-based call mechanism, etc. and the interpretive code is much more compact than the native instruction set. The interpreter makes the Propeller's 32K main memory look like the main memory of the processor rather than an I/O device with limited access which it essentially is.
At the heart of this is the observation that, in all programs, a very small portion (usually less than 10%) of the program accounts for perhaps 90% of the execution time. For greatest efficiency, this 10% needs to be carefully optimized in the native instruction set. In a processor with limited memory like the Propeller, the other 90% should be optimized for storage space since execution speed doesn't really matter. Spin was designed with this in mind so that the crucial 10% could be hand written and optimized in assembly language and combined with a very compact interpretive code for the other 90% that executes at a reasonable speed.