I think it's important to remember that absolute share size doesn't mean all that much. What needs to happen is the Propeller see enough use in it's niches to sustain the community that produces it, and that includes Parallax. It's a little eco-system, and all it needs to flourish and grow is enough energy (money) moving to permit that to happen. Anything beyond that is a damn good thing, but not strictly necessary to assure longer term viability.
And those kinds of products can often be "that competitive secret sauce" for those people willing to explore them and make them part of their overall effort. Might not need it all the time, but when you do need it, you need it really bad, kind of thing.
This is a very informative thread. In May I will finally have my degree and I plan on using the Prop in my upcoming career, if the boot fits the application.
I constantly have to remind my team member (senior design) that using a Prop USB board + Spinneret is not a poor engineering design. His argument is that the fellow AeroQuad gentlemen use only one uC. I remind him that we are not creating a hobbyist toy but an Intelligent Autonomous UAV. Also if the AeroQuad added some of the capabilities of our design then they would have to increase their intelligence (another uC) as well.
Being able to quickly and efficiently relocate objects/code using the COGs has become a major advantage for me. Everyday I move a method/object to a different location, or I embed it in another COG, or I give it it's own COG, or I reverse what I just did and start at square one. I understand interrupts and how to use them, I would have thrown this project out the window if I had to use interrupts.
To counter: there will always be something better and nothing will ever be the best. i.e-there is always a faster car on the street.
Are these five people you prompted to migrate to the Propeller developing commercial products with the Propeller, or are they hobbyists?
4 of them are purely hobbyists, the other developing a commercial product (now with the prop for future designs). All 5 of them are of course hobbyists, as I think is true for many of us our hobby is our profession.
As has been noted, many of the hobbyists of today are the commercial developers of tomorrow, and they tend to take there hobby preferences with them to the commercial products.
Thanks, glad someone got a kick out of that imagery.
Leon,
Again yes, you can get to unreachable pins on xcores by communicating over hardware links (I have done that tutorial example your refer to).
But, as I said, when you do so it costs dearly. Firstly there is the complication of having to write the code to do it, that's not hard but it's there. Worse is that it uses channel resources and
it wastes a precious thread at the "pin end". Or that channel end could be handled by an existing thread which makes spaghetti out of your code and impacts performance of that thread. Then there is the issue of all the time it takes to do that channel communication..
The Prop, having such a regular structure in it's cores and pins does not have any of these issues. Just write "outa[bla, bla]" and it's done. Why the X chip can't do this I don't know.
You are right, those hardware comms channels are excellent for communicating across cores and even more excellent when communication chip to chip.
I'd like to make a light hearted comparison:
One of the longest lived and most produced chip designs ever is the humble 555 timer. The 555 does not do anything much, there's no C compiler for it and I can't even run Linux on it:) But when you have a situation that needs one its perfect. One could add a lot of bells and whistles to a 555 but then it would not be a 555 anymore.
The Prop is not a microprocessor, my modern standards apparently it's not even a micro-controller. C support for it is poor and it does not run Linux. But I can see a lot of situations where if your situation needs one its perfect.
But I can see a lot of situations where if your situation needs one its perfect.
I must say this, without the Prop/Spin/etc..., my PRS cannot be realized in such a short period of time and with such tiny resources ... Prop's the way for me ....
It's been a while since I've spent any 'quality' time on the forum, as I now have 2 commercial products using the Prop. I just couldn't resist this thread. I never considered all of that other company longevity, and size stuff. If I was worried about it then it was my responsibility as a developer to make sure I did a good job in representing that key element of my 'team', just like the forum here.
The products make the company, not vice versa.
Parallax has a very rich and successful history. Look at the Stamp.
It's going to be the killer app with the marketing wrapper that shines the light brightly on the Prop to bring it out. It's capability is only truly appreciated by those of us who have really worked with it - and ultimately it does not matter anyway. The 68000 was always a better processor than the 8088 and it's evil spawn's but the IBM PC drug it into the light and made it a success.
Look at the iPod and Walkman. Sony had iPod (MP3) technology fully 3-4 years ahead of Apple. I still have my digital walkman. It was Jobs who put a white cord on the headset attached to a sexy package, came up with catchy marketing and put 99 cent songs on the web. Suddenly an MP3 player is cool.
I think the Prop will have it's day in the light but the Gracey's have done all they can, now it's up to us developers to make it really happen.
Jim-
The Propeller chip caught on with me. Tasks running in cogs are a higher level of abstraction than interrupt service routines, so the programming model is much closer to typical HLL threading.
Once I got over the servo voltage hump, my 6 axis robot arm project was much easier than it would have been with the BS2, and moderately easier than using an Arduino. The cogs allowed me to have floating point for the inverse kinematic transforms, a servo controller, and move generation in one tidy package.
I don't think the propeller really fits into the current uC market. In the segment where ARM et al. live, Propeller has more than enough MIPS to compete, but they're more awkward to use spread over multiple cores, memory is limited, and there's no memory management. On the opposite end, where the tiny 8 bit micros live (Microchip and Atmel especially) cost is king. That's why there are so many of them, you buy the very smallest part that your application will fit on. The propeller is completely wasted blinking some leds. The propeller is very close to being an excelent number cruncher, doing things normally served by DSPs, but the lack of floating point, multiplication, division and high speed i/o put it out of the running.
The propeller is a jack of all trades, but developers only need one trade, and they want a master.
The propeller does have floating point, multiplication, division, and high speed I/O, just not built-in as primitive hardware functions. Floating point in software is pretty fast. Floating point addition and subtraction are less than 5us, multiplication is about 10us, and division is about 13us. The newer F32 package may be a little bit faster. Integer multiplication is about 2.3us for a 16 x 16 multiplication yielding a 32 bit product. Division of a 32 bit dividend by a 16 bit divisor takes about the same amount of time. 32 x 32 multiplication with a 64 bit product would take about 6us and division with a 64 bit dividend and 32 bit divisor would be similar.
High speed I/O depends on what you mean by that. Several asynchronous serial I/O objects can handle in excess of 230KBps with a full duplex connection. There are some half duplex asynchronous serial I/O objects that can handle in excess of 1MBps. Clocked SPI can be done several times faster than that.
There are a number of Propeller instructions specifically included for use with DSP algorithms using fixed point arithmetic. CORDIC is also very fast on the Propeller. You might have a look at Chip's vocal tract synthesis examples and the phoneme processing front end done by Phil Pilgrim.
You're correct that the Propeller doesn't fit well into the current uC market. It is unlike pretty much anything there. For some applications, it simply cannot compete at chip cost or with one or another specific features. On the other hand, it has unique features that make it very competitive for a variety of applications where ease of use, rapid prototyping, flexibility, deterministic timing are all important.
I don't think the propeller really fits into the current uC market. .....Propeller has more than enough MIPS to compete, but they're more awkward to use spread over multiple cores
Your comment has some merit. The Prop is very different than
most current uC's. The processor industry is at an awkward stage
where to keep pace with Moore's law they have had to move to
multiple cores on a single chip. This brings awesome power and
new abilities like improved timing and less need to do traditional
interrupt coding. But it also makes it very hard for programmers
not used to this strange new system. Programmers are artists and
just as an artist should not have to deal with all the nitty-gritty of
fashioning their artistic tools at the basic level they should not have
to deal with multiple cores directly. What is needed is a software
interface layer that insulates programmers from the complexities of
the multiple cores and presents them with a system that allows them
to program as though there is a single core that simply has exciting
new abilities to perform faster, more precisely and with far less fussing
about worrying over the speed of the code in traditional interrupt routines.
The Prop is a mini version of the powerful multiple core processors used
in most PCs and Laptops. The concept of many cores on a uC was not
dreamed up to keep pace with Moore's law since 400+mhz uC's still pack
quite a punch with just one core. The Prop is an attempt to move uC's into
the same new territory where everything else from laptops to super computers
now reside.
The interface layer of software is what is missing. New IDEs are needed with
languages that can handle all the details of spreading the work out across the cores
to best advantage. The programmers should be focused only on the art of programming
and not be constantly burdened by the dirty details of handling all those cores
profitably.
As multi core programmers there are things we simply should not have to deal with.
-How to use the power of each core fully and not waste anything. This
is hard since there are no interrupts available in the propeller's cores.
-How to communicate data easily between cores.
-How to create the various peripherals, these should be generated to the
programmers specs by the IDE itself. If you need USB just detail the
USB capability you need and the IDE should generate the code to create
it and never force you to deal with the details. Same with all the other
peripherals like video..etc. Just tell the IDE what viedo abilities you
need on what pins and it appears.
-How to keep track of how much processor power you have left. Things
like how many more precision timing tasks can be handled, how many
more peripherals can be generated..etc These details should be displayed
in a simple form by the IDE so the coder knows how much cowbell s/he has left.
I understand why no such IDE, compilers and languages exist. It will be
a monumental task to create them, the complexities are staggering. But
these are the tools programmers of multi core processors need and they
must be delivered to them.
Those problems were solved many years ago by Tony Hoare with his Communicating Sequential Processes (CSP). XMOS's hardware and XC language are based on CSP, their tools make hardware and software development of parallel processing systems consisting of an arbitrary number of devices communicating over high-speed XLinks quite straightforward.
Holly, if you're using the Prop as intended the Proptool and "object" model give you about as much of what you're talking about as is practical in an environment where waste is to be discouraged. Need video? Drop the object in yoru project and call the start method. Need to know how much cowbell is left? Hit F8. Cog usage is runtime so you do have to keep track of that, but it's not rocket science. You're not supposed to be micro-managing which cog does what, and the programming tools that do so (including the Forth implementation) really aren't doing it right.
Everyone wants more memory but it's worth keeping in mind that cogs are several times faster than they have any right to be at 80 MHz in part because of the 9-bit address space, which means every 32-bit instruction can contain source and destination addresses as well as the opcode instead of having to fetch those things in separate operations.
What I am seeing in this thread is that the greatest strength of the Propeller, and the main reason for Parallax to get into the IC design business and create it, is that it is different from other uC's. But its greatest weakness is that people don't understand how to use it because it is different from other uC's. And the most amusing thing about the Propeller is that both of those statements are true at the same time.
What I am seeing in this thread is that the greatest strength of the Propeller, and the main reason for Parallax to get into the IC design business and create it, is that it is different from other uC's. But its greatest weakness is that people don't understand how to use it because it is different from other uC's. And the most amusing thing about the Propeller is that both of those statements are true at the same time.
So that in a nutshell is the "Parallax Propeller Paradox"
if you're using the Prop as intended.... You're not supposed to be micro-managing which cog does what, and the programming tools that do so (including the Forth implementation) really aren't doing it right. ... more memory ...You're not supposed to be micro-managing which cog does what, and the programming tools that do so (including the Forth implementation) really aren't doing it right.
"as intended"? This appears to be a mistaken assumption. The Prop Tool and Spin are "Initial Option", not Only Option.
"Micro managing...cog" is a bloatware concept, which assumes the generic resource management provided by the automated parts of the system is sufficient. But then you have to carry all the overhead of the generic facilities.
Concerning forth, then next paradigm for function management (propforth V5.x summer 2011) is targeted to include "semi-automatic" cog/memory management where given functions load themselves into monory, execute, and unload themslves. Using SD as main storage, Hub function and data upto 2K and assembler functions upto 496 longs swap them selves in (call) and out (forget) as needed with no other overhead (the colorforth paradigm). The user has to consider how to deal with th SD transfer time in the context of the specific application's timing needs. Very simple, kickin' fast, perfect for my needs on the prop. This might be too different for people conditioned to operate in the "bloatware" paradigm. To me, this is a potentilly nice use of the prop
What I am seeing in this thread is that the greatest strength of the Propeller, and the main reason for Parallax to get into the IC design business and create it, is that it is different from other uC's. But its greatest weakness is that people don't understand how to use it because it is different from other uC's. And the most amusing thing about the Propeller is that both of those statements are true at the same time.
As a point of interest in favor of the Prop:
Last night, I was testing my High color VGA (on breadboard), I unplugged the wall wart from the board (still plugged into the monitor), and it continued to run for almost 2 full seconds off just the residual capacitive charge (I repeated this a couple times after that to verify). Now out of all the MCUs that I have worked with, no other MCU consumes little enough current to do this.
I've been in a coupla portable "propping" scenarios where I had a marginal battery. I could literally follow the battery down it's end charge curve, by programing in increasingly conservative ways. At one point, I could test the signal and a few sprites, but not a lot, as that was too many COGs doing too much. Eventually, it was signal COG only, and then nothing.
Propeller has more than enough MIPS to compete, but they're more awkward to use spread over multiple cores
That's an interesting perspective. Many here would say that the MIPS are easier to use in real-time application because
of the freedom from having to mess around with interrupts and task priorities etc.
Not to mention that having independent cores makes mixing and matching objects in your application an order of magnitude easier.
It depends on whether or not one expects peak, sequential compute. To get that, where all the MIPS are summed on the Prop, is awkward. The thing isn't built that way.
Where those MIPS can be distributed, the prop rocks!
Maybe we should have a CPU metric where concurrent MIPS and the number of concurrent entities is considered?
Prop would be 20 MIPS * 8, some other CPU might be 40 MIPS * 2, etc...
I know this will be an unpopular idea.
But the OBEX itself is a hindrance to
advancement of the state of the art in
multiple processor technology.
The IDE/Compiler/language should handle
the complexities of multiple cores. And should
generate and integrate peripheral functions.
This is not needed for geeks that like things like
assembly language and getting close to the hardware..etc.
But those types of individual are RARE! The people that will
do the most interesting work have no interest in these things.
We must create the tools for those creative people to utilize
multiple core processors since that seems to be the only
technology that is going to advance the state of the art in
computer power. (until a viable quantum computing processor
becomes available)
This is the mission, it is a difficult one.
edit: Instead of adding stuff to an OBEX, creative
coders should be improving an IDE that transparently
integrates peripheral abilities to create a more powerful
system for creating cool stuff that people want and need.
I've been in a coupla portable "propping" scenarios where I had a marginal battery. I could literally follow the battery down it's end charge curve, by programing in increasingly conservative ways. At one point, I could test the signal and a few sprites, but not a lot, as that was too many COGs doing too much. Eventually, it was signal COG only, and then nothing.
Impressive. I was running off the stored charge in the board and five 10 MicroFarad Caps for two seconds, with 8 cores running, KB & Mouse, pushing three 4 bit RDACs, and that is where I was very impressed with the Prop.
because of the freedom from having to mess around with interrupts and task priorities etc.
Not to mention that having independent cores makes mixing and matching objects in your application an order of magnitude easier.
The IDE/Compiler/language should handle the complexities of multiple cores. And should generate and integrate peripheral functions.
I think you have a valid point there.
Imagine this scenario:
1) I'm writing my Propller app. and I want to output some text via a UART, perhaps back to my PC for debugging.
2) Somewhere in my IDE I select a UART object and add it to my project, not having to write any code to do so.
3) Somewhere in my IDE is a box showing what objects I have included in my project.
4) I click on that new UART object and up pops a configuration box where I set pins, default baud rate etc etc.
5) I continue writing my code "uart.str(string("Hello world"))" etc etc.
This is the kind of thing that goes on with FPGA development tools. Want a particular logic block, a shift register
say? Just find it in the IDE and drop it into the design.
Personally I'm not so much into IDE's to do this kind of thing but I can see it's attraction.
Prof Braino, my point about managing cogs is that Chip clearly intended (and it says so in the data sheet) that cogs are generic; with minor exceptions involving rarified speed timing the eight cogs are interchangable. There isn't a lot of bloat associated with treating them that way; if you might want to stop the cog later it takes a whole byte to save which one started up for your cognew. Otherwise, nobody cares which cog is doing what; the prop itself sorts that out as you start them up.
This is what makes it easy to stick three resistors on the demoboard breadboard and pump out another video channel for debug information, or run three copies of the 4-port serial object (edited a bit for non-interference) and run 12 serial ports. But if you've drawn a map and said cog 6 is running video, what do you do when you want to run two video outputs? Now you've got a special map for that application, and my experience is that those special maps start to multiply like Darwin's finches. Just look at all the different versions of fullduplexserial tweaked for this and that particularity and imagine having the cog number hard-coded into it as well.
The problem I see with the obex -- and this could be considered a general problem for the Prop itself -- is that objects which are generic enough to be universally useful tend to be bloaty for any particular application which doesn't use all the embedded functionality. This flies in the face of the other Prop philosophy of learning to be frugal with resources to get the more out of a limited environment than most people would think possible. The obex is nice for n00bs because it can get them quickly up to speed on basic I/O, but then it traps them in a land of limited functionality until they learn enough Spin and PASM to tweak things.
The point of the "select your peripherals from the library in the IDE idea" is that it immediately advertises to anyone looking at Prop for the first time that rather than having no peripherals it has a vast array of them. Just pick what you want and configure it. Done.
Comments
And those kinds of products can often be "that competitive secret sauce" for those people willing to explore them and make them part of their overall effort. Might not need it all the time, but when you do need it, you need it really bad, kind of thing.
I constantly have to remind my team member (senior design) that using a Prop USB board + Spinneret is not a poor engineering design. His argument is that the fellow AeroQuad gentlemen use only one uC. I remind him that we are not creating a hobbyist toy but an Intelligent Autonomous UAV. Also if the AeroQuad added some of the capabilities of our design then they would have to increase their intelligence (another uC) as well.
Being able to quickly and efficiently relocate objects/code using the COGs has become a major advantage for me. Everyday I move a method/object to a different location, or I embed it in another COG, or I give it it's own COG, or I reverse what I just did and start at square one. I understand interrupts and how to use them, I would have thrown this project out the window if I had to use interrupts.
To counter: there will always be something better and nothing will ever be the best. i.e-there is always a faster car on the street.
Thanks Dan! I knew he was a Propeller fan (he used one in Bill Paxton Pinball and he's using a few in his new Pinball), but I missed this video.
As has been noted, many of the hobbyists of today are the commercial developers of tomorrow, and they tend to take there hobby preferences with them to the commercial products.
Thanks, glad someone got a kick out of that imagery.
Leon,
Again yes, you can get to unreachable pins on xcores by communicating over hardware links (I have done that tutorial example your refer to).
But, as I said, when you do so it costs dearly. Firstly there is the complication of having to write the code to do it, that's not hard but it's there. Worse is that it uses channel resources and
it wastes a precious thread at the "pin end". Or that channel end could be handled by an existing thread which makes spaghetti out of your code and impacts performance of that thread. Then there is the issue of all the time it takes to do that channel communication..
The Prop, having such a regular structure in it's cores and pins does not have any of these issues. Just write "outa[bla, bla]" and it's done. Why the X chip can't do this I don't know.
You are right, those hardware comms channels are excellent for communicating across cores and even more excellent when communication chip to chip.
I'd like to make a light hearted comparison:
One of the longest lived and most produced chip designs ever is the humble 555 timer. The 555 does not do anything much, there's no C compiler for it and I can't even run Linux on it:) But when you have a situation that needs one its perfect. One could add a lot of bells and whistles to a 555 but then it would not be a 555 anymore.
The Prop is not a microprocessor, my modern standards apparently it's not even a micro-controller. C support for it is poor and it does not run Linux. But I can see a lot of situations where if your situation needs one its perfect.
I must say this, without the Prop/Spin/etc..., my PRS cannot be realized in such a short period of time and with such tiny resources ... Prop's the way for me ....
The products make the company, not vice versa.
Parallax has a very rich and successful history. Look at the Stamp.
It's going to be the killer app with the marketing wrapper that shines the light brightly on the Prop to bring it out. It's capability is only truly appreciated by those of us who have really worked with it - and ultimately it does not matter anyway. The 68000 was always a better processor than the 8088 and it's evil spawn's but the IBM PC drug it into the light and made it a success.
Look at the iPod and Walkman. Sony had iPod (MP3) technology fully 3-4 years ahead of Apple. I still have my digital walkman. It was Jobs who put a white cord on the headset attached to a sexy package, came up with catchy marketing and put 99 cent songs on the web. Suddenly an MP3 player is cool.
I think the Prop will have it's day in the light but the Gracey's have done all they can, now it's up to us developers to make it really happen.
Jim-
Once I got over the servo voltage hump, my 6 axis robot arm project was much easier than it would have been with the BS2, and moderately easier than using an Arduino. The cogs allowed me to have floating point for the inverse kinematic transforms, a servo controller, and move generation in one tidy package.
I think you meant to type "Zog support for it is poor" - Catalina support for it is excellent!
Ross.
The propeller is a jack of all trades, but developers only need one trade, and they want a master.
High speed I/O depends on what you mean by that. Several asynchronous serial I/O objects can handle in excess of 230KBps with a full duplex connection. There are some half duplex asynchronous serial I/O objects that can handle in excess of 1MBps. Clocked SPI can be done several times faster than that.
There are a number of Propeller instructions specifically included for use with DSP algorithms using fixed point arithmetic. CORDIC is also very fast on the Propeller. You might have a look at Chip's vocal tract synthesis examples and the phoneme processing front end done by Phil Pilgrim.
You're correct that the Propeller doesn't fit well into the current uC market. It is unlike pretty much anything there. For some applications, it simply cannot compete at chip cost or with one or another specific features. On the other hand, it has unique features that make it very competitive for a variety of applications where ease of use, rapid prototyping, flexibility, deterministic timing are all important.
Your comment has some merit. The Prop is very different than
most current uC's. The processor industry is at an awkward stage
where to keep pace with Moore's law they have had to move to
multiple cores on a single chip. This brings awesome power and
new abilities like improved timing and less need to do traditional
interrupt coding. But it also makes it very hard for programmers
not used to this strange new system. Programmers are artists and
just as an artist should not have to deal with all the nitty-gritty of
fashioning their artistic tools at the basic level they should not have
to deal with multiple cores directly. What is needed is a software
interface layer that insulates programmers from the complexities of
the multiple cores and presents them with a system that allows them
to program as though there is a single core that simply has exciting
new abilities to perform faster, more precisely and with far less fussing
about worrying over the speed of the code in traditional interrupt routines.
The Prop is a mini version of the powerful multiple core processors used
in most PCs and Laptops. The concept of many cores on a uC was not
dreamed up to keep pace with Moore's law since 400+mhz uC's still pack
quite a punch with just one core. The Prop is an attempt to move uC's into
the same new territory where everything else from laptops to super computers
now reside.
The interface layer of software is what is missing. New IDEs are needed with
languages that can handle all the details of spreading the work out across the cores
to best advantage. The programmers should be focused only on the art of programming
and not be constantly burdened by the dirty details of handling all those cores
profitably.
As multi core programmers there are things we simply should not have to deal with.
-How to use the power of each core fully and not waste anything. This
is hard since there are no interrupts available in the propeller's cores.
-How to communicate data easily between cores.
-How to create the various peripherals, these should be generated to the
programmers specs by the IDE itself. If you need USB just detail the
USB capability you need and the IDE should generate the code to create
it and never force you to deal with the details. Same with all the other
peripherals like video..etc. Just tell the IDE what viedo abilities you
need on what pins and it appears.
-How to keep track of how much processor power you have left. Things
like how many more precision timing tasks can be handled, how many
more peripherals can be generated..etc These details should be displayed
in a simple form by the IDE so the coder knows how much cowbell s/he has left.
I understand why no such IDE, compilers and languages exist. It will be
a monumental task to create them, the complexities are staggering. But
these are the tools programmers of multi core processors need and they
must be delivered to them.
transparent cores are a good idea .
Peter
Everyone wants more memory but it's worth keeping in mind that cogs are several times faster than they have any right to be at 80 MHz in part because of the 9-bit address space, which means every 32-bit instruction can contain source and destination addresses as well as the opcode instead of having to fetch those things in separate operations.
What I am seeing in this thread is that the greatest strength of the Propeller, and the main reason for Parallax to get into the IC design business and create it, is that it is different from other uC's. But its greatest weakness is that people don't understand how to use it because it is different from other uC's. And the most amusing thing about the Propeller is that both of those statements are true at the same time.
So that in a nutshell is the "Parallax Propeller Paradox"
Well said.
(Your Message Is Too Short...)
"as intended"? This appears to be a mistaken assumption. The Prop Tool and Spin are "Initial Option", not Only Option.
"Micro managing...cog" is a bloatware concept, which assumes the generic resource management provided by the automated parts of the system is sufficient. But then you have to carry all the overhead of the generic facilities.
Concerning forth, then next paradigm for function management (propforth V5.x summer 2011) is targeted to include "semi-automatic" cog/memory management where given functions load themselves into monory, execute, and unload themslves. Using SD as main storage, Hub function and data upto 2K and assembler functions upto 496 longs swap them selves in (call) and out (forget) as needed with no other overhead (the colorforth paradigm). The user has to consider how to deal with th SD transfer time in the context of the specific application's timing needs. Very simple, kickin' fast, perfect for my needs on the prop. This might be too different for people conditioned to operate in the "bloatware" paradigm. To me, this is a potentilly nice use of the prop
Last night, I was testing my High color VGA (on breadboard), I unplugged the wall wart from the board (still plugged into the monitor), and it continued to run for almost 2 full seconds off just the residual capacitive charge (I repeated this a couple times after that to verify). Now out of all the MCUs that I have worked with, no other MCU consumes little enough current to do this.
Fun stuff.
That's an interesting perspective. Many here would say that the MIPS are easier to use in real-time application because
of the freedom from having to mess around with interrupts and task priorities etc.
Not to mention that having independent cores makes mixing and matching objects in your application an order of magnitude easier.
Where those MIPS can be distributed, the prop rocks!
Maybe we should have a CPU metric where concurrent MIPS and the number of concurrent entities is considered?
Prop would be 20 MIPS * 8, some other CPU might be 40 MIPS * 2, etc...
But the OBEX itself is a hindrance to
advancement of the state of the art in
multiple processor technology.
The IDE/Compiler/language should handle
the complexities of multiple cores. And should
generate and integrate peripheral functions.
This is not needed for geeks that like things like
assembly language and getting close to the hardware..etc.
But those types of individual are RARE! The people that will
do the most interesting work have no interest in these things.
We must create the tools for those creative people to utilize
multiple core processors since that seems to be the only
technology that is going to advance the state of the art in
computer power. (until a viable quantum computing processor
becomes available)
This is the mission, it is a difficult one.
edit: Instead of adding stuff to an OBEX, creative
coders should be improving an IDE that transparently
integrates peripheral abilities to create a more powerful
system for creating cool stuff that people want and need.
BTW: I love your avatar....I do hope that is not a real
picture of you though :-)
I think you have a valid point there.
Imagine this scenario:
1) I'm writing my Propller app. and I want to output some text via a UART, perhaps back to my PC for debugging.
2) Somewhere in my IDE I select a UART object and add it to my project, not having to write any code to do so.
3) Somewhere in my IDE is a box showing what objects I have included in my project.
4) I click on that new UART object and up pops a configuration box where I set pins, default baud rate etc etc.
5) I continue writing my code "uart.str(string("Hello world"))" etc etc.
This is the kind of thing that goes on with FPGA development tools. Want a particular logic block, a shift register
say? Just find it in the IDE and drop it into the design.
Personally I'm not so much into IDE's to do this kind of thing but I can see it's attraction.
This is what makes it easy to stick three resistors on the demoboard breadboard and pump out another video channel for debug information, or run three copies of the 4-port serial object (edited a bit for non-interference) and run 12 serial ports. But if you've drawn a map and said cog 6 is running video, what do you do when you want to run two video outputs? Now you've got a special map for that application, and my experience is that those special maps start to multiply like Darwin's finches. Just look at all the different versions of fullduplexserial tweaked for this and that particularity and imagine having the cog number hard-coded into it as well.
The problem I see with the obex -- and this could be considered a general problem for the Prop itself -- is that objects which are generic enough to be universally useful tend to be bloaty for any particular application which doesn't use all the embedded functionality. This flies in the face of the other Prop philosophy of learning to be frugal with resources to get the more out of a limited environment than most people would think possible. The obex is nice for n00bs because it can get them quickly up to speed on basic I/O, but then it traps them in a land of limited functionality until they learn enough Spin and PASM to tweak things.
The point of the "select your peripherals from the library in the IDE idea" is that it immediately advertises to anyone looking at Prop for the first time that rather than having no peripherals it has a vast array of them. Just pick what you want and configure it. Done.