Loopy said, Compared to the Propeller at 80Mhz, you still get 80MIPs per processor out of the SX and versus 20MIPs the Propeller. Seems slower. I believe that you can easily get a PIC to clock at 20Mhz and produce 20MIPs.
It's much faster. The prop is 20 x 8 for all eight cogs = 160 MIPs. The Pic is not multi-core. MIPs and MHz don't match in the prop, it's not a 1 to 1 relationship. MIPs is subjective based on the instruction from one to the next and from chip to chip. In special cases the prop runs at twice its specs.
Firstly, I'd like to say that I think the Propeller is a wonderful device.... in its own way.
But I do wonder why everyone wants to do 32bit floating point maths when often 16bit or 8bit integer math is enough for control. (This is an old issue and has been around since the 1970s - people just don't want to think in base two integer math for the sake of speed.)
What I didn't drag into the discussion were other brand processors that do indeed do 20Hhz, one clock 32bit instructions and have a lot of additional hardware. (I love the purity of having firmware do it rather than just buying features.)
But the bottom line is that UNLESS you are using all 8 cogs, you are not getting anywhere close to 160MIPs. Still, one does have to admit that the Propeller doesn't easily compare with anything else out there, and it looks as though we will one day get a 16 cog Propeller to ponder.
As it is, I have difficulty exploiting 8 cogs, so the SXes still appeal to me.
But I do wonder why everyone wants to do 32bit floating point maths
Funny you should say that, I'm just now hacking away on the C interface code for the float32 object for Zog.
Why am I doing this? Well, thing is Catalina has floating point support and C under Zog does not:)
I have said this here many times. My old boss would say "If you think you need floating point to solve the problem then you don't understand the problem".
At the time we had no floating point support in the hardware or the language, Coral 66, but Coral did support fixed point types. So it was a good lesson in doing without.
Mostly I think it just comes down to laziness:)
All this talk of MIPs is getting old.
Some other PIC, AVR, ARM may have more MIPs than a Prop. So what?
Can you configure that chip to provide 8 UARTs or more? Can you make a software defined radio receiver out of it? Does it have 32 general purpose I/Os I can use for whatever I like. etc etc etc.
Yeah, Heater has got it right. You can often get more done with one package with the Prop. And I suspect you can learn far more than you might with another vendor's product. There is a huge amount of creative insight gained by using something different.
Cheap dsPICs have been used for software-defined radios - much better ones than can be implemented with the Propeller. I don't know of any radio amateurs using the Propeller for an SDR.
The Propeller can demodulate an RF signal directly by setting up its counters to do I/Q detection. See: http://forums.parallax.com/showthread.php?t=105674 However, one would probably get better performance by pre-mixing to a constant IF frequency (say 10 MHz) that can be amplified and filtered more easily, then demodulated by the Prop. You would also get better image rejection, since the image frequencies are more widely separated from the fundamental and can be filtered out ahead of the first mixer stage.
If were not talking about the number of I/O's then in theory using all 32 IO's you could transfer data from one propeller to another propeller using one COG at 320 Million Bits per second
100ns for a 'fetch/move' = 10MHz ... times a 32 bit wide data buss = 320 Million Bits per second.
The bottle neck being the number of IO's ... supposing you had 256 IO's, then with 8 COGS you could in theory transfer 2 Billion 560 Million Bits per second. (320 Million times 8)
Beau, what happens in your example when a bit stream appears on pins 28/29 that correctly addresses the EEPROM? One could of course connect/disconnect the EEPROM with a mux.
Cheap dsPICs have been used for software-defined radios - much better ones than can be implemented with the Propeller. I don't know of any radio amateurs using the Propeller for an SDR.
It depends on how you define better. In this case, better is certainly not simple. But that does not answer the question, is there a multi-core pic? Besides, it only takes one wire to implement radio on the prop, and implement on the pic takes a whole gamut of circuitry involvement, even if internal. I believe there are radio amateurs using the prop for many uses, even if the use is not entirely sdr. Give it some time. The prop is new in this area. I'm sure we'll see more Software Defined Radio with the Prop in time. Why? As to the title of this thread, when you operate at electromagnetic radiation speeds, you are talking about light speed. There will surely be a bigger pipeline coming up in the future.
jazzed, Who said anything about having any EEPROM connected? :smilewinkgrin:
There are multiple ways to get past the EEPROM - F10 load a program and store it offline, and freeze and hold the states of the machine. I have never needed EEPROM in my Propeller test machine. Also designate one prop as the EEPROM memory master and hold it separate from the others.
It depends on how you define better. In this case, better is certainly not simple. But that does not answer the question, is there a multi-core pic? Besides, it only takes one wire to implement radio on the prop, and implement on the pic takes a whole gamut of circuitry involvement, even if internal. I believe there are radio amateurs using the prop for many uses, even if the use is not entirely sdr. Give it some time. The prop is new in this area. I'm sure we'll see more Software Defined Radio with the Prop in time. Why? As to the title of this thread, when you operate at electromagnetic radiation speeds, you are talking about light speed. There will surely be a bigger pipeline coming up in the future.
The Propeller radio implementation simply doesn't compare with software-defined radios implemented on other devices, such as the dsPIC. No special hardware is required in the dsPIC itself for an SDR, everything following the quadrature detector is done in software. I simply can't see how the Propeller can handle incoming RF over the HF band, at microvolt signal levels.
If were not talking about the number of I/O's then in theory using all 32 IO's you could transfer data from one propeller to another propeller using one COG at 320 Million Bits per second
100ns for a 'fetch/move' = 10MHz ... times a 32 bit wide data buss = 320 Million Bits per second.
The bottle neck being the number of IO's ... supposing you had 256 IO's, then with 8 COGS you could in theory transfer 2 Billion 560 Million Bits per second. (320 Million times 8)
Beau, wow, excellent! It sounds like 320 million bits per second using ONE cog is now the record for a single Propeller to Propeller setup.
I was also thinking of an active 3,200 IO's total with access to 800 cogs. Somehow these would need to be arrayed and networked to make a bus wider than 32 bits.
The Propeller radio implementation simply doesn't compare with software-defined radios implemented on other devices, such as the dsPIC. No special hardware is required in the dsPIC itself for an SDR, everything following the quadrature detector is done in software. I simply can't see how the Propeller can handle incoming RF over the HF band, at microvolt signal levels.
Leon is right about the Propller not being able to detect microvolt signal levels. But he's comparing apples with oranges: a Propeller that attempts to do everything from the antenna on (albeit poorly), with a dsPIC that starts from the baseband I and Q signals, after the RF has been amplified and down-converted. I think that the Propeller, given the same advantages of external circuitry, could match the dsPIC's performance in this app -- even without a MAC.
A propeller without a standalone boot mechanism is just a hobby toy.
Jazzed, It's good the Prop can stand alone and boot. But i f you really need a hobby toy, maybe you'll find a way so it cannot boot. But I cannot see why. What does this have to do with finding ways of making your propeller faster?
Leon is right about the Propller not being able to detect microvolt signal levels. But he's comparing apples with oranges: a Propeller that attempts to do everything from the antenna on (albeit poorly), with a dsPIC that starts from the baseband I and Q signals, after the RF has been amplified and down-converted. I think that the Propeller, given the same advantages of external circuitry, could match the dsPIC's performance in this app -- even without a MAC.
-Phil
Humanoido asserted that similar performance could be achieved with the Propeller without external hardware. That simply isn't feasible.
The RF isn't amplified by the QSD, it's just a switch. The dsPIC is much cheaper and easier to use in that sort of application. Has the Propeller got enough memory available?
The RF isn't amplified by the QSD, it's just a switch. The dsPIC is much cheaper and easier to use in that sort of application. Has the Propeller got enough memory available?
So you're saying that the dsPIC's 12-bit ADC is capable of detecting microvolt levels coming from the QSD? Can you cite a reference?
Leon said, Humanoido asserted that similar performance could be achieved with the Propeller without external hardware. That simply isn't feasible.
Leon, I did not want to imply that. Sorry if I did. I said, one wire radio, but no claim as to the performance. I never heard of the pic doing a one wire radio. Have you? (My second question). My 1st question, repeated, where is the multi-core pic?
I can build a radio receiver with a single transistor that will outperform one using a Propeller, FWIW.
Why would anyone want a multi-core PIC? They deliver plenty of performance from a single core - up to 40 MIPS from the 16-bit devices, and 60 MIPS is being worked on.
I didn't say it did. Most SDRs using dsPICs and other DSPs use stereo codecs, not built-in ADCs. They use them for output as well as input giving a two-chip solution, apart from the RF stuff.
Jazzed, It's good the Prop can stand alone and boot. But i f you really need a hobby toy, maybe you'll find a way so it cannot boot. But I cannot see why. What does this have to do with finding ways of making your propeller faster?
Not being stand-alone is good for code development or cases where other chips are doing the download (which makes development harder). It is possible to use other external devices to download the Propeller(s) which would use all 32 pins for Beau's "speed up".
As Beau said though, such a speed up it is theoretical. I would like to see a practical application of it if possible rather than watching someone blow smoke. Maybe you will find a way to demonstrate this?
We're going in circles here. You said, "No special hardware is required in the dsPIC itself for an SDR, everything following the quadrature detector is done in software," and, "the RF isn't amplified by the QSD, it's just a switch." These two statements combined make a specific claim for the dsPIC that it alone is able to handle microvolt-level signals without prior amplification. I want to know how. A specific citation would be appreciated.
Comments
It's much faster. The prop is 20 x 8 for all eight cogs = 160 MIPs. The Pic is not multi-core. MIPs and MHz don't match in the prop, it's not a 1 to 1 relationship. MIPs is subjective based on the instruction from one to the next and from chip to chip. In special cases the prop runs at twice its specs.
Humanoido
But I do wonder why everyone wants to do 32bit floating point maths when often 16bit or 8bit integer math is enough for control. (This is an old issue and has been around since the 1970s - people just don't want to think in base two integer math for the sake of speed.)
What I didn't drag into the discussion were other brand processors that do indeed do 20Hhz, one clock 32bit instructions and have a lot of additional hardware. (I love the purity of having firmware do it rather than just buying features.)
But the bottom line is that UNLESS you are using all 8 cogs, you are not getting anywhere close to 160MIPs. Still, one does have to admit that the Propeller doesn't easily compare with anything else out there, and it looks as though we will one day get a 16 cog Propeller to ponder.
As it is, I have difficulty exploiting 8 cogs, so the SXes still appeal to me.
Funny you should say that, I'm just now hacking away on the C interface code for the float32 object for Zog.
Why am I doing this? Well, thing is Catalina has floating point support and C under Zog does not:)
I have said this here many times. My old boss would say "If you think you need floating point to solve the problem then you don't understand the problem".
At the time we had no floating point support in the hardware or the language, Coral 66, but Coral did support fixed point types. So it was a good lesson in doing without.
Mostly I think it just comes down to laziness:)
All this talk of MIPs is getting old.
Some other PIC, AVR, ARM may have more MIPs than a Prop. So what?
Can you configure that chip to provide 8 UARTs or more? Can you make a software defined radio receiver out of it? Does it have 32 general purpose I/Os I can use for whatever I like. etc etc etc.
The RF is brought down to the "Audio" range of a sound card etc, and then DSP'd to recover the information.
-Phil
100ns for a 'fetch/move' = 10MHz ... times a 32 bit wide data buss = 320 Million Bits per second.
The bottle neck being the number of IO's ... supposing you had 256 IO's, then with 8 COGS you could in theory transfer 2 Billion 560 Million Bits per second. (320 Million times 8)
Who said anything about having any EEPROM connected? :smilewinkgrin:
The Propeller radio implementation simply doesn't compare with software-defined radios implemented on other devices, such as the dsPIC. No special hardware is required in the dsPIC itself for an SDR, everything following the quadrature detector is done in software. I simply can't see how the Propeller can handle incoming RF over the HF band, at microvolt signal levels.
I was also thinking of an active 3,200 IO's total with access to 800 cogs. Somehow these would need to be arrayed and networked to make a bus wider than 32 bits.
Beau how do you propose something useful as a standalone device would work with your suggestion?
-Phil
Humanoido asserted that similar performance could be achieved with the Propeller without external hardware. That simply isn't feasible.
The RF isn't amplified by the QSD, it's just a switch. The dsPIC is much cheaper and easier to use in that sort of application. Has the Propeller got enough memory available?
-Phil
Leon, I did not want to imply that. Sorry if I did. I said, one wire radio, but no claim as to the performance. I never heard of the pic doing a one wire radio. Have you? (My second question). My 1st question, repeated, where is the multi-core pic?
Why would anyone want a multi-core PIC? They deliver plenty of performance from a single core - up to 40 MIPS from the 16-bit devices, and 60 MIPS is being worked on.
You didn't answer my questions about the dsPIC.
-Phil
Most simple SDRs use codecs, with up to 24-bit resolution.
As Beau said though, such a speed up it is theoretical. I would like to see a practical application of it if possible rather than watching someone blow smoke. Maybe you will find a way to demonstrate this?
We're going in circles here. You said, "No special hardware is required in the dsPIC itself for an SDR, everything following the quadrature detector is done in software," and, "the RF isn't amplified by the QSD, it's just a switch." These two statements combined make a specific claim for the dsPIC that it alone is able to handle microvolt-level signals without prior amplification. I want to know how. A specific citation would be appreciated.
Thanks,
-Phil