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.
@ 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....
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.
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."
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.
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
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.
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
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.
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
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.
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:-
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.
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[noparse]:)[/noparse]
@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.
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
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
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. [noparse][[/noparse]RUSH - Freewill]
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
Comments
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
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
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
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
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
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
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
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
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
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
nametag
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
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*
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[noparse]:)[/noparse]
@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.
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
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
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. [noparse][[/noparse]RUSH - Freewill]
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
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
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.
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
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
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.
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.
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
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
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.
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.