re:Heck if it's only 10 percent of the Pi owners out there who are interested in such things then it still huge an audience of 500,000.
That suggests that there are 5 million Pi owners. We know that there have been over 5 million Pi's sold however, Pi's sold and the # of Pi owners are two different things. How many Pi owners have 2,3,4, 5 etc Pi's which would really cut down the over all number of Pi owner's . Personally I have 2 original model B Pi's and 1 Raspberry Pi 2.
The Rpi is a natural fit for the Prop and Parallax should have had rolled out a interface board when sales hit a million. Associating the Rpi with the Prop is a easy no brainer to gain sales and visibility, Even if the sales were only a hundred thousand units, that's still a lot, not to mention getting the Parallax brand out there.
Parallax was a natural fit to supply the niche. They are a educational VAR that could provide the hardware, software, supposrt and project tutorials for such a project.
They should have jumped at it.
Markaeric:
The reason IO is so small on the Rpi because there wasn't anything available at the time of the launch and almost a year into it when Eben rolled out the AVR IO board. Even then it cost a lot more than the PI and you had to put it together. It was a bad deal that hampered Rpi's use for IO work. That really worked against it. Software was another issue, also a lack of books to support real world experimentation with the Prop.
"Tiny niche" even it's just 100,000 or so, that's still a lot, even for a mid-sized company. Maybe Parallax sitting on a massive pile of money and can afford to blow off purchasers who aren't buying at least a quarter million Props at a time. I know I certainly wouldn't turn my nose up at selling 100k worth of mcu boards even if I only made a $2 off each one. Most companies would fire a sales rep who would lose a sale like that.
Speaking from my own experiences, I'm now using a Raspberry Pi in my projects whenever feasible whereas I used to use a propeller. Being able to program in python and having an entire Linux environment is quite handy. The place where the propeller has come in handy is when I needed to do real-time IO. I had a recent Christmas project where I controlled a half dozen addressable LED strands. To implement the timing necessary to do that on the Pi by bit banging out the GPIO would have been a pain. Instead, I dedicated a cog on a prop to each strand of lights, and controlled the prop via serial from the Pi. Quick, easy, and reliable.
A "propeller hat" for the Pi would have been very convenient. I planned to take the time to lay out such a PCB post-Christmas. My current solution is build on a propeller proto-board with both the pi and proto-board jammed into a parallax plastic case, and while a little ungainly in appearance, it works just fine.
I think there's a great opportunity for the Prop to provide real-time IO capabilities to Pi users.
A "propeller hat" for the Pi would have been very convenient. I planned to take the time to lay out such a PCB post-Christmas. My current solution is build on a propeller proto-board with both the pi and proto-board jammed into a parallax plastic case, and while a little ungainly in appearance, it works just fine.
I think there's a great opportunity for the Prop to provide real-time IO capabilities to Pi users.
There are already 2 Propeller hats for Raspberry Pi:
Maybe you can save yourself a little time and effort unless you just really want to build your own.
Thanks. That pimoroni one looks like a particularly interesting design, with some prototyping space. That would have been a cleaner implementation for me. I'm tempted to grab a couple to have on hand for the next project that comes along.
I hope I am not crashing the party, but I want to go back... way, way back (sarcasm intended). To the forum topic. Code compatibility on the Prop2, to me, is not 100% mandatory, but I am really liking Spin on the Prop1 and am warming up to PASM. SPIN is fun and Chip has fun doing what he does for a living. His hardware and programs show it. If the Prop2 is going to deviate from code compatibility on the Prop1 to the extremes, I (one little endian) will hold off on investing on the new chip (at least for a while). C, talking to a PI, getting a bigger audience, might be good for the company, which is absolutely fine with me, but I am so happy with learning on Prop 1 and the uniqueness of the architecture it has. I guess I can be a bit of a contrarian and an outlier; maybe, just maybe, there are more of me out there.
On the Pi com topic:
I have computers. I have too many computers. I don't want a Pi, because it is another computer, albeit small and cheap. Sure, the Prop may work well with PI, but how much does that really matter to the educational market, and people like me. When I see Pi and hear about Pi, it is revolving around the fact that it is a small computer and can do things that computers can do, but small and cheaper. The argument about them being thought of as HTPCs is along these lines.
To those who are scolding the company in this forum:
If you think there is so much more money to be made on marrying two brands, cash in on it somehow and stop whining on the forums.
I like the brand and am excited about what the P2 has to offer, but again, C is not what would sell it to -me- (nobody special). I also hope the company prospers and has much more growth in the dev and educational community. The talk about a lack of feedback could be somewhat warranted, but again, it makes no difference on my purchases from Parallax. Chip is braining away with his brains. He is running the development, he will communicate when something important happens.
... Code compatibility on the Prop2, to me, is not 100% mandatory, but I am really liking Spin on the Prop1 and am warming up to PASM. ...
If the Prop2 is going to deviate from code compatibility on the Prop1 to the extremes, I (one little endian) will hold off on investing on the new chip (at least for a while).
Code compatibility means many things.
* Binary Compatible, the P2 is not.
* C-code Compatible, we can expect so, eventually..
* Spin-code Compatible, we can expect so, probably sooner than C.
* PASM Compatible - clearly not 100%, but there will hopefully be enough common ground (& things like conditional ASM controls and macros ) that porting PASM is not too onerous.
It is technically possible, with conditional ASM controls and macros, to have one source file target both CPUs.
re: I have no experience with Pimoroni yet. It is someplace between England and my mailbox.
Why don't you start a new thread about it . I'll have a look the Pi/ Prop software the Propeller Hat uses and try to use it with the Propeller Professional Development Board PDB
Invent-O-Doc, It has been done already ! (read ErNa's post above)
It has three versions 16-cog Low-power, Usb and Gigabit-Ethernet. Each of the three versions can have integrated Flash or not (without flash). A lot of packages to choose: TQFP-64 (for L and U versions), TQFP-128 and FBGA-236 (for all versions), FBGA-324 (U and E versions). No specs on clock but seems near 500 MHz. I wonder which process technology they have used (65nm or below?). They have a weird X... name on it. And it seems that they get serveral millions US$ from Xilinx, Huawei an Bosch. They have a really nice product brief PDF in which they explain how bad the interrupts are, how good they are doing real-time and deterministic responses, and why engineers have been doing this because there was no other choice ... eh! Wait a moment this is not ...
Sometimes I know: If someone understood what I said, I didn't express myself correctly.
A relation may be bear to bear, beer to beer, peer to peer (onetwoone) or one to many or manytoone or manytomany. If it happens you stand inline with a howitzer, it matters on which side you stand.
There is a xmos chip (the one) and there are a lot of engineers (the many) which in the end are all competing. Parallax offers a chance: there is an engineer (the one) who created an unique solution based on the P2 and as this solution succeeds, he will find a lot of Px (the many), which will evolve. xmos doesn't create a ecosystem, but wants to be part of an ecosystem.
xmos doesn't create a ecosystem, but wants to be part of an ecosystem.
Err, seems to me that company is rather successfully making its own ecosystem. Support from one of the world's larger firms, with a 26M equity infusion. Smartpins may offer something unique, however 16-core at 500Mhz with USB2 Phy at 4.75/unit in quantity would seem to be market dominating in the interrupt-less market.
I'm confused. Does the xCORE-200 have 16 cores or 16 'cores'?
Not 100% certain since the available data is somewhat less than clear but it sounds like the 16 "cores" are actually 2 cores that can execute 8 threads each using hardware to switch between threads.
I'm confused. Does the xCORE-200 have 16 cores or 16 'cores'?
Pay attention to the MIPS number. They quote 2000 MIPS @ 500 MHz, so that means 4 cores.
However, they also have (16) 125 MIPS 'cores', and you can mix them how you want, so you can have (2) 500 MIPS + (8) 125 MIPS or (1) 500 MIPS + (12) 125 MIPS. They are hardware isolated threads, and 125 MIPS is pretty good.
I prefer programming the prop, and I prefer the package and available boards for the prop, but I have to admire the brute hardware of the xmos.
It's 8 threads, "logical cores", per physical core. That particular example is just 2 physical cores. They have a bad habit of not making any distinction between a physical core and their so called logical cores. In fact I suspect they even go as far as not even making a distinction between the whole chip and physical cores either.
As per page 2 of the architecture flyer - https://www.xmos.com/published/xcore-architecture-flyer?secure=1
Execution rate is 5 clock cycles per instruction with no sequential overlap and therefore no blocking nor flushing of the pipeline is ever needed. However, to completely fill the pipeline, a full 5 threads must be concurrently fetching instructions. Anything less and rated MIPS is not achieved.
No one task can execute faster than 1/5 of clock rate.
As per page 2 of the architecture flyer - https://www.xmos.com/published/xcore-architecture-flyer?secure=1
Execution rate is 5 clock cycles per instruction with no sequential overlap and therefore no blocking nor flushing of the pipeline is ever needed. However, to completely fill the pipeline, a full 5 threads must be concurrently fetching instructions. Anything less and rated MIPS is not achieved.
No one task can execute faster than 1/5 of clock rate.
So they are still stuck at 100 MIPS with now up to 5 allowed, before cross-thread ('illogical core') impact kicks in.
With the claimed 64b fetch, you would expect more gain than they have ?
The ability to slot-map the tasks sounds great, and something that was talked about for P2.
That is two cores each implementing 8 hardware scheduled threads. Notice how on that little diagram they label the threads as "logical cores". It's a marketing scam to casually refer to them as cores elsewhere.
@altosack
Pay attention to the MIPS number. They quote 2000 MIPS @ 500 MHz, so that means 4 cores.
This calculation is not so simple in XMOS land.
A single tread on a single core will run at full speed (half or quarter clock rate, I forget, it may have changed with the new models)
A second thread on a core will run at the same speed again. As will three and four threads. This works out nicely because instructions from all those threads are streamed through the four stage pipeline and make maximum use of the hardware.
But, add that fifth thread, there are no more free slots in the pipeline and all threads are slowed down to accommodate it. Slower again for the sixth and seventh threads.
By the time we get to 8 threads they are all executing a one half the speed of that original single thread.
Why, because it's one core not eight.
Notice how the speed of a thread is influenced by how many threads are running, once you get to 4 and above. This breaks determinism in terms of calculating execution time by instruction counting. This is not such a big deal on XMOS as the dev tools can give you timing reports at compile time.
Edit: Seems the pipe lining and thread interleaving may have changed a bit with recent XMOS chips. Still the gist of my discussion above is true I believe. I'll have to get some of these new XMOS devices and check this out.
On that page they have "The xCORE-200 explorerKIT also features a 3D accelerometer, a 3-axis gyroscope " and then later in the feature list "3D Accelerometer and magnetometer". I wonder which it is.
Edit: Seems the pipe lining and thread interleaving may have changed a bit with recent XMOS chips. Still the gist of my discussion above is true I believe. I'll have to get some of these new XMOS devices and check this out.
Yeah, they seem to have decided that 5 stages, with two execute, is a better timing spread. Presumably when they were trying to maximise the clock rate. Funnily, Chip has come to the same conclusion.
There is mention of a dual instruction fetch also, hence the listed doubling of MIPS, but there seems to be some restriction on use, though, because they still list the single fetching as normal.
With the availability of the new version of xTIMEcomposer Studio, the xCORE Timing Analyser can be used to check execution times using the new devices.
Comments
That suggests that there are 5 million Pi owners. We know that there have been over 5 million Pi's sold however, Pi's sold and the # of Pi owners are two different things. How many Pi owners have 2,3,4, 5 etc Pi's which would really cut down the over all number of Pi owner's . Personally I have 2 original model B Pi's and 1 Raspberry Pi 2.
The Rpi is a natural fit for the Prop and Parallax should have had rolled out a interface board when sales hit a million. Associating the Rpi with the Prop is a easy no brainer to gain sales and visibility, Even if the sales were only a hundred thousand units, that's still a lot, not to mention getting the Parallax brand out there.
Parallax was a natural fit to supply the niche. They are a educational VAR that could provide the hardware, software, supposrt and project tutorials for such a project.
They should have jumped at it.
Markaeric:
The reason IO is so small on the Rpi because there wasn't anything available at the time of the launch and almost a year into it when Eben rolled out the AVR IO board. Even then it cost a lot more than the PI and you had to put it together. It was a bad deal that hampered Rpi's use for IO work. That really worked against it. Software was another issue, also a lack of books to support real world experimentation with the Prop.
"Tiny niche" even it's just 100,000 or so, that's still a lot, even for a mid-sized company. Maybe Parallax sitting on a massive pile of money and can afford to blow off purchasers who aren't buying at least a quarter million Props at a time. I know I certainly wouldn't turn my nose up at selling 100k worth of mcu boards even if I only made a $2 off each one. Most companies would fire a sales rep who would lose a sale like that.
A "propeller hat" for the Pi would have been very convenient. I planned to take the time to lay out such a PCB post-Christmas. My current solution is build on a propeller proto-board with both the pi and proto-board jammed into a parallax plastic case, and while a little ungainly in appearance, it works just fine.
I think there's a great opportunity for the Prop to provide real-time IO capabilities to Pi users.
There are already 2 Propeller hats for Raspberry Pi:
MIkronauts RoboPi
Pimoroni Propeller Hat
Maybe you can save yourself a little time and effort unless you just really want to build your own.
Thanks. That pimoroni one looks like a particularly interesting design, with some prototyping space. That would have been a cleaner implementation for me. I'm tempted to grab a couple to have on hand for the next project that comes along.
On the Pi com topic:
I have computers. I have too many computers. I don't want a Pi, because it is another computer, albeit small and cheap. Sure, the Prop may work well with PI, but how much does that really matter to the educational market, and people like me. When I see Pi and hear about Pi, it is revolving around the fact that it is a small computer and can do things that computers can do, but small and cheaper. The argument about them being thought of as HTPCs is along these lines.
To those who are scolding the company in this forum:
If you think there is so much more money to be made on marrying two brands, cash in on it somehow and stop whining on the forums.
I like the brand and am excited about what the P2 has to offer, but again, C is not what would sell it to -me- (nobody special). I also hope the company prospers and has much more growth in the dev and educational community. The talk about a lack of feedback could be somewhat warranted, but again, it makes no difference on my purchases from Parallax. Chip is braining away with his brains. He is running the development, he will communicate when something important happens.
To the FPGA Prop2 devs; best of luck to you
* Binary Compatible, the P2 is not.
* C-code Compatible, we can expect so, eventually..
* Spin-code Compatible, we can expect so, probably sooner than C.
* PASM Compatible - clearly not 100%, but there will hopefully be enough common ground (& things like conditional ASM controls and macros ) that porting PASM is not too onerous.
It is technically possible, with conditional ASM controls and macros, to have one source file target both CPUs.
re: I have no experience with Pimoroni yet. It is someplace between England and my mailbox.
Why don't you start a new thread about it . I'll have a look the Pi/ Prop software the Propeller Hat uses and try to use it with the Propeller Professional Development Board PDB
It has three versions 16-cog Low-power, Usb and Gigabit-Ethernet. Each of the three versions can have integrated Flash or not (without flash). A lot of packages to choose: TQFP-64 (for L and U versions), TQFP-128 and FBGA-236 (for all versions), FBGA-324 (U and E versions). No specs on clock but seems near 500 MHz. I wonder which process technology they have used (65nm or below?). They have a weird X... name on it. And it seems that they get serveral millions US$ from Xilinx, Huawei an Bosch. They have a really nice product brief PDF in which they explain how bad the interrupts are, how good they are doing real-time and deterministic responses, and why engineers have been doing this because there was no other choice ... eh! Wait a moment this is not ...
A relation may be bear to bear, beer to beer, peer to peer (onetwoone) or one to many or manytoone or manytomany. If it happens you stand inline with a howitzer, it matters on which side you stand.
There is a xmos chip (the one) and there are a lot of engineers (the many) which in the end are all competing. Parallax offers a chance: there is an engineer (the one) who created an unique solution based on the P2 and as this solution succeeds, he will find a lot of Px (the many), which will evolve. xmos doesn't create a ecosystem, but wants to be part of an ecosystem.
Err, seems to me that company is rather successfully making its own ecosystem. Support from one of the world's larger firms, with a 26M equity infusion. Smartpins may offer something unique, however 16-core at 500Mhz with USB2 Phy at 4.75/unit in quantity would seem to be market dominating in the interrupt-less market.
Not 100% certain since the available data is somewhat less than clear but it sounds like the 16 "cores" are actually 2 cores that can execute 8 threads each using hardware to switch between threads.
Pay attention to the MIPS number. They quote 2000 MIPS @ 500 MHz, so that means 4 cores.
However, they also have (16) 125 MIPS 'cores', and you can mix them how you want, so you can have (2) 500 MIPS + (8) 125 MIPS or (1) 500 MIPS + (12) 125 MIPS. They are hardware isolated threads, and 125 MIPS is pretty good.
I prefer programming the prop, and I prefer the package and available boards for the prop, but I have to admire the brute hardware of the xmos.
As per page 2 of the architecture flyer - https://www.xmos.com/published/xcore-architecture-flyer?secure=1
Execution rate is 5 clock cycles per instruction with no sequential overlap and therefore no blocking nor flushing of the pipeline is ever needed. However, to completely fill the pipeline, a full 5 threads must be concurrently fetching instructions. Anything less and rated MIPS is not achieved.
No one task can execute faster than 1/5 of clock rate.
With the claimed 64b fetch, you would expect more gain than they have ?
The ability to slot-map the tasks sounds great, and something that was talked about for P2.
That is two cores each implementing 8 hardware scheduled threads. Notice how on that little diagram they label the threads as "logical cores". It's a marketing scam to casually refer to them as cores elsewhere.
@altosack This calculation is not so simple in XMOS land.
A single tread on a single core will run at full speed (half or quarter clock rate, I forget, it may have changed with the new models)
A second thread on a core will run at the same speed again. As will three and four threads. This works out nicely because instructions from all those threads are streamed through the four stage pipeline and make maximum use of the hardware.
But, add that fifth thread, there are no more free slots in the pipeline and all threads are slowed down to accommodate it. Slower again for the sixth and seventh threads.
By the time we get to 8 threads they are all executing a one half the speed of that original single thread.
Why, because it's one core not eight.
Notice how the speed of a thread is influenced by how many threads are running, once you get to 4 and above. This breaks determinism in terms of calculating execution time by instruction counting. This is not such a big deal on XMOS as the dev tools can give you timing reports at compile time.
Edit: Seems the pipe lining and thread interleaving may have changed a bit with recent XMOS chips. Still the gist of my discussion above is true I believe. I'll have to get some of these new XMOS devices and check this out.
https://www.xmos.com/support/boards?product=18230&secure=1
It's not available yet, but it looks as though it should be quite inexpensive. Lots of app notes and software are available.
Interesting.
On that page they have "The xCORE-200 explorerKIT also features a 3D accelerometer, a 3-axis gyroscope " and then later in the feature list "3D Accelerometer and magnetometer". I wonder which it is.
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FXOS8700CQ
I found it on this page:
http://www.xmos.com/support/appnotes/an00181
Version 14.0 of xTIMEcomposer Studio, which supports the new devices, is available:
http://www.xmos.com/support/tools
I'm in the process of installing it.
Yeah, they seem to have decided that 5 stages, with two execute, is a better timing spread. Presumably when they were trying to maximise the clock rate. Funnily, Chip has come to the same conclusion.
There is mention of a dual instruction fetch also, hence the listed doubling of MIPS, but there seems to be some restriction on use, though, because they still list the single fetching as normal.