Shop OBEX P1 Docs P2 Docs Learn Events
Spin programming structure. — Parallax Forums

Spin programming structure.

DgswanerDgswaner Posts: 795
edited 2007-12-22 16:24 in Propeller 1
first of all pardon my terminology,

I've been working on each component and getting the connections and code working for each sensor and motor/servo control. I'm about to the point of putting it all together but I was looking for some pointers about how to structure it. I'll see if I can make this clear.

this is how I have it structured.

Main program
Fullduplex serial
soundgen (sound)
PING
and few others

If I want to add code for motor control should I add it in the main program or make an object for it. I could see that working fine either way, but I also want to have a section of code for having my bot rotate slowly reading a compass and turning until it's facing a desired direction. this could use the first object or just a function. are there any benefits about using one method vs another? if I use more objects I'll have to use more global vars. with a host of sensors and functions could I run out of variable space? if I have most of the objects in the main program I'll have 10+ object besides the ones referenced by the objects.

here is what I mean:

main program
objects.....

Motor control
HB55
full duplex serial
VS

Main program
Objects...
Motor control
HB55
full duplex serial


I don't quite know how to plan this. does keeping the main program small and having lots of object save memory? or is it better to keep most of the code in the main program.

I'm sure that each situation is different and I'm not asking for a complete map of how this bot should be programmed. I'm asking for the "good rule of thumb" guidance for projects in general. I have a ton of sensors and I plan on adding a few more. I'm a little worried about running out of memory. and or variable space.

and insight would be appreciated.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

DGSwaner

Post Edited (Dgswaner) : 12/20/2007 10:30:07 PM GMT

Comments

  • deSilvadeSilva Posts: 2,967
    edited 2007-12-20 22:10
    Dgswaner,
    you are just touching one of the least understood and most researched topics of software engineering, called "programming in the large".

    I could recommend you 5 books out of 50, but I doubt you will profit from reading them as they use specific notation ("UML") which even could be a problem "per-se"

    The main key is still "experience" and "good taste".

    So I can only recommend the "hard way": Program two or three versions and see how you like them.

    One of the rules of thumb for modularization is:
    - Increase cohesion within modules
    - Decrease coupling between modules

    You should not care about implementation considerations, as the amount of variables or the overhead it might take to call another object compared to calling a local routine. Of course, when you pass a limit, you have to, but I am not aware of such a limit in your case.

    The main issue for larger programs ist: Can it still be understood what is going on?

    I just stumbled over this link wich - though highly technical - will give you an idea what box of pandora you have opended.... www.csc.liv.ac.uk/~igor/COMP201/files/SE_L14L15.ppt
  • DgswanerDgswaner Posts: 795
    edited 2007-12-20 22:24
    although I can't explain the "increase cohesion with in Modules", I do get what your saying.

    but I'm not sure what you mean by decrease coupling between modules." limit the amount of objects calling other objects, and have the main program call each different object?

    I guess after 33 years I'm tired of learning the hard way, I'm hoping for a few "good taste" tips so I can ease my work load.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

    DGSwaner
  • deSilvadeSilva Posts: 2,967
    edited 2007-12-20 22:37
    There are no "good taste" tips - that's just as in real life smile.gif
    You have to develop your own "good taste"

    ("White wine for the fish, red wine with the beef, a glass of champagne with the chicken, and some port after the cheese...")
  • CardboardGuruCardboardGuru Posts: 443
    edited 2007-12-20 23:11
    First of all you won't save memory by using objects rather than just keeping everything in the same file. In fact it'll cost you an extra couple of longs per object used. Which is usually neither here nor there.

    I'd say:
    * Create an object when you have definite plans to reuse a piece of functionality in more than one program. Or when you are going to release it for others to use.
    * If you are using multiple cogs, put the functionality for each different cog into a separate object. The main (top object) usually being what runs in cog 0.

    Other than that, usually just do things in methods in your main program.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Help to build the Propeller wiki - propeller.wikispaces.com
    Play Defender - Propeller version of the classic game
    Prop Room Robotics - my web store for Roomba spare parts in the UK
  • Mike GreenMike Green Posts: 23,101
    edited 2007-12-20 23:56
    The use of objects gives you what's known as encapsulation.· When the only interaction between a hunk of code and another hunk of code is via a couple of subroutine calls and maybe a couple of constant definitions,·you have a great candidate for using an object for the subsidiary hunk.· This works great for most I/O drivers and other "functional units".· For example, I have a dictionary that's part of the little compiler-compiler I posted recently.· This is perfect for defining as an object.· There are only a few calls to it and everything else is internal to the dictionary implementation.· It does use I2C and runs into a little inefficiency with the lack of sharing of objects, but that's minimal.
  • rjo_rjo_ Posts: 1,825
    edited 2007-12-21 05:04
    Dgswaner,

    The world is your oyster. Plan to use more than one prop in your system and in the beginning develop a very simple signaling system... so that you can switch modes easily. Take a look at Andre LaMothe's book... it is full of interesting factoids that aren't immediately obvious to a complete novice after a good year of hacking around the forum and the other info sources. I particularly like his approach to networking... nice and simple.

    Rich
  • DgswanerDgswaner Posts: 795
    edited 2007-12-22 16:24
    Thanks for the info everyone. I didn't want to get too far down the road and find out I was doing something the hard way.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    "A complex design is the sign of an inferior designer." - Jamie Hyneman, Myth Buster

    DGSwaner
Sign In or Register to comment.