Just from my POV, one of the reasons the Prop didn't take the world by storm is because it was difficult to ascertain at a glance what it was good for. The numbers weren't that appealing. What can be done in 512 words?? Turns out a whole lot! But I didn't believe it until I saw it. So I don't think video harmed the Prop's reputation, or pigeon-holed it, ever.
Marketing is indeed different than advertising. Marketing the P1, and probably the Px, imho, should be all about what it can do...simultaneously...and to perfection. It is too difficult to explain at a glance the efficiency of the Propeller's instruction set, or the nuances of cog-to-cog cooperation, or the synergy between SPIN and PASM. Save your breath and your money, and just demonstrate all the crazy results of those cooperating factors.
What It Good For: Determininstic execution, very fast. This is thanks to NO INTERUPTS. Also due to Minimal Hardware Overhead.
What It Good For: Low Power applications. Also due to Minimal Hardware Overhead.
What It Good For: Many things are once. Eight tasks in hardware, many more with a slight execution time cost (with cooperative execution)
Nothing else comes close, at least in my limited experience. My caution is against changes that jeapordize determininistic fast execution, and/or sacrifice low power.
With more cogs, RAM, pins, we can perfom tasks of greater complexity for modest additional power cost.
I would not worry. Video will be there and Chip said he's doing VGA through the DACS. This means we can do everything else. Composite at the speed these COGS should be is a no brainer, and we can do a nice signal too! The YCbCr format can also be done. We are just going to need to write some reasonable color space schemes.
I would not worry. Video will be there and Chip said he's doing VGA through the DACS. This means we can do everything else. Composite at the speed these COGS should be is a no brainer, and we can do a nice signal too! The YCbCr format can also be done. We are just going to need to write some reasonable color space schemes.
You know, the math block being able to do something like 12.5M operations per second *per cog* means it should keep up with SD pixel rates. That divided by 15625 gives 800 pixels/lines. You could do a cordic or math operation on every pixel
I think what User Name was getting at is the thought processes that happen if the average MCU user accidentally stumbles across the Propeller: "
Hmmm...8 processors, that might be interesting...
Only 512 instruction can be run a native speed in each processor, that's pretty useless isn't it?
I can run bigger programs but I need an interpreter, eeew, horrible slow...
The thing does not even support interrupts...
God, it doesn't even have the simplest peripherals on chip, like UARTs, SPI, I2C, PWM, like every other 50 cent chip has had for years now.
How could you ever use this to do anything serious like the work I do every day...
Must be a toy...
Next.
"
And that is why the Propeller is virtually unknown in such circles.
Braino,
I think what User Name was getting at is the thought processes that happen if the average MCU user accidentally stumbles across the Propeller:
... which is good to know, but entirely uunrelated to the list of high level requirements. Confusing non-requirements with requirements is a leading cause of problems.
Wishes, intent, hopes, what if's, etc are NOT testable with yes/no or present/not-present. And noone can objectively determine if they are present and complete. And therefore will NEVER be present and complete.
IF you want a project to be completed, there needs to be a list of criterion to qualify as complete.
The items on the list must be testable as present or not.
Then one can determine if the percentage of the items on the list is great enough to consider complete.
Otherwise you get what you get, and it won't be what you actually want. Or at least it has not been so far. (this included to pretty much every project I have worked on).
The requirements list starts with the highest level requirement.
Then is broken down to the items that support each high level requirement.
And so on.
CARE must be taken to NOT allow items into the top of the list that arre not high level requirements, and not to let items into the lower lists that do not support the high level requirements.
THIS is the method to eliminate feature creep. It also allows us to keep within budget, and finish early.
Most folks don't believe this and/or refuse to follow these guidelines. Its not my money, why do I get so riled up?
There you go with the lists and book keeping again. Well, we all know all that. We don't disagree.
Thing is we don't know the high level requirements. The other thing is it's not for us Parallax groupies to set them.
We can only clamor for this or that personal favorite feature. Or, better still, throw ideas for solutions into the pot.
Now, my description of an engineers thought processes when finding the Propeller is tangentially related. You see he has his own top level requirements for whatever project he is trying to do. In his mind they will already have been translated into sub requirements on the device he is looking for. Must have X amount of RAM and Y amount of speed. Must have UART, SPI, PWM etc etc etc. As such the Prop looks useless. It does not meet those requirements.
Of course our engineer is making a bit of a mistake. For example, yes he needs serial comms. He has translated that into "must have UART hardware". He is not open to the other possibilities of getting his functionality.
And that is all to do with the sub-thread here about marketing the Propeller. Raising awareness of the possibilities.
Of course our engineer is making a bit of a mistake. For example, yes he needs serial comms. He has translated that into "must have UART hardware". He is not open to the other possibilities of getting his functionality.
How about we make one of our high-level requirements to get more open minded engineers?? That is testable and we can answer it with a Yes/No!
If you want to market the Prop with umpteen serial ports, SPI, I2C, PWM, VGA etc etc then you need to actually have that functionality in the chip from power-up assigning functions to cores etc by means of mask ROM or even a preprogrammed SPI Flash as a chip set. I know that sounds dumb but doing it that way gets it into the comparison charts with "peripherals" and then each "peripheral" is listed as being smart and totally reconfigurable so that a serial port could even become a 32 channel PWM for instance (whaaaa!). Then even though it has all these "peripherals" it still has not dual core, not quad core, but octal core (left), yes, 32-bits x 100MIPs x 8 but wait... you can swap some of the cores for peripherals or some of the peripherals for cores all the way to 16 whopping cores (whaaaa......thunk!).
When the engineer gets up from the floor again they just know that they have to try this chip out for sure. Now, the next question is where's that low cost evaluation board they can order?
Thought: The evaluation board might be the perfect vehicle to have a P2 with a preprogrammed SPI Flash or alternatively the tools should automatically load the "object" simply because this peripheral has been referred to.
I would not worry. Video will be there and Chip said he's doing VGA through the DACS. This means we can do everything else. Composite at the speed these COGS should be is a no brainer, and we can do a nice signal too! The YCbCr format can also be done. We are just going to need to write some reasonable color space schemes.
It was nice to have VGA and NTSC/PAL on Propeller for hobby use.
But for industrial use (high volume customers) you need at least:
1) Parallel RGB interface (some of them use LVDS and MIPI)
2) Be able to address at least 1.5 MB of RAM (much better if RAM is already embedded)
Some people says that none of the propeller high volume customers use VGA. This is obvious, why they would want to use a VGA interface plus an expensive VGA to Parallel RGB converter if they already have other ICs that interface directly using Parallel RGB to the display?
There you go with the lists and book keeping again. Well, we all know all that. We don't disagree.
Thing is we don't know the high level requirements. The other thing is it's not for us Parallax groupies to set them.
Do not misunderstand. My function is not to set requirements.
My function is to ASK whether SOMEBODY owns this task. And if somebody performed this task, did they check that what ever they call "requirement", are these testable in some way?
From these two answers, we can very accurately the likelyhood of failure (both no = automatic fail very likely).
To determine the likihood of success is just as easy. We divide the number of requirements that are testable by the total number of requirements. That number is the maximum success we can expect.
Actual success is the number of requirements whose test actually passed divided by the total number of requirements.
As I said, I don't set the requirements. I just do integer math. And point out that it can be EASY to get 100% sucess.
Only ONE person owns the project, this would be Chip. Everyone else's opinion is just a buffet of arbitrary raw data. I offer only a light snack. Chip owns the project, did anyone check for testable requirements?
Thought: The evaluation board might be the perfect vehicle to have a P2 with a preprogrammed SPI Flash or alternatively the tools should automatically load the "object" simply because this peripheral has been referred to.
Cypress operate along these lines with the PSoC - they have module data sheets, and those are soft modules that do get revisions from time to time.
Prof, if I go "up on level" to business related requirements and then come back down a level, here's what I find required
- code protection
- more pins
- video output with 8 bit or better luminance
- analog input flexibility similar to the digital flexibility we enjoy on P1. This is a big, hard to find feature, and key differentiator from going FPGA (your initial requirements as listed are actually a good case for going direct to fpga)
Not far below those requirements are
- debugability. Monitor, pasm instruction for firing off a serial message, great.
As far as numbers of cogs, ram, pins, MHz are concerned, I don't really care as long as it can do the job. I'd accept a 50MHz P2, no problem. But doubling of each, as is proposed now, is fantastic if it can be achieved. Any excess resources if available should go into hub ram, definitely.
Finally, P2 needs to represent "what's possible" rather than something squeezed through a v-model of requirements. That's what I find so refreshing about the P1.
Prof, if I go "up on level" to business related requirements and then come back down a level, here's what I find required
- code protection
- more pins
- video output with 8 bit or better luminance
- analog input flexibility similar to the digital flexibility we enjoy on P1. This is a big, hard to find feature, and key differentiator from going FPGA (your initial requirements as listed are actually a good case for going direct to fpga)
I wonder if there are also on the official Parallax requirements on Chip's clip board?
- code projection: What does this buy us? it only delays someone figuring out the code. Cheaper and just about as effective to just dip the thing in epoxy, isn't it? It this isn't free I question its value.
- more pins: I hope this IS on the real requirements, I am very interested in 64 pins.
- video oputput: This is cool, but tneds to go unused 7 times on prop 1 chips that use video, and 8 times on prop chips that don't use video. I question the value add compared to better cheaper video solutions. (But I wouldn't say no it a next version had video).
- analog input: If analog input were available on every pin, even with some additional external hardware, this might be big. But is would have to compare favorable against standard AD parts.
Not far below those requirements are
- debugability. Monitor, pasm instruction for firing off a serial message, great.
This is already present as a software solution, as demonstrated with propforth. But I guess this is not universally impementable with other tools, or folks would have done it.
As far as numbers of cogs, ram, pins, MHz are concerned, I don't really care as long as it can do the job. I'd accept a 50MHz P2, no problem. But doubling of each, as is proposed now, is fantastic if it can be achieved. Any excess resources if available should go into hub ram, definitely.
If excess resourses existed, I would agree with RAM
Finally, P2 needs to represent "what's possible" rather than something squeezed through a v-model of requirements. That's what I find so refreshing about the P1.
What could "squeezed through a v-model" mean? Either you have a plan, or you don't. When you don't have a plan, you might get something, but its not what you wanted, and its expensive, and it late.
...
Again, this is not to SET the requirements, just to ask if requirements have been set, and give some examples of what tends to lead to success, contrasted with what tends to lead to over runs in time, budget, a result that "ain't quite right". Believe you me, I've seen the latter enough to not wish it on anybody, particularly my aquainances in this community.
I wonder if there are also on the official Parallax requirements on Chip's clip board?
- code projection: What does this buy us? it only delays someone figuring out the code. Cheaper and just about as effective to just dip the thing in epoxy, isn't it? It this isn't free I question its value.
- more pins: I hope this IS on the real requirements, I am very interested in 64 pins.
- video oputput: This is cool, but tneds to go unused 7 times on prop 1 chips that use video, and 8 times on prop chips that don't use video. I question the value add compared to better cheaper video solutions. (But I wouldn't say no it a next version had video).
- analog input: If analog input were available on every pin, even with some additional external hardware, this might be big. But is would have to compare favorable against standard AD parts.
Parallax does have a list. Ken published it recently (weeks ago). The list was quite short although IIRC two items were added that were missed.
IIRC these were on the list...
(a) Code protection (its done and was on P2 and will be on P1+/P2)
(b) More hub memory (done)
(c) C programming (WIP)
(d) More pins (done)
(e) Faster (done - P2 achieved and now P1+/P2 still achieves requirement)
(f) Hubexec (included by Chip/Ken from what I recall)
(g) SPI Flash (done) (included by Chip)
I don't recall if analog was on the list or not. IMHO it is a requirement.
Surprisingly, Video was not on the list.
Comments
What It Good For: Determininstic execution, very fast. This is thanks to NO INTERUPTS. Also due to Minimal Hardware Overhead.
What It Good For: Low Power applications. Also due to Minimal Hardware Overhead.
What It Good For: Many things are once. Eight tasks in hardware, many more with a slight execution time cost (with cooperative execution)
Nothing else comes close, at least in my limited experience. My caution is against changes that jeapordize determininistic fast execution, and/or sacrifice low power.
With more cogs, RAM, pins, we can perfom tasks of greater complexity for modest additional power cost.
You know, the math block being able to do something like 12.5M operations per second *per cog* means it should keep up with SD pixel rates. That divided by 15625 gives 800 pixels/lines. You could do a cordic or math operation on every pixel
Plus a whole lot of "special effects and fades"
I think what User Name was getting at is the thought processes that happen if the average MCU user accidentally stumbles across the Propeller:
"
Hmmm...8 processors, that might be interesting...
Only 512 instruction can be run a native speed in each processor, that's pretty useless isn't it?
I can run bigger programs but I need an interpreter, eeew, horrible slow...
The thing does not even support interrupts...
God, it doesn't even have the simplest peripherals on chip, like UARTs, SPI, I2C, PWM, like every other 50 cent chip has had for years now.
How could you ever use this to do anything serious like the work I do every day...
Must be a toy...
Next.
"
And that is why the Propeller is virtually unknown in such circles.
... which is good to know, but entirely uunrelated to the list of high level requirements. Confusing non-requirements with requirements is a leading cause of problems.
Wishes, intent, hopes, what if's, etc are NOT testable with yes/no or present/not-present. And noone can objectively determine if they are present and complete. And therefore will NEVER be present and complete.
IF you want a project to be completed, there needs to be a list of criterion to qualify as complete.
The items on the list must be testable as present or not.
Then one can determine if the percentage of the items on the list is great enough to consider complete.
Otherwise you get what you get, and it won't be what you actually want. Or at least it has not been so far. (this included to pretty much every project I have worked on).
The requirements list starts with the highest level requirement.
Then is broken down to the items that support each high level requirement.
And so on.
CARE must be taken to NOT allow items into the top of the list that arre not high level requirements, and not to let items into the lower lists that do not support the high level requirements.
THIS is the method to eliminate feature creep. It also allows us to keep within budget, and finish early.
Most folks don't believe this and/or refuse to follow these guidelines. Its not my money, why do I get so riled up?
There you go with the lists and book keeping again. Well, we all know all that. We don't disagree.
Thing is we don't know the high level requirements. The other thing is it's not for us Parallax groupies to set them.
We can only clamor for this or that personal favorite feature. Or, better still, throw ideas for solutions into the pot.
Now, my description of an engineers thought processes when finding the Propeller is tangentially related. You see he has his own top level requirements for whatever project he is trying to do. In his mind they will already have been translated into sub requirements on the device he is looking for. Must have X amount of RAM and Y amount of speed. Must have UART, SPI, PWM etc etc etc. As such the Prop looks useless. It does not meet those requirements.
Of course our engineer is making a bit of a mistake. For example, yes he needs serial comms. He has translated that into "must have UART hardware". He is not open to the other possibilities of getting his functionality.
And that is all to do with the sub-thread here about marketing the Propeller. Raising awareness of the possibilities.
How about we make one of our high-level requirements to get more open minded engineers?? That is testable and we can answer it with a Yes/No!
When the engineer gets up from the floor again they just know that they have to try this chip out for sure. Now, the next question is where's that low cost evaluation board they can order?
Thought: The evaluation board might be the perfect vehicle to have a P2 with a preprogrammed SPI Flash or alternatively the tools should automatically load the "object" simply because this peripheral has been referred to.
It was nice to have VGA and NTSC/PAL on Propeller for hobby use.
But for industrial use (high volume customers) you need at least:
1) Parallel RGB interface (some of them use LVDS and MIPI)
2) Be able to address at least 1.5 MB of RAM (much better if RAM is already embedded)
Some people says that none of the propeller high volume customers use VGA. This is obvious, why they would want to use a VGA interface plus an expensive VGA to Parallel RGB converter if they already have other ICs that interface directly using Parallel RGB to the display?
Do not misunderstand. My function is not to set requirements.
My function is to ASK whether SOMEBODY owns this task. And if somebody performed this task, did they check that what ever they call "requirement", are these testable in some way?
From these two answers, we can very accurately the likelyhood of failure (both no = automatic fail very likely).
To determine the likihood of success is just as easy. We divide the number of requirements that are testable by the total number of requirements. That number is the maximum success we can expect.
Actual success is the number of requirements whose test actually passed divided by the total number of requirements.
As I said, I don't set the requirements. I just do integer math. And point out that it can be EASY to get 100% sucess.
Only ONE person owns the project, this would be Chip. Everyone else's opinion is just a buffet of arbitrary raw data. I offer only a light snack. Chip owns the project, did anyone check for testable requirements?
I do get excited about this stuff don't I?
Skip the requirements. Whatever. I don't care if it has no CORDIC or multiply or HUB slot sharing or Turbo Encabulator.
Just give me the chip already!
Agreed! (But now I want a Turbo Encabulator also...)
As you see it uses a Propeller
Cypress operate along these lines with the PSoC - they have module data sheets, and those are soft modules that do get revisions from time to time.
- code protection
- more pins
- video output with 8 bit or better luminance
- analog input flexibility similar to the digital flexibility we enjoy on P1. This is a big, hard to find feature, and key differentiator from going FPGA (your initial requirements as listed are actually a good case for going direct to fpga)
Not far below those requirements are
- debugability. Monitor, pasm instruction for firing off a serial message, great.
As far as numbers of cogs, ram, pins, MHz are concerned, I don't really care as long as it can do the job. I'd accept a 50MHz P2, no problem. But doubling of each, as is proposed now, is fantastic if it can be achieved. Any excess resources if available should go into hub ram, definitely.
Finally, P2 needs to represent "what's possible" rather than something squeezed through a v-model of requirements. That's what I find so refreshing about the P1.
I wonder if there are also on the official Parallax requirements on Chip's clip board?
- code projection: What does this buy us? it only delays someone figuring out the code. Cheaper and just about as effective to just dip the thing in epoxy, isn't it? It this isn't free I question its value.
- more pins: I hope this IS on the real requirements, I am very interested in 64 pins.
- video oputput: This is cool, but tneds to go unused 7 times on prop 1 chips that use video, and 8 times on prop chips that don't use video. I question the value add compared to better cheaper video solutions. (But I wouldn't say no it a next version had video).
- analog input: If analog input were available on every pin, even with some additional external hardware, this might be big. But is would have to compare favorable against standard AD parts.
This is already present as a software solution, as demonstrated with propforth. But I guess this is not universally impementable with other tools, or folks would have done it.
If excess resourses existed, I would agree with RAM
What could "squeezed through a v-model" mean? Either you have a plan, or you don't. When you don't have a plan, you might get something, but its not what you wanted, and its expensive, and it late.
...
Again, this is not to SET the requirements, just to ask if requirements have been set, and give some examples of what tends to lead to success, contrasted with what tends to lead to over runs in time, budget, a result that "ain't quite right". Believe you me, I've seen the latter enough to not wish it on anybody, particularly my aquainances in this community.
IIRC these were on the list...
(a) Code protection (its done and was on P2 and will be on P1+/P2)
(b) More hub memory (done)
(c) C programming (WIP)
(d) More pins (done)
(e) Faster (done - P2 achieved and now P1+/P2 still achieves requirement)
(f) Hubexec (included by Chip/Ken from what I recall)
(g) SPI Flash (done) (included by Chip)
I don't recall if analog was on the list or not. IMHO it is a requirement.
Surprisingly, Video was not on the list.
Anybody have a link? That's really all I wanted.