PDA

View Full Version : Any new version of propeller? Anything?



Zap-o
05-18-2010, 05:52 AM
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.

http://forums.parallax.com/images/smilies/tongue.gif

Peter Jakacki
05-18-2010, 06:12 AM
An engineer can have dreams but he also needs to work with what he has got now. Don't ever give up on the Propeller but just remember that it never was meant to be an answer to everything, it is the microcontrollers of microcontrollers and it's versatility reaches right over into many other areas. However, it is not a DSP, definitely not, as I am sure you will agree, but also it is not a "micro processor" although many other microprocessors are put to shame by it.

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 (http://docs.google.com/Doc?docid=0AVS8dcreQOsuZGRncThrNGJfNWd0dmNyZmho&hl=en)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

Mike Green
05-18-2010, 06:15 AM
You really need to read some of Chip's (and Ken's) comments over the last few years on projections for finishing complex projects and products like the Propeller (I or II).· Parallax is a company that works on an engineering-driven model rather than a sales-driven model.· They understand that complex new things (even old things) take time to do properly and that unforseen things happen along the way.· You will not get any projected delivery or announcement dates or even estimates that mean anything at all because that's the way this sort of development is done.· Chip does make announcements from time to time of features that he's decided to include or plans to include, but may not if something unforseen comes up along the way.· You can ask all you want (and your boss can ask too) about where things are at, but·you won't get an answer you can use for planning.

·

jazzed
05-18-2010, 06:37 AM
Zap-o said...
I need more (my boss needs more) processing power, i/o and memory.

Well, describe each need and their reasons, what you do now, and what you think might be done to achieve the objectives. Maybe someone here can offer helpful suggestions. If no solutions come up, then maybe it's time to move on.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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.

Phil Pilgrim (PhiPi)
05-18-2010, 07:07 AM
jazzed,

My thoughts exactly! I suspect that some of the Propeller's capabilities are being overlooked.

-Phil

localroger
05-18-2010, 07:32 AM
A little bird recently told me not to give up hope for a P1 with 64 I/O pins to tide us over while P2 is worked out. Since I've asked for this very thing myself I was very happy to hear the little bird singing this tune, and I hope it's right. Those 32 extra I/O lines would go a long way for adding on what isn't on the P8X32A die itself.

Rayman
05-18-2010, 07:33 AM
I'm ready for more power and I/O and memory myself :)

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

rjo_
05-18-2010, 07:50 AM
Peter,

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

Peter Jakacki
05-18-2010, 08:14 AM
@Rich

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 http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

rjo_
05-18-2010, 08:16 AM
And I am still using a crowbar to unlock my door:)

Peter is right... unless you happen to need a crowbar.

Zap-o
05-18-2010, 08:43 AM
Fellas,

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.

localroger
05-18-2010, 09:25 AM
Zap-O, my little bird might not be happy about me mentioning this at all here -- its sources are engineering based, you know, and there's all kinds of uncertainty, and unfulfilled promises are a worse thing than promises never given. But I feel your pain and just wanted to pass on the hint that there might be something cookin'. We love ourselves some propeller chip down here in da bayou and while the P2 sure sounds nice, it's also gonna be a power hog and we got some plans that might be better served by a 64 I/O P1 with its lower power process. In all honesty I think I have more uses for that chip than for the P2 as specified. I hope Parallax really does build it. *crosses fingers*

Phil Pilgrim (PhiPi)
05-18-2010, 09:28 AM
Regarding the 496-instruction limit per cog: has anyone (except, perhaps, Chip with the Spin interpreter http://forums.parallax.com/images/smilies/smile.gif ) had serious difficulties with that constraint? I haven't. It seems that a judicious allocation of resources between Spin and Assembly renders that limitation virtually moot. Am I wrong to make such a bald assertion?

-Phil

kwinn
05-18-2010, 09:48 AM
More cog memory would be useful even if it has to be accessed indirectly. Makes for larger buffers and look-up tables without the overhead of a hub access. The 496 instruction limit is less of a problem. For my applications the constraints would be 1 - No. of I/O pins, 2 - cog memory limit, 3 - hub memory limit. This is not to say that careful programming and distribution of tasks to cogs has not gotten around the limits so far, it has, but it has not been easy.

RossH
05-18-2010, 10:03 AM
@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 (http://forums.parallax.com/showthread.php?p=844004)

Peter Jakacki
05-18-2010, 01:38 PM
While I bemoan the fact that the Prop is limited by a 9-bit cog address I am also very well aware that the only way around this is to increase the cog word length from 32-bits to say 40 or even 64-bits. The 9-bit source and destination addressing built into each instruction is fast and efficient while it is operating withing these constraints. It is not possible to "allocate" more cog RAM for one and less for the other as it comes back down to the architecture of the cog and it's 32-bit orthogonal instructions which can only ever address 512 words directly. If Prop III was ever designed it could have the extra 32-bits in the instruction to increase the addressing range of cog memory all the way up to 32MB and immediate values accordingly. So you see even 40 bit wide instructions though they might sound a bit weird would resolve this bottleneck while maintaining some instruction set compatibility, the extra 8-bits would simply be all zeros normally but would allow 32KB cog addressing. Of course the whole data path, decode, ALU would have to be 40-bit, you never know, it might start a trend. A word of 5 bytes could be called a "quip", oh, how sly and witty http://forums.parallax.com/images/smilies/smile.gif

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*

mpark
05-18-2010, 08:52 PM
Peter Jakacki said...
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.


Amen, brother.

Ale
05-18-2010, 09:02 PM
I think you are ready for that other uC... the... how was it ?.... the ymos ? http://forums.parallax.com/images/smilies/lol.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH (http://propeller.wikispaces.com/MATH)
pPropQL: propeller.wikispaces.com/pPropQL (http://propeller.wikispaces.com/pPropQL)
pPropQL020: propeller.wikispaces.com/pPropQL020 (http://propeller.wikispaces.com/pPropQL020)
OMU for the pPropQL/020 propeller.wikispaces.com/OMU (http://propeller.wikispaces.com/OMU)
pPropellerSim - A propeller simulator for ASM development sourceforge.net/projects/ppropellersim (http://sourceforge.net/projects/ppropellersim)

CannibalRobotics
05-18-2010, 09:36 PM
The prop is a beast in the right jungle. It's a swiss army knife of a processor. At some point though an application will go beyond just about any processor. Certian applications do put a load on the resources of the chip, like graphics. If you have a graphics intensive program though, perhaps a co-processor is the answer? The prop II will come out some day, we'll all be wowed by it for some time then we'll be begging for more. In the near term, look at the bars others jumped over and the limits of those processors.
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.

Leon
05-18-2010, 10:19 PM
Ale said...
I think you are ready for that other uC... the... how was it ?.... the ymos ? http://forums.parallax.com/images/smilies/lol.gif


Yes, a YMOS chip would be the best solution if he wants more performance now. http://forums.parallax.com/images/smilies/smilewinkgrin.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

bill190
05-18-2010, 10:35 PM
Phil Pilgrim (PhiPi) said...
Regarding the 496-instruction limit per cog: has anyone (except, perhaps, Chip with the Spin interpreter http://forums.parallax.com/images/smilies/smile.gif ) had serious difficulties with that constraint? I haven't. It seems that a judicious allocation of resources between Spin and Assembly renders that limitation virtually moot. Am I wrong to make such a bald assertion?

-Phil
I ran smack into that limit with·the first assembly program I wrote to lower the volume on a Sony receiver. Luckily I was not using any stack space, so I was able to reduce the stack space for cognew and then had just enough room.

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!

·

Jack Buffington
05-19-2010, 02:22 AM
I too would love to see a 40 bit code word (or greater) for the propeller II. It would of course have to have corresponding additional RAM in each cog. If a 40 bit code word existed then the Propeller wouldn't be crippled with C that could only run in LMM. It could have decently complex programs that could be programmed in C which could run at full speed inside of a cog. That would be awesome. C is the way that programmers do their thing these days. To ignore that is to ignore the reality of the way the world works. I'm sure that the propeller is getting passed over by development teams because of the lack of being able to program in C and have it run at full speed.

Mike Green
05-19-2010, 02:40 AM
I'm dismayingly amazed by the number of people who look at C as the holy grail of programming. It's a tool for heavens' sake! It makes many programming tasks easier in exchange for a loss of efficiency, both in code space and execution efficiency. One of the goals of compiler designers is to minimize this loss of efficiency, but it can't be eliminated. One thing you have little or no control over is execution timing. To allow the compiler to properly optimize, you have to allow it to reorder operations, sometimes in ways you can't predict easily.

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.

jazzed
05-19-2010, 03:11 AM
The point that you have to use LMM or other overlay methods
(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 http://forums.parallax.com/images/smilies/eyes.gif ...
... 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.

Ravenkallen
05-19-2010, 03:23 AM
Jack is right. You are not anything in the world's eyes, unless you can program in C. I personally favor basic over all other programming languages, even C. Utilizing the right resources and basic is just as "Cool" as C.

Jack Buffington
05-19-2010, 04:12 AM
I guess that I should append my comment to say that yes, it really doesn't matter to me what language I would need to use. I just want to use a high level language to do things so that I don't get bogged down in having to repeatedly program up a NxM multiply function or have to manually deal with keeping track of a two dimensional array. I can do it. I just don't want to. Propeller assembly is a really great assembly and is quite powerful but that isn't enough to make me want to use it all of the time. If I am writing a serial driver or something that needs exact timing, most likely assembly is the way to go but for higher level programs such as dealing with a user interface or math heavy stuff, a good compiler will generate almost as efficient code as hand done assembly. I can deal with code that runs 95% as fast as hand done assembly but not with code that runs at 20%. Increasing the RAM available to a COG will encourage compiler makers to compile for direct execution within a cog rather than what is done now because cog RAM just isn't big enough to hold a complex program. At that point it won't matter if I have a preference for C or not because this being the propeller community, dozens of languages will pop up in short order to support everyones' preferences. We'll all be happy.

Sapieha
05-19-2010, 05:43 AM
Hi Jack Buffington.

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

Dr_Acula
05-19-2010, 06:02 AM
localroger said "A little bird recently told me not to give up hope for a P1 with 64 I/O pins to tide us over while P2 is worked out."

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 (http://www.smarthome.viviti.com/propeller)

heater
05-19-2010, 07:02 AM
Sapieha: I don't get the idea. Perhaps somehow the COGs could access external RAM via some kind of BUS made from the I/O pins. BUT how can the executable code space be made bigger when the instruction format only has 9 bit source and destination fields?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Sapieha
05-19-2010, 07:22 AM
Hi heater.

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

Dr_Acula
05-19-2010, 07:44 AM
@heater, I think I know what Sapieha is saying and it would work. Indeed, I think it is the model that pullmoll is using for the qZ80.

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 (http://www.smarthome.viviti.com/propeller)

Post Edited (Dr_Acula) : 5/19/2010 12:51:18 AM GMT

Sapieha
05-19-2010, 07:48 AM
Hi Dr_Acula.

You not need that many pins to some of SDRAMS as some of them have mixed ADDRESS/DATA lines.

Regards
Christoffer J.


Ps. And on most SDRAMS 16 pins can address 32 address lines in SDRAM as them are same for ROW/Column only have separate strobe signals.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

Post Edited (Sapieha) : 5/19/2010 12:53:06 AM GMT

Dr_Acula
05-19-2010, 07:59 AM
Ah, good point Sapieha. So, even more possibilities.

I wonder if localroger's little bird would be interested to know there are other birds squaking and flapping their wings with excitement!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller (http://www.smarthome.viviti.com/propeller)

Ravenkallen
05-19-2010, 08:07 AM
@ DR_acula....... If you wanted more ram space you could just multiplex the two ram chip's address and data lines. Of course only·cog could access it at a time.·Then you could read·or write·any given memory cell with the chip select pin. You could theoretically have·more than megabyte of ram ....TI also·sells a dip·NVSRAM, that have 128 kilobytes of memory. Just a suggestion....http://forums.parallax.com/images/smilies/scool.gif http://forums.parallax.com/images/smilies/scool.gif

Dr_Acula
05-19-2010, 08:17 AM
Yes, good point. 64 I/O pins makes so many things possible.

Cluso pioneered the 512 kilobyte ram chip but it used 8 data lines and 19 address lines and now he has to work with just one pin for TV and can't do VGA and can't do so many other things because there are no pins left.

With 64 I/O pins you can have a 32 bit data bus. Or two cogs with their own seperate ram and no need for complex code locking each cog out to prevent data clashes.

You could do other cool things too - eg multiplex 32 x 32 leds with no need for latches.

Yes, a 64 I/O propeller chip is the chip for me!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller (http://www.smarthome.viviti.com/propeller)

localroger
05-19-2010, 08:47 AM
Dr_Acula, my little bird is pretty confident in its tweet. But from my perspective it's third or fourth hand information, and as we know what my little bird heard from Parallax is always subject to change. My company has, on my advice, decided to invest (on our scale at least) pretty heavily in the Propeller. It's really the only way for us to pursue certain projects my corporate masters have wanted to pursue for years, considering that we can't really afford resources like "actual engineers."

Dr_Acula
05-19-2010, 08:56 AM
Tweet, squak, flap flap! This sounds interesting, even if it is third or fourth hand. (or first hand but you are protecting your source with obfuscation).

The propeller is a great chip to invest in. I guess there are always the comments that 'no point in speculating about something that doesn't exist', but on the other hand, if you take a propeller and add some latch chips and create lots of I/O pins that way, and then later on along comes a chip with more I/O pins, it only ends up a few lines of code to change, and things also get a lot faster.

There are probably those difficult questions - eg if you put resources into a 64 pin chip how much does that take out of the prop II and can you justify it, but what if the prop II takes too long to come to market, what if people prefer a chip with lower power consumption etc etc.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller (http://www.smarthome.viviti.com/propeller)

RossH
05-19-2010, 08:57 AM
@All,

I didn't mean to trigger yet another language war, or start yet another Prop II/III wishlist thread. I was just responding to Phil's question asking whether anyone has actually run into problems with the Prop's 496 limit. The answer is a resounding YES. The very first non-trivial program I tried to write for the Prop (a 3D flight simulator written in SPIN and PASM and intended to run on the Hydra) ran into this limit very early - I had to dedicate 5 cogs to various drivers and 2 cogs to the floating point, but in both cases at least one of those cogs was required not for speed, but just to overcome the 496 cog instruction limit. This left me only one cog for the main application code, but because of the 496 instruction limit this code could not be written in PASM, but had to be written in SPIN.

There are of course other examples, but I though that was a good one precisely because it DID NOT depend on using anything other than "out of the box" Parallax software, such as the SPIN compiler, various Parallax drivers, and the floating point libraries.

However, after several months work I realized that my project was likely to be impossible to implement in either SPIN or PASM - SPIN was too slow, and 496 instructions was not enough to implement what I needed to do in PASM. When I found out about LMM I considered converting the application code over to that - but I simply couldn't face the idea of hand-coding such a complex application directly in LMM. While I might take on such a job if someone paid me, it's certainly not what I had in mind when I originally bought the Hydra. This is why I originally started work on Catalina instead.

I'm REALLY NOT trying to promote either C or Catalina here - I agree with Mike that C is just one of the tools in a programmer's toolbox, and in many cases SPIN and/or PASM are far more suitable when programming for the Prop - but I strongly disagree with Jack that C on the Prop is 'crippled'. C was in fact the right answer for this particular project. The program executes about 8-10 times faster as a C program than the equivalent SPIN program (partly because I built floating point support directly into the Catalina kernel). While the result is not as fast as PASM, it is fast enough. The program could also be translated almost trivially from SPIN to C (in fact it would have been much easier to write in C in the first place because C has built-in support for floating point and SPIN doesn't). And (to get back to the original point) it allowed me to overcome the 496 PASM instruction limit without having to resort to the complexities of LMM. If that means C is 'crippled' then SPIN is also 'crippled' because it is so slow, and PASM is also 'crippled' because it is limited to 496 instructions.

In fact none of these are 'crippled' - they are just different tools with different time/space tradeoffs. C is definitely not the holy grail of programming, and it is definitely not the language of choice for all (or even most) Prop applications. It is just another tool that has a useful place in a complete Propeller toolbox.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=844004)

Sapieha
05-19-2010, 09:13 AM
Hi RossH.

I'm not lover of C in any form BUT BIG THANKS You write Yours Catalina C compiler.
As it is not only one of Tools - BUT one more that we have to play with.

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

RossH
05-19-2010, 09:28 AM
@Sapieha,

Thanks for your support - I'll make a C programmer of you yet!

At the risk of derailing the thread again in another direction, I'm intrigued by your statement that the TurboProp will offer better handling of external SDRAMs. I was expecting a speed improvement, and of course having more pins helps out as well - but it sounds like you are talking about something else entirely. Can you give us any more detail?

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=844004)

Sapieha
05-19-2010, 09:36 AM
Hi RossH.

If You look on UPEC thread - Chip posted Diagram on TurboProp's Pin's IN/OUT possibility's.

If You look on this diagram You will find that them have SDRAM IN/OUT support.
BUT as I not have sen entire presentation that Chip had on this UPEC I can only speculate what can be possible.

Regards

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

RossH
05-19-2010, 10:49 AM
@Sapieha,

Ok - I found the diagram you are referring to. I guess this means there will be some pin configurations designed to facilitate direct chip-to-chip logic (i.e. to disable any ADC or comparators etc). Also the I/O mode labelled 'SDRAM Clock' out may be to strobe the SDRAM automatically when you set any new data on the SDRAM Data pins - currently this requires a couple of additional PASM instructions, so this would indeed speed the whole read/write cycle up.

Can anyone who saw Chip's presentation enlighten us?

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=844004)

jennie99
05-19-2010, 11:23 AM
Hi Peter,


I think 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. But never give up. http://forums.parallax.com/images/smilies/hop.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
nametag (http://www.pcnametag.com)

Peter Jakacki
05-19-2010, 01:31 PM
Welcome to the forum Jennie.

Having more directly addressable I/O is always a bonus but of course complicates the package. I don't have a worry in any of my designs with I/O devices as I normally use I2C "smart" solutions using small cheap micros as I2C slaves (search the threads). Anyway I design custom PCBs rather than use modules normally but it is very very easy for me to add a normal serial I/O modules to my PUPPY range of products if needed:-

Puppy page: docs.google.com/Doc?docid=0AVS8dcreQOsuZGRncThrNGJfNWd0dmNyZmho&hl=en (http://docs.google.com/Doc?docid=0AVS8dcreQOsuZGRncThrNGJfNWd0dmNyZmho&hl=en)
Puppy thread: http://forums.parallax.com/showthread.php?p=901459

Prop II's cogs will run 8 times faster than Prop I and might even have more functionality per MIP but it will still have the same 9-bit internal address limitations so it won't be more powerful in that regard.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*

heater
05-19-2010, 02:09 PM
localroger: "...considering that we can't really afford resources like "actual engineers."""

Wow, localroger, in that one statement you explained why the Prop is not making inroads into the "professional" main stream world and is overlooked for all kinds of spurious reasons: "no C compiler", "not enough memory", "no code protection" bla, bla, etc, etc. No, it's because all those "actual" engineers are afraid someone might find out they are not actually required in many cases:)

@RossH: Your story about your flight simulator and Catalina sounds like history repeating itself. By all accounts Unix, and hence C, started life on a PDP-7 as a means for Ken Thompson to run his Space Travel game.

Looks like we are banging our heads against the same issues as Ken did in 1969, speed, memory, complexity.
Why do so many, my self included, desperately want a micro-controller to be something a lot bigger than it was designed to be?

By the way, what happened with the flight simulator?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

RossH
05-19-2010, 02:53 PM
@heater,

Completing the flight simulator is still on my list of "things to do" once I get Catalina sorted. It runs, but not well. I got to the point of being able to fly a spacecraft around obstacles in empty space (and shoot at them!) but the basic 3d engine needs to be re-implemented using quaternions to make it fast enough to add all the gameplay elements I also wanted. But other things keep getting in the way. Every time I think it has finally percolated to the top again I find more things need doing on Catalina. Last time it nearly made it to the top I got an email from Bob Anderson saying how he wanted to write a debugger for Catalina. Hence "BlackCat" got born, but "PropCommander" - the original impetus behind Catalina - still languishes incomplete. So blame Bob!

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=844004)

Cluso99
05-19-2010, 03:33 PM
WOW. I take a flight interstate and am off-air for 36 hours and I have a 2 page thread to catch up on.

The Prop I is being USED in ways NEVER intended by it's designer (Chip). It's a microcontroller and a microcontroller does not have an external data/address bus. Over 4 years ago, a 80MHz PIC or AVR was not possible so PASM was ultra-fast and Spin was quite fast. Not so today. 32KB of hub RAM for code space was enormous back then and has only recently been matched. An internal Flash is not necessarily equivalent to SRAM - it depends on the application.

The PropII will come at the next speed level and have lots of hub ram. No, it will not be what we all want, but it is only what we can get in a fixed die size and the resources available to Parallax.

Now, if all the above means that the Prop I or II cannot do what we want, and something else can, then I hate to point out the obvious, but the Prop I or II is the wrong chip for the job. It is not a be-all end-all chip. It has some limitations, as few as they are. That's life.

Prop II & SDRAM. Some time ago on another thread, Chip found a nice cheap SDRAM (8MB??). I suspect what we are seeing is possibly an implementation of this in the Prop II. We will have to wait (I have no inside info), but I am optomistic.

If the Prop IB (64 I/O) comes, I will be estatic. I see different applications for this to the Prop II.

You know,·the Prop II will resolve so many things and open up so many other possibilities·that (as I have previously predicted) I see us all complaining we do not have enough cogs and not that a cog·only has ~500 longs. Why? Because we will overcome·the cog space problem·with LMM and overlays due to the faster clock and quad-long hub access.

Meanwhile.....· ·I am designing with what I have today. Prop I does not do everything although it does do one hell of a lot - Thanks Chip http://forums.parallax.com/images/smilies/yeah.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade (http://forums.parallax.com/showthread.php?p=786418),·RamBlade (http://forums.parallax.com/showthread.php?p=849265),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) (http://forums.parallax.com/showthread.php?p=778427) ZiCog (Z80) (http://forums.parallax.com/showthread.php?p=788511) , MoCog (6809) (http://forums.parallax.com/showthread.php?p=811043)·
· Prop OS: SphinxOS (http://forums.parallax.com/showthread.php?p=819353)·, PropDos (http://www.orrtech.us/propdos/) , PropCmd (http://obex.parallax.com/objects/440/)··· Search the Propeller forums (http://www.google.com/advanced_search?q=+site:forums.parallax.com&num=20&hl=en&lr=)·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBlade Props: www.cluso.bluemagic.biz (http://www.cluso.bluemagic.biz)

Bean
05-19-2010, 06:13 PM
I wish I knew for sure that the 64 pin version of the Prop1 was REALLY going to be available. I would start on supporting it in PropBasic.

I know the registers are there (INB, OUTB, DIRB) so it probably IS going be out sometime. I just don't want to waste my time implementing it if it is just a pipe-dream.

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Use BASIC on the Propeller with the speed of assembly language.
PropBASIC thread http://forums.parallax.com/showthread.php?p=867134

March 2010 Nuts and Volts article·http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp5.pdf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two rules in life:
· 1) Never divulge all information
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you choose not to decide, you still have made a choice. [RUSH - Freewill]

Sapieha
05-19-2010, 06:53 PM
Hi heater.

You said
"Why do so many, my self included, desperately want a micro-controller to be something a lot bigger than it was designed to be?"

My answer.
That Propeller are one "GOLIATH" that only dress it in one micro-package. Very incredible piece of silicon THAT we still only started discover.
And still have MUCH to Discover - what is possible to be done with it. As we only scratched on top of it's possibility's.

Regards
Christoffer J.

Ps.AND I wish that Propeller 1.5 (64pin) are not only nothing we dream on that some talk it will come - BUT at it will COME - as son as possible.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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

localroger
05-20-2010, 10:08 AM
heater, I grok what you're saying but it's not a bug, it's a feature. I do embedded controls. Some of this hardware features blazingly slow 40 MHz x86 processors and costs USD$2K+ per unit. The manufacturers have all kinds of things we don't have -- ESD testing rooms, the three engineers who are paid $80K a year to sign compliance forms, and more. We can't compete with that. But if we can shortcut all the stuff that the Prop lets us shortcut, keeping the difficult to manage high frequency signals on the die so the PCB's can be simple, eliminating UARTs and ADC's and video controllers and LCD controllers (which seem to have no standardization), then we can make something really nice really cheap and slip it under the door. And the best part is that there's not other vendor offering any comparable part (Leon and his XMOS fetish notwithstanding) so if anybody tries to rip off what we do, it will be kind of obvious what they did.

potatohead
05-20-2010, 10:11 AM
Localroger, that's damn cool, and a spot on application of the propeller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness! (http://propeller.wikispaces.com/)
8x8 color 80 Column NTSC Text Object (http://obex.parallax.com/objects/550/)
Safety Tip: Life is as good as YOU think it is!

Sal Ammoniac
05-28-2010, 06:37 AM
I've finally found the perfect use for the Propeller I: an I/O controller.

I've considered it for the main processor for some of the projects I have underway, but I've always run into code space, data space, or speed limitations that would be too difficult to circumvent without devoting more effort than the problems are worth. There are other things about the Propeller that, in my opinion, makes it a less than stellar microcontroller for many applications: lack of JTAG debugging support, lack of native floating point support in the Propeller Tool, non-mainstream language, etc.

What I have found the Propeller perfect for is an I/O processor. It's plenty fast enough to implement many of the I/O functions I need, and the lack of code space is not important for this application. The counter units are really helpful here too, as is the ability to support multiple I/O streams with the eight cogs, all running tight, deterministic code unhindered by anything else going on in the chip.

I'm using a simple SPI interface between the ARM Cortex M3 main MCU (which does have the code/data space, floating point, and debugging support I need for my main applications) and the Propeller. One cog handles the command interface. This "command" cog then parcels out various I/O tasks to code running on the other cogs and eventually responds back to the ARM with data and/or status.

I expect most, if not all, of my future projects will use this arrangement of an ARM application MCU and Propeller I/O processor. I'm getting the best of both worlds.

Phil Pilgrim (PhiPi)
05-28-2010, 09:16 AM
I've heard the "non-mainstream language" critique way too many times. The latest version was in the editorial of the June 2010 of Nuts & Volts. It's total nonsense. Programming is an art and a discipline. Programming (i.e. how to think abstractly, analytically, and algorithmically) is what people learn. If you know how to program, the choice of language is secondary, and you can adapt to what's available. For someone who's a competent programmer, the only barrier presented by a particular language is a stubborn unwillingness to learn it.

-Phil

JasonDorie
05-28-2010, 09:17 AM
I'm a little late to the party here, but one of the recurring themes is how restrictive the memory space on the cogs are, particularly for floating point support - two cogs! For one of my own apps, I needed add, subtract, multiply, divide, atan2, and conversion to/from float/int. The first four were all in one cog, along with the conversions and some other code. The atan2 operation was in the second cog. It took me under an hour to fold them into a single cog after cutting out the operations I wasn't using.

Granted, it'd be nice if I didn't have to do this, but I think most people treat the supplied objects as immutable, but in reality they're tweakable like anything else. I think it's kind of awesome that Parallax supplies them as code and encourages this kind of thing, and I learned quite a bit by digging around in there.

Oldbitcollector (Jeff)
05-28-2010, 09:25 AM
Phil said...

I've heard the "non-mainstream language" critique way too many times. The latest version was in the editorial of the June 2010 of Nuts & Volts. It's total nonsense. Programming is an art and a discipline. Programming (i.e. how to think abstractly, analytically, and algorithmically) is what people learn. If you know how to program, the choice of language is secondary, and you can adapt to what's available. For someone who's a competent programmer, the only barrier presented by a particular language is a stubborn unwillingness to learn it.

-Phil



Bryan burned me a bit with his statements about the Propeller. The Propeller can be programmed in both BASIC and C.

Arrrrrr!

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Are you Propeller Powered?
Propeller Feature Projects: PropellerPowered.com (http://www.propellerpowered.com)
Visit the: PROPELLERPOWERED SIG forum (http://www.savagecircuits.com/forums/forumdisplay.php?29-Propeller-Powered) kindly hosted by Savage Circuits (http://www.savagecircuits.com).

Sal Ammoniac
05-28-2010, 10:30 AM
Phil said...
I've heard the "non-mainstream language" critique way too many times. The latest version was in the editorial of the June 2010 of Nuts & Volts. It's total nonsense. Programming is an art and a discipline. Programming (i.e. how to think abstractly, analytically, and algorithmically) is what people learn. If you know how to program, the choice of language is secondary, and you can adapt to what's available. For someone who's a competent programmer, the only barrier presented by a particular language is a stubborn unwillingness to learn it.


You make good points, and I had no issues learning Spin or the Propeller assembly code. In fact, Spin was so easy I was able to write useful code in it after a few hours of reading the datasheet.

Where lack of a mainstream language is important to me is the fact that I have tens of thousands of lines of code written in C, which has been the de facto standard in the embedded world for nearly 30 years, that would be a real pain to port to Spin, especially since it's full of floating point code. My current project involves the reuse of almost 20,000 lines of that code, and even if I could convert all the floating point code to fixed point, or use the convoluted method required by Float32, it probably wouldn't fit in the 32K hub space anyway.

Mike Green
05-28-2010, 10:45 AM
The Propeller is not the only solution for problems. It is not designed for implementing a 20,000 lines of C program, particularly one that involves a substantial amount of floating point. It's foolish to expect that it should work for a problem on that order. You'd be much better off with a largish ARM processor or something similar that can run Linux. The Propeller's floating point library is intended for convenience when a little bit of floating point is needed for a project.

I'm really struck how much "mainstream" computer science has moved away from what has been a very rich area. Sophisticated people used to develop their own programming languages or language extensions for a project. Read "The History of Programming Languages" sometime.

RossH
05-28-2010, 10:56 AM
@OBC,

Yes, I agree. The whole argument about mainstream languages on the Prop is now a bit beside the point. Mainstream languages are available to those who want or need them.

I've just posted a comment on the Nuts & Volts web site.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=844004)

RossH
05-28-2010, 11:13 AM
@Mike

Not disagreeing with you - but I have to point out that I routinely run 10,000+ line C programs on the Prop which require floating point. I won't claim that the performance is outstanding, but it is as fast as I need it to be - and I can do it with about $20 worth of hardware. For what I want to do, the Propeller is just about a perfect fit in both price and functionality. There are indeed ARM/Linux based solutions that could do it much faster, but would they be cheaper? I doubt it. And would they be as much fun? Definitely not!

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=844004)

Sal Ammoniac
05-28-2010, 11:16 AM
Mike said...
It's foolish to expect that it should work for a problem on that order. You'd be much better off with a largish ARM processor


That's exactly what I'm doing, although I'm not using Linux. The ARM runs the main code and talks to a Propeller, which does most of the I/O.

Mike Green
05-28-2010, 11:41 AM
RossH,
I know that Catalina can do it with an external static RAM, but that's certainly not how the Propeller was designed to function. It's incredible that we can do as much as we can with this chip. There is a big hit though in this case both in execution speed (which is still quite good) and in the number of I/O pins available.

RossH
05-28-2010, 11:56 AM
@Mike,

Yes, I was not really arguing with your main point - just highlighting the fact that while the Prop can't do everything, it's so extraordinarily flexible that it is a cost-effective solution across a huge range of applications.

I don't think there is another chip on the market that comes so close to being a panacea.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=844004)

heater
05-28-2010, 12:28 PM
Some times it appears that Chip is an evil genius that is playing with us. It's as if he purposely set the limits of the Propellers speed and memory capacity at such a levels as to make common things doable but only just. Tantalizingly in the realm of "it must be possible". He wanted to drive us all mad attempting to do those things.

USB - Only just doable.
Z80 or other emulation only just.
Ethernet - Only just, bit banging UDP.
C language support - Only just.
Floating point - Only just.

I'm sure others have many more examples to support my thesis.

Chip's evil and twisted mind is not in a hurry to put us out of our torment with the Prop II. He's enjoying watching us squirm to much. Notice how he intentionally did not release the 64 pin Prop I.

Err..OK. Only joking.

Still you must admit that those Prop limits have spawned a lot of interesting solutions to all kinds of problems over the years. If the limits were lower there would be no chance and no one would bother. If they were a bit higher it would be boringly easy.

I nominate Bill's invention of LMM as the most brilliant of those solutions to work around the Prop's limits.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Phil Pilgrim (PhiPi)
05-28-2010, 12:40 PM
Mike Green said...
I'm really struck how much "mainstream" computer science has moved away from what has been a very rich area. Sophisticated people used to develop their own programming languages or language extensions for a project.

I've been out of the academic loop for a long time now, so I'm not familiar with today's curricula. But if, as you imply, university undergrad comp-sci programs are just teaching how to program in C or Java, say, they've been reduced to little more than trade schools. Not that there's anything wrong with trade schools -- far from it; but being proficient in one or two languages does not, by itself, merit a college degree.

-Phil

Phil Pilgrim (PhiPi)
05-28-2010, 12:48 PM
Heater,

It doesn't matter what the processor is or how powerful. There will always be apps for which that processor will be almost -- or only just -- capable. It's our nature to probe those limits. But I'd have to say that doing so with the Prop has been more fun than with any other MPU I've used. I think it's because there always seems to be one more wrinkle to explore and with which to eke out yet another iota of performance.

-Phil

heater
05-28-2010, 01:03 PM
Phil: "It's our nature to probe those limits" - Yep
Phil: "doing so with the Prop has been more fun than with any other MPU..." - Yep.
Phil: "...one more wrinkle to explore..." - Hope so.

I think the magic is that there are, of course, limits and that Prop has such an unorthodox architecture to let you get around those limits. But that unorthodox architecture forces you to think in somewhat different ways to do it. If it were any old boring run of the mill design one would not bother to push the limits one would just go out and get a different chip.

Bill's LMM is a case in point. That technique is just not applicable to most other chips with variable length instructions for example. But here we are, after that little bit of sideways thinking with two C compilers, some CPU emulators and whatever else on the Prop using it that looked stupid to attempt before.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

HollyMinkowski
05-28-2010, 01:13 PM
heater said...
Some times it appears that Chip is an evil genius that is playing with us.


He is a genius, of that I'm certain. Before I actually got out in the working
world and saw first hand how important making a profit was I would have said
that the prop should have lots more features. But I now understand that
Chip had to make it a realistic product that would have a market.

no profit would mean we would have no propeller at all to play with :-(

This amazing chip is so wonderful that I don't think I will ever discover
everything there is to know about it. Just the joy of not having to write
interrupt code is reason enough to use the prop whenever you possibly
can. I almost decided against using the propeller. I have a mild case of
OCD and if something seems to be not exactly the way it should be then it
is hard for me to use it. I considered the lack of on board program storage
to be "just not right" but the 8 cogs and no interrupts kept making me look
again and again at the prop. It's pretty funny now but I got around this at
first by gluing the eeprom chip on top of a dip prop and wiring it up along
with a resistor so that it would be a complete package..lol .. this made me
comfortable using it and then I moved on gradually to where I could consider
the prop and it's necessary external eeprom chip to be a complete package
of parts that was a lot like a mcu with flash program storage built in. Pretty
weird huh.

@Sal Ammoniac
What you are doing, combining a prop with an ARM chip is a perfect example
of using the prop to best advantage.

I guess the thing I would like the most for the prop is some more cog ram!
I keep running out of ram and having to go back and rewrite code to cram
everything in. Would be nice to have enough room to store a lot more data
where you could access and alter it quickly.

heater
05-28-2010, 01:26 PM
Holly: OCD or not I think many people have viewed the Prop the same way. Including myself. When you are searching around for a micro-controller to do some job and you have seen many micro-controllers before you have some fixed ideas about what you are looking for. As I have said here before I skipped over the Prop on seeing it in a catalog the first few times. "To small" I thought, "You cant' do anything in 496 instructions" I thought, "to weird" I thought.

Eventually it starts to dawn on you...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Leon
05-28-2010, 02:05 PM
localroger said...
And the best part is that there's not other vendor offering any comparable part (Leon and his XMOS fetish notwithstanding) so if anybody tries to rip off what we do, it will be kind of obvious what they did.


It's horses for courses - XMOS is more suitable from some things than the Propeller, and vice versa. For instance, the Propeller can't do high-speed USB and Ethernet on the same chip, and it's harder to do VGA on the XMOS chip than on the Propeller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM

Post Edited (Leon) : 5/28/2010 7:34:39 AM GMT

Toby Seckshund
05-28-2010, 02:09 PM
I was fortunate to not have known about the Prop until greater minds had got past all those initial dismissals. I wanted more ram for an ethernet project, I wanted a chip that could do VGA, I wanted ...

Then I saw the YBOX2 and that was that.

Mike is right about the stubborness in resisting new languages, unfortunately I caught that one back with the Z80!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point