When to keep a cog running?

Bob Reynolds

I am an experienced microcontroller programmer and have recently made a commitment to switch to the propeller chip. I build control electronics for exhibits at a science museum.

I seem to be able to write code which will do what I want it to - until I start launching those routines into their own cogs. I've had several problems which seemed to be cured by inserting an endless repeat loop at the end to keep the cog alive - even after that cog should have completed its job. In other cases, like the one I'm trying to debug today, a code module in one cog will only run properly if the main code module (presumably in cog 0) is allowed to terminate.

I'm convinced I'm not running out of cogs. I'm always using a start method which first invokes a stop method.

I realize this all sounds rather vague. I can provide specific code snippets to further illustrate my problems, but I have the feeling I'm missing something fundamental. Can anyone give me some rules-of-thumb about keeping cogs alive or allowing them to terminate?

Thanks for your time,

Bob Reynolds
Lead Electronics Developer
Oregon Museum of Science and Industry

Mike Green

When a cog stops running (including when the main routine "runs off the end"), it does so by resetting itself or by being reset by another cog. As part of that, all the I/O registers in the cog get reset to zero as well and that affects any I/O that the cog has been doing. In particular, if the cog has set its I/O direction to output for any bits, that will get changed to all inputs. Unless some other cog is also trying to output to that I/O pin, the pin will become an input (high impedance). There is priority logic for the actual I/O pins and the "closest" cog whose direction bit is set to output will control the I/O pin.

The cog's counters are also reset which will stop any pulse stream being produced by the cog like a PWM signal or clock.

Bob Reynolds

Thanks Mike. That changes my mental model of the propeller a bit.

Bob Reynolds

ciphernet

Hi Bob,

Have you tried to read the "Methods and Cogs - A Propeller Education Lab" PDF file you can find under the "download" section.

That document gives good insight in controlling COG´s. A COG will terminate when it run out of instructions to excute or can be forced to close down if instructed to do so by the STOPCOG instruction.

Check·pages 186-193 in the PROP manual for use of these COG commands.

Try and posting your code and I am sure you will get great help with your project.


Jan

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·Give me some slack, please.. I have programmed SX controllers for five years but the prop just blows my mind :-)

Mike Green

Bob,
Just for curiousity, what has been your "mental model"? Have you picked it up from the manual or from magazine articles or what?

I think your choice of the Propeller as a controller for exhibits is excellent. It's a very powerful controller, yet much more straightforward to use than many other comparable devices. If you haven't looked at it, consider using FemtoBasic for some of your exhibits since many of them don't need high speed or large, complex control programs, yet need access to the I/O pins and the cog counters. BoeBotBasic is a variant that includes servo control and typical robotics sensors (the PING ultrasonic sensor, modulated IR distance sensing, and a Hitachi compass). It's pretty easy to add other specialized statements and the interpreter is written in Spin.

Bob Reynolds

Mike,

I've been through the manual several times and have read the Education Lab docs. My problem is finding the time for uninterrupted programming sessions. If have read, with interest, about Femtobasic and BoeBotBasic. I spent about ten years writing code for the 8051 family, mostly in asm. I switched to PICs and PicBasic pro about seven years ago. If I were still programming as a hobby I would have time to investigate every new programming tool/language/environment that came along. Most of my time is spent deciding what an exhibit should do. When it comes time to implement those decisions (often months later) I need to use a tool I understand, not take time to learn a new one.

The PICs had enough advantages over the 8051 to justify a change. The Propeller easily justified another change. A few months ago I dug into the literature deep enough to design three boards using Propeller chip and now am catching up with the software end.

My current project uses two Propeller driven boards. One is a stepper motor controller which runs two motors. The other reads 36 pushbuttons, switches LEDs in each button, talks through two serial ports to solid state audio/vga players and through a third to the stepper board. A year ago I would have built this using several PICs, with a lot of I/O and processing time dedicated in intra-chip communications, and still would have had some complicated nested loops to keep track of everything. With the Propeller I can have one cog handle the main loop, another switch de-bouncing, another to read the debounced switch states and control the switch lighting, and three to implement buffered serial ports, all communicating through shared memory.

This all requires new ways of thinking. I've become familiar enough with spin that I seldom stumble over syntax errors, but I'm still getting my head around multiple cogs and their interactions.

Mine is an interesting business. Everything is a prototype, but has to stand up to very rough use for years (no kid visiting the museum today cares whether the exhibits still work tomorrow.) Parts costs mean almost nothing as we seldom build more than three copies of anything. I usually have time and money to build a crude prototype, but the second iteration has to work. It must be flexible, since we are never sure exactly what it should do until it's on the museum floor and we can watch our visitor's interactions. It must be serviceable over the phone or modular enough to be sent back for repair, since most of our exhibits travel.

But, there's something new to invent every day - I'm sure it beats spending my life writing control code for washing machines or microwave ovens.

Bob

rokicki

> There is priority logic for the actual I/O pins and the "closest" cog whose direction bit is set to output will control the I/O pin.

Hmm, am I misremembering something? I mean, the great Mike Green can't be wrong here, but I thought it was that if *any*
cog with the direction bit set to output tried to set the pin high, the pin would be high; only if none of them set it high would it
be low. That is, it's not the "closest" cog, but rather, any cog attempting to set it high would make it high.

I must be misunderstanding something.

rokicki

Bob, I'm very curious what hardware you are using in your Propeller exhibits. Are you using protoboards, then?
Or demo boards (since so many more connectors and stuff is just already mounted)? It sounds like you have a
really cool job; congratulations! I'm sure I'm not the only one interested in any specific exhibits you build with the
Prop.

deSilva

When you study the most instructive sketch of the basic Propeller architecture with all its ANDs and ORs from registers to I/o pins - generally "Figure 1" in most descriptions - I should say that Rockiki has some foundation under his statement

@Bob
I still have no understanding what your misconceptions could be - everything is explained in documentations much more clearer than I could do....

Mike Green

Bob and Rokicki,
I'm using the term "priority" loosely. The net result of the AND/OR chain is that, if any cog uses an I/O pin as an output, that takes priority over other cogs' use of input mode. Similarly, if any cog sets an output pin to a one, that takes priority over an output state of zero. Because this is done with a chain of gates, cog 7 really does take priority since it's closest to the I/O driver. It's not too important practically, but you should be able to see it with a good scope under the right circumstances.
Mike

rokicki

I don't understand what you mean by "priority". In terms of latency, or where precisely the edge is with respect to the internal
clock edge, I do understand that cog7 may have very slightly different timing on output transitions than cog3. But priority seems
to imply that if cog3 and cog7 both try to do something, cog7 will "win", and I don't see any asymmetry that would cause this.

Although it would be interesting to calculate observed gate delays by measuring latency between clock edges and output edge
transitions when using different cogs. I don't have the equipment for that (you'd probably need to measure sub-nanosecond
delays which requires a multi-gigahertz scope).

Fred Hawkins

Bob Reynolds said...
.... A year ago I would have built this using several PICs, with a lot of I/O and processing time dedicated in intra-chip communications, and still would have had some complicated nested loops to keep track of everything. With the Propeller I can have one cog handle the main loop, another switch de-bouncing, another to read the debounced switch states and control the switch lighting, and three to implement buffered serial ports, all communicating through shared memory. ...

Nicely put and worth highlighting.

Fred