C'mon inservi, you know you wanna program in prop assembler. Honestly, I found C just as difficult at first. Granted, that was a long time ago, but so was the assembly language learning. --and the CPU's (minus the 6809) were tough, compared to the prop. Many of them still are, IMHO.
Gonna pick up on the C complier, when it arrives?
hippi, I'll run a few spin variants tonight. I'm a bit curious too.
...err scratch that. Got sucked into the next TV Text driver revision.
Not to rehash anything but I believe that several of you guys misinterpreted Sapieha's comments. (Mention the "T" word and everybody's back gets up a little.)
I think what Sapieha actually meant... given all of these contraints... if it weren't for these other capabilities THEN the Prop would be a "T.."
He only has 400 motors to control... how hard could that be for 800 Propellers?
I have faith that the A/D issue will be addressed in PROP II, but there seems to be a pressing need right now.
You guys are designing boards every other clock cycle... how about a Prop board with really good A/D built in. Would an onboard instrument amplifier be too much to ask for?
I heard a rumor that there was a new demo board coming ... possibly having A/D on it, but I am guessing that it won't have an instrument amplifier.
With regard to the other issues... it all sounds like engineering to me.
See attached a prelim design of our PropBus System.
The motorship PCB ·is only slightly larger than a std business card.
The mother PCB has 3.3V + 5V connectors on it.
Also·a connector with power and the I2C signals..
plus a RCA connector for Video output ( debugging)
24 I/O lines are broken into 3 blocks of 8 I/O
Via ribbon cable IDC headers people can add their own little PCB's
Initially we will supply 3· I/O cards for simple prototyping· on the bench.
These little cards have 8 inputs Switches and 8 leds on it.
So our previously posted "Handy in/out schematic a few day's ago.
So the system is open and can be added to as you wish..
Commports·· RS485 etc etc etc...Ethernet ( how many i/o needed for that ??)
If anybody has any ideas or wants to develop their own cool add ons
let me know would love to see what can be done.
We seem to run into people wanting various options so it is hard
to pin it down what is needed .. that's why this simple platform to get started..
Have not as yet submitted the Gerbers files as yet still tossing and turning on the final
version ..
I agree, we are way off topic. The thread started out as a discussion about how to determine the speed of SPIN relative to ASM, and it has moved into an editorial about whether or not the speed of the Propeller is adequate, and whether it should be called a "toy". Whether SPIN is fast enough or not depends on your application, but it's useful to be able to gauge HOW fast it is. Let's have some science rather than opinions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Thank you all you guys to make my initial question in comparing SPIN/ASM so rich in answers ! We almost reach the 100 replies !
But that's what good forums are all about isn't it?
I learned that the PROP is a very good MC if you consider the price and what you get out of it. If you have to do a fast job than just kick off a COG and program in assembler, it's just a pitty that we can't use ASM inline functions with SPIN here I think that would be more flexibel. If you have todo some GUI (highlevel) eg showing values (I/O) on screen and stuff like that, than SPIN language is your way to go ; it's easy to learn and well documented. Of course there is the low memory part but I think for plenty MC applications this will be sufficient. (maybe not enough to handle an array of 200 motor drivers Just one small thing that I found odd at first as a newbie on this MC was the maximum number for a direct move in asm. (1FF)
So again thanks a lot you all and may the propeller be with us.
Given one's SPIN program is actually something in the HUB, being interpreted by a COG, wouldn't in-line assembly essentially be large memory model code, by default?
To do otherwise, one either has to cram that inline code into the interpreter COG (and there just isn't room for that), or fire off another COG, (which is the norm now) right? Am I missing some core thing here?
Ken Peterson said...
I suppose your added means that your definition of "inline" allows interpretation.
That, too...
But you first have to understand the consequences of Potatohead's analysis: There will be no space in the SPIN's COG!
(a) So you need a second COG
(b) So you have to load it with some program; again the SPIN Interpreter will not do this for you for its limitations as well as for compatibility
(c) So you have to organize that all by yourself - please do!
A simple possibility is:
- Write your "inline" code into your DAT as usual, each snippet starts with ORG 0
- Start the INLINE_COG
- Whenever you need a "snippet" tell the INLINE_COG to fetch the snippet - i.e. copy it to its own COG @ address zero - and "call" it.
This is simplicity itself. But after you have done it (20 minutes work) you will scratch your head and wonder what the difference is to the "old style"....
There however is one very important difference: You can load arbitrarily many pieces of code, of course only one afteranother, and no connection between them...
But - to my surprise - that "20-minutes-inline-COG" does not seem to exist. Too easy??
Comments
SPIN is very slow. That is the reason why my actual project are in c language in Microchip PIC.
Best regards,
dro.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Well, I can play Dogey Kong on my Prop!
hehe...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
hehehehe... [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Gonna pick up on the C complier, when it arrives?
hippi, I'll run a few spin variants tonight. I'm a bit curious too.
...err scratch that. Got sucked into the next TV Text driver revision.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Post Edited (potatohead) : 10/3/2007 7:14:34 AM GMT
Not to rehash anything but I believe that several of you guys misinterpreted Sapieha's comments. (Mention the "T" word and everybody's back gets up a little.)
I think what Sapieha actually meant... given all of these contraints... if it weren't for these other capabilities THEN the Prop would be a "T.."
He only has 400 motors to control... how hard could that be for 800 Propellers?
I have faith that the A/D issue will be addressed in PROP II, but there seems to be a pressing need right now.
You guys are designing boards every other clock cycle... how about a Prop board with really good A/D built in. Would an onboard instrument amplifier be too much to ask for?
I heard a rumor that there was a new demo board coming ... possibly having A/D on it, but I am guessing that it won't have an instrument amplifier.
With regard to the other issues... it all sounds like engineering to me.
I love it when you guys talk[noparse]:)[/noparse]
Rich
See attached a prelim design of our PropBus System.
The motorship PCB ·is only slightly larger than a std business card.
The mother PCB has 3.3V + 5V connectors on it.
Also·a connector with power and the I2C signals..
plus a RCA connector for Video output ( debugging)
24 I/O lines are broken into 3 blocks of 8 I/O
Via ribbon cable IDC headers people can add their own little PCB's
Initially we will supply 3· I/O cards for simple prototyping· on the bench.
These little cards have 8 inputs Switches and 8 leds on it.
So our previously posted "Handy in/out schematic a few day's ago.
So the system is open and can be added to as you wish..
Commports·· RS485 etc etc etc...Ethernet ( how many i/o needed for that ??)
If anybody has any ideas or wants to develop their own cool add ons
let me know would love to see what can be done.
We seem to run into people wanting various options so it is hard
to pin it down what is needed .. that's why this simple platform to get started..
Have not as yet submitted the Gerbers files as yet still tossing and turning on the final
version ..
Cheers
Ron· OZ
Post Edited (OzStamp) : 10/3/2007 11:04:44 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
But that's what good forums are all about isn't it?
I learned that the PROP is a very good MC if you consider the price and what you get out of it. If you have to do a fast job than just kick off a COG and program in assembler, it's just a pitty that we can't use ASM inline functions with SPIN here I think that would be more flexibel. If you have todo some GUI (highlevel) eg showing values (I/O) on screen and stuff like that, than SPIN language is your way to go ; it's easy to learn and well documented. Of course there is the low memory part but I think for plenty MC applications this will be sufficient. (maybe not enough to handle an array of 200 motor drivers
So again thanks a lot you all and may the propeller be with us.
cheers
Guy
To do otherwise, one either has to cram that inline code into the interpreter COG (and there just isn't room for that), or fire off another COG, (which is the norm now) right? Am I missing some core thing here?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
See what this means?
We HAVE ALREADY INLINE CODE!
It's done by COGNEW(@asm, somePar)
@deSilva:·· I suppose your added [noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The more I know, the more I know I don't know.· Is this what they call Wisdom?
Post Edited (Ken Peterson) : 10/3/2007 11:59:36 PM GMT
But you first have to understand the consequences of Potatohead's analysis: There will be no space in the SPIN's COG!
(a) So you need a second COG
(b) So you have to load it with some program; again the SPIN Interpreter will not do this for you for its limitations as well as for compatibility
(c) So you have to organize that all by yourself - please do!
A simple possibility is:
- Write your "inline" code into your DAT as usual, each snippet starts with ORG 0
- Start the INLINE_COG
- Whenever you need a "snippet" tell the INLINE_COG to fetch the snippet - i.e. copy it to its own COG @ address zero - and "call" it.
This is simplicity itself. But after you have done it (20 minutes work) you will scratch your head and wonder what the difference is to the "old style"....
There however is one very important difference: You can load arbitrarily many pieces of code, of course only one afteranother, and no connection between them...
But - to my surprise - that "20-minutes-inline-COG" does not seem to exist. Too easy??