Any new version of propeller? Anything?
Zap-o
Posts: 452
As life has it, my boss wants me to explore more advanced circuitry. The propeller was/is an awesome chip - I just wish that I had another version. I need more (my boss needs more) processing power, i/o and memory. I grow hopeless and tired of connecting 2 propellers together or using i/o expanders and the limited i2c bus IC's to make up for what the propeller is missing. Before I move to another micro processor is there any date in sight? Any hope for me (my boss) to continue to use this awesome device propeller!?
This is written with a positive tone in mine, so please don't think otherwise.
This is written with a positive tone in mine, so please don't think otherwise.
Comments
I know and I have said many times that when it comes to running large "application" programs efficiently that the Propeller does not excel in this area. Processors such as ARM chips are cheap and have large Flash memories well suited to running large application programs, at pure assembler speed if you like, in the region of tens to hundreds of MIPS. But these chips don't do what the Propeller does either. Recognize the Prop for it's strengths and utilize them, every chip has it's weaknesses, don't blindly believe that the Prop is the only solution, I'd love it to be, but it isn't.
What's the solution? Complement them, marry them together and put that synergy to work, it's a brilliant solution. This is what I have done in the past and I get the best of both worlds. I even have my new PUPPY Prop modules with an LPC2148 backpack for that reason. docs.google.com/Doc?docid=0AVS8dcreQOsuZGRncThrNGJfNWd0dmNyZmho&hl=en
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
My thoughts exactly! I suspect that some of the Propeller's capabilities are being overlooked.
-Phil
But, I'm very happy with Prop1, so I won't risk getting Chip mad at me yet...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
I whole heartedly agree with you. You have the right answer. So, please don't be offended by anything I say. I am not an engineer. I make that as clear as possible as often as possible. But I am interested in solving real problems as quickly and efficiently as my tired brain will allow. I am going to present a counter argument which might·be wrong most of the time.
Let me give you an example... I lost the key to the back door of my falling apart garage. The reasonable thing to do would be to install a new door lock. But I have tried that before and the amount of time it took me to install it wrong just isn't worth spending on that door. I do like to lock that door so kids can't get in trouble, and I have found out that I can open it with a butter knife or a crowbar or even a hammer on occasion... because the frame is so rotted, just about anything will work.
Peter, you solve problems with the precision a watch maker. But this level of precision is not always required.
The Prop2 will make it easier to have the equivalent power of 8? 16? Prop1s... but it won't have unlimited memory. One of the reasons we are stuck with I2C type solutions is that no-one produces a handy little expansion module with shift registers in and out.
My contention is that if a Prop2 will solve your problem... then solving that problem now with the Prop1 should be a lot easier than it is. There are products to be made. They aren't yet available because the size of the market is a problem for some guys. That creates opportunities for the younguns, if they can just be pointed in the right direction.
On the processor argument... I have my own bench mark, a routine for finding prime numbers, which I understand right down to the machine cycle. From this, I am convinced that if your problem has the right grain... then a parallelized Prop system will hold its own against some very, very powerful systems... it all depends upon what the logic requires. The actual amount of logic in lots of important applications is paper thin.
I have another algorithm for image processing... paper thin logic, but to be really robust, it has an outer limit on memory that is somewhere in the stratosphere. It would fit nicely in the Props program space and definitely would work with the memory available... it won't be as good as if I had the same logic and infinite amounts of RAM. But there are lots of problems that can be solved with less than a perfect implementation. And... although the logic works very well, there might be a way to eliminate the memory requirement. Putting it on a Prop will allow me to look carefully at it again.... maybe I missed somethihng... maybe there is a little glue that would get rid of the memory monster.
Regards,
Rich
Post Edited (rjo_) : 5/18/2010 1:01:34 AM GMT
I wholeheartedly agree and disagree with you. Prop II by it's sheer speed will make Spin spin at least 8 times faster and whereas now one Spin instruction takes a few microseconds in future will then take a fraction of a microsecond. I agree, Prop II will be much better.
Put the speed aside and the increase in hub memory and you still have a 9-bit internal address limited cog, dot period, full stop. Hub access will be faster in Prop II but nowhere near as fast as internal memory. Compare this with any other "processor" and none usually have less than 16-bit address bus at full speed of much less than a microsecond. My example of the LPC2148 which is just another processor is that it has 512kB of directly addressable Flash that effectively runs at full speed, or use the internal RAM etc. Any application that I have written in the ARM chip blitzes the Prop in this department. Now you mention benchmarks but they are not applications which themselves are characterized by large program space (read address space) whereas benchmarks can just fit into cog RAM where they can excel much like a lot of Intel code will run from L1 cache at FTL going nowhere. The real world doesn't work like that though.
So, to reiterate, I'd love the Prop to be the only solution, which it isn't, plus also it's about what is available NOW. I am patient and when Chip unveils the Prop II then I will be happy to scrap my hybrid designs, yes, I will be overjoyed. Until then......
EDIT: I think I missed your recent edits, whatever they were
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Peter is right... unless you happen to need a crowbar.
Thanks for the words.
@Phil - I feel that I am using the propeller to its potential. 2 stepper motors with 2 optical position sensors, 4 com ports, 2 - 30 Amp PWM h-bridges, 8 Chan 16 bit A/D converters, D/A converters, 5x5 button matrix, 4 Mosfets as switches, a LCD display, and other i2c devices. I have hundreds perhaps thousands of line of code in just one cog.
@ localroger - That would be a life saver, any dates?
@ Peter Jakack - Thinks for bringing me back down to earth. You are correct I need to keep using creative was to enhance the propeller as it is not the answer to all.
I suppose I am excited and as usual my excitement gets the best of me.
-Phil
I'm always amazed at how much it is possible to do on the Prop in 496 instructions, so I think that if you are using it as a microcontroller with all eight cogs dedicated to a single application then you are correct that it is not a limitation - at worst, it just requires a bit of rethinking about how to implement the application.
But the Prop is such a versatile beast that many of us here use it for things which are simply impossible with other microcontrollers - and when you instead treat the Prop as eight independant general-purpose processors (which many of us do) the 496 instruction limit on each one is very constraining.
Just as one trivial example - when implemented in PASM the floating point emulation libraries occupy two cogs. This is not done for speed, since only one of the cogs is used at a one time - it is done this because it just won't fit in a single cog.
Of course, you can argue about the value of floating point on a microcontroller, and you can also argue that the floating point libraries can also be implemented in SPIN and therefore not require any addiitonal cogs. But many applications have a need for fast floating point, and on the Prop this requires you to sacrifice two valuable cogs - just because of the 496 instruction limit.
On the other hand, I also find myself wasting a lot of cog space - e.g. a simple keyboard driver or serial driver wastes most of the available cog space.
In an ideal world, it should be possible to allocate the cog space to each cog on startup - this would allow for less to be allocated to simple driver cogs, with more being available for cogs running complex application code. For simplicity, it could be made allocatable only in pages of of 512 longs each, with the special registers always appearing at the top of the last allocated page.
While it may be too late to include such a design change in the Prop II, it could make both the Prop I and the Prop II just a special case of a new "super-sized" Prop III
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
At present the Prop is cheap and fast and extremely versatile and flexible, I don't ever want to upset that golden apple cart. Prop B with 64 I/O is another good option but someone has got to step up and place a huge order for those things to make it viable.
Rumors and dreams and hopes of Prop II are not very conducive to current designs and getting the most out of what we actually have. I am also very sure that once we have Prop II that it won't take long until we start having "Prop III, how long?" threads.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
Amen, brother.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
pPropellerSim - A propeller simulator for ASM development sourceforge.net/projects/ppropellersim
The Space Shuttle flew for about 6 years on the IBM AP-101 which originally had about 424 kilobytes of magnetic core. (F-15's and B-52'a too) It had 16, 32bit registers, 154 instructions, one processor and a 16 bit address buss. The CPU could process about 400,000 instructions per second.
Sojouner wandered about Mars doing all of it's thinking with an 80c85 8-bit processor which topped out at 64K of 8 bit.
What is the project that needs so much more power?
J-
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Signature space for rent!
Send $1 to CannibalRobotics.com.
Yes, a YMOS chip would be the best solution if he wants more performance now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
BUT note that I was not using any subroutines when first getting this to work. I simply copied the code to send a 1 bit over and over or to send a·0 bit over and over.
This is nice when developing/testing this stuff because you can modify the timing on one bit, run it, then very clearly see that differently timed bit on the testing data. With a subroutine the timing on all the bits would change of course. Handy for troubleshooting if you can verify that just that one thing changes.
But that is just the way I do things and not really necessary!
As to the finished program, this uses subroutines and around 1/10 the space.
Just need to call one subroutine to send a 1 bit and one subroutine to send a 0 bit and these only need to be listed once.
And as to adding more functions like volume up, change channel, or whatever, these could each be their own separate·object, so no need to try to cram them into the assembly space for volume down.
And in that case, cognew and cogstop would allow each function to operate, then go away and free-up a cog for another function.
BTW - While developing this, I was using one cog to generate the 38 kHz carrier, another cog to send the bits, and a 3rd cog with an IR receiver to test the signal! I think this is really cool stuff!
·
For microcontrollers like the Propeller, many tasks are very very time sensitive. They have to be hand coded in assembly language and optimized. The design of the Propeller's instruction set actually is very well suited to this type of programming. Compilers actually interfere with this sort of programming and most programming languages, C included, have no way to specify the timing information needed.
(which cuts performance) to do reasonable sized things at good
speed with Propeller has always been pretty disturbing to me.
Again distracted by language choices
... everyone has and is entitled to their opinions.
Let's give benefit of a doubt and ignore the language war stimulus please.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I have study Chip's last Diagram over I/O pins possibility and I think some speed improvements to execute biger programs will come with Prop II (Turbo) as I can see on that diagram He implement some handling of SDRAM's - If He to that give us possibility to tun COG directly from SDRAM's that can give us full blown on that COG (128MHz with one cycle instructions - Maybe only little slower.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Well, I like the tune this little bird is singing!
Brainstorming this further, 64 I/O could solve a lot of problems. You could add an external ram with no interfacing chips needed. Cogs don't have enough memory? Well, add an external ram chip and use LMM code. Why not add two ram chips and run them independently. 64kilobytes takes 16 address lines and 8 data lines. You could have two of these using 48 lines and still have lots left over for VGA etc. So that would give two cogs with 64k of memory each, working independently, and with probably only one NOP wait state (depending on the ram chip). Cache ram would be fast enough that it would be quite possible to use existing code to create a user space larger than 32k that would be (almost) transparent to the coder.
Ram chips are only a few dollars - and one or two ram chips plus a 64 I/O prop may well cost less than a P2. And possibly use less power as well.
I wonder how hard it would be to make a 64 I/O prop chip with the same specs as the existing prop? Just bring out more pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
As You know - Chip said He will incorporate LMM possibility's In COG's instructions/handle.
That can give possibility to RUN BIG programs directly from SDRAM's
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
But the difference might be that the LMM code would be in external ram rather than hub ram. Or you could mix and match where the code is stored.
I just thought of another thing. With 64 I/O pins you could access external ram 32 bits at a time. 32 bit data bus, 16 bit address bus and you still have 16 pins free for other things. 64 kilolongs for a cog, with almost the speed of native pasm. (it doesn't have to be 64 kilolongs, it could be any size depending on what ram chips you choose).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 5/19/2010 12:51:18 AM GMT