Shop Learn
LOPO List of Propeller objects ...wanted ...needed suggestions.. — Parallax Forums

LOPO List of Propeller objects ...wanted ...needed suggestions..

OzStampOzStamp Posts: 377
edited 2006-02-28 15:40 in Propeller 1
List Of· Propeller Objects wanted ...suggestions please add

Post Edited (OzStamp) : 2/23/2006 5:11:50 AM GMT


  • FORDFORD Posts: 221
    edited 2006-02-23 06:04
    1wire comms.

    Serial data in with WAIT and timeout commands, like serin does now.

    SPSTR type function.

    HYP function
  • OzStampOzStamp Posts: 377
    edited 2006-02-23 06:58
    A new count function would be great.

    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.

  • william chanwilliam chan Posts: 1,323
    edited 2006-02-23 10:38
    Can we create a Propeller Object and then sell it on the forum?

  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-02-23 16:32
    William, the problem is that there is no compiled Object capability, all objects are included in on the source code level, so theres nothing to "lock up" the object. This was intentional because the designers did not want there to be a proprietary library industry for the chip popping up. They want a more communal "open source" style of programming the chip.

  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-02-23 17:06
    I take it there's not enough ram to make for "public" and "private" varibles within a program?
    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
  • Martin HebelMartin Hebel Posts: 1,231
    edited 2006-02-23 17:08
    Yup, there will be PUB and PRI functions, local and global variables and passing data similar to the examples you gave!

    Cool, eh?

    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 HebelMartin Hebel Posts: 1,231
    edited 2006-02-23 17:19
    Oh........ one other cool things to toss in.... variables and arrays may be passed by reference (@var) allowing the address of variables to be sent. Pointers!!


    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
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-02-23 19:07
    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
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2006-02-26 08:11
    This may seem a bit hokey for an OBJECT request, but having the ability to record and download data from a Cassette Recorder or other Audio Recording device would really appeal to some younger users. [noparse][[/noparse]I am only 58 years old.]

    "When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

    ······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan
  • StarManStarMan Posts: 306
    edited 2006-02-26 22:23
    My interests lie in architectural lighting.· If anyone is inclined to do so, I would like to see·a multiple·dimmer (triac) interface, maybe some DMX communications, and of course pwm control of LEDs.

    Chris I.
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2006-02-26 22:26
    Since I'm part of the EFX team, lighting control is something on my mind too.· The DMX512 stuff is trivial, really, and triac dimming shouldn't be particularly difficult considering the speed/instruction set of the Propeller.

    Jon Williams
    Applications Engineer, Parallax
  • Kaos KiddKaos Kidd Posts: 614
    edited 2006-02-27 14:31
    Hmmmm, no comments on a register object?
    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
  • Piper984Piper984 Posts: 74
    edited 2006-02-27 16:43
    Ok, maybe this is too far out there... Is it possible to have a PBASIC like interpretter running in one of the COGS? Like a BasicStamp2 emulation environment? I don't know if there would be much demand for it or not, and I assume that since Spin is interpretted as well, there might have been a purpose in not using basic syntax. But on the surface, it seems like a pchip cog could be programmed to interpret basic syntax read from eeprom location.
  • cgraceycgracey Posts: 13,610
    edited 2006-02-27 18:50

    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.
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-02-27 19:29
    Being in the process of writing some of Spin based programs, I will attest that everything Chip has said is true. Once you understand the way spin and the IDE works, it is a very "straight from head to code" process. Alot of the commands PBASIC users are used to aren't pre-built into Spin, but some of use are working on getting some object libraries together to ease the transisition for PBASICers (RCTIME, SHIFTIN and SHIFTOUT, etc etc).

  • Brian RileyBrian Riley Posts: 626
    edited 2006-02-27 23:03
    Thanks for the explanation Chip that is quite heartening. Its kind of neat to be here in the beginning.

    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
  • Paul BakerPaul Baker Posts: 6,351
    edited 2006-02-27 23:07
    Each product has its own niche to fill, so none of thier existing lines of products (BS series, SX) are slated for the scrap heap. Even the lowly BS1 has been reinvigorated by the Prop-1 controller, pretty good for a product around a decade old.

  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2006-02-28 06:41
    I am really looking forward to an easy language to use with this. Intially I was thinking that a Propeller Assembler would be quite fun, but now I begin to see that I might 'never get out of first gear.'

    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
  • John AbshierJohn Abshier Posts: 1,115
    edited 2006-02-28 15:40
    I have a few suggestions for robotics.·

    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??
Sign In or Register to comment.