Propeller libraries
Franny
Posts: 127
Howdy!
Why do we need libraries, I'm new to the propeller chip, I can pretty much do anything I can think of with the basic stamp without libraries, Why is it that we need one for pretty much everything we do with the propeller like to rotate a servo? Thanks
Why do we need libraries, I'm new to the propeller chip, I can pretty much do anything I can think of with the basic stamp without libraries, Why is it that we need one for pretty much everything we do with the propeller like to rotate a servo? Thanks
Comments
Of course you can write all that stuff yourself if you prefer.
Do you really want to spend tens or hundreds of hours creating these things yourself or would you rather just use what is already made and get on with your project?
On your specific point about rotating a servo: Yes, you can do that with a BASIC Stamp. If you're going to do it properly, however, you need to refresh your servo(s) every 20ms. This is not easy to do with a BASIC Stamp. Not so with the Propeller. Declare a servo object that runs in its own cog (processor) and Bob's your uncle; it's like connecting a servo controller without having to connect an extra physical device. And as Mike pointed out, you can modify objects as you please. I do a lot of work with servos and wasn't happy with any of the existing objects so I wrote my own.
Another biggy that gets BASIC Stamp users is high speed serial, and the ability to receive serial while you're doing something else (you can't with the Stamp). That's not the case with the Propeller. Again, it's handled by its own processor so your main program code can happily do its thing and then check for serial when it wants to.
As Heater and Mike point out, having those libraries/objects made available to you can save time or, at the very least, serve to educate you. For most things I tend to write my own objects, but I do like reviewing code by others as I tend to learn a lot from it.
Objects are mostly drivers that the Chip and the community has written to perform various hardware functions in the prop. Take for instance the FullDuplexSerial object mentioned. This runs the UART implementation in 1 cog. A second cog is used to communicate with it (written in spin) and implements a much higher level of comms. It can write/format strings, hex, decimal, etc. You will find that FDX (as we often call it) will be your friend, more so than any other object. When you want to check what is going on in your program, just output something to FDX and you can see it on your PC. We typically run this at 115,200 baud - quite fast hey!!
Notice the careful use of "mostly" -- this is important. An object does not have to use another cog, though many like FDX, servo drivers, pwm drivers, etc., do. Since my earliest days with the BASIC Stamp 1 I have worked with character LCDs. My LCD object, for example, does not require another cog as it is 100% Spin. With the Propeller I don't have copy-and-paste my LCD routines to a new program, I can declare my LCD object and use it.
This is the advantage of object libraries: easy code re-use.
It's for sending and receiving serial data, like SEROUT and SERIN in PBASIC. The difference is that FDX runs in its own processor so it can do things "in the background" relative to your main program. Debugging is a possibility (BTW, the DEBUG statement in PBASIC is a special form of SEROUT). For example, I often add a monitor cog to programs I'm developing that lets me keep track of variables while the program runs (simple debugging). The difference between this and PBASIC is that my monitor code -- again, running in another cog -- does not have any affect on my main program timing (as DEBUG does in PBASIC).
You're talking apples and oranges. The default language for SimpleIDE is C, Libraries are a standard feature of C hence their use is naturally part of SimpleIDE. When you program the Propeller in Spin (which you can also do in SimpleIDE), what we call libraries is C are called objects. The point is the same: re-usable code.