Help create the Spin Standard Library!

A big focus of PropellerIDE is to make Spin a more compelling choice for Propeller development. With that in mind, I have recently started reworking the Spin library bundled with PropellerIDE.

Objective

I want to create a library similar in nature to the LameStation SDK, but useful for any kind of Propeller development. Here's why:
  • With a consistent style and organization, experience with one object informs the use of many others.
  • With few, well-known objects, it is easy to determine the right object to use for a given job (for example, the current library has 3 different floating point libraries and I have no idea which one to use)
  • With well-defined interfaces, modules can be upgraded with new IDE releases while minimizing impact to existing code, or swapped out for similar objects.

Contributing

This is a big job, and I can't do it by myself. Here's how you can help.
  • Suggestions/code submissions of objects to incorporate.
  • Review/explanation of existing objects to see which are actually useful and/or appropriate for a basic library.
  • Comparison of similar objects for inclusion (FullDuplexSerial vs. Parallax Serial Terminal, or both, for example).

Important Links

Don't be shy!

Your contributions will help ensure that there is a place for Spin in Parallax products for years to come.

If you love this fun, little language, and want to make sure it lives on forever, help us make a stellar standard library that shows off everything Spin is capable of.
LameStation, the game console parents want their kids to play!
PropellerIDE, an integrated, cross-platform IDE for the Propeller
PropellerManager, an event-driven C++ API for managing Propeller devices
«1345

Comments

  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,194
    edited 2015-12-29 - 07:43:42
    Bret,

    I agree with most of your style recommendations, except for:

    1. Indentation: Spin standard is two, not four spaces. Four is too much.

    2. The first character of global variables should be capitalized; local variables, lower-case.

    3. The use of CamelCase or Underline_style should be optional. Both are equally readable.

    4. I like a leading underline (sometimes) for PRIvate method _names. It's a useful sigilt to distinguish from PUBlic method calls.

    But those are just my personal preferences that I don't even always follow. More generally, why bother enforcing style at all? Such dictums only irritate people who have their own ways of coding. So long as a program is readable, what difference does it make?

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • Parallax started something like that a while ago, calling it 'Gold Standard' Objects. They even developed style guidelines and such. As far as I was able to follow just FullDuplexSerial reached the 'Gold Standard'. Participation was minimal and so it dried out.

    The library delivered with the PropTool is full of useful stuff, but sadly quite confusing for a beginner. The best stuff is from @Chip, but sadly he likes 2 letter label/constant names. His video drivers would be way more understandable with meaningful long descriptive names.

    Sadly they aren't, and all the other guys like baggers and potatohead and whoever else kept that short naming thing for constants and labels doing their video stuff.

    No way to grook that for a beginner. So doing a rework of that library is a honorable task. Sisyphus comes into my mind for some reason.

    Some years ago I started a standard library by using the wonderful spin documenter from @PhiPi. Something like Doxigen for spin, creating nice html docs out of the spin source.

    So I reworked Kye's FAT_Engine for example. But a couple of month later he came out with a new version and all my work was useless.

    Now with Parallax using GIT things might change. But if changes do not make it upstream, all effort is useless.

    Sadly,

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Duane DegnDuane Degn Posts: 10,002
    edited 2015-12-29 - 07:57:43
    I just tried to find the "Parallax Gold Standard" style guide which I have been following since it was introduced but the link I had for it was dead.

    In the Gold Standard, IIRC, the underline style was used for constants. All variables began with a lowercase letter. Method names were capitalized.

    IMO, it's important to differentiate between variable names and method names.

    BTW, programming in Spin/PASM is pretty much my day job these days. I've been trying to learn to use the Arduino and C. I remember initially being irritated to have to learn Spin in order to use the Propeller but now I find C very irritating to use. All those unneeded characters which are redundant if one uses proper (two spaces) indentation.
  • Bret,

    I agree with most of your style recommendations, except for:

    1. Indentation: Spin standard is two, not four spaces. Four is too much.

    2. The first character of global variables should be capitalized; local variables, lower-case.

    3. The use of CamelCase or Underline_style should be optional. Both are equally readable.

    4. I like a leading underline (sometimes) for PRIvate method _names. It's a useful sigilt to distinguish from PUBlic method calls.

    But those are just my personal preferences that I don't even always follow. More generally, why bother enforcing style at all? Such dictums only irritate people who have their own ways of coding. So long as a program is readable, what difference does it make?

    -Phil

    Style is arbitrary. Consistency is what's important. Programmers spend vastly more of their time reading code than writing it. I want it to be as easy as possible to pick up a new object and use it. Without consistency, every object is a new headache, a new puzzle to unravel. This project reduces the barriers to entry for new users.
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • msrobots wrote: »
    Parallax started something like that a while ago, calling it 'Gold Standard' Objects. They even developed style guidelines and such. As far as I was able to follow just FullDuplexSerial reached the 'Gold Standard'. Participation was minimal and so it dried out.

    The library delivered with the PropTool is full of useful stuff, but sadly quite confusing for a beginner. The best stuff is from @Chip, but sadly he likes 2 letter label/constant names. His video drivers would be way more understandable with meaningful long descriptive names.

    Sadly they aren't, and all the other guys like baggers and potatohead and whoever else kept that short naming thing for constants and labels doing their video stuff.

    No way to grook that for a beginner. So doing a rework of that library is a honorable task. Sisyphus comes into my mind for some reason.

    Some years ago I started a standard library by using the wonderful spin documenter from @PhiPi. Something like Doxigen for spin, creating nice html docs out of the spin source.

    So I reworked Kye's FAT_Engine for example. But a couple of month later he came out with a new version and all my work was useless.

    Now with Parallax using GIT things might change. But if changes do not make it upstream, all effort is useless.

    Sadly,

    Mike

    Sisyphus absolutely comes to mind, but I have no intention of working against contributors.

    That's why I will only be incorporating new objects that follow the style guide, or are stable enough that it doesn't matter whether the original creator plays ball or not. Many library objects may be only loosely based on the original objects, with no effort made to keep track of the upstream. Such a strategy is not ideal, but if community participation does fall flat, this is the only way to do it without losing my mind.

    But that's why I am reaching out. If developers want to participate and have their objects included with every download of PropellerIDE, they can work with me to do it. With GitHub, developers can update their objects in place in the repository, so the Spin standard library can and should be the new upstream for anyone serious about contributing.

    If we all work together, we can see Spin become a serious contender to C in Parallax Education programs, which would mean more investment, more development, more user base, more everything. So why wouldn't Spin developers want to participate?

    A project like this benefits the entire Spin community, so let's make it happen.
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • Cluso99Cluso99 Posts: 14,570
    edited 2015-12-29 - 11:58:43
    Brett,
    A few things come to mind...

    The gold standard was a great idea but the only object done was FullDuplexSerial. It was done without consultation so the couple of changes that I had done and posted in obex wasn't included.

    There have been many discussions about making it possible to have a mini operating system and using the top of hub for rendezvous locations. On every instance, no one was interested in creating a standard except a small number of us. With the total lack of enthusiasm and support, a few of us did our own thing.

    Now many of those no longer frequent the forums.

    I truly wish you well with your endeavours but please don't expect wonders here. It's been tried before without success :(
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Whilst I think it would be great to have a standard Spin library I think this is an idea that is doomed to failure. That sounds very negative but I have perhaps a more workable suggestion below.

    I think it will fail because:

    0) I always thought OBEX was the "Standard Library". It's the first place I look for anything I need for the Propeller. It's pretty well static as any any standard library should be.

    1) This idea has been tried before. The "Gold Standard Object" intitiative. It flopped.

    2) Fixing up formatting and such of someone else's work is basically forking it. A bad idea unless the original authors are on board. Any bug fixes or new features they add to their project/object won't make it into the standard fork.

    3) It's "busy work" with no functional gain that nobody really wants to do.

    Basically all such standards for code contributions to OBEX should have been in place from the beginning. Then the "standard" would be done already.

    What I would like to see is a sort of package manager as used in Python or Node.js where a simple command like "ppm install f32" (Propeller Package Manager) installed the f32 object into my project from OBEX and away I go. What do I care how it is written or formatted? Of course the Prop Tool or other IDEs would have a GUI to do this.

    Now for the positive suggestion:

    Work on such a standard library for the PII. The PII is a clean slate. Many of those good things in OBEX and elsewhere will need to be ported to the PII. Whilst that major work is going on standards for formatting and whatever can be applied. It's quite likely that the original authors of those objects won't be around or so inclined to do this work so a fork is justified. Many people will be motivated to take their favorite thing from OBEX and "fix it for the PII". It's not just "busy work" it has a functional outcome.

    Arrange that this all happens in a git (github) powered OBEX/Standard Library for the PII















  • There are a couple of reasons why the Gold Standard flopped. The most important is that it expressly forbade several tricks which are absolutely essential for some applications due to the Propeller's memory limitations. For example, it required you to "properly" use par to pass parameter blocks to pasm cogs instead of poking the parameters into the image before doing cognew. But par is wasteful and unnecessary if you know you aren't going to stop and restart the cog or change those parameters on the fly. It's nice and clever that Chip's video objects can do that but I have never had a need for it and I have cog objects that simply wouldn't fit in the cog if I had to do that. IIRC it also didn't allow any of the mechanisms that would be used to reclaim a cog image's Hub RAM once launched. The fact is we've all done some pretty clever programming to cram an application into 512 longs or 32 kb, and any standard that forbids those methods is doomed to fail.
  • I have all the time wanted to impose a coding/naming standard onto myself. I haven't ever fully succeeded, but partially. E.g. sometimes the function of a variable is so obvious that I don't bother calling it intNameofThis or such, but in general I try to make the code legible, even educational, if I can.
    I was quite frustrated in my early Spin days that the code I found in OBEX was not more self explanatory, and more logically structured. A lot of it is just hacked together, it seems. On the other hand, I guess a lot would say that my code has too much overhead in it.
    Not long ago I was advised by the Forum not to use the |<n operator, but instead 1<<n, even if it is slightly less efficient - because with the latter syntax 'anyone' will understand it. I think that was a good advice and a good attitude to promote.
    I suspect it will be hard to make the majority follow any kind of strict standard, as it is mostly the 'newbies' who benefits from it, but would help make Spin survive. I hate all that void() { } etc. of the alternative.

    Erlend
    21st century - when everything changes
    "Better with a DAT and a COG than with a CAT and a DOG"
  • Heater.Heater. Posts: 21,213
    edited 2015-12-29 - 16:58:26
    Strangely enough in recent times I have come to love Javascript.

    JS is full of () and {} and ;

    Now all my JS code is very nicely and consistently formatted. How did that happen? Well for JS there are many tools called "linters", jslint, jshint, eslint and so on. Most of them can be run from the editor as I type my code. The linters get things underlined with red squigglies if they think I am straying from correct style. I fix it as I type.

    Those () and {} and ; make all this possible. I'm guessing its not so easy for a language with white space indenting and no formal specification.

    Without such tools it's a huge and boring task to enforce any "house style."

    Now, I'm not sure why a "house style" is even needed. A thousand people have created a thousand useful objects for Spin, in their own way, as long as it works as advertised I'm happy. What do I care how they wrote it. Same as if I use "printf" or whatever in C.

    For educational examples certainly there is a need for clarity and consistency. But converting all of OBEX to be so is not realistic.






  • potatoheadpotatohead Posts: 9,697
    edited 2015-12-29 - 17:32:36
    I disagree on formatting work in the OBEX. Just link back to the original. It's all MIT, so do what you want. That is what the code is there for.

    Re: little nubby variable names

    Noted. :)

    I actually caught some flack for verbose comments and more aggressive code section delineation, so I quit. Strange world we live in sometimes.

    There is only one style I consider important and that is more and better comments. Code can be documentation. Good comments help a lot with that.

    A long while back, I went through graphics_demo.spin and commented the crap out of it, and added a few helper methods. Few people have used the cooler stuff that code does. The tv, vga, and tvtext.spin drivers can actually do a lot more than it appears.

    I thought on reason for that was lack of docs. The HYDRA book helped, as did comments.

    But, somehow that code still goes underused. I do however get more requests for help from people who have read the commented code, so there is that, and it's good.

    Is it lack of interest? Is it lack of general video and graphics info, definitions, how to info?

    Heck, if I know. But I do know more comments is better.

    While making this library, why not comment the code more? Pick it apart and share what you learn? The originals are still there, and people can work with either one, and many people are gone or have just moved on, but the code is still there.

    I'm working on some driver related things for P2 and will consider more comments, better comments, and a least comments that expand on those little variable name nubs.

    The thing is, I personally dislike long var names. Short is good, once the name gets mapped to an idea. So, I'll split the middle, keep short names, but comment them. Fair?

    :)
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • I do very strongly agree with Heater on house style.

    People write how and what they write. When we get in the way of that, we don't get as much code. I personally have not put code out there in the past for concerns over style, etc...

    But, I'm past that now. Just put it out there, no worries.

    I think it's much better to comment and document .

    If you have to prioritize... which comes first?

    Consistency, or understanding?

    I'll take the latter every time. The former makes life a bit easier, but not that much easier.

    YMMV, of course!
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • potatoheadpotatohead Posts: 9,697
    edited 2015-12-29 - 17:44:10
    As far as education goes, more material on how to understand code is probably good. Picking through a video driver, for example, means knowing something about video in addition to knowing something about code.

    When I worked through Chip's TV.spin long ago, I printed it out, then started reading and annotating. Did a lot of looking up of video concepts, and a lot of tests by changing the code and looking at output with a TV and scope.

    IMHO, how to do that is an important skill. The code is a great document itself, but one must couple that with subject matter learning too, or it won't make much sense.

    That cycle is currently repeating with P2 video. New concepts in play. I've got a driver printed out, am testing, etc... all over again. Chip will put the bare nubs out there. It's enough to go forward and it's enough to grok how, what, and why, but you gotta work for it.
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • There are as many 'standards' as there are programmers. Each is valid.

    The term 'herding cats' springs to mind.

    Sandy
    Infantryman's Axiom; Always cheat, always win.
  • I've been quietly keeping up with thread and quite like the idea. I agree with potatohead's thoughts, which I think are in line with Brett's original idea: no need to convert the whole obex, but take what's necessary from it to create a new standard library with common functions in it. If everything is going to be categorized as a single "library" then it I firmly believe it should be consistent - in naming style, whitespace, coding conventions, etc.
    potatohead wrote: »
    The thing is, I personally dislike long var names. Short is good, once the name gets mapped to an idea. So, I'll split the middle, keep short names, but comment them. Fair?

    Here's where I disagree. I think long and descriptive variable and function/method names are a good thing. Very good. Long enough that comments on the variables become redundant and are therefore deleted. To make this reasonable though requires using an editor with autocomplete, which we finally have with PropellerIDE.
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: http://david.zemon.name:8111/?guest=1
  • There is always find and replace!
    Do not taunt Happy Fun Ball! @opengeekorg ---> Be Excellent To One Another SKYPE = acuity_doug
    Parallax colors simplified: https://forums.parallax.com/discussion/123709/commented-graphics-demo-spin<br>
  • Sandy,
    There are as many 'standards' as there are programmers.
    Must be more than that, I have double standards :)

    More seriously people change their style as their experience grows. Or they don't worry about it much and whatever comes out that day is OK, was it 4 space tabs or 8, ah never mind.

    For example, that urge for copious comments soon fades when you realize that comments are lies. They are traps waiting for you. Always out of date and incorrect. As an author you tire of having to read, re-reread and adjust your comments every time you tweak your code or refactor it some way.

    Naming things is the hardest problem in computer science. Names are also lies and traps.

    That "int32TurnipCounter" may have been a 64 bit counter of any kind of vegetable for years but no one wanted to change it because it means editing 20 modules. And then you'd have to fix the documentation to reflect that change.














  • Are there any new library features that are needed that are not covered by what is already in the OBEX?
  • This thread seems to have gone all over the place, so to clear some things up:
    • I am not replacing OBEX. They accomplish different goals. As David said, this library would contain only a small subset of what can be found in OBEX.
    • I am not reformatting OBEX. Objects that find their way into the Spin standard library would be maintained separately and free to diverge from their sources. Original authors are free to continue doing what they do, or they can move their objects over to live full-time as components of the standard library, and maintain them there. I don't care about bleeding edge. I want a solid foundation available to everyone without needing to look for it. Many objects will rarely need to change once installed.
    • This is not the "Gold Standard". This effort is not based on the "Gold Standard" or any other standard. It does not forbid any technical tricks so long as the behavior is well-understood and won't interfere with other objects.
    • The style guide is set. The project will use the style guide as written, but it can be updated if there are issues it does not address or there are conflicting rules.
    • This project already exists. There already is a library included with every PropellerIDE release; I want to make it better. All this discussion about whether it should be done is unnecessary.
    • This project benefits users now. A Spin package manager is a fantastic idea, but requires building a new OBEX with an API, which is far beyond what I'm proposing currently. Propeller 2 is another issue entirely. I believe that the Propeller never reached its full commercial potential, and a big reason is because it's inaccessible to beginning programmers. This project provides a Python-like "batteries included" experience that Propeller Spin desperately needs to make it easier to just get up and go with the platform.

    Now, maybe I haven't been clear, but I don't think what I am asking for is so far-fetched. So far, there haven't been any responses in the spirit of the original post. So to reiterate, this is what I am asking for:
    • Suggestions/code submissions of objects to incorporate.
    • Review/explanation of existing objects to see which are actually useful and/or appropriate for a basic library.
    • Comparison of similar objects for inclusion (FullDuplexSerial vs. Parallax Serial Terminal, or both, for example).
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • I use the OBEX a lot to get examples of code that I may need. My issue and correct me if I'm wrong... Is that If I include a library all of the functions are compiled. There is no #IfDef capability in the SPIN Compiler.

    So with all being said above about naming conventions a better compiler would be helpful.

    Your goal of a "Standard Library" is great but will run the propeller chip out of memory because you are including everything.

    Someone Please tell me I'm WRong on this!!!

    FYI: I have programmed in many languages and I love SPIN!!! It needs a few more functions but all and all it is pretty good for micro control.
  • This may not be another Gold standard, but it kind of looks like one. If I understand the requirements, the objects must be useful, and they must be written following a standard format, and they must be approved by someone to be included. That's pretty much what the previous Gold standards were.
  • digital32 wrote: »
    My issue and correct me if I'm wrong... Is that If I include a library all of the functions are compiled. There is no #IfDef capability in the SPIN Compiler.

    PropellerIDE uses OpenSpin which does include support for basic pre-processor options such as #ifdef and #ifndef
    https://github.com/parallaxinc/OpenSpin/wiki/Preprocessor
    David
    PropWare: C++ HAL (Hardware Abstraction Layer) for PropGCC; Robust build system using CMake; Integrated Simple Library, libpropeller, and libPropelleruino (Arduino port); Instructions for Eclipse and JetBrain's CLion; Example projects; Doxygen documentation
    CI Server: http://david.zemon.name:8111/?guest=1
  • digital32 wrote: »
    I use the OBEX a lot to get examples of code that I may need. My issue and correct me if I'm wrong... Is that If I include a library all of the functions are compiled. There is no #IfDef capability in the SPIN Compiler.

    So with all being said above about naming conventions a better compiler would be helpful.

    Your goal of a "Standard Library" is great but will run the propeller chip out of memory because you are including everything.

    Someone Please tell me I'm WRong on this!!!

    FYI: I have programmed in many languages and I love SPIN!!! It needs a few more functions but all and all it is pretty good for micro control.

    Unused method removal is close to being available in OpenSpin but I have not released a version of PropellerIDE that includes it.

    Even so, I want to keep core objects as small as possible, with a focus on smaller APIs and using nested objects instead of large monolithic objects wherever possible. I have had good luck with this strategy on the LameStation SDK, where the single largest consumer of RAM in the average LameStation game is game content.

    Take FrappyBard. The entire game, including 7 core LameStation libraries and game content, is 10kB.
    https://github.com/lamestation/lamestation-sdk/blob/master/games/FrappyBard/FrappyBard.spin

    It's possible to do a lot in the little space on the Propeller.
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 22,194
    edited 2015-12-30 - 05:40:44
    Brett Weir wrote:
    I want to keep core objects as small as possible, with a focus on smaller APIs and using nested objects instead of large monolithic objects wherever possible.
    Good! I've always felt that not every I/O object needs dec, hex, and other such methods. Those can be handled by a separate formatting object. Character and string methods are plenty sufficient for basic I/O.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
  • It would be nice to have a good selection of standard objects.

    IMHO it is best to have an easy to understand object rather than dictate standards. Long meaningful names do not always equate to short names with good comments.

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Well, let's get started then. I'm looking for objects that can fill the following roles.

    Here's what I'm looking for:
    • FullDuplexSerial would be great for com.serial
    • Float32 would be great as math.float
    • TV would be great for display.tv

    Off the top of your heads, do you guys have any suggestions for any of these? Can you think of any I haven't listed here that should be covered by this library?
    sensor.distance.ir
    sensor.distance.laser.sf02
    sensor.distance.laser.sf10
    sensor.distance.ping
    sensor.camera
    sensor.color
    sensor.altimeter
    sensor.gas
    sensor.gps
    sensor.tilt
    sensor.etape
    sensor.temperature
    sensor.humidity
    sensor.flex
    sensor.motion.xband
    sensor.motion.soundimpact
    sensor.light.qti
    sensor.gyroscope
    sensor.accel.tri.mma7455
    io.eeprom
    io.eeprom.spi
    io.sdcard
    com.can
    com.usb
    net.xbee.mesh
    net.xbee.wifi
    
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • I'll drop in my 2 cents worth, as a somewhat newbie to spin.
    Readable objects are important, with descriptive variable and function names when possible.
    Also important are the demos that go with those objects.
    Frustrating is when I open a demo for a spin object and it has outputs to TV or LCD screens, which seems silly, as I have a nice usb connection and serial terminal ready to go, already hooked up. Of course demos for those things would output to them, but not ping or float32 demos, right?
    Demos that have little or no comments as to what they are doing and why are also frustrating, or no pin definition as a constant. Demo's are where the comments need to be most verbose, as that is where the newbie learns.
    ~ Roxy ~ Propeller Girl
    "Pardon my innocence, as I'm often wrong, and when not, I am probably incorrect"
  • Roxanna77 wrote: »
    Frustrating is when I open a demo for a spin object and it has outputs to TV or LCD screens, which seems silly, as I have a nice usb connection and serial terminal ready to go, already hooked up.

    There has definitely been an overreliance on video objects in the demo code. Reducing the complexity and "time-to-run" of examples is another target I have for this rework.
    LameStation, the game console parents want their kids to play!
    PropellerIDE, an integrated, cross-platform IDE for the Propeller
    PropellerManager, an event-driven C++ API for managing Propeller devices
  • Brett,
    I have done 2 LCD routines, one for the Nokia 5110 mono and one for what they call the 5110 color although its nothing like the 5110 interface. Most of my code is well documented although I don't tend to use long names. There are demo programs for these. Since both these LCDs are cheap on eBay, they make good little displays.

    If you use FullDuplexSerial (FDX) can you please add the few mods I did - in the obex as FullDuplexSerial_rr004? - buffer sizes can be changed by powers of 2. Cant recall the other tiny bits, but they are commented clearly what I have done.

    Another good object is the multiple serial driver - cannot recall the name but I think Tracy Allen was involved. I have never looked/used it, but the discussions have been good on this driver.

    I also have a pair of 1pin drivers for composite monochrome TV and PS2 keyboard (obex under debug). On the thread there are diagrams of how to simple connect these with a few resistors. FYI the TV only requires 1 series resistor between ~100R-1K.

    As for SD, you cannot go past Kye's FAT driver. I have split this into two sections, the spin functions and the PASM driver. I have added a few more calls to the spin code. I have folded the PASM code to reduce the size somewhat, but its more of a black box that just handles FAT16/32 raw access, plus rebooting. I use it in my PropOS, which BTW I believe is well documented.

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Brett Weir wrote:
    Off the top of your heads, do you guys have any suggestions for any of these?
    I think your object names need to specify particular products. For example, Parallax sells two color sensors, and they interface in drastically different ways. So sensor.color (or sensor.light.color) is too generic. And even the same product might interface in several different ways, requiring several different objects. The TSL1401 linescan module, for example, has an analog output, entailing either an A/D converter (but which one?) or a sigma-delta input circuit. Or ... the analog output can simply be thresholded by driving a logic input pin.

    -Phil
    “Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupery
Sign In or Register to comment.