Propellers best feature is the hardest to keep straight (at least for me)

dennisap67

Is anyone else having problems getting used to programming in parallel?
I keep switching into serial code execution mode and get confused (not an abnormal state for me).
I guess it is because I have never had access to a parallel processor before. This isn't a derogatory remark against the propeller btw, I love it and plan to keep playing with it. I might not ever get the hang of parallel processing but it will be fun trying.

Paul Baker

The easiest means for someone just starting out is to write asynchronous programs, this is where each cog is running a dedicated function and when they need to communicate with each other they write some information in a predetermined section of memory, and each cog that needs to know if there is any updated information occasionally checks the locations and acts upon any updated information. You can think of it like other processors where they have a dedicated peripheral, the propeller has a generic processor to fullfill the roll. So if you need a UART, you load up a cog with the appropriate code to function as one. And you have 1 master cog that fullfills the role of the core of a traditional microcontroller. Obviously there are more complex schemes the Propeller can do such as using synchronous programs, concurrent master cogs etc. but it's best to start off with the simpler model until you get more accustomed to the chip.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Mike Green

It's really not too different from programming with a conventional single processor controller that happens to have a variety of on-chip peripherals. From the single processor's standpoint, they're all peripherals (UART, timers, SPI, ADC). The fact that many of them may have their own special purpose controllers or at least a state machine really doesn't affect much of what you do with the "single" processor.

Say I have a Propeller program with video output, a keyboard, full duplex serial channel, servo controller, and compass. The fact that there are six (2 for VGA video) processors doing the "virtual" peripherals and they're programmed in the same language as my part of things ... well that doesn't really matter to what I have to do with the seventh ... and there's another one idle if I need it.

potatohead

I really like the hardware analogy the best.

It's easy to think in terms of having a custom chip that does x. From there, it's kind of nice in that the follow on questions and data inputs and outputs all seem to flow fairly nicely. What data needs to move, what does it look like, how to set / communicate states, etc... I love this about the prop actually. The whole thing is really fun, compared to interrupts, handling kernels, etc...

One other method I sometimes explore is personification. Thinking through computer networks is easy and fun this way. Applying it to the Propeller isn't a bad way to start --at least it wasn't for me. I also do this with data management (which is my professional work) Getting people to grok how documents are managed, checked in, checked out, revisions, etc... is a total sleeper. Never teach it after lunch! It helped me with the Propeller.

So, I setup this scenario where there are up to 8 people, all working in their little offices. There are 32 phone lines that talk to the outside world directly, a central document storage area common to all offices, and the mail cart that moves documents (data) to and from the offices in round robin fashion. There is one company clock, everybody sees, with each office having their own clocks too, etc... Of course, no document moves between offices. You need to use the cart for that. The phone lines are shared, so a quick conversation can happen between offices, but that takes one of the 32 phone lines, that might be really busy depending on the business being done. All communication with the outside world happens via the phone lines, etc...

When the company starts, the central storage area is loaded up with the necessary startup data, one office comes up and is running. It can make requests for others to start operating, depending on what's having to be done, but that takes some time as all the necessary information for that person needs to come from the central document pool.

From there the trade offs are easily seen. Having a quick conversation between people directly office to office can happen, but it costs one of the phone lines that are needed to communicate with the outside world. The manager needs to be able to coordinate tasks between offices, so that takes memos being passed around to tell others what to do, and how to file their results. Etc...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!

Post Edited (potatohead) : 7/27/2007 7:06:44 PM GMT

dennisap67

@Paul: I think I was trying to run before I could walk as far as asynchronous programs are concerned. Going back to a more basic approach to get the hang of the chip is a good idea. I guess I saw the huge potential of the chip and wanted to utilize it all right now. Patience has never been my strong point.

@mike: I agree with it not being too different than a "single processor controller that happens to have a variety of on-chip peripherals". Most of the time I did ok but somewhere in the middle of working with the chip i would switch into thinking of the prop as a single processor controller and forget to coordinate the cog activity.

thanks for the help and ideas. I'm sure I will figure it out, I just need more of that patience thing.

RinksCustoms

I too had this problem with patients, it took two slower readings of the manual to really understand how the program interacted with the cogs. Comming almost directly from the analog IC level of doing things, I thought the basic stamp was a god send until parallax introduced the propeller. At first, i kept reverting back to Stamp style serial programming. I find it much easier to program in parallel though.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
E³ = Thought

http://folding.stanford.edu/·- Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.