Oh gawd !!!!!!!!! I look at the date for the Tryit's original post and realize that it was April 1st. Is this all just another prank?
I just learned that Fluke isn't make a 114 kit for SparkFun.
At some point the more Linux platforms you have, the more you have files scattered where you can't find them. Be careful...
=++++++++
I am very ready to try running the ArduinoUno 3-D printer code to see it it will easily port over to the Propeller. Yet another interesting project.
@Jazz
I will start a new one when I do. IDBruce wants to produce an El Cheapo 3-D printer and the Propeller as yet doesn't have a G-code interpreter for that.
I have either the option to create one from scratch (already began research on that) or to port the ArduinoUNO code.
This is very heavy on the floating-point maths. May included an ADC use for temperature readings. And I am not exactly sure what else it might throw at the conversion process.
ALL of this has already been hashed out ad infinitum. Regardless of its beginnings, the Propeller now supports alternative IDEs and numerous variants of C, including one that (as I understand) Parallax has poured significant resources and money into. The chip itself does not support ADC, but many of the full board products that Parallax sells do. Every day Parallax pays the salaries to education specialists at the company who work up courseware for the Propeller running C. And the new Prop has ADC built-in.
So get over it.
Whether Parallax designs a Linux-based SBC would, no doubt, depend largely on whether they can bring anything new to the game. With Beagle, Pi, and now Arduino (among others, including Chinese knock-offs) offering close-to-cost ARM boards for Linux, is there any incentive for additional companies to jump in? Looks like a bloodbath waiting to happen, with consumers left holding lots of abandoned product. Companies don't always need to offer everything their competitors do.
I think that insults the moderators. I believe this thread has generated constructive feedback and dialogue if not at least to affirm Parallax users. Like I said earlier, I started with the Basic Stamp 2, on the Boe Bot.
I think the responses have been pretty civil. Carry on.
And BTW, welcome to the forums. I hope we can help with any info you need to include the Propeller in your tool list.
As far as the C arguments go, Parallax has an official C/C++ offering because it is required for education sales these days (and lots of those customers require officially supported). If it wasn't for missing market share, Parallax would probably have never bothered. Even with it being an official product, it is very difficult to remain a developer sometimes because of hostility of some forumites towards the C language. Ya, it's there, it works perfectly well, and there is lots of effort invested by the education staff, but it will always be not the first choice of most Parallax contributors. Tastes like cardboard ....
Thank goodness Parallax is responding to the market. To the last comment above, I just don't understand the aversion to C programming. It doesn't make sense technically or economically. With C, if you don't have a need for floating point, just use integers. But the fact that both are there serves a broader range of users and a larger market share. Moreso, especially for students, C/C++ is so ubiquitous in the industry, it would serve them better to learn it over proprietary languages like Spin.
Same with on-board ADCs, if you don't need them, good, reconfigure them as general purpose I/Os. For others who need them onboard for speed (acquisition rate) and simplicity (less cost and less clutter on breadboard), it serves them too. Broader market share. For me, floating point and ADCs are absolutely crucial because I deal with robotics and feedback control systems involving Kalman filters (double precision crucial). Here, integer math does not make sense. Floating point frees me from having to deal with the constraints of integer math and allows me to focus on the physics of the problem. Has anyone tried the Eigen matrix library on PropellerGCC? This would be very useful.
Again, the Propeller-2 seems very promising and I like that it aims toward a broader user base and market share. The specs do not mention USART, PWM, SPI and I2C. Are they not included as onboard hardware?
Again, the Propeller-2 seems very promising and I like that it aims toward a broader user base and market share. The specs do not mention USART, PWM, SPI and I2C. Are they not included as onboard hardware?
These are all done in software. There are plenty of COGs. That's the beauty of the Propeller. Start a COG to do Full Duplex Serial, Start a COG to do SPI or I2C. Starts a COG to do PWM. If Your not using these services, you can shut down the COG to do something else.
I am giving P1 specs. P2 may be more capable of some of the hardware.
UARTs, I2C, SPI, and PWM are all easily available in the Propeller, in software. When you need more than one, you just use more software rather than go shopping for another chip.
The Propeller has full-duplex UART up to 3M baud demonstrated. Similarly speed is not a problem with i2C or SPI. And of course, there is VGA video if you need it.
+++++++++++
C makes it easier to work with the hardware forms of these items, but then you are stuck if you don't have enough hardware. Even ADC and DAC have been done nearly entirely in software with a few bits - resistors and capacitors.
What's the point? More low level skills developed, better grasp of what can be done.
The specs do not mention USART, PWM, SPI and I2C. Are they not included as onboard hardware?
The Propeller philosophy is to use soft peripherals so that any pin can serve any purpose. It means hardware producers do not need to keep 14 variations of one chip in inventory (a real cost for businesses). It also means some sacrifice of speed in some cases like SPI, but other functional advantages are having up to: 30x PWMs, 7x SPI channels (MOSI,MISO,CLK,CS), 15x I2C channels, 15x 115200 baud UARTS, and/or 9x USARTs on a propeller. The types of lower speed devices are practically unlimited ... there are even low-speed USB port designs that can be added to the currently shipping Propeller chip (P8x32a).
The specs do not mention USART, PWM, SPI and I2C. Are they not included as onboard hardware?
Why would they be included in hardware when software does it better?
Lets see:
USART any 2 pins. Maybe a couple more pins if you need the hardware handshake functions.
PWM any single pin and the CTR counters.
SPI any 4 pins.
I2C any 2 pins.
Plus the software driver.
And almost any other interface you could think of.
Why would they be included in hardware when software does it better?
Lets see:
USART any 2 pins. Maybe a couple more pins if you need the hardware handshake functions.
PWM any single pin and the CTR counters.
Oh okay, they're done in software. So you do bit banging and use dedicated COGs for the peripherals leaving other COGs for the project program. Does this put a limit on USART baud rate? Does the peripheral software (C/C++ version) reduce program space significantly?
What about Propeller-2 RAM, the specs are a bit confusing. What is the total RAM available for variables, and total flash for program space? What is the projected cost of the Propeller-2?
The Propeller lives in a different world to the regular micro-controller. The idea, at it's simplest, is "let's do it in software" rather than depending on some fixed configuration of hardware support.
As a result a Propeller can drive 32 PWM servos, at the same time. Or multiple UART interfaces. Or multiple SPI/I2C. Or whatever you want in combination.
No idea what the limits are but I have a full duplex UART that operates up to 115200 baud written in C!. No doubt the assembler objects do better.
Yes, RAM is tight. Still there are ways to get COGs loaded with driver software and still have your HUB RAM free for application code afterwards.
Let's not talk about the P2. It does not exist. There is a lot that can be done with the P1.
Does the peripheral software (C/C++ version) reduce program space significantly?
Depends on what you want to do. You can look at all the devices and libraries available in the Propeller-C Simple Library here. There are Standard C Libraries of course, but they are bigger with floating point, etc... All Simple Library User IO devices can be used with the Simple Text library. The Simple Library serial UART offers a 115200 baud per channel (15x UARTS) for debugging or other simple communications (main thread blocking) without using a COG (name for a Propeller core) and code overhead is very small. A more complex Simple Library fdserial UART device (up to 7x UARTS + more possible) that allows "interrupt like" asynchronous capability is available that uses a COG and takes more code space. We don't have a basic index of all functions yet ... WIP.
The Propeller lives in a different world to the regular micro-controller. The idea, at it's simplest, is "let's do it in software" rather than depending on some fixed configuration of hardware support.
Let's not talk about the P2. It does not exist. There is a lot that can be done with the P1.
I'm more interested in the P2. I see it as multi-core 32-bit microcontroller programmable in C (I hope) with more built-in ADCs (13-bit) and peripherals than any other competing module by nearly a factor of 10. There is nothing like this on the market! With the right price ($39.95 or cheaper) and the right marketing (high schools, colleges, MAKE:, maker faire, etc.), you can do to Arduino what Arduino did to the Basic Stamp. Collaboration with R-Pi and Arduino wouldn't hurt either. A recommendation: change the word "COG" to multi-core. Good luck.
A recommendation: change the word "COG" to multi-core.
Not a good idea. A "cog" is not the same as a "core". Multi-core chips do not necessarily have their cores fully integrated - in fact, they may be completely independent.
On the propeller, all cogs are tightly coupled to the hub, and spin synchronously.
A "COG" is not the same as a "core". Perhaps. But then a "core" is not the same as a "core" either.
As you point out multicore chips may well have independent cores with their own RAM and so on. XMOS xcores are an example.
On the other hand multiple core Intel devices do share RAM, rather like COGS share HUB.
On the other hand "core" as in "IP core" in the FPGA/ASIC world might not even be a CPU.
I don't mind "COG" but I also see that using terms the majority of the industry is familiar with might be a good idea.
P.S. XMOS now refers to the hardware scheduled threads in their devices as "logical cores". What used to be cores are now called "tiles". It's a devious and dishonest marketing trick.
But in the Propeller case the term "core" for COG is not at all dishonest. It's seems quite correct to me. It aligns with the use of "multiple core" for Intel, ARM and other devices does it not?
Renaming things so that your target market can recognize them is a marketing ploy but not necessarily dishonest.
Aside: Reminds me of the time I volunteered to take an old TV to the dump for someone. I was not familiar with the town so they gave me directions "Go this way..that way..it's on the right, you will see the sign" After cruising around a bit I gave up trying to find the dump or a recycling centre or anything and returned with the old TV. Turns out there was a big sign to the dump on the very road I cruised up and down. It read "Civic Amenity Point". Who would have guessed?
Oh okay, they're done in software. So you do bit banging and use dedicated COGs for the peripherals leaving other COGs for the project program. Does this put a limit on USART baud rate? Does the peripheral software (C/C++ version) reduce program space significantly?
What about Propeller-2 RAM, the specs are a bit confusing. What is the total RAM available for variables, and total flash for program space? What is the projected cost of the Propeller-2?
As I said previously, the useful Baud rate has already be demonstrated to be 3mega-baud (Try Tachyon Forth for this and a USB interface)
Do you have to use a Cog for just one peripheral.. NO.. we have objects that can do Four serial ports in one Cog. And you can the same with I2C or SPI if you need to hold back cogs for other things.
Does peripheral code reduce programing space significantly?
Only if you choose to be wasteful. You can extend your programing space into a larger EEPROM for an SDcard if you find the Propeller short of space.
Flash space for programming --
Well using an SDcard, it can run to 32Gbytes. Does that count as flash space?
Projected cost of the Propeller2 -- I have given up trying to figure that out - TBD.
RAM space for variables in the Propeller2-
Well in the Propeller 1 you have Cog RAM and Hub RAM - you can use it all for variables, but that would mean that you forgot to include program code. It is a see-saw between the two. In the Propeller1 - CogRAM has 496 32bit slots, HubRAM has 8k 32bit slots or it can get down to 16 bit or 8 bit slots, depending on what you need or want.
In the Propeller2, total Hubram was recently doubled and Chip Gracy found the means to add some significant features at no added cost while sorting out a few bugs that caused production delays. So we are waiting for a few pleasant and exotic surprises.
Unlike the AVR chips, the Propellers are not just taking a basic products and up-sizing it. Creative features are looked for and when the opportunity to include them arises, new things get added.
++++++++
Are you researching a magazine review? Who for? The Arduinio Tre? or the Propeller 2?
These are highly different devices. Having a Linux SOC doesn't really increase microcontroller power so much as add a Linux computer to a traditional Arduino.
For instance, you wanted ADCs. The Propeller 2 may have roughly 90 ADCs if you need that many. Each i/o pin is intended to be able to do the same thing.
Did Peter back down to 2Mbps? Maybe for awhile, but PropForth also claimed to later achieve 3Mbps and I think everyone pretty much agreed that 3Mbps was feasible.
The thing is that with 32K of Hubram, sending to the Propeller at 3Mbps tops off any buffer absurdly fast. The only real utility I can think of this rate is for sending a fast feed of a data stream from the Propeller.
Tryit seems to want to find points of comparison in a numbers game that presumes similar architecture.
The reality is that the Arduino is a group of chips with a variety of features AND very dis-similar architecture.
The BIGGEST reason to learn the Propeller is to comprehend an alternative architecture and how that affects performance. IN some ways, it is very surprising.
For instance, Cogs don't have to be deployed to a dedicated task. Some cogs might be tasked for one use and never change, but other cogs can run a task, stop, and become available for an entirely different task as required. And unused cogs can run portions of a task in parallel to accelerate processing, then be redeployed.
All the Arduinos have is interrupts to change tasks or to time-slice multitasking. Time-slice means everything is slowing down to get virtual parallel processing. IN the Propeller, no slow down occurs and maybe some acceleration.
So its ARCHITECTURE versus ARCHITECTURE, not feature versus feature.
(I hate these comparison discussions as they should be contrasts discussions. You can't set up a spreadsheet and just check off which is better.)
What good is the lowest price if you never use the device? Especially if the device that is marginally higher priced will become well used.
I skipeed the Raspberry Pi and got a Cubieboard for a higher price (and a longer wait) and I am glad I did. More of the features I wanted and CAN USE.
But in the Propeller case the term "core" for COG is not at all dishonest. It's seems quite correct to me. It aligns with the use of "multiple core" for Intel, ARM and other devices does it not?
Renaming things so that your target market can recognize them is a marketing ploy but not necessarily dishonest.
Again, very well put. Lots of Wozniaks in this thread, not enough Steve Jobs like @Heater. I think you have to capture the prospective customer at the Title, like a New York Times headline, or a movie trailer. For example: "Propeller2 - Multi-Core with 8 32-bit Processors" grabs the Maker's attention. Aside from Parallax customers, COG is not recognized by the broader market, which I presume is the target.
Well, multi-core is bit vague as the relationship between the cores. It might be useful in a headline, but Cog is still there to indicate how the mutliple-cores actually interact together in harmony.
In the Propeller, the multiple cores can all access i/o at and one time. In fact, the output from one Cog can over-ride the output from another in a very handy arbitration scheme.
In contrast, if you take other multiple core devices; you may or may not have this extremely important feature. It is NOT just the number of cores that indicate utility -- IT is the relationship of how the cores share and arbitrate i/o.
+++++++++
The worst I have seen so far is the 144 core GA144 Forth chip by Charles Moore. I/o is not shared to the outside world in the 8 x 16 grid and the 144 multi-core has many cores that have to work through other cores to get to the outside world. To make matters worse, the cores that have i/o to the outside world are tasked to specifics -- hardware RS232, I2c, SDcard, etc. so getting to an i/o capable core is a big programing distraction.
I keep saying you have to comprehend the architecture; not just the jargon for selling and counting.
So multi-core alone does not call attention to what is going on. This is not a mere marketing ploy (like Starbucks insisting I order a 'grande' latte rather than allowing me to say 'medium').
IMO, Mr. Steve Jobs may have been a great salesman, but he was a greedy jerk. Without the Woz, and others of such dedication he wouldn't have had a product to exploit.
Once again Tryit reveals his true ambitions.... create a sales slant for the Tre and against the Propeller.
Just friendly chatter. It's worth knowing what the competition is up to, so no need to ban me from forum. The new Arduino Tre is scheduled to arrive any time now (Spring 2014). Is the price known yet? Will it fall near the Raspberry Pi or BeagleBone Black? I'm very excited for Arduino's leap to the SBC domain (single-board-computer). I'm a bit concerned with the price for the following reasons: (1) it will be manufactured in the United States , (2) it must integrate two processors from different vendors (ATMEL and TI), and (3) it features more peripherals than R-Pi and BeagleBone Black. That said, it has to be more expensive than a 32-bit Due, but hopefully less than sixty. For Arduino's sake, I hope the cost does not exceed $59.95 USD. On the other hand, in the very unlikely case the price is the same or less than the R-Pi Model B, that would dethrone R-Pi as the de facto king of SBCs. Share your information or opinion on price for the community.
"Arduino started in 2005 as a project for students at the Interaction Design Institute Ivrea in Ivrea, Italy. At that time program students used a "BASIC Stamp" at a cost of $100, considered expensive for students. Massimo Banzi, one of the founders, taught at Ivrea.[4]
A hardware thesis was contributed for a wiring design by Colombian student Hernando Barragan. After the wiring platform was complete, researchers worked to make it lighter, less expensive, and available to the open source community. The school eventually closed down, so these researchers, one of them David Cuartielles, promoted the idea.[4]
The current prices run around $30 and related "clones" as low as $9.[4][5] A simple Arduino Mini Pro[6] clone may be had from China for less than $4, post paid.[7]""
The focus on price is relitive to any one point in time.
You can't use a processor without a programing language and an IDE.
In the beginning, the BasicStamp was a bargain at $50 just because it included a free IDE and a language much simpler than C (which was really only available in Intel form for free).
Parallax was more generous and easier to use than the competition. Arduino learned from this and dummied up C's reputation by hiding under terms of 'wiring' and 'sketches'.
Way back then, chips were cheap. But if you wanted a free microcontroller IDE at that time, you likely had only Assembler.
The size of the RAM in the BasicStamp (32 bytes of RAM) made C rather absurd. And PIC Basic wasn't working quite right at over a hundred dollars, just because there were too many PIC chips to support.
++++++++++
When C finally became FREE for the AVR chips, the Arduino became competative -- but it was a very long wait. The industry wanted thousands of dollars for a version of C on any AVR and while the resources in the AVR seemed promising -- the early chips had bug problems... while the PIC was reliable.
There was an AVR copy of BasicStamp called the BasicX by NetMedia. But trouble with chip bugs, lack of clear documentation and support, and a VisualBasic approach made it harder for a beginner to get much done.
And so the slant of implying that Parallax was overcharging at $100USD for a BasicStamp chip is a bit of a distortion. There has NEVER been a BasicStamp chip that retailed at $100 (though that might be the cost after shipping and duty in Italy).
And the Arduino arrived with the windfall of a Free C compiler for AVR chips as the industry finally let go of the dream of having customers pay big bucks for the IDE and the C.
The microprocessor industry's greed created a niche for the BasicStamp to thrive; and then pretty much took it away when they realize they were loosing market share.
AVR are good for what they are. But an ArduinoUNO actually has only 2.0Kb Ram compared to 32Kb Ram of a PropellerOne. Most of the program is in Flash that is pretty much read-only memory in actual use. One has to go to an ArduinoDUE to exceed the Propeller RAM resources.
My main point is Parallax has the Propeller now at $25 for a useful board and should not be slammed for selling the BasicStamp at prices that were generous in the beginning. The BasicStamp is made in California and has a higher cost due to the California economic environment.
Parallax has to have Propeller boards made in China to compete in today's world. And Arduino clones out of China are awash in the marketplace.
The price competition is good for all of us. But it does favor the deep pockets of larger chip manufacturers that are able to exploit huge economies of scale in production runs.
Comments
I just learned that Fluke isn't make a 114 kit for SparkFun.
At some point the more Linux platforms you have, the more you have files scattered where you can't find them. Be careful...
=++++++++
I am very ready to try running the ArduinoUno 3-D printer code to see it it will easily port over to the Propeller. Yet another interesting project.
Must do.
Port "easily" is questionable, but it will certainly be a good exercise.
I will start a new one when I do. IDBruce wants to produce an El Cheapo 3-D printer and the Propeller as yet doesn't have a G-code interpreter for that.
I have either the option to create one from scratch (already began research on that) or to port the ArduinoUNO code.
This is very heavy on the floating-point maths. May included an ADC use for temperature readings. And I am not exactly sure what else it might throw at the conversion process.
So get over it.
Whether Parallax designs a Linux-based SBC would, no doubt, depend largely on whether they can bring anything new to the game. With Beagle, Pi, and now Arduino (among others, including Chinese knock-offs) offering close-to-cost ARM boards for Linux, is there any incentive for additional companies to jump in? Looks like a bloodbath waiting to happen, with consumers left holding lots of abandoned product. Companies don't always need to offer everything their competitors do.
I think the responses have been pretty civil. Carry on.
And BTW, welcome to the forums. I hope we can help with any info you need to include the Propeller in your tool list.
Thank goodness Parallax is responding to the market. To the last comment above, I just don't understand the aversion to C programming. It doesn't make sense technically or economically. With C, if you don't have a need for floating point, just use integers. But the fact that both are there serves a broader range of users and a larger market share. Moreso, especially for students, C/C++ is so ubiquitous in the industry, it would serve them better to learn it over proprietary languages like Spin.
Same with on-board ADCs, if you don't need them, good, reconfigure them as general purpose I/Os. For others who need them onboard for speed (acquisition rate) and simplicity (less cost and less clutter on breadboard), it serves them too. Broader market share. For me, floating point and ADCs are absolutely crucial because I deal with robotics and feedback control systems involving Kalman filters (double precision crucial). Here, integer math does not make sense. Floating point frees me from having to deal with the constraints of integer math and allows me to focus on the physics of the problem. Has anyone tried the Eigen matrix library on PropellerGCC? This would be very useful.
Again, the Propeller-2 seems very promising and I like that it aims toward a broader user base and market share. The specs do not mention USART, PWM, SPI and I2C. Are they not included as onboard hardware?
These are all done in software. There are plenty of COGs. That's the beauty of the Propeller. Start a COG to do Full Duplex Serial, Start a COG to do SPI or I2C. Starts a COG to do PWM. If Your not using these services, you can shut down the COG to do something else.
I am giving P1 specs. P2 may be more capable of some of the hardware.
It's an empty canvas.
The Propeller has full-duplex UART up to 3M baud demonstrated. Similarly speed is not a problem with i2C or SPI. And of course, there is VGA video if you need it.
+++++++++++
C makes it easier to work with the hardware forms of these items, but then you are stuck if you don't have enough hardware. Even ADC and DAC have been done nearly entirely in software with a few bits - resistors and capacitors.
What's the point? More low level skills developed, better grasp of what can be done.
Have a nice day. maybe you should.... TRYIT.
The Propeller philosophy is to use soft peripherals so that any pin can serve any purpose. It means hardware producers do not need to keep 14 variations of one chip in inventory (a real cost for businesses). It also means some sacrifice of speed in some cases like SPI, but other functional advantages are having up to: 30x PWMs, 7x SPI channels (MOSI,MISO,CLK,CS), 15x I2C channels, 15x 115200 baud UARTS, and/or 9x USARTs on a propeller. The types of lower speed devices are practically unlimited ... there are even low-speed USB port designs that can be added to the currently shipping Propeller chip (P8x32a).
Lets see:
USART any 2 pins. Maybe a couple more pins if you need the hardware handshake functions.
PWM any single pin and the CTR counters.
SPI any 4 pins.
I2C any 2 pins.
Plus the software driver.
And almost any other interface you could think of.
Duane J
Oh okay, they're done in software. So you do bit banging and use dedicated COGs for the peripherals leaving other COGs for the project program. Does this put a limit on USART baud rate? Does the peripheral software (C/C++ version) reduce program space significantly?
What about Propeller-2 RAM, the specs are a bit confusing. What is the total RAM available for variables, and total flash for program space? What is the projected cost of the Propeller-2?
The Propeller lives in a different world to the regular micro-controller. The idea, at it's simplest, is "let's do it in software" rather than depending on some fixed configuration of hardware support.
As a result a Propeller can drive 32 PWM servos, at the same time. Or multiple UART interfaces. Or multiple SPI/I2C. Or whatever you want in combination.
No idea what the limits are but I have a full duplex UART that operates up to 115200 baud written in C!. No doubt the assembler objects do better.
Yes, RAM is tight. Still there are ways to get COGs loaded with driver software and still have your HUB RAM free for application code afterwards.
Let's not talk about the P2. It does not exist. There is a lot that can be done with the P1.
Depends on what you want to do. You can look at all the devices and libraries available in the Propeller-C Simple Library here. There are Standard C Libraries of course, but they are bigger with floating point, etc... All Simple Library User IO devices can be used with the Simple Text library. The Simple Library serial UART offers a 115200 baud per channel (15x UARTS) for debugging or other simple communications (main thread blocking) without using a COG (name for a Propeller core) and code overhead is very small. A more complex Simple Library fdserial UART device (up to 7x UARTS + more possible) that allows "interrupt like" asynchronous capability is available that uses a COG and takes more code space. We don't have a basic index of all functions yet ... WIP.
I'm more interested in the P2. I see it as multi-core 32-bit microcontroller programmable in C (I hope) with more built-in ADCs (13-bit) and peripherals than any other competing module by nearly a factor of 10. There is nothing like this on the market! With the right price ($39.95 or cheaper) and the right marketing (high schools, colleges, MAKE:, maker faire, etc.), you can do to Arduino what Arduino did to the Basic Stamp. Collaboration with R-Pi and Arduino wouldn't hurt either. A recommendation: change the word "COG" to multi-core. Good luck.
We all look forward to it eagerly though...
Not a good idea. A "cog" is not the same as a "core". Multi-core chips do not necessarily have their cores fully integrated - in fact, they may be completely independent.
On the propeller, all cogs are tightly coupled to the hub, and spin synchronously.
Thanks. But we don't expect to need it.
Ross.
A "COG" is not the same as a "core". Perhaps. But then a "core" is not the same as a "core" either.
As you point out multicore chips may well have independent cores with their own RAM and so on. XMOS xcores are an example.
On the other hand multiple core Intel devices do share RAM, rather like COGS share HUB.
On the other hand "core" as in "IP core" in the FPGA/ASIC world might not even be a CPU.
I don't mind "COG" but I also see that using terms the majority of the industry is familiar with might be a good idea.
P.S. XMOS now refers to the hardware scheduled threads in their devices as "logical cores". What used to be cores are now called "tiles". It's a devious and dishonest marketing trick.
And one we shouldn't emulate.
Certainly not at the behest of an Arduweenie who appears to be concerned that the P2 might steal some of their market.
Ross.
Renaming things so that your target market can recognize them is a marketing ploy but not necessarily dishonest.
Aside: Reminds me of the time I volunteered to take an old TV to the dump for someone. I was not familiar with the town so they gave me directions "Go this way..that way..it's on the right, you will see the sign" After cruising around a bit I gave up trying to find the dump or a recycling centre or anything and returned with the old TV. Turns out there was a big sign to the dump on the very road I cruised up and down. It read "Civic Amenity Point". Who would have guessed?
Moral of this story: Never volunteer for anything!
Ross.
"symmetrical multi-processor with 8 32-bit processors"
I like that even better than "COGS" or "cores".
Slap. I'm agreeing with you again.
That's ok. Just don't make a habit of it. People will talk.
As I said previously, the useful Baud rate has already be demonstrated to be 3mega-baud (Try Tachyon Forth for this and a USB interface)
Do you have to use a Cog for just one peripheral.. NO.. we have objects that can do Four serial ports in one Cog. And you can the same with I2C or SPI if you need to hold back cogs for other things.
Does peripheral code reduce programing space significantly?
Only if you choose to be wasteful. You can extend your programing space into a larger EEPROM for an SDcard if you find the Propeller short of space.
Flash space for programming --
Well using an SDcard, it can run to 32Gbytes. Does that count as flash space?
Projected cost of the Propeller2 -- I have given up trying to figure that out - TBD.
RAM space for variables in the Propeller2-
Well in the Propeller 1 you have Cog RAM and Hub RAM - you can use it all for variables, but that would mean that you forgot to include program code. It is a see-saw between the two. In the Propeller1 - CogRAM has 496 32bit slots, HubRAM has 8k 32bit slots or it can get down to 16 bit or 8 bit slots, depending on what you need or want.
In the Propeller2, total Hubram was recently doubled and Chip Gracy found the means to add some significant features at no added cost while sorting out a few bugs that caused production delays. So we are waiting for a few pleasant and exotic surprises.
Unlike the AVR chips, the Propellers are not just taking a basic products and up-sizing it. Creative features are looked for and when the opportunity to include them arises, new things get added.
++++++++
Are you researching a magazine review? Who for? The Arduinio Tre? or the Propeller 2?
These are highly different devices. Having a Linux SOC doesn't really increase microcontroller power so much as add a Linux computer to a traditional Arduino.
For instance, you wanted ADCs. The Propeller 2 may have roughly 90 ADCs if you need that many. Each i/o pin is intended to be able to do the same thing.
The thing is that with 32K of Hubram, sending to the Propeller at 3Mbps tops off any buffer absurdly fast. The only real utility I can think of this rate is for sending a fast feed of a data stream from the Propeller.
Tryit seems to want to find points of comparison in a numbers game that presumes similar architecture.
The reality is that the Arduino is a group of chips with a variety of features AND very dis-similar architecture.
The BIGGEST reason to learn the Propeller is to comprehend an alternative architecture and how that affects performance. IN some ways, it is very surprising.
For instance, Cogs don't have to be deployed to a dedicated task. Some cogs might be tasked for one use and never change, but other cogs can run a task, stop, and become available for an entirely different task as required. And unused cogs can run portions of a task in parallel to accelerate processing, then be redeployed.
All the Arduinos have is interrupts to change tasks or to time-slice multitasking. Time-slice means everything is slowing down to get virtual parallel processing. IN the Propeller, no slow down occurs and maybe some acceleration.
So its ARCHITECTURE versus ARCHITECTURE, not feature versus feature.
(I hate these comparison discussions as they should be contrasts discussions. You can't set up a spreadsheet and just check off which is better.)
What good is the lowest price if you never use the device? Especially if the device that is marginally higher priced will become well used.
I skipeed the Raspberry Pi and got a Cubieboard for a higher price (and a longer wait) and I am glad I did. More of the features I wanted and CAN USE.
Again, very well put. Lots of Wozniaks in this thread, not enough Steve Jobs like @Heater. I think you have to capture the prospective customer at the Title, like a New York Times headline, or a movie trailer. For example: "Propeller2 - Multi-Core with 8 32-bit Processors" grabs the Maker's attention. Aside from Parallax customers, COG is not recognized by the broader market, which I presume is the target.
In the Propeller, the multiple cores can all access i/o at and one time. In fact, the output from one Cog can over-ride the output from another in a very handy arbitration scheme.
In contrast, if you take other multiple core devices; you may or may not have this extremely important feature. It is NOT just the number of cores that indicate utility -- IT is the relationship of how the cores share and arbitrate i/o.
+++++++++
The worst I have seen so far is the 144 core GA144 Forth chip by Charles Moore. I/o is not shared to the outside world in the 8 x 16 grid and the 144 multi-core has many cores that have to work through other cores to get to the outside world. To make matters worse, the cores that have i/o to the outside world are tasked to specifics -- hardware RS232, I2c, SDcard, etc. so getting to an i/o capable core is a big programing distraction.
I keep saying you have to comprehend the architecture; not just the jargon for selling and counting.
So multi-core alone does not call attention to what is going on. This is not a mere marketing ploy (like Starbucks insisting I order a 'grande' latte rather than allowing me to say 'medium').
IMO, Mr. Steve Jobs may have been a great salesman, but he was a greedy jerk. Without the Woz, and others of such dedication he wouldn't have had a product to exploit.
Once again Tryit reveals his true ambitions.... create a sales slant for the Tre and against the Propeller.
Most people eat sound bites or starve.
Interesting topic.
Note this discussion that mentions that the Arduino's success is supposely because of overpricing of the Basic Stamp by Parallax..
http://en.wikipedia.org/wiki/Arduino
"Arduino started in 2005 as a project for students at the Interaction Design Institute Ivrea in Ivrea, Italy. At that time program students used a "BASIC Stamp" at a cost of $100, considered expensive for students. Massimo Banzi, one of the founders, taught at Ivrea.[4]
A hardware thesis was contributed for a wiring design by Colombian student Hernando Barragan. After the wiring platform was complete, researchers worked to make it lighter, less expensive, and available to the open source community. The school eventually closed down, so these researchers, one of them David Cuartielles, promoted the idea.[4]
The current prices run around $30 and related "clones" as low as $9.[4][5] A simple Arduino Mini Pro[6] clone may be had from China for less than $4, post paid.[7]""
You can't use a processor without a programing language and an IDE.
In the beginning, the BasicStamp was a bargain at $50 just because it included a free IDE and a language much simpler than C (which was really only available in Intel form for free).
Parallax was more generous and easier to use than the competition. Arduino learned from this and dummied up C's reputation by hiding under terms of 'wiring' and 'sketches'.
Way back then, chips were cheap. But if you wanted a free microcontroller IDE at that time, you likely had only Assembler.
The size of the RAM in the BasicStamp (32 bytes of RAM) made C rather absurd. And PIC Basic wasn't working quite right at over a hundred dollars, just because there were too many PIC chips to support.
++++++++++
When C finally became FREE for the AVR chips, the Arduino became competative -- but it was a very long wait. The industry wanted thousands of dollars for a version of C on any AVR and while the resources in the AVR seemed promising -- the early chips had bug problems... while the PIC was reliable.
There was an AVR copy of BasicStamp called the BasicX by NetMedia. But trouble with chip bugs, lack of clear documentation and support, and a VisualBasic approach made it harder for a beginner to get much done.
And so the slant of implying that Parallax was overcharging at $100USD for a BasicStamp chip is a bit of a distortion. There has NEVER been a BasicStamp chip that retailed at $100 (though that might be the cost after shipping and duty in Italy).
And the Arduino arrived with the windfall of a Free C compiler for AVR chips as the industry finally let go of the dream of having customers pay big bucks for the IDE and the C.
The microprocessor industry's greed created a niche for the BasicStamp to thrive; and then pretty much took it away when they realize they were loosing market share.
AVR are good for what they are. But an ArduinoUNO actually has only 2.0Kb Ram compared to 32Kb Ram of a PropellerOne. Most of the program is in Flash that is pretty much read-only memory in actual use. One has to go to an ArduinoDUE to exceed the Propeller RAM resources.
My main point is Parallax has the Propeller now at $25 for a useful board and should not be slammed for selling the BasicStamp at prices that were generous in the beginning. The BasicStamp is made in California and has a higher cost due to the California economic environment.
Parallax has to have Propeller boards made in China to compete in today's world. And Arduino clones out of China are awash in the marketplace.
The price competition is good for all of us. But it does favor the deep pockets of larger chip manufacturers that are able to exploit huge economies of scale in production runs.