OK. At risk of life and limb here I am going to make the Prop-XMOS comparison.
PropII is only 40 MIPS per cog running C code (LMM, as per your post). That's less than half the speed of an X thread (assuming 4 per core). It's also vaporware at this point whereas the X chips are in production (I could as well say that a future X chip could raise the bar even higher, but I won't because it doesn't exist yet.)
The free X development tools support C, XC, and C++ along with JTAG debugging ($50) in an Eclipse IDE. Will Parallax themselves support such an integrated, seamless environment at launch, or will it be a matter of stitching together a bunch of third party tools (Catalina, PASD, ViewPort, etc.)?
(I didn't intend this discussion to digress into a Propeller vs. "X" debate, but someone did mention the multicore aspect of the Propeller implies that it doesn't need to support C in any meaningful way (at least that's how I interpreted it.))
I'd suspend the judgement until Kuroneko will get the new counters to jump in the flaming ring... or doing the laundry... or cooking diner
Seriously, I'm quite satisfied by the way the prop II is shaping up.
For normal control applications, 128KB is enough (probably 32KB was, in the majority of cases). The number of pins was more limiting.
For the retro and prop-os noisy cats... I think we just scratched the surface of speed improvements obtainable thru caching, partly because the authors of the two available solutions got "sidetracked" playing with hardware again ...but 128KB and burst fill rates from SDRAM are going to change the game!
Well the question in the thread is "Is the Prop II too little too late?"
There isn't really an answer to that unless comparison with other existing and possibly future devices is made.
Yes, Leon, hopefully XMOS will also have moved on. Let's say they double their speed next year and or halve the chip cost, two cores for the current price of one. Who knows? Still the Prop II is standing up well.
Sal, why would make my comparison assuming I'm only using 4 of the available X threads? I have no such limitations in the Prop.
As you see from the Parallax Semiconductor threads Parallax is intent on having the same Eclipse IDE as XMOS and the same compiler (different back end of course) for C.
You might conclude that Prop II may end up a bit behind in the performance race. On the plus side a Prop II will always be a hundred times easier to work with than an XMOS.
Well the question in the thread is "Is the Prop II too little too late?"
There isn't really an answer to that unless comparison with other existing and possibly future devices is made.
Yes, Leon, hopefully XMOS will also have moved on. Let's say they double their speed next year and or halve the chip cost, two cores for the current price of one. Who knows? Still the Prop II is standing up well.
Sal, why would make my comparison assuming I'm only using 4 of the available X threads? I have no such limitations in the Prop.
As you see from the Parallax Semiconductor threads Parallax is intent on having the same Eclipse IDE as XMOS and the same compiler (different back end of course) for C.
You might conclude that Prop II may end up a bit behind in the performance race. On the plus side a Prop II will always be a hundred times easier to work with than an XMOS.
"Too Little, Too Late" I don't think so.
I made the comparison using four threads because four threads have full performance (100 MIPS), while eight have only 50 MIPS each (although if what you say about the PropII running C via LMM is true, 50 MIPS is still better than 40 MIPS).
I'm glad to hear that Parallax is working on an Eclipse-based IDE. Will it have integrated debugging as well, or will it be like the current Prop tool (compiler and code downloader)?
What you say about the ease of use of XMOS is true from the perspective of a hobbyist, but not for a professional developer. I had a large chunk of Spin/PASM code from one of my projects ported to XC and running within hours of getting my first development board.
Sal:
You are missing that for a comparable price you only get a single core XMOS device. Yes the Prop II could be said to be slower than some devices, most of witch were microcomputer CPUs first and integrated into MCUs later, and a couple of which have much higher price tags (including XMOS), this says a lot as the production quantity of the Prop II is expected to be significantly lower than the other MCUs.
Sal:
You are missing that for a comparable price you only get a single core XMOS device.
How do you know what a PropII is going to cost? I haven't seen any price announcements yet, in fact I don't even think Parallax knows yet as they don't know what the production costs will be.
Sal you are correct about that. Though they have given us some good best guesses, including logical reasoning behind there guesses. As a result I would be surprised to to see a price tag greater than $16. And having now checked, you could not match the performance of the Prop II in 'X' for under $23.
I'd suspend the judgement until Kuroneko will get the new counters to jump in the flaming ring... or doing the laundry... or cooking diner
The bad news for Kuroneko is that his beloved phsx registers will be hidden behind special load and store instructions, instead of residing the the cog's address space. But the good news (and it's very good news) is that the Prop II's autoincrement features will obviate any need for his famous counter magic.
As for headway, some perspective is in order. It is not necessary for Parallax to become the next Microchip. It is only necessary that the share needed to support the propeller ecosystem at a nice profit be realized.
Apple has done that for years, and today has extended that to be very profitable, leveraging many core differentiators over time to build a very solid business that continue to have a moderate overall PC share.
The same is possible for Parallax, and the fact that they are a private company is actually a significant competitive advantage here.
For that to occur, it's only necessary for a small sub-set of overall potential users of the technology see the value of the chip.
The focus then is on margin and making the most of the differentiators, and communicating that to people clearly so that those prospects, who would see the competitive advantage, do so, and adopt the tech successfully.
It is not possible to do something that is actually new, without also doing the boot-strapping needed to enable successful adoption of the technology. Parallax sees that, and is making the efforts necessary. From there, it's just a matter of time before we know whether or not the new effort is successful enough to be longer term viable.
I suspect it is, and again Parallax being a private company means the variance on what is possible and practical is considerable, and not directly comparable to others in this tech space, who do not operate on the same basis.
Seen this movie a lot of times. Parallax is actually well positioned here, and that's all we need to know as users right now. Our futures are fairly secure, with a lot of upside possible.
Maybe the business goals that Parallax sets for themselves differ from the business goals that others set for them.
It is true that we won't have hardware debugging at the PASM level. The concurrency of things does limit the negative impact of that however. Seems to me, from what I've seen so far, implementing those debugging features could have a design impact, and must they be licensed? Would like somebody to answer that.
At the LMM level, couldn't "hardware like" debugging be implemented in the kernel?
You mean JTAG? It's an IEEE standard and there are no licensing requirements, AFAIK. A lot of companies that used to use JTAG are now using a simpler two-wire debugging and programming technique.
It is true that we won't have hardware debugging at the PASM level. The concurrency of things does limit the negative impact of that however. Seems to me, from what I've seen so far, implementing those debugging features could have a design impact, and must they be licensed? Would like somebody to answer that.
At the LMM level, couldn't "hardware like" debugging be implemented in the kernel?
The typical way hardware debugging is implemented is via JTAG (IEEE 1149.1) and, as far as I know, doesn't require a license fee.
In my opinion, the concurrency of cog execution makes hardware debugging more necessary, not less.
@Kevin: Absolutely that's true. Made that point a lot of times. They are looking for a sustainable business that gets everybody paid and that can grow and meet their own goals, whatever they may be. I do not think I've seen those goals articulated beyond what I just wrote.
As for requiring more not less debugging, I see a strong case either way. How the programs are built impacts things. My own experience, both just writing my code, and working with others, seems to indicate more emphasis on program design methodology would deliver the biggest return. I think I'm going to stick with that for now. Again, my personal experience clearly shows investments there pay off huge.
Frankly, the chip is simple and consistent. We make as big of a mess as we choose to. Where there is a lot of complexity in the hardware, or said hardware is "buggy", or put a nicer way, not self-consistent, yeah a hardware level debugger makes good sense, because it's not always possible to know the behavior.
On props we do know the behavior, but for some pretty damn exotic cases, pushing the edge. So then, one has to ask the question why not build in ways that limit the unknowns? Fair question, don't you think?
Sal:
I am a bit confused by some of your statements.
1) What can you do with those standard debugging interfaces that you can not do using a cog with a well designed debug routine (especially if the LMM of your C compiler cooperates)??
2) Are you anti-prop? Many of your arguments seem to suggest this.
As for requiring more not less debugging, I see a strong case either way. How the programs are built impacts things. My own experience, both just writing my code, and working with others, seems to indicate more emphasis on program design methodology would deliver the biggest return. I think I'm going to stick with that for now. Again, my personal experience clearly shows investments there pay off huge.
Having hardware debug capability doesn't preclude or replace good program design in any way. This is not a zero sum thing.
Frankly, the chip is simple and consistent. We make as big of a mess as we choose to. Where there is a lot of complexity in the hardware, or said hardware is "buggy", or put a nicer way, not self-consistent, yeah a hardware level debugger makes good sense, because it's not always possible to know the behavior.
On props we do know the behavior, but for some pretty damn exotic cases, pushing the edge. So then, one has to ask the question why not build in ways that limit the unknowns? Fair question, don't you think?
This is one of the most ridiculous statements I've seen in a while. Hardware debug support isn't there because the hardware is buggy, it's there to debug software. When is it not always possible to "know the behavior" on other MCUs? The things are deterministic, period, with respect to instruction execution. Short of a bug in the chip, each instruction will have a consistent outcome.
Sal:
I am a bit confused by some of your statements.
1) What can you do with those standard debugging interfaces that you can not do using a cog with a well designed debug routine (especially if the LMM of your C compiler cooperates)??
Hardware debugging as implemented on MCUs let you do things such as set breakpoints, single step code, set hardware watchpoints (which trigger when the desired memory location is written or written with a specified data pattern). This is non-invasive to the software--you don't have to include special code in your code for it to work, like you do with ViewPoint and PASD, and you don't need to use the equivalent of a cog to do so. Check out the XMOS development tools for a very well-executed example of hardware debugging on a multi-core, multi-thread architecture.
2) Are you anti-prop? Many of your arguments seem to suggest this.
Quite the contrary. I've used the Prop in several of my projects and will continue to do so. It makes a great I/O processor when coupled with something like an ARM Cortex-M3 to run the main application code (in C) that implements things like control algorithms, filters, etc.
I wish Parallax would create a new forum (perhaps they could call it the "Propaganda" forum) specifically for these kind of threads that wander all over the place and (more often than not) end up as "Propeller vs chip X" arguments.
RossH:
I could not agree more. There always seem to be those that push 'X', and seem to think of the Propeller as a peripheral processor rather than a microcontroller.
RossH:
I could not agree more. There always seem to be those that push 'X', and seem to think of the Propeller as a peripheral processor rather than a microcontroller.
We're comparing the Propeller with X, not necessarily pushing X, because of the similarities (both are multi-core processors with no built-in peripheral support).
And what's wrong with the Propeller as peripheral processor? There's even a chapter devoted to this topic in the "official" Propeller book.
Coming into this conversation kind of late, but i think the Prop2 will do just fine among it's dedicated audience. Sure the Prop2 ain't no ARM, but it will be epic:) My only beef with it was the lack of a DIP package, which considering the circumstances(96 I/O pins), i guess not much can be done... I hope bigger companies will look at all of the resources available and realize that Parallax is a very dedicated company. Their small size IS their strength. They can just hop on the forums and ask questions or even call Parallax themselves. I can't see a Propeller being embedded in very small gadgets, but they might find use in commercial products that need something a little heavier, without resorting to a higher end micro. A lot of critics have not even tried a Propeller and yet they cast so much doubt.. That new 20 dollar board is going to kick some ***:)
Anyway, heater did the comparison, so would you please update the prices and add Prop 1 to your table. IIRC search the PropII threads and you will be pleasantly surprised that Parallax were aiming for under $12 (or less?) for the Prop II. Not sure if that is still valid or not.
Threads and cores are NOT the same. They share resources common resources, particularly in our case, cog ram!
Anyway, there will be lots we can do with the Prop II. Just that it will not do everything I/we would like. It doesn't really matter because there will be plenty of possibilities and there will be lots of flexibility in this design. Even something as simple of inverting pins by a single register saves code space and simplifies the code.
ROM space:I thought the latest specs indicated 32KB but perhaps from Beau's pic we may have 4x that??? Presuming 128KB ROM, then there is room for an additional 8x8 font. Full FAT16/32 drivers and SPI, I2C, FDX (maybe multiport because of extra speed). Because I don't have any inside info, I could speculate that perhaps the "Gold Objects" could be put into ROM.
Presuming only 32KB ROM (4 blocks of 8K --- has to be 4x blocks because of the quad long accesses) then if the 16x16 font was removed we recover a huge rom space for other things. IIRC there is no requirements for some of the tables because of cordic (which I know nothing about). This would free up enough space for a lot of objects plus perhaps floating point code.
If 128KB ROM, then by reducing to 32KB ROM would give us 96KB / 6 (sram requires at least 6x die space) = 16KB extra hub space. So 96KB ROM === 16KB SRAM die space. Let us ignore the problem of 36KB blocks of SRAM that cannot be as regular (efficient) as 32KB blocks for die space. Pretty big argument for gold objects to be in rom, even if not used. And if they prove to have bugs, well we can always load them. That is what Apple did with the Mac and look how well it worked for them. Anything in ROM does not preclude you making your own, but it does bring more standardisation.
Another comment is that Parallax is only a small private company that does not have the external pressures to make certain percentage profits. Chip & co have some very nice values and passions that you do not find in most (any?) corporations. They do not have to sell billions of chips, although that would be nice.
and seem to think of the Propeller as a peripheral processor rather than a microcontroller.
I'm putting together a free beginners book for people
wanting to learn how to build uC projects without
the expense of buying something like an Arduino.
It's a book mostly about the 8 bit AVR uCs because
they are so popular and cheap and have a really good
free C compiler available.
I have started scribbling notes for a chapter of the
book that describes how to use the Propeller as
a powerful peripheral processor for handling video,
audio and precision timing chores. The Prop really
is great for this role! In fact, I wish Parallax would
sell pre-programmed 32kb eeproms already set up
to deliver the power of the Prop as a video/audio
engine to be used by simpler uCs like the ones I
am describing in this book...the Tiny85, 328p and
1284p.
It is so incredibly easy to make an AVR talk to a Prop
using I2C or even just a single pin. We should all pitch in
and design a 32kb eeprom stuffed full of goodness for
the users of lesser uCs. If this eeprom was made available
pre-programmed then they would not need to buy a programmer
to use the prop as a peripheral engine. They would not have to
learn any Spin or PASM. Many would eventually want to dig
deeper and would end up exposed to using the Prop not as
just a peripheral chip but as the heart of their projects.
Come on guys, this is a really good idea! :-)
Parallax could sell props at a discount paired with a pre-programmed
eeprom and include a free PDF describing its usage. And point to
some YouTube vids of it in action. Get some projects using it onto
Hack-A-Day and lots of people would see them.
EDIT: Oh, and maybe stick in Kye's incredible SD driver!
Imagine a lowly Tiny85 with access to graphics/audio and
Multi-GB SD cards...using just one of its 6 I/O pins.
Notes:
Approximate prices. Prop II price is unknown of course.
XS1 MIPS can go to 100 when 4 or less threads are used.
I have not counted Prop HUB ROM, COG RAM or XS-1 OTP.
Have now included the 64 pin X chip.
If anyone has corrections to the table please shout.
Again it looks as if Prop II is not going to be "Too little too late" even if the X guys jump ahead by a factor of two by the time the Prop II comes out.
Threads and cores are NOT the same. They share resources common resources, particularly in our case, cog ram!
Didn't we have this debate before?
For all intents and purposes threads and cores are the same given shared RAM.
In the single core X chips all threads can share a common RAM space. Just like Prop cores share HUB. With the same kind of round robin access timing. In both cases they allow for "event" driven programming rather than relying on interrupts.
As for the ROM space, from looking at the chip floor plan it still seems to me they are using a lot of space that could be better used for other interesting active functionality. Most ROM is not used most of the time in most apps.
I think you have an excellent idea. Little Prop boards with pre-programmed EEPROMs. You are not selling a Prop you are selling a video interface, or a terminal or a multi serial port adapter or sound synthesizer for use with Arduinos or whatever.
You know all these comparisons between different micros just prolong this tedious debate.
If people want to use Xmos or any other type of micros then that of course is great, just go and use it!
This is just like the Amiga vs Atari ST debate in the 90's, it too was a complete waste of energy and time.
This whole business of 'I wish Prop II had this' and 'I think it should have that' etc... totally pointless too, do you really think Chip et al will change the design now.
It seems we are complaining about / judging a device that doesn't even exist yet.
Put your creative efforts into something practical guys, you are all intelligent people and you are wasted on trivialities such as this.
Coley
@mods - this thread should be locked before it turns into another 'my chip is better than yours' style argument which have cluttered this forum for years.....
I agree with you. And RossH. However the question was asked so it got responses:)
In fact it was a very reasonable question so one had to put ones head up and look what the Prop II is up against.
A little friendly rivalry is not so bad from time to time. As long as we remember to keep a cool head and and an open mind. Recommend chips and solutions based on their suitability to tackle particular problems and applications and considering abilities of the users rather than some blind passion for the thing we happen to know most about. I like all chips, since I discovered TTL in 1970 something. (Well except for the Intel 286 of course:))
No, I don't expect Chip to be making big changes to his design now. In fact I hope all resource are focused on getting the thing done as it is (which I'm sure is the case). I think the Prop II is going to be excellent and as such I want it ASAP:)
Comments
PropII is only 40 MIPS per cog running C code (LMM, as per your post). That's less than half the speed of an X thread (assuming 4 per core). It's also vaporware at this point whereas the X chips are in production (I could as well say that a future X chip could raise the bar even higher, but I won't because it doesn't exist yet.)
The free X development tools support C, XC, and C++ along with JTAG debugging ($50) in an Eclipse IDE. Will Parallax themselves support such an integrated, seamless environment at launch, or will it be a matter of stitching together a bunch of third party tools (Catalina, PASD, ViewPort, etc.)?
(I didn't intend this discussion to digress into a Propeller vs. "X" debate, but someone did mention the multicore aspect of the Propeller implies that it doesn't need to support C in any meaningful way (at least that's how I interpreted it.))
I'd suspend the judgement until Kuroneko will get the new counters to jump in the flaming ring... or doing the laundry... or cooking diner
Seriously, I'm quite satisfied by the way the prop II is shaping up.
For normal control applications, 128KB is enough (probably 32KB was, in the majority of cases). The number of pins was more limiting.
For the retro and prop-os noisy cats... I think we just scratched the surface of speed improvements obtainable thru caching, partly because the authors of the two available solutions got "sidetracked" playing with hardware again
There isn't really an answer to that unless comparison with other existing and possibly future devices is made.
Yes, Leon, hopefully XMOS will also have moved on. Let's say they double their speed next year and or halve the chip cost, two cores for the current price of one. Who knows? Still the Prop II is standing up well.
Sal, why would make my comparison assuming I'm only using 4 of the available X threads? I have no such limitations in the Prop.
As you see from the Parallax Semiconductor threads Parallax is intent on having the same Eclipse IDE as XMOS and the same compiler (different back end of course) for C.
You might conclude that Prop II may end up a bit behind in the performance race. On the plus side a Prop II will always be a hundred times easier to work with than an XMOS.
"Too Little, Too Late" I don't think so.
I made the comparison using four threads because four threads have full performance (100 MIPS), while eight have only 50 MIPS each (although if what you say about the PropII running C via LMM is true, 50 MIPS is still better than 40 MIPS).
I'm glad to hear that Parallax is working on an Eclipse-based IDE. Will it have integrated debugging as well, or will it be like the current Prop tool (compiler and code downloader)?
What you say about the ease of use of XMOS is true from the perspective of a hobbyist, but not for a professional developer. I had a large chunk of Spin/PASM code from one of my projects ported to XC and running within hours of getting my first development board.
You are missing that for a comparable price you only get a single core XMOS device. Yes the Prop II could be said to be slower than some devices, most of witch were microcomputer CPUs first and integrated into MCUs later, and a couple of which have much higher price tags (including XMOS), this says a lot as the production quantity of the Prop II is expected to be significantly lower than the other MCUs.
How do you know what a PropII is going to cost? I haven't seen any price announcements yet, in fact I don't even think Parallax knows yet as they don't know what the production costs will be.
But it's got eight hardware threads, which are equivalent to eight cores, delivering a lot more MIPS than the Prop I. It costs about the same.
-Phil
Maybe the business goals that Parallax sets for themselves differ from the business goals that others set for them.
It is true that we won't have hardware debugging at the PASM level. The concurrency of things does limit the negative impact of that however. Seems to me, from what I've seen so far, implementing those debugging features could have a design impact, and must they be licensed? Would like somebody to answer that.
At the LMM level, couldn't "hardware like" debugging be implemented in the kernel?
The typical way hardware debugging is implemented is via JTAG (IEEE 1149.1) and, as far as I know, doesn't require a license fee.
In my opinion, the concurrency of cog execution makes hardware debugging more necessary, not less.
As for requiring more not less debugging, I see a strong case either way. How the programs are built impacts things. My own experience, both just writing my code, and working with others, seems to indicate more emphasis on program design methodology would deliver the biggest return. I think I'm going to stick with that for now. Again, my personal experience clearly shows investments there pay off huge.
Frankly, the chip is simple and consistent. We make as big of a mess as we choose to. Where there is a lot of complexity in the hardware, or said hardware is "buggy", or put a nicer way, not self-consistent, yeah a hardware level debugger makes good sense, because it's not always possible to know the behavior.
On props we do know the behavior, but for some pretty damn exotic cases, pushing the edge. So then, one has to ask the question why not build in ways that limit the unknowns? Fair question, don't you think?
I am a bit confused by some of your statements.
1) What can you do with those standard debugging interfaces that you can not do using a cog with a well designed debug routine (especially if the LMM of your C compiler cooperates)??
2) Are you anti-prop? Many of your arguments seem to suggest this.
Having hardware debug capability doesn't preclude or replace good program design in any way. This is not a zero sum thing.
This is one of the most ridiculous statements I've seen in a while. Hardware debug support isn't there because the hardware is buggy, it's there to debug software. When is it not always possible to "know the behavior" on other MCUs? The things are deterministic, period, with respect to instruction execution. Short of a bug in the chip, each instruction will have a consistent outcome.
Hardware debugging as implemented on MCUs let you do things such as set breakpoints, single step code, set hardware watchpoints (which trigger when the desired memory location is written or written with a specified data pattern). This is non-invasive to the software--you don't have to include special code in your code for it to work, like you do with ViewPoint and PASD, and you don't need to use the equivalent of a cog to do so. Check out the XMOS development tools for a very well-executed example of hardware debugging on a multi-core, multi-thread architecture.
Quite the contrary. I've used the Prop in several of my projects and will continue to do so. It makes a great I/O processor when coupled with something like an ARM Cortex-M3 to run the main application code (in C) that implements things like control algorithms, filters, etc.
Ross.
Ross.
I could not agree more. There always seem to be those that push 'X', and seem to think of the Propeller as a peripheral processor rather than a microcontroller.
We're comparing the Propeller with X, not necessarily pushing X, because of the similarities (both are multi-core processors with no built-in peripheral support).
And what's wrong with the Propeller as peripheral processor? There's even a chapter devoted to this topic in the "official" Propeller book.
Anyway, heater did the comparison, so would you please update the prices and add Prop 1 to your table. IIRC search the PropII threads and you will be pleasantly surprised that Parallax were aiming for under $12 (or less?) for the Prop II. Not sure if that is still valid or not.
Threads and cores are NOT the same. They share resources common resources, particularly in our case, cog ram!
Anyway, there will be lots we can do with the Prop II. Just that it will not do everything I/we would like. It doesn't really matter because there will be plenty of possibilities and there will be lots of flexibility in this design. Even something as simple of inverting pins by a single register saves code space and simplifies the code.
ROM space:I thought the latest specs indicated 32KB but perhaps from Beau's pic we may have 4x that??? Presuming 128KB ROM, then there is room for an additional 8x8 font. Full FAT16/32 drivers and SPI, I2C, FDX (maybe multiport because of extra speed). Because I don't have any inside info, I could speculate that perhaps the "Gold Objects" could be put into ROM.
Presuming only 32KB ROM (4 blocks of 8K --- has to be 4x blocks because of the quad long accesses) then if the 16x16 font was removed we recover a huge rom space for other things. IIRC there is no requirements for some of the tables because of cordic (which I know nothing about). This would free up enough space for a lot of objects plus perhaps floating point code.
If 128KB ROM, then by reducing to 32KB ROM would give us 96KB / 6 (sram requires at least 6x die space) = 16KB extra hub space. So 96KB ROM === 16KB SRAM die space. Let us ignore the problem of 36KB blocks of SRAM that cannot be as regular (efficient) as 32KB blocks for die space. Pretty big argument for gold objects to be in rom, even if not used. And if they prove to have bugs, well we can always load them. That is what Apple did with the Mac and look how well it worked for them. Anything in ROM does not preclude you making your own, but it does bring more standardisation.
Another comment is that Parallax is only a small private company that does not have the external pressures to make certain percentage profits. Chip & co have some very nice values and passions that you do not find in most (any?) corporations. They do not have to sell billions of chips, although that would be nice.
I'm putting together a free beginners book for people
wanting to learn how to build uC projects without
the expense of buying something like an Arduino.
It's a book mostly about the 8 bit AVR uCs because
they are so popular and cheap and have a really good
free C compiler available.
I have started scribbling notes for a chapter of the
book that describes how to use the Propeller as
a powerful peripheral processor for handling video,
audio and precision timing chores. The Prop really
is great for this role! In fact, I wish Parallax would
sell pre-programmed 32kb eeproms already set up
to deliver the power of the Prop as a video/audio
engine to be used by simpler uCs like the ones I
am describing in this book...the Tiny85, 328p and
1284p.
It is so incredibly easy to make an AVR talk to a Prop
using I2C or even just a single pin. We should all pitch in
and design a 32kb eeprom stuffed full of goodness for
the users of lesser uCs. If this eeprom was made available
pre-programmed then they would not need to buy a programmer
to use the prop as a peripheral engine. They would not have to
learn any Spin or PASM. Many would eventually want to dig
deeper and would end up exposed to using the Prop not as
just a peripheral chip but as the heart of their projects.
Come on guys, this is a really good idea! :-)
Parallax could sell props at a discount paired with a pre-programmed
eeprom and include a free PDF describing its usage. And point to
some YouTube vids of it in action. Get some projects using it onto
Hack-A-Day and lots of people would see them.
EDIT: Oh, and maybe stick in Kye's incredible SD driver!
Imagine a lowly Tiny85 with access to graphics/audio and
Multi-GB SD cards...using just one of its 6 I/O pins.
I up dated my original table and here it is again.
Cores RAM I/O Max H/W MIPS/Thread Price Pins Threads XS1-L1 1 64K 36 8 50 $7.5 XS1-L1 1 64K 64 8 50 $7.5 Prop II 8 128K 92 8 160 (40 MIPS LMM) $12 Prop I 8 32K 32 8 20 (4 MIPS ???) $8Notes:
Approximate prices. Prop II price is unknown of course.
XS1 MIPS can go to 100 when 4 or less threads are used.
I have not counted Prop HUB ROM, COG RAM or XS-1 OTP.
Have now included the 64 pin X chip.
If anyone has corrections to the table please shout.
Again it looks as if Prop II is not going to be "Too little too late" even if the X guys jump ahead by a factor of two by the time the Prop II comes out.
Didn't we have this debate before?
For all intents and purposes threads and cores are the same given shared RAM.
In the single core X chips all threads can share a common RAM space. Just like Prop cores share HUB. With the same kind of round robin access timing. In both cases they allow for "event" driven programming rather than relying on interrupts.
As for the ROM space, from looking at the chip floor plan it still seems to me they are using a lot of space that could be better used for other interesting active functionality. Most ROM is not used most of the time in most apps.
I think you have an excellent idea. Little Prop boards with pre-programmed EEPROMs. You are not selling a Prop you are selling a video interface, or a terminal or a multi serial port adapter or sound synthesizer for use with Arduinos or whatever.
If people want to use Xmos or any other type of micros then that of course is great, just go and use it!
This is just like the Amiga vs Atari ST debate in the 90's, it too was a complete waste of energy and time.
This whole business of 'I wish Prop II had this' and 'I think it should have that' etc... totally pointless too, do you really think Chip et al will change the design now.
It seems we are complaining about / judging a device that doesn't even exist yet.
Put your creative efforts into something practical guys, you are all intelligent people and you are wasted on trivialities such as this.
Coley
@mods - this thread should be locked before it turns into another 'my chip is better than yours' style argument which have cluttered this forum for years.....
I agree with you. And RossH. However the question was asked so it got responses:)
In fact it was a very reasonable question so one had to put ones head up and look what the Prop II is up against.
A little friendly rivalry is not so bad from time to time. As long as we remember to keep a cool head and and an open mind. Recommend chips and solutions based on their suitability to tackle particular problems and applications and considering abilities of the users rather than some blind passion for the thing we happen to know most about. I like all chips, since I discovered TTL in 1970 something. (Well except for the Intel 286 of course:))
No, I don't expect Chip to be making big changes to his design now. In fact I hope all resource are focused on getting the thing done as it is (which I'm sure is the case). I think the Prop II is going to be excellent and as such I want it ASAP:)
OK. So now back to that PASM coding....