IMHO some of the complaints people have about the Propeller are:
1. It's not a typical micoprocessor/microcontroller with an external memory bus & dedicated I/O, and a GCC port all ready to run Linux.
2. It doesn't meet their immediate requirements out of the box (or out of the ObEx). It's not plug & play, ready to go.
3. It can't accomplish their specific goals, because even with it's power & flexibility, there are still tasks which cannot be achieved within the Propeller's limitations of 32+16KB onboard RAM, and 8 20MIPS 32bit ALUs without hardware multiply, divide or floating point.
But, for those who are prepared to do some work and embrace the flexibility of software defined I/O, the Propeller is capable of some impressive results.
@idbruce, not to pick on you, but I suspect you are seeking the "one true answer" where there are multiple answers depending on the requirements. For some multi-Propeller projects as simple serial connection is all that is required. Each Propeller passes "messages" to the other which then are handled at the other end and changed into commands which are passed to the local cog drivers. But for others the number of Propellers or the application requirements means more complex interconnections and protocols are required. Consider the number of serial interfaces which exist for peripherals: RS-232, I2C, SPI, 1-wire, 802.3, USB, Firewire, PS2 and many more. Each designed to meet certain requirements.
So I did missed the special I/O hardware - because the functions are implemented in software!
So why is it invisible on Parallax site?
To insure Propeller future there needs to be a REAL technical and highly visible description of the product, kinda of „one click shopping“ style.
In past there were some articles on success stories. I have not seen them lately.(Or are they also burried on cluttered site?)
I hate to be blunt – but SPIN better spin away and fast.
PS I love my „speed demon „ SX“.
AA7EJ Vaclav
The perceived problems facing Propeller in commercial and industrial applications are well known and have all been previously discusssed -
Cost, not single-chip (needs Eeprom), slow boot time, no code protection, proprietary language (plus interpreted, slowish), no native "C", no interactive debugger, Windows-only official tools, novel architecture, and (for some) no hardware ADC.
The biggest obstacle by far though is the users; engineers and management. If they can grasp it, see its utility then none of the above may matter. If they don't, or the issue are enough to them to legitimately cross it of their list, then they won't use it. You can explain it, try to open their eyes, but you can't force a solution onto people which they stubbornly refuse to accept.
On the other hand, that's no reason for Parallax to change what they do just to get commercial acceptability on a wider scale. If Parallax wanted a commercially competing product they'd probably have designed an ultra-efficient C-supporting chip. Instead they designed something else which has its own unique selling points.
I've said before that I don't understand this obsession over Parallax having to compete with the 'big boys of the semi industry', having to command a massive commercial market, or this being necessity in any way, for Parallax or users. There's nothing to be ashamed of with what they have. No, it's not something else, it's a Propeller.
Do people worry and fret that their superb local restaurant isn't a franchise as large as McDonalds ?
One of the main thoughts I see in the replies is lack of documentation. Is anyone interested in starting a Prop Wiki? Everyone can share what they know, and articles can be written in any method (from a simple "how-to" to high-level theory and practice).
I can't speak for everyone, but I think a lot of people want it all to be Parallax based, instead of Wiki. Everyday that this forum exists, the documentation gets better. And I truly believe that Parallax will pull through for us and provide us with the much needed documentation. I believe from here on in, it is just a matter of patience and perhaps some fresh ideas on what kind of documentation would really be helpful.
Maybe someone could add a link to the GG Tutorials in the STICKY: Propeller / Hydra key index - Getting Started. For those newer Propeller users that don't know of them.
I would really like to see some of that stuff on the wiki there, for example the interface section. A ton of those links do not work anymore unfortunately.
The wiki does need some pointers to the vast amount of info stored elsewhere. Often the wiki is the first port of call but that does not mean it has to contain all the info, just valid links.
I will always have fond memories of the prop.
It was my first real experience in multi-core
programming....and that alone was worth far more
than the price of admission. :-)
The prop2 should have more commercial success
than the prop1. I tried hard to get the prop1 used in
projects but only managed to move a few hundred of them.
The hard sell was partly because I was the only one that was
able to program them in spin and pasm. I basically
made the prop a black-box that could be controlled
by another processor that the other guys could work
with. IMO the prop1's best use is as a powerful uc that
can be easily added to a project to handle video, audio and
anything that needs really precise timing.
I made a tool using just a prop and a few cheap parts that
allowed for easy debugging of several pretty advanced
systems. The prop was contained in a small case with
a vga cable coming out one end and several leads with
clips out the other side. The prop analyzed the data from the
test leads and determined by the nature of that data what device
it was connected to and then displayed the analysis of the data
on a vga monitor. It could make changes to the flash memory
of the processors in the external devices if needed...this cheap
little gizmo saved an enormous amount of time and the few that
I originally built became so scarce that they ended up making
a small production run of the things. The only lead that had to
be connected to a specific point was the ground lead..the rest
were interchangeable and the prop figured out what lead was
connected where by looking at the signals it was getting.
IMO there are many such inexpensive and relatively simple
tools that the prop could be the heart of....there is $ to be made
in this :-)
Sort of true. Do you mean multi-tasking or parallel processing? Pretty much all embedded systems I have worked on used multi-tasking either as actual tasks defined in some operating system or just as interrupt handlers firing of at regular intervals or on demand.
If you were meaning "parallel processing" I think that is somewhat missing the point. The Prop is not actually designed as a high speed parallel processor.
Rather what all those parallel running COG gives you is the flexibility to have enormous choice in the combinations of peripherals you can use for any particular job. Because those peripherals are defined by the software loaded into COGs rather than actual silicon hardware it becomes possible to support all kinds of hardware configurations whilst only having to think about, purchase, stock a single device.
This I think is a great benefit when prototyping different embedded systems or manufacturing low quantities of many different products. One does not have to worry that that particular AVR or PIC with the features you need for a particular product is going go out of production and trigger a product redesign.
I will answer your question with a very authorive "I don't know" ;-) In other discussions about the prop, I have noticed I don't utilize it like the majority of folks here. I am so narrow minded that I don't really consider how the the cogs are a like software configurable peripherals. Working soley on motion control application, I enjoy the parallel processing that the COGs provide. In my previous attempts at a motion control system, my system ended up with numerous micros (Atmels) all communicating with each other while they performed parallel processing. When I discovered the Prop, I realized that having all the "micros" in one package could save me a ton of time which was wasted in chip-to-chip communications. While I certainly didn't mind working with interrupts with the Atmels, I do like the way all cogs are working at the same time resulting in more efficient throughput.
So for me to determine if I am using it as muli-tasking or parallel processing, I consider it both in my application.
I see your point about the single-chip stocking as it is so flexible due to the software configuration of the peripherals.
No matter how you see it or look at it, it is an amazing device!
Do people worry and fret that their superb local restaurant isn't a franchise as large as McDonalds ?
Some: Yes. They want to have a singular experience everywhere and over and over.
The propeller kicks you first time you touch him right and you only wanna be dirty!
Thinking about the future of the Prop, I have just realized that there is one thing I have been thinking about backwards.
We, or at least I, have been looking forward to having an easier way to add external RAM to the Prop II, thus making it more attractive for programming "in the large" with tools such as Catalina and Zog for C or for something like "big spin". This "making it easier" implies having a bunch more I/O pins to use for data/address buses whilst having pins spare for real I/O plus possibly some logical assistance to drive the bus built into the Prop.
I'm now thinking this is looking at the situation backwards.
My new proposal is:
1) The Prop has pins that can be used as address/data bus BUT rather than the bus being for driving external RAM from the Prop it is used to enable some external CPU, an ARM say, to access the HUB memory directly.
2) Basically the external Processor sees the Prop as a RAM device.
3) Access to the HUB from the external bus is interleaved, by the HUB, with the normal round robin access cycle of the COGs.
4) So the external CPU can become an "external COG".
With that it place the Prop II, or III or what, would become a brilliant, flexible, inteligent I/O device for any other processor, an ARM say. The "external cog" then takes care of the large wodges of application code and the Prop does what it does best, the real-time deterministic stuff. Forget trying to make the Prop into a general purpose CPU which it is not.
I'm sure it's to late to consider such things for the Prop II but we can day dream can't we?
Very interesting idea, Heater! The hub negotiation could be handled via a WAIT output from the Prop. But do modern microprocessors still know what to do with a WAIT input? There would also have to be a way to access the Prop's lock mechanism.
I was just starting to think I was being a bit off the wall.
I have no idea about bus interfaces on modern processors like ARM etc. Even without a WAIT there must be some way to organize getting data in and out of HUB from an external processor. After all it must be done all the time with peripheral devices perhaps via some DMA mechanism.
I like Heaters idea. Some of the PIC chips (16F877 comes to mind) have a mode where 8 pins are used for I/O and a few other pins are for a R/W signal or something along those lines.
Maybe in the short term a solution which uses a cog to act as the external access controller would be useful for proof of concept.
Maybe in the short term a solution which uses a cog to act as the external access controller would be useful for proof of concept.
Yes indeed, we can do that already. But it does waste a cog for a simple bus controller, and the bandwidth is poor. You have to shunt data into the COG under software control and then out of that COG into HUB where it finds it's way to some other COG.
One could have a clocked I/O system as used by XMOS where data is clocked into and out of a FIFO. From the other end of the FIFO it gets clocked into HUB.
I was fishing for an ultra simple to use scheme to introduce a ninth "ghost COG" which is actually an external CPU.
No doubt that having direct external access to the Hub RAM would be best, but like you said, probably too late to even hope for that on Prop II.
Speaking of the clocked I/O, I'd love to see some shift registers on Prop II that would allow faster SPI emulation than we can currently achieve, I haven't really seen those mentioned in any of the Prop II threads.
Even with direct access, you'd have to sacrifice a cog to get external access into the normal rotation. Otherwise, the hub RAM would have to be multi-port, which would not only increase its die size but complicate data arbitration, since the hub memory could be altered asynchronously.
I think the prop 1 chip is great for certain applications, to really get into the mass market Parallax
needs to get the Prop II finished.
One thing that would really help Prop 1 designs would be a fast Pasm Fat32 SD Card driver.
Mike G. & Rayman have done a great job with there utilities but they use up allot of precious
memory. I have noticed that most Prop1 projects use an SD card so this would be very useful
for all of us.
Other useful objects would be fast serial and I2C drivers that will run with the 6.25 MHz crystal.
I was wondering about that. I imagined an external "phantom" COG that access HUB RAM via the HUB commutator. Thus it's access would be in sync with the normal HUB cycles BUT there would be 9 steps around the cycle rather than 8.
That HUB access performance hit is probably not acceptable so perhaps one COG would be dropped and the "phantom" COG takes its place. An approach I really don't like.
So that leaves us with:
1) The external CPU driving the bus.
2) The external bus being handled by a COG as it might be done now.
3) BUT lets have some logic assistance in silicon to turbo charge it.
Perhaps some of that is already on the drawing board, who knows?
As an alternative, the external access could be shared with one of the cogs, with the cog having priority so determinism is preserved. The external bus would be granted access only if there was not a request pending from the shared cog.
BigFoot,
Kye's FAT32 SD card drivers are very well written and fast, much faster than the one I wrote. All of the I2C drivers I've written are independent of the system clock frequency. They should run fine at 6.25MHz (100MHz). Pretty much all of the serial drivers will also work fine at that speed. Sphinx is an operating system for the Prop 1 that includes a Spin compiler / assembler. Its SD card I/O only supports FAT16, but that's good for up to 2GB cards.
Sphinx has the advantage that all of its I/O drivers are loaded into cogs so there's very little hub memory required for I/O freeing up most of the 32K for the Spin program.
Excellent idea, you've cracked it. Someone call Chip.
Now, why can't said bus, driven by the external CPU, share HUB access with ALL the COGs such that if any COG is not using HUB memory during it's time slot then the external processor is granted access.
This has the startling result of giving a higher bandwidth into HUB memory for the external processor than any of the COGs!
Now, why can't said bus, driven by the external CPU, share HUB access with ALL the COGs such that if any COG is not using HUB memory during it's time slot then the external processor is granted access.
It's a nice idea, but the Prop II design is at a point where very little can be changed without causing large delays and expenses, particularly something like this that would require new data paths.
Comments
1. It's not a typical micoprocessor/microcontroller with an external memory bus & dedicated I/O, and a GCC port all ready to run Linux.
2. It doesn't meet their immediate requirements out of the box (or out of the ObEx). It's not plug & play, ready to go.
3. It can't accomplish their specific goals, because even with it's power & flexibility, there are still tasks which cannot be achieved within the Propeller's limitations of 32+16KB onboard RAM, and 8 20MIPS 32bit ALUs without hardware multiply, divide or floating point.
But, for those who are prepared to do some work and embrace the flexibility of software defined I/O, the Propeller is capable of some impressive results.
@idbruce, not to pick on you, but I suspect you are seeking the "one true answer" where there are multiple answers depending on the requirements. For some multi-Propeller projects as simple serial connection is all that is required. Each Propeller passes "messages" to the other which then are handled at the other end and changed into commands which are passed to the local cog drivers. But for others the number of Propellers or the application requirements means more complex interconnections and protocols are required. Consider the number of serial interfaces which exist for peripherals: RS-232, I2C, SPI, 1-wire, 802.3, USB, Firewire, PS2 and many more. Each designed to meet certain requirements.
So why is it invisible on Parallax site?
To insure Propeller future there needs to be a REAL technical and highly visible description of the product, kinda of „one click shopping“ style.
In past there were some articles on success stories. I have not seen them lately.(Or are they also burried on cluttered site?)
I hate to be blunt – but SPIN better spin away and fast.
PS I love my „speed demon „ SX“.
AA7EJ Vaclav
Cost, not single-chip (needs Eeprom), slow boot time, no code protection, proprietary language (plus interpreted, slowish), no native "C", no interactive debugger, Windows-only official tools, novel architecture, and (for some) no hardware ADC.
The biggest obstacle by far though is the users; engineers and management. If they can grasp it, see its utility then none of the above may matter. If they don't, or the issue are enough to them to legitimately cross it of their list, then they won't use it. You can explain it, try to open their eyes, but you can't force a solution onto people which they stubbornly refuse to accept.
On the other hand, that's no reason for Parallax to change what they do just to get commercial acceptability on a wider scale. If Parallax wanted a commercially competing product they'd probably have designed an ultra-efficient C-supporting chip. Instead they designed something else which has its own unique selling points.
I've said before that I don't understand this obsession over Parallax having to compete with the 'big boys of the semi industry', having to command a massive commercial market, or this being necessity in any way, for Parallax or users. There's nothing to be ashamed of with what they have. No, it's not something else, it's a Propeller.
Do people worry and fret that their superb local restaurant isn't a franchise as large as McDonalds ?
Fresh stuff is going up here.. http://www.gadgetgangster.com/tutorials.html
OBC
I can't speak for everyone, but I think a lot of people want it all to be Parallax based, instead of Wiki. Everyday that this forum exists, the documentation gets better. And I truly believe that Parallax will pull through for us and provide us with the much needed documentation. I believe from here on in, it is just a matter of patience and perhaps some fresh ideas on what kind of documentation would really be helpful.
Bruce
Maybe someone could add a link to the GG Tutorials in the STICKY: Propeller / Hydra key index - Getting Started. For those newer Propeller users that don't know of them.
Ron
I'm going to do one better.. A new list is being developed and will replace the one currently here:
http://software.propellerpowered.com
OBC
It was my first real experience in multi-core
programming....and that alone was worth far more
than the price of admission. :-)
The prop2 should have more commercial success
than the prop1. I tried hard to get the prop1 used in
projects but only managed to move a few hundred of them.
The hard sell was partly because I was the only one that was
able to program them in spin and pasm. I basically
made the prop a black-box that could be controlled
by another processor that the other guys could work
with. IMO the prop1's best use is as a powerful uc that
can be easily added to a project to handle video, audio and
anything that needs really precise timing.
I made a tool using just a prop and a few cheap parts that
allowed for easy debugging of several pretty advanced
systems. The prop was contained in a small case with
a vga cable coming out one end and several leads with
clips out the other side. The prop analyzed the data from the
test leads and determined by the nature of that data what device
it was connected to and then displayed the analysis of the data
on a vga monitor. It could make changes to the flash memory
of the processors in the external devices if needed...this cheap
little gizmo saved an enormous amount of time and the few that
I originally built became so scarce that they ended up making
a small production run of the things. The only lead that had to
be connected to a specific point was the ground lead..the rest
were interchangeable and the prop figured out what lead was
connected where by looking at the signals it was getting.
IMO there are many such inexpensive and relatively simple
tools that the prop could be the heart of....there is $ to be made
in this :-)
I will answer your question with a very authorive "I don't know" ;-) In other discussions about the prop, I have noticed I don't utilize it like the majority of folks here. I am so narrow minded that I don't really consider how the the cogs are a like software configurable peripherals. Working soley on motion control application, I enjoy the parallel processing that the COGs provide. In my previous attempts at a motion control system, my system ended up with numerous micros (Atmels) all communicating with each other while they performed parallel processing. When I discovered the Prop, I realized that having all the "micros" in one package could save me a ton of time which was wasted in chip-to-chip communications. While I certainly didn't mind working with interrupts with the Atmels, I do like the way all cogs are working at the same time resulting in more efficient throughput.
So for me to determine if I am using it as muli-tasking or parallel processing, I consider it both in my application.
I see your point about the single-chip stocking as it is so flexible due to the software configuration of the peripherals.
No matter how you see it or look at it, it is an amazing device!
Chris
Some: Yes. They want to have a singular experience everywhere and over and over.
The propeller kicks you first time you touch him right and you only wanna be dirty!
We, or at least I, have been looking forward to having an easier way to add external RAM to the Prop II, thus making it more attractive for programming "in the large" with tools such as Catalina and Zog for C or for something like "big spin". This "making it easier" implies having a bunch more I/O pins to use for data/address buses whilst having pins spare for real I/O plus possibly some logical assistance to drive the bus built into the Prop.
I'm now thinking this is looking at the situation backwards.
My new proposal is:
1) The Prop has pins that can be used as address/data bus BUT rather than the bus being for driving external RAM from the Prop it is used to enable some external CPU, an ARM say, to access the HUB memory directly.
2) Basically the external Processor sees the Prop as a RAM device.
3) Access to the HUB from the external bus is interleaved, by the HUB, with the normal round robin access cycle of the COGs.
4) So the external CPU can become an "external COG".
With that it place the Prop II, or III or what, would become a brilliant, flexible, inteligent I/O device for any other processor, an ARM say. The "external cog" then takes care of the large wodges of application code and the Prop does what it does best, the real-time deterministic stuff. Forget trying to make the Prop into a general purpose CPU which it is not.
I'm sure it's to late to consider such things for the Prop II but we can day dream can't we?
-Phil
I was just starting to think I was being a bit off the wall.
I have no idea about bus interfaces on modern processors like ARM etc. Even without a WAIT there must be some way to organize getting data in and out of HUB from an external processor. After all it must be done all the time with peripheral devices perhaps via some DMA mechanism.
Maybe in the short term a solution which uses a cog to act as the external access controller would be useful for proof of concept.
C.W.
Yes indeed, we can do that already. But it does waste a cog for a simple bus controller, and the bandwidth is poor. You have to shunt data into the COG under software control and then out of that COG into HUB where it finds it's way to some other COG.
One could have a clocked I/O system as used by XMOS where data is clocked into and out of a FIFO. From the other end of the FIFO it gets clocked into HUB.
I was fishing for an ultra simple to use scheme to introduce a ninth "ghost COG" which is actually an external CPU.
No doubt that having direct external access to the Hub RAM would be best, but like you said, probably too late to even hope for that on Prop II.
Speaking of the clocked I/O, I'd love to see some shift registers on Prop II that would allow faster SPI emulation than we can currently achieve, I haven't really seen those mentioned in any of the Prop II threads.
C.W.
-Phil
needs to get the Prop II finished.
One thing that would really help Prop 1 designs would be a fast Pasm Fat32 SD Card driver.
Mike G. & Rayman have done a great job with there utilities but they use up allot of precious
memory. I have noticed that most Prop1 projects use an SD card so this would be very useful
for all of us.
Other useful objects would be fast serial and I2C drivers that will run with the 6.25 MHz crystal.
I was wondering about that. I imagined an external "phantom" COG that access HUB RAM via the HUB commutator. Thus it's access would be in sync with the normal HUB cycles BUT there would be 9 steps around the cycle rather than 8.
That HUB access performance hit is probably not acceptable so perhaps one COG would be dropped and the "phantom" COG takes its place. An approach I really don't like.
So that leaves us with:
1) The external CPU driving the bus.
2) The external bus being handled by a COG as it might be done now.
3) BUT lets have some logic assistance in silicon to turbo charge it.
Perhaps some of that is already on the drawing board, who knows?
-Phil
Kye's FAT32 SD card drivers are very well written and fast, much faster than the one I wrote. All of the I2C drivers I've written are independent of the system clock frequency. They should run fine at 6.25MHz (100MHz). Pretty much all of the serial drivers will also work fine at that speed. Sphinx is an operating system for the Prop 1 that includes a Spin compiler / assembler. Its SD card I/O only supports FAT16, but that's good for up to 2GB cards.
Sphinx has the advantage that all of its I/O drivers are loaded into cogs so there's very little hub memory required for I/O freeing up most of the 32K for the Spin program.
Excellent idea, you've cracked it. Someone call Chip.
Now, why can't said bus, driven by the external CPU, share HUB access with ALL the COGs such that if any COG is not using HUB memory during it's time slot then the external processor is granted access.
This has the startling result of giving a higher bandwidth into HUB memory for the external processor than any of the COGs!
Now we have an excellent smart peripheral device.
-Phil
C.W.
How do we get Chip on board?