It's nice to hear someone's experience with the Propeller. I think you've stated things well. I think you're also correct about why the Propeller is slow to be adopted.
By the way, have a look at the 4-port serial driver in the Object Exchange. It will save you a cog and works nicely. You do need to add a parameter to your calls, but that's easy to do with the editor's find/replace command.
I think we all stick to what we know and use until forced to change, like you needed to do for the VGA. I haven't changed PASM compilers (even though I tested it) because I had no requirement. That is, until I needed conditional assembly. It straight away flagged some warnings, one of which was a bug. Now I have conditionals, I won't be going back.
One of the problems for the prop is, as you stated, seen as a hobbyist device. Unfortunately, this is true in the most part, even though it is great for the prime time commercial use. Its benefits are just not appreciated, and it's not my expertise to give this sort of input - after 100,000's of micros under my belt, I appreciate what it can do, but I am really out of that game now.
You will note from my other threads, any project that is not specifically price conscious, can use more than 1 prop for a simple solutions. Offload the smart peripherals from the workhorse. Then the workhorse has the full facilities.
You mention common interfaces to the objects. I agree this is a problem. There are some fine ways to pass PASM to PASM and I am trying to get to a standard style, but there will always be an inherent different number of parameters. I have pulled a number of different ideas together. I like the command, result, followed by parameters (addr, hub, size, etc). The command is cleared when the task is complete and the result is -ve if an error occurs. There are two things to remember. Setting the command must be done last after the parameters are loaded, and must be cleared by the task cog last, after the result and parameters are written.
A lot of code seems to be written packing address/functions/etc into 1 long as if this takes less space, but in fact takes more code space to pack and unpack and longer also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
A lot of code seems to be written packing address/functions/etc into 1 long as if this takes less space, but in fact takes more code space to pack and unpack and longer also.
Sometimes it's not all about space. Reading and writing a single long is an atomic operation. That can be handy when you are multiprocessing [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
BradC: I obviously did not express myself correctly. I would rather use a few longs, one for each variable, rather than packing 4 sections into 1 long parameter for passing. It actually takes longer to pack/unpack, both in time and space, and it's harder to read.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
By the way, have a look at the 4-port serial driver in the Object Exchange. It will save you a cog and works nicely. You do need to add a parameter to your calls, but that's easy to do with the editor's find/replace command.
obex.parallax.com/objects/340/
It is nice to see this kind of discouragement ... it drives away competition [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I think we all stick to what we know and use until forced to change, like you needed to do for the VGA. I haven't changed PASM compilers (even though I tested it) because I had no requirement. That is, until I needed conditional assembly. It straight away flagged some warnings, one of which was a bug. Now I have conditionals, I won't be going back.
One of the problems for the prop is, as you stated, seen as a hobbyist device. Unfortunately, this is true in the most part, even though it is great for the prime time commercial use. Its benefits are just not appreciated, and it's not my expertise to give this sort of input - after 100,000's of micros under my belt, I appreciate what it can do, but I am really out of that game now.
You will note from my other threads, any project that is not specifically price conscious, can use more than 1 prop for a simple solutions. Offload the smart peripherals from the workhorse. Then the workhorse has the full facilities.
You mention common interfaces to the objects. I agree this is a problem. There are some fine ways to pass PASM to PASM and I am trying to get to a standard style, but there will always be an inherent different number of parameters. I have pulled a number of different ideas together. I like the command, result, followed by parameters (addr, hub, size, etc). The command is cleared when the task is complete and the result is -ve if an error occurs. There are two things to remember. Setting the command must be done last after the parameters are loaded, and must be cleared by the task cog last, after the result and parameters are written.
A lot of code seems to be written packing address/functions/etc into 1 long as if this takes less space, but in fact takes more code space to pack and unpack and longer also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Sometimes it's not all about space. Reading and writing a single long is an atomic operation. That can be handy when you are multiprocessing [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm