LOPO List of Propeller objects ...wanted ...needed suggestions..
OzStamp
Posts: 377
List Of· Propeller Objects wanted ...suggestions please add
Post Edited (OzStamp) : 2/23/2006 5:11:50 AM GMT
Post Edited (OzStamp) : 2/23/2006 5:11:50 AM GMT
Comments
Serial data in with WAIT and timeout commands, like serin does now.
SPSTR type function.
HYP function
For example counting on an input for an indefinate amount of time possibly synced
to an external input or internal flag condition ·would be really cool.
Possible format·· Count CntPin,SyncPin/var·0/1,Register.
Count pulses on Input "CntPin" while SyncPin or Internal Flag X is 0 or 1 and
store the amount of pulses "Register"
The register would have a Long type variable 32 bits
Pulse rate slow·from 0.5HZ to highest possible "100KHZ" would be great
This instruction would be very useful in many applications.
Often used in the Factory Automation area "Function" Counter with Preset
Small PLC's do this sort of stuff on multiple inputs with great ease.
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
That would lead to programming with calls like "CALL GETREADING(Var...Var...Var)" and "Var=READTHERMO(Var,Var,Var)"
...
I would hope that someone is writing a book or two about the ASM and Spin language...
As well as maybe telling the folks at ISIS about the design so they can create a model for it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
Cool, eh?
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
Disclaimer: ANY Propeller statements made by me are subject to my inaccurate understanding of my limited time with it!
Southern Illinois University Carbondale -Electronic Systems Technologies
Personal Links with plenty of BASIC Stamp info
and SelmaWare Solutions - StampPlot - Graphical Data Acquisition and Control
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
Disclaimer: ANY Propeller statements made by me are subject to my inaccurate understanding of my limited time with it!
Southern Illinois University Carbondale -Electronic Systems Technologies
Personal Links with plenty of BASIC Stamp info
and SelmaWare Solutions - StampPlot - Graphical Data Acquisition and Control
I think I just wet my self! AWESOME!
A register object.
This would allow the programmer to take a set pf pins and define them as bits within the object.
The object could allow the bit for bit direction of each pin within the register object to be set.
It could also allow for the reading & setting of bits as numerical values.
It would need some Prams
SIZE Examples :LITTLENIB (2 bits), NIB (4 Bits), BYTE (8 Bits), WORD (16 Bits)
PINS (A list of pins in the order they would appear in the Register)
Example of a PINS arguement: (2,3,0,1) (Assign Pin 2= Bit0, Pin 3 = Bit1, Pin 0=Bit2, Pin1 = Bit3 in the correct order for lo/hi xfers)
An Example of how it might look:
Some_Var REGISTER WORD PINS(8,9,10,11,12,13,14,15,0,1,2,3,4,5,6,7)
This would create a register var that would internaly store the hibyte/lowbite needed for i/o with a number of products.
It would need to directly interface with any existing bit modifiers.
And it would need modifiers for PIN states, for inverting pin states at the hardware level, not in code level.
Example: An active Low is the inversion of Active High, so, you could invert the PINs output (in the register setup), and treat it like a regular pin in code.
The idea stems from groups of pins designated from real world devices that have indivual bit pairs meaning things.
The ability of creating a register var from a group of pins simplifies the program logic and readability of the program.
This makes reading, writing and changing direction of groups of pins much easier to follow, and catching errors much easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
Chris I.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Something that could make reading encoders much simplier...
Or dealing with other hardware simplier to deal with
I like the lighting controll ideas.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket
KK
·
I'm looking forward to us getting some documentation to you about Spin,·because I think you will see that not only is it a·huge improvement over PBASIC, but it is·VERY simple, too. I think the Spin examples shown·thus far look intimidating because Spin is being used to do housekeeping that has more to do with 'hardened' objects than regular coding.
Here's what Spin is all about:
1) Easy to learn and use
2) Broad and deep·application
3) Small, highly-readable source
4)·Tidy object modularity
5) Zero redundancy - no need to restate·function/procedure interfaces, etc.
6) "Gets out of·the way" so you can think clearly about your code's behavior·and not worry if you've properly answered a bunch of riddles.
To me,·Spin is, by·far, the·cleanest and simplest language I've ever used.·I love to program in it! I type what I mean and it stares right back at me, clear as a bell. I find it·exceptionally easy to revisit code later and understand·my original intentions.
Of course, I might be partial,·but·please understand: It wasn't made the way it was because·that was·all we could do, or even because we wanted to be·unique. It was made to be exactly what we thought would be best, all things considered, and we did not compromise. Jeff and I spent hundreds of hours massaging concepts, often sleeping on matters,·before things took their final forms. Concepts would often get revisited, and sometimes deeply revised, setting off chains of re-thinks.·For every·ten steps forward, there were nine steps backwards. This is where most of our energy went. The actual implementation was a lot of work, but the hardest part was·developing a congruous set of hardware and software concepts that harmonized perfectly together. At this point, I'm not wishing we would have done·anything differently. I think it all turned out just right. In time, any warts that are there will be exposed through use, and we'll use whatever we learn to make the next generation better.
So, please don't get worried about Spin. This is a giant non-issue. If you had learned Spin first, and then saw PBASIC, you would be getting a headache for far worse reasons.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
One concern that I have is the large investment in time, effort and money I have in BS2 & SX based materials. What is the future of the BS2 and SX lines and PBASIC-SX/B-CCS/C languages? Do you see them phasing down and/or out over the next 3-4 years in favor of the Prop chip and it successors? Or will they evolve in parallel filling one set of niches as the Propeller and its successors fill the 'heavy lifter' niches?
thanks ...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
cheers ... brian riley, n1bq, underhill center, vermont
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10
Since so much needs to be defined and understood about the new architecture, a good higher level language being developed by those that created the concept is really the best way to begin.
Regarding different languages, devices seem to dictate what is most appropriate. I know it seems like a lot, but one has to trust that they can learn far more than they realize. And, it can be quite an enjoyable achievement.
For example - The average person knows about 25,000 words; an intelligent person might know about 60,000 or more. Algebra, Trig, Geometry, Calculus, Boolean Logic, Various Numerical Based maths are all just part of the 'languages' we assimilate in learning about electronics.
[noparse][[/noparse]For Chinese, I have had to learn 6 - 7 phonological notations and both traditional and simplified character sets. My English students learn 3-8 phonological systems in order to read Western dictionaries.] Those who try to learn just one, only learn one point of view and become self limited, stunted.
The BasicStamp will always be PBasic, The SX [noparse][[/noparse]while more adaptible] is really two flavors [noparse][[/noparse]high level] SX/B and [noparse][[/noparse]low level] SASM.
C programmers seem to want to have someone else write the low level language, but disdain Basic as 'unsophisticated'. It is an awkward cultural phenomina more than a functional requirement to have C. C is great for huge programs in large machines with teams of programers, but these are one chip computers with one or a few people doing the design.
The Propeller is far too unique to become a subset of something else's language. It is a fresh palette and a new canvas. As with all hardware, it will have a resident Assembly language that directly derives out of the 'machine code' -- but the higher level, new user language that is intuitive of its own nature is a logical and organic evolution of the project.
Above all don't set limits on yourself about learning more languages -- enjoy what you will be discovering.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)
······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
1st:· pose object.· Input is channel A & B from two encoders, wheel base and wheel diameter, initial x, y, theta (defaults to 0,0,0).· Output is x, y, theta.· Possible also vx and vy.
2nd: motion control (low level).· Input is speed and rotational velocity, PID constants.· Output is speed control to motors HB-25 format, PWM format, Poulou format.
3dr:·motion control (high level).· Input is go to x, y, theta at vel.· Could be modeled after the motor controls in Interactive C??