Anyone used the Propellor system + Spin? Thoughts?

Community General Discussions
1

Just wondering if I can get some feedback on the Propellor system?

 

Specifically this one:

http://gadgetgangster.com/find-a-project/56?projectnum=257

 

In theory, it's like a multi-core Arduino, but without the Analouge channels. I like the idea of lots of cores, it should make coding easier - less hassle with interupts. I can cope without Analouge, as there is always ADC available as a breakout board. You can also call on a 32Mb memory via a shield, which is also nice.

 

But... Spin, the coding langauge looks like a bit of a mess, and a bit painful, and also, this is a robot forum, I want to use the board for robots, and this forum has about 5 posts in total about them, which makes me think people have found issues with joining the two together??

 

Any comments/thoughts gratefully recieved.

 

Steve

2

Spin is not the most easy language.

Spin might not be as most easy as Picaxe or Basic Stamp. But there are only two languages for the Propeller. Spin is the easiest of the two. I am working and learning about spin right now. It seems to get very easy once you get better at it. I think you should do good with Spin. Now considering the GG board. I have not used it myself yet, (though I wish to soon) but I think you should ask someone like CtC. He has used 2 or 3 of them on his biggest robot, Walter. He used another one on his niffty TX. Now about if the GG board works well with robots. I have already stated CtC used 2 with one of his best robots. Imagine not just 8 cogs, but 16 cogs! The Propeller chip is very useful with robots. You could have a Ultrasonic Sensor moving, while the robot moves, while the robot could make logical decisions with other sensors, at the same time. Now that might be a little over board, but you see my point. The Prop is very good with robots, when it comes to Parrallel-Processing. Ask Gareth or CtC for more about the Prop. They have alot more experience. I hope this could help you Steve.

3

…

You forgot to mention the second language but I bet it is not used as much as spin .By the way it is called pasm meaning propeller

assembly .

 

4

Yeah

I didnt think to mention it, since of course it is assembly, which makes it pretty hard.

 

5

Yup this is what I say too ,

Yup this is what I say too , I just mentioned it for the record ,someone else may had this question .

6

Spin + embedded Pasm = SPasm?

Spin + embedded Pasm = SPasm?

7

Yup, I’m here.

The Propeller chip, and the Gadget Gangster USB board (and Spin too) are the most bad-ass robot brain you can buy. Period.

Alright, here we go:

The propeller chip is simply amazing. There are a few things to get used to, yes, but the pro’s outweigh the con’s by a mile. The 8 cogs and true parallel processing cannot be beat. Take for example Walter. Walter is powered by 2 DeWalt drill motors --One of which is running “backward” in that it is on the “other” side of the robot. Because of this, it is very important to keep an eye on them so we keep going straight. No problem, just start a cog for that. You just fire up a cog and have it keep an eye on your wheel encoders. It keeps an eye on the speed and if it needs to be adjusted, it just changes the speed variable. Meanwhile, in the cog that is doing the drive and navigation, that speed variable also changes and badda boom, the robot is going straight.

Another good example of cogs is for comunication. I have one cog that does nothing but sit there and wait for serial transmissions. In an interrupt based system, not only are you always being well, interrupted, but you can keep an eye on what, one serial line? I have a constant watch of 4 serial lines, all at 115,200 with both RX and TX. As data comes in, variables get updated. All the other cogs have access to these variables --It is not that these numbers are getting “sent” to the other cogs, the variables are “just there” (global) --Any cog can just reach out and grab any variable it wants (which is being updated by itself or another cog) and it will always get the “most recent” value of that variable. Because this all runs “in the background” in its own cog, the main code really never knows it is even going on. With this system, when 2 chips are used (or any other serial device), the data transfer is so seamless, you quickly forget it is even happening. Set it and forget it.

Let’s see, what else --Oh 80mhz is just slighly faster than the 16 you will find on an Arduino and because of the 8 cogs, that is 80mhz * 8  --not-- 80mhz/8. Wicked fast, period.

You can’t beat the video-out with a stick. Why buy a $30 16x2 LCD when you can buy a $40 real-life-tv-screen LCD with full color, graphics, ton of text, etc.

Last off, the objects (libraries) are identical to the “main code” you are writing. I have no idea how to modify (let alone even open) an arduino library --with spin, it is just like what you are already writing. You can take an object, strip it, add to it, remove the parts you want and add them directly to your own code. Whatever you want. Plenty of stuff on the object excange too.

One more last: The GG USB board is the one you want. Great board, USB, SD, volt regs, etc --I love mine. If you get one, grab a ProtoPlus module for it. It is just a few bucks but will give you breadboard space as well as video and audio out.

Yeah, I like the propeller.

8

Also, here’s a great guide

Also, here’s a great guide to programming in spin put together by Nick from Gadget Gangster.

Spin (Programming Language)

9

Thanks for the comments - more questions though

Glad to see the positivity about the Propellor - I ordered a couple of them, along with a the 32Mb RAM upgrades. 

 

I wanted to ask more about the programming model.

Is the processing truely parrallel - with all of the MPI type mesiness that that brings, or is it a distrbuted system, where there are 8 independent cores?

If it’s the latter - and I’m guessing it is - what type of communications system exists between them? Is there some form of MQ where you can transact over a bus, or are the 8 cores isolated?

For example - taking CtC’s example further - can you have a system running which is handling motion - driving motors for example - and a second “cog” handling ultra-sonic location - which is essentially asyncronous - and then have that U/S cog interupt the main cogs with a “do something different” message?

hmmm… thats a bad example. I guess what I’m trying to ask is what sort of programming patterns are available in Propellor? Can I assume discrete cores? Is there some form of bus or MQ between them? Does it support syncrnous and Async events within the same system etc etc?

 

Thanks again

Steve

10

I have absolutely no

I have absolutely no experience with the Propeller. But here is what I understood from CtC’s explanation:

Imagine that one microcontroller is a guy working in a room. Another microcontroller is another guy working in another room. To communicate, they need to send/receive messages in one form or another. The Propeller is like 8 guys working in the same room. They do not need to send/receive messages, they share all the resources. Anything one of them has done is available for the others imediately. If they need to communicate with another microcotnroller, then yes, they send/receive messages. It’s as simple as that.

To have an easy start, you can use 12Blocks, a graphical environment for Spin, where you can connect blocks to write your program and then look at the generated Spin source. Pretty powerful, but if you love it, you’ll have to spend some $$ on it after 30 days. 

11

TRUE real-life parallel

This is really parallel, period. Consider the prop to be simply 8 brains in one package. At the same time, all the brains share the same bullitin board and everyone can see everyone’s sticky notes. It is more like running one big main code but all the subroutines (8 of them) can all run at the same time.

Your ultrasound example is a good one, lets run with it. Let’s also assume there is another cog that does nothing but watch a button --an actual push button wired to an input pin.

 

PUB init (main cog)

start up the sonar cog (sonar cog is now running side by side with the main loop)
start up the button cog (button_watch cog is now running side by side)
continue onto main


PUB main (also main cog)

repeat

   if button_value=1 then dosomething
   if sonar_range is < danger then driveaway from the object

 

PUB sonar_cog

repeat

    fire off sonar and put the range into variable sonar_range

 

PUB watch_button

repeat

   If button_pin is high then let button_value=1
   else
   button_value=0

Ok, so here we have 3 cogs running side-by-side. Each one has a repeat so they will all loop around forever. As you can see, the ultrasound cog does nothing but fire the sonar and put that range into the variable sonar_range. Same with the button, just keep looping and update the variable. The values of these variables do not get “sent” to any of the other cogs --it is already there! Every time the main cog/code loops around it will need the variables button_value and sonar_range --and its already got them. Everybody has them as a matter of fact. They also have the most recent copy of the variable as well --within just a few clock ticks. If for instance, you wanted the watch_button cog to do something with the sonar_range variable, just do it --It has access to that variable as well. Everybody can see everything --its all automatic.

In terms of one cog “interrupting” another --that would be as simple as having a “flag_variable”. In the cog/code that you want interrupted, you just add a line, “if flag_variable=1 then do something different” and keep and eye on it. In the interrupter code, when you want to interrupt, just change that “flag_variable” to a 1. That’s it. Every cog can see the change.

Again, it does take a bit of time to get used to things but I promise, you will love life after just a week or two of fiddling around.