The beanie is not a problem. As we are talking about the perceptions of some supposed "professionals" here is my story (again) ...
As a young graduate engineer I was designing systems using microprocessors back in 1980. You know, the good old days of the 8080, Z80, 6800, 6809, etc, etc.
Despite moving more and more into software over the years I remained involved in processor selection and hardware design well into the 1990's. Intel 386, the Inmos Transputer and such.
Years later I felt the urge to do something with a modern MCU. What were my choices? ATMEL AVR and Microchip PIC basically.
On searching the catalogs, on line and off, that I found at the time I stumbled across this weird thing called a Propeller. From a company I had never heard of. It was not in there with the other microprocessors and MCUs but buried away in some other section of the catalog.
I quickly skipped over the Propeller. Why?
1) What are these "COG" things?
2) Hmm.. they seem to be 32 bit processors.
3) But only having 512 instructions to work in is kind of useless.
4) There are no peripherals. No UART, no PWM, no nothing much.
5) Yeah OK, seems to have some video support, but I don't need that.
6) No interrupts. What, how can anyone do anything serious with that?
7) No C compiler. At least give me something I can relate to.
8) Yes there is this weird Spin language. But the only compiler for that is Windows only. Basically useless to me. This is 2000 and something, where is any Open Source and Linux support?
So I persisted with the AVRs and PICs. Eventually I had pile of dead AVRs and PICs on the bench. Mostly because of badly set fuses due to the wonky Linux tools available at the time.
And I had one little project were having an interrupt upset the critical path was bad news.
On a whim I decided to check out that crazy Propeller thing.
Then the light came on. With multiple cores one does not need peripherals, just code the interface you need. With multiple cores one does not need interrupts, just dedicate a core to the interrupt handler. With multiple cores your timing need not be upset by external events, they are handled elsewhere. The small code space of a COG is not such a problem, most of your code is not so time critical.
The flexibility of the Propeller is amazing.
Anyway, after this ramble, note that the beanie logo was never a consideration.
Maybe this is the time to start creating a library of peripheral implementations with consistent interfaces so they are available when the chip hits the market. It's all well and good to say you can make any peripheral you want with smart pins but customers shouldn't have to do that for standard interfaces like UART, SPI, I2C, etc. There should be off-the-shelf implementations of these standard peripherals at day one.
Yes, libraries and examples are going to be needed.
The examples should include minimal (hello world) type use, and maximal ( 'I can have HOW many UARTS ?!'), as the minimal ones show how easy it is to use one, and the maximal ones show just how many you could have.
It is that second example, that will grab peoples attention.
There seems to be no attention going into a clean up pass on opcodes and assembler, in this quiet time. Not sure what Chip is working on right now ?
These comments are all enlightening; however, when making statements or suggestions, I think that we should generally avoid saying what someone else's company should *definitely* do or not do with respect to marketing or perhaps anything else. It seems to me that most things are not so black and white.
These comments are all enlightening; however, when making statements or suggestions, I think that we should generally avoid saying what someone else's company should *definitely* do or not do with respect to marketing or perhaps anything else. It seems to me that most things are not so black and white.
That's true I guess. Maybe it would be better to say "it would probably be a good idea if ..." rather than "should ...".
Hi Chip, I was just on the way to say: please stop this discussion and continue to work after that summer break.
As soon as the P2 is available, we should focus on searching the right application and ease hobby use cases by having a breakout board or just commercialize Peters p2d2.
But now you came first. I can not contribute to answer your question, as I have to learn to understand what we can do with P2 and in doing so I hope to learn mnenonics and syntax as I make use of the chip. However the mnemonics are.
In the meantime I continue to follow P on twitter and try to make good use of syntax and mnomonics I read, making some improvements like: Hundreds of Propusers will joinyou at Rockling. Will be quite a scene - great people who truly love this place and what come out of it!
When this long lasting nightmare is over, we will go to a bright future!
These comments are all enlightening; however, when making statements or suggestions, I think that we should generally avoid saying what someone else's company should *definitely* do or not do with respect to marketing or perhaps anything else. It seems to me that most things are not so black and white.
That's true I guess. Maybe it would be better to say "it would probably be a good idea if ..." rather than "should ...".
Of course, in a forum like this, any persons 'should' really means "it would probably be a good idea if ...", but one form is quicker to type
I've never used a Python-coded Assembler - does anyone have any speed benchmarks for Python as Assembler ?
I did dabble in fasmg, which is a script-based assembler, and that's very powerful, but not especially fast.
If the assembler has all the advanced features i'm happy to wait.
After waiting for FPGA tools, a minute is a snap.
and downloaded for a quick try...
first link one Seems unhappy with the directory tree, tho it looks fine to me....
The second link py6502, seems to (mostly) run the test examples of test6502.py etc fine in Python27 - this includes HEX dumps, SREC dumps, symbols, and a Simulation dump of 200 lines.
Missing from that seems to be Linking, and Macros, & Conditional assembly, but it is a basic functional framework.
and the above ones seem to need Pythonesque wrappers, so are not quite the classic
\path\AssemblerName.exe -s-w-i-t-c-h-e-s FileName.ASM that users might expect ?
We might say P2Fire. But, uncomfortable connotations. Chip in Red Bluff lives too close to the Carr Fire just 31 miles north outside Redding. Chip, is the smoke bad where you are? P2Caliente?
Also, "Fire" is too close to "Hot", and we don't want that!. Maybe P2WayCool.
For the last few days, the sky has been getting clearer. There was so much ash in the air a few days ago that you couldn't even tell what part of the sky the sun was in. Ash has been settling on to everything outside, just a wispy coating.
In that case, it should be the Propeller Phoenix .
Love the comments and story that Heater wrote about "The beanie is not the problem..." August 11. Absolutely agree 100 percent. We here on the forum know the Prop is a great platform, but how do we transfer that knowledge to everyone else? The name "P2" means nothing to the microprocessor world. That is why I like the Propeller "Phoenix" name - it gets you attention as something different and more powerful. A good start, but what else? and why? Of all the "stuff" the Prop can do, why is it that the PIC, Arduino and their ilk getting all the attention? These platforms are definitely harder to get working, just look at some of the articles written on them. Line after line of code & stuff you have to do, and in the end they still lack in speed and ease of use. But people still spend inordinate amounts of time trying to "fix" them. I have never had that much trouble with any of my Prop projects, just sayin'
Keep it simple. Keep it industrial. As we saw, the beanie ("art") caused some to question the serious nature of the Propeller, which may have negatively impacted sales. In fact, I think it would be wise to adopt the current P2 industrial style to the P1 and put the beanie (and other graphical elements) out to pasture. Save the art for marketing materials -- don't use it on chips.
Comments
As a young graduate engineer I was designing systems using microprocessors back in 1980. You know, the good old days of the 8080, Z80, 6800, 6809, etc, etc.
Despite moving more and more into software over the years I remained involved in processor selection and hardware design well into the 1990's. Intel 386, the Inmos Transputer and such.
Years later I felt the urge to do something with a modern MCU. What were my choices? ATMEL AVR and Microchip PIC basically.
On searching the catalogs, on line and off, that I found at the time I stumbled across this weird thing called a Propeller. From a company I had never heard of. It was not in there with the other microprocessors and MCUs but buried away in some other section of the catalog.
I quickly skipped over the Propeller. Why?
1) What are these "COG" things?
2) Hmm.. they seem to be 32 bit processors.
3) But only having 512 instructions to work in is kind of useless.
4) There are no peripherals. No UART, no PWM, no nothing much.
5) Yeah OK, seems to have some video support, but I don't need that.
6) No interrupts. What, how can anyone do anything serious with that?
7) No C compiler. At least give me something I can relate to.
8) Yes there is this weird Spin language. But the only compiler for that is Windows only. Basically useless to me. This is 2000 and something, where is any Open Source and Linux support?
So I persisted with the AVRs and PICs. Eventually I had pile of dead AVRs and PICs on the bench. Mostly because of badly set fuses due to the wonky Linux tools available at the time.
And I had one little project were having an interrupt upset the critical path was bad news.
On a whim I decided to check out that crazy Propeller thing.
Then the light came on. With multiple cores one does not need peripherals, just code the interface you need. With multiple cores one does not need interrupts, just dedicate a core to the interrupt handler. With multiple cores your timing need not be upset by external events, they are handled elsewhere. The small code space of a COG is not such a problem, most of your code is not so time critical.
The flexibility of the Propeller is amazing.
Anyway, after this ramble, note that the beanie logo was never a consideration.
The Propeller is not an MCU as anyone knows such things. It does not have what they expect.
It's very flexible, like an FPGA. Of course FPGA vendors will supply IP blocks for any and every peripheral interface you can imagine.
The Prop is not an MCU. It's an FPCA. "Field Programmable Core Array". A blank slate that needs those IP blocks to make it functional.
Brilliant Heater.
Yes, libraries and examples are going to be needed.
The examples should include minimal (hello world) type use, and maximal ( 'I can have HOW many UARTS ?!'), as the minimal ones show how easy it is to use one, and the maximal ones show just how many you could have.
It is that second example, that will grab peoples attention.
There seems to be no attention going into a clean up pass on opcodes and assembler, in this quiet time. Not sure what Chip is working on right now ?
As soon as the P2 is available, we should focus on searching the right application and ease hobby use cases by having a breakout board or just commercialize Peters p2d2.
But now you came first. I can not contribute to answer your question, as I have to learn to understand what we can do with P2 and in doing so I hope to learn mnenonics and syntax as I make use of the chip. However the mnemonics are.
In the meantime I continue to follow P on twitter and try to make good use of syntax and mnomonics I read, making some improvements like: Hundreds of Propusers will joinyou at Rockling. Will be quite a scene - great people who truly love this place and what come out of it!
When this long lasting nightmare is over, we will go to a bright future!
Of course, in a forum like this, any persons 'should' really means "it would probably be a good idea if ...", but one form is quicker to type
I really want to have a P2.
For some strange reason I like this idea..... :cool:
I found a couple of Python Assemblers...
https://github.com/ranu010101/CS242-two-pass-assembler
https://github.com/dj-on-github/py6502
and downloaded for a quick try...
first link one Seems unhappy with the directory tree, tho it looks fine to me....
The second link py6502, seems to (mostly) run the test examples of test6502.py etc fine in Python27 - this includes HEX dumps, SREC dumps, symbols, and a Simulation dump of 200 lines.
Missing from that seems to be Linking, and Macros, & Conditional assembly, but it is a basic functional framework.
and this one looks to have macros and a Loader, I think based on the Simplified Instructional Computer
https://github.com/TejaBlaze/System_Software
and the above ones seem to need Pythonesque wrappers, so are not quite the classic
\path\AssemblerName.exe -s-w-i-t-c-h-e-s FileName.ASM that users might expect ?
As requested, topic split to create new thread here:
Assembler mnemonics and syntax
http://forums.parallax.com/discussion/comment/1443744/#Comment_1443744
My car likes this!
Out of the ashes, (P2 Hot)