Spin or PropBasic
mickal
Posts: 75
Hi, Ive been reading threads on the different Prop compilers/languages and would like advice on which to choose. I have a little experience with Basic and micro controllers so am wondering if PropBasic is the way to go for a Prop beginner ? Or would I be missing out on the object library ?
Would that apply to the C compilers too Thanks.
Would that apply to the C compilers too Thanks.
Comments
You could certainly start with PropBasic if you're comfortable with Basic, but keep in mind that PropBasic is not a standard Basic and there are some limitations on the complexity of statements as well. Spin has the advantage that it's a richer language with more features than PropBasic even though it may be unfamiliar to you. On the other hand, it's pretty easy to learn.
Other options include C using Catalina. Like using PropBasic, you'd not have as easy access to everything in the Object Exchange, but you'd have a lot of C libraries available to you as long as you realize that there's limited memory available (roughly 32K bytes).
I'm kind of biased towards starting with Spin. There are some nice tutorials on getting started with Spin ... read the Propeller Education Kit's tutorials and see what you think.
Catalina C is very good but has a bit of a steep learning curve if you don't know C. However, it has one little secret feature in that if you add an external memory chip you can program in huge programs - 512k with a single sram chip, or up to 32mb with another ram chip.
Spin is where I would start though. It is not too dissimilar to Basic. A big advantage is the vast majority of code in the Obex is in Spin so you can get things like a keyboard, display, memory card, mouse working quickly.
Truth is, SPIN is not hard. The Prop chip has some unique features. Learning these is best done in the native SPIN and PASM environment.
The object exchange is filled with lots of great code, and most of it is setup and easy to use from within the Prop Tool, and on a common board, like the demo board.
If it were me, I would setup on something common, use the simple tools, and get started with the Propeller that way. As you move into Prop Basic, C, or other things, you will have learned how the Propeller itself works, which is important overall.
I am a fan of PropBasic. The reason is its speed, which is several times faster than spin. You can write fast hardware drivers in PropBasic. If you use Spin, you will have to learn assembler too for fast drivers.
On the other hand, if the hardware-drivers for your project allready exist in OBEX or if you don't need too much speed for your hardware, you can use SPIN.
SPIN is something like a common language between the propeller users of course. OBEX, tutorials and this forum use Spin mainly.
Christof
The language;Spin syntax/ indentation is explained very nicely in manual downloaded with Prop Tool. I checked out a few webinar downloads and wish there were a lot more.
There is no serial command so this is why the Serial Objects are supplied ??
I think the hard part is understanding what is happening at a low-ish level, and this I guess applies for any language or micro.
For instance I was trying to understand Simple_Serial.Spin and have hquestions about "&" , ">>" these operators are explained with truth tables or shift examples
but ,well it does seem like a lot is being done and im getting stuck. Why is there a 'Bitwise &' in the sin := assignment ?
Likewise the waitpeq command seemed straightforward till i saw it used here. I guess its waiting for rx pin to go high but its been anded which I wonder why.
Other than dira,ina,outa im going to make an effort to avoid 1's/0's
sin := rxPin & $1F ' WHAT IS THE PURPOSE OF "& $1F" ' set rx pin sout := txPin & $1F ' WHAT IS THE PURPOSE OF "& $1F" ' set tx pin inverted := baud < 0 bitTime := clkfreq / ||baud PUB rx: rxByte | t {{ Receive a byte; blocks caller until byte received. }} if rxOkay dira[sin]~ ' make rx pin an input [COLOR="#ff0000"] waitpeq(inverted & |< sin, |< sin, 0) [/COLOR] 'WHAT IS PUROSE OF "inverted &" ' wait for start bit t := cnt + bitTime >> 1 ' WHAT IS THE PURPOSE OF " >> 1" ' sync + 1/2 bit repeat 8 waitcnt(t += bitTime) ' wait for middle of bit rxByte := ina[sin] << 7 | rxByte >> 1 ' sample bit waitcnt(t + bitTime) ' allow for stop bit rxByte := (rxByte ^ inverted) & $FFCurrently I have been in the process of converting a lot of basic code for another MicroController to spin to run on the propeller... So I will try to give a few hints. I have also thought about trying out PropBasic as it states that it has nearly the speed of the ASM, whereas Spin is considerably slower. I however stayed with Spin as there are many objects available up on OBEX that I wanted to start with including: XBee, PS2, Servo...
It has taken me awhile to get used to the Spin language and there are several things that either it does not support or I have not found a way of doing. Things like:
a) Conditional compile some code. That is if I want some debug code that is compiled in when I do something like: DEBUG = 1
b) Continue a statement to multiple lines. Many basics have a character you put in at the end to say it continues to the next line... This is nice when statements get complicated.
c) Ways for a child object to be able to communicate back to the parent object. I have worked around this...
Also be careful when you write the code as some things that still compile don't work the same way. Example is: if x >= 5 and x <= 10
In basic this says x is between 5 and 10 where in spin the >= will do an assignment to X... This has bit me a few times!
But back to your questions: sin := rxPin & $1f
This is anding with hex 1f. Which will truncate off the top N bits, which makes sure that sin will always have a value between 0 and 31.
The code: (inverted & |<sin,
Is I believe the same as: (inverted & (1 << sin),
That is you and the variable inverted with the bitmask where the SIN bit is set to 1...
The line t:= cnt + bittime >> 1
Could be written: t:= cnt + bittime/2
That is you are shifting the variable bittime to the right one bit which is the same as dividing by 2.
That is all for now.
Good Luck
Kurt
You can continue a statement to subsequent lines by using the { } comment characters to include the end of the line in a comment. Put the { at the end of the first line and the } at the beginning of the second line and the end of line will be ignored by the compiler.
Child objects have to communicate back to a parent by accessing shared memory. The parent passes the address of a communications area to the child and the child uses BYTE[], WORD[], and LONG[] to access those variables using the passed address. Alternatively, the parent can call methods in the child that set / return variables that are stored in the child's variables space. Look at some of the objects in the Object Exchange for examples.
Yep, for the child objects, I am currently doing the provide a set of public methods for the parent to call to get the data. I may convert to pass a pointer to a data block at some point, if I find the overhead of all of the calls as a problem, but so far does not appear to be.
I personally wish there was some way to pass pointers to objects, but so far I have worked around it. Example I want to output debug information both from my top level object as well as the child objects. So I tried to find a way to pass a pointer to the serial object... Finally worked around this by using the SerialMirror.spin object... Sort-of a kludge but gets the job done... Not sure what I will do if for example I also want to be able to use the XBEE object in multiple objects... But for now I will work through those issues if and when I need to.
Thanks again
Kurt
Cheers.