Launching, stopping cogs, newbie question

xanatos

I am feeling dumb.· I have been working with the basic stamps for a while now, and in the same amount of time I have been working with the Propeller now (about a week), I had, when working with the stamps, already gotten them to talk and respond to inputs from a variety of sources and control things from hundreds of feet away, interface with the PINK server, etc....

Now, with the propeller, I cannot make a simple program work beyond a single cog!· Anyway... onward.

I have written a small program to scan the onboard LEDs on the Propeller Demo board, and gave it its own PUB name.· I launch that in one cog.· I also have another PUB routine that is supposed to monitor the status of a pushbutton (ina[noparse][[/noparse]7]) and when it sees it go to a 1, it is to stop the first cog.· It does not.· The LEDs just scan on happily...· I have attached the code.

I have gone over the Fundamentals Lab, and the programs there, of course, work.· But simply replicating what exists doesn't work as a learning strategy for me - I need to try the principles in something I create separate from the lessons presented.· There is obviously something I am not grasping, and I am reaching out in the hopes that someone can point to what I am misunderstanding, and show me what the difference needs to be.· I seem to simply not be able to see what I am missing.

Thanks VERY much for putting me back on the tracks here!· I'm astounded by the available power of the Propeller and I want to "get it all" here.· This thing can do things the basic stamp couldn't touch!

Dave

mpark

Your StopLeds routine tests ina[noparse][[/noparse]7] just once. Try making it loop until ina[noparse][[/noparse]7] goes high, like this:

PUB StopLeds  

    dira[noparse][[/noparse]7] := %0                    
    repeat until ina[noparse][[/noparse]7] == 1
    cogstop(2)

xanatos

That works (as long as I remember to NOT indent the cogstop!) Thank You!· It has, in fact, allowed me to absolutely fly past the point I was stuck at.· I am now launching and controlling multiple (new) routines from multiple cogs with ease.· I am sincerely thankful!

Dave

Post Edited (xanatos) : 9/1/2009 1:42:57 AM GMT

Whit

Dave,

Have you watched any of the webinars? I found them very helpful... They talked about topics I hadn't even thought of yet and got me thinking of new possiblities. They are here for the Prop - http://www.parallax.com/tabid/766/Default.aspx

I'm glad you are enjoying the Prop.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+


"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney

Post Edited (Whit) : 9/1/2009 2:08:48 AM GMT

xanatos

Hi Whit,

Thanks for the link - these are high on my to-do list, but my schedule is truly rediculous, insane and out of control at the moment! LOL! I am trying to get programming in while waiting to babysit granddaughter #1 while granddaughter #2 enters the world! I am hoping to get to watch some of the webinars while in the waiting room on birth day! Are they iPod Touch friendly?

EDIT:· I just looked at the link again - most of these are SHORT!· Cool!!!·· :-)

Dave

Post Edited (xanatos) : 9/1/2009 2:12:50 AM GMT

xanatos

Am I correct in my understanding that using "waitpeq" in place of the "repeat until" line will conserve significantly on power consumption? It seems to work exactly the same, and if it does use less power... that's a plus!

Thanks,

Dave

photomankc

IIRC the wait commands all conserve power as compared to a repeat loop which is simply causing the processor to execute a tight loop as fast as it can operate. To really cut power consumption you need to to learn how to switch the clock speed from PLL mode into RCSLOW on the fly if all you are doing is polling for a button press. I have a project I'm working on where I can get the whole board down to 14mA with the processor running at 40Mhz but when I put it to 'sleep' and wait for a press to wake it up I switch to RCSLOW (20KHz) and the whole board drops to 60 microamps draw with the 3.3V regulator running and the 5V regulator in shutdown.

All that and without the 'sleep glitching' of the basic stamps I was using prior.

xanatos

This sounds interesting to me! Since I want to do a lot of battery-powered, remote applications with the prop, how would I learn to switch the clock speed from PLL mode into RCSLOW on the fly? 60uA sounds like a nice number!

Mike Green

Read the Propeller Manual! The CLKSET statement documentation discusses switching from one of the internal clocks to an external clock, but it works the same way in reverse.

xanatos

Hi Mike,

CLKSET it is. Problem with the RTM statement - which is always good - is that some of us, when we RTM, do not always understand what we read when presented against real-world applications. Sometimes - at least for me - I need to have the real-world problem to solve before the things in the manual even begin to take shape as being meaningful in my mind. I know this because I have already RTM several times - I actually printed out the entire spin language reference and read through it before I hit the sack at night, and yet despite this, until I saw photomankc's statement, the CLKSET statement did not seem obvious to me. It may be that I simply have an odd learning style that is not well served by simply reading the manual, AND that my learning style is NOT served by sequential learning - I jump around a lot in what I learn. That learning style, however, has served me very, very well over the years, despite it possibly being somewhat annoying to those who can RTM and then know exactly what to use when the problem arises later. I need to do hands-on (or at least brain-in) work on a project before I even know what questions to ask, and often even with multiple reads of the manual, when starting on a project, it takes me a little time to get the feel for the command structure. So when you tell me to RTM, it might help you to know that not only have I read it, but I have also read the Prop Fundamentals Lab manual, and literally hundreds of posts on this forum. Often, it takes some level of knowledge before more knowledge can begin to make sense to someone just starting in on a new piece of hardware and software. My questions build my knowledge to a place where I no longer need to ask most of the time.

An example being that now knowing that CLKSET is the place to review the functions I am asking about, I can begin to integrate that into what I am working with which is, currently, very basic stuff on the prop, sprinkled with a few things that would probably be considered more obscure.

Don't get me wrong - I understand and appreciate where the RTM response comes from, and I do not want to give the impression I am asking to be spoon fed. I am not. But for every question I ask like this that gets answered, I learn 100 things more before I find I need to ask another question.

Thanks for the info,

Dave

Mike Green

I appreciate your comments about RTM and you're quite correct. Still, it's helpful for people to have made at least one pass through the manual (as you've done) so there's a common context. You might remember that there are a couple of pages early in the manual that discuss the clock and the clock mode settings even if you don't remember quite where it is. You could go back there, find the section, and see if it's useful for what you want to do.

It's helpful (for us) for you to say "I've looked at the manual, read the part on the clock modes again, and it's just not clear how that works in a real program". That way there's a starting point for discussion that's really needed in a forum setting.

It's also satisfying occasionally to proclaim "Read The Manual" complete with an exclamation point.

xanatos

LOL! Yes, been there. I usually tend, after a while of nonproductive questions, to want to add the F in the RTM! statement!!!

Regarding your statement that it's helpful to say "I've looked at the manual, read the part on the clock modes again, and it's just not clear how that works in a real program", it would be more accurate for me to state that in reading the manual, when reading through that particular area the first few times, I understood it perfectly IN THE CONTEXT of the manual. It becomes a completely unlinked piece of information, however, when someone says "learn how to switch the clock speed from PLL mode into RCSLOW on the fly..." While I had a general idea that there must be something in the manual specifically, the format of the statement was such that it did not elicit any recognition and connection with what I had read at that point. Only when you mentioned CLKSET did the association happen. Hence the off-the-cuff question - mainly looking not for explanation, but association. More often than not I find that I already have the exact piece of knowledge I need, just not the association in conscious awareness between it and the question at hand. Sometimes...

Also, my question about the clocking was - in that particular post - really just a response in the moment to the tantalizing statement made by photomankc. Figured I'd ask in case he was still hanging around on the board. Never hurts to ask!

Dave

photomankc

I hear ya. I was in the same boat. I'll post an example here:

Setting to RCSLOW is fairly easy:

clkset(%000_00_001, 20_000)

Basically I clear out all the PLL modes and XTAL modes and set it to the internal slow osc. I like to set the register in binary since it's easy to see the bits of the register your setting.


Now later on in the program I need to get going again. That's a two step process. The crystal and PLL unit need some time to get stable.

clkset(%011_10_000, 12_000_000)
waitcnt(cnt+120_000)
clkset(%011_01_110, 40_000_000)

So first I turn on the PLL and switch to the internal fast clock and give it some time to get stable. The time wasn't critical as anything over a few microseconds is enough but this worked and I didn't change it since I didn't need to. Next I enable the crystal inputs, set the proper crystal loading and set the PLL multiplier I want to use. Again, looking at the CLK register in the datasheet should show you what I am doing there.

It was not at all clear to me till I saw a real-world example and then I was off and running.

xanatos

Awesome info, thanks very much. For me, there's nothing like seeing in the real. I get more from looking through the code samples in the Fundamentals Lab and things I've seen on line and this forum than I ever get from the manual. Initially the manual serves as just vague overview of some of the capabilities. Then I learn as much as I can from experimenting and looking through working code snippets. After some time (more in the case of the propeller), the manual finally becomes what it is supposed to be - a place I can reference quickly to get the info I need, because by then, I know enough to know what I need to learn about. ANd eventually, I get to the point where I can do it all in my head without hardly ever having to refer to anything! For the basic stamp, that progression took about 3 months. My stamps are happily chattering at me through Emic modules, and chatting with PCs and the web via the PINK module, and with each other several hundred yards away via XBees. What I am seeing with the props is that 1) it will take me at least twice that long to get equally as comfortable using them, and 2) the functions available to me with the propeller will make the extra effort worth it 1000 times over!

Thanks again for the detailed info. I have already implemented some routines with CLKSET and tested to be sure they are working as I expected.

Learning this stuff is a lot like learning a spoken language. You don't really know a language if all you can do is just regurgitate the examples in response to the canned statements. It's when you can recognize alternate forms of a statement, and formulate completely novel constructions that are grammatically, syntactically and contextually correct and intelligible to the listener that you can say you "know" a language. That's what I try to do with the various programming languages I "collect". My programming experience started back in 1996 with HTML, and it's been YEARS since I've had to reference a manual for that, or JavaScript, CSS, Perl, VBScript or ActionScript. I'm looking forward to the time I can say the same for Spin, PASM and C!

Dave

photomankc

Oh, BTW:

That 60uA current is mostly the quiescent current of the two regulators. The prop is drawing about 7uA itself. The 5v reg is drawing about 30uA, the 3.3V regulator is running about 20uA and the Prop itself between 7 and 10uA. You won't get close to that with cheap linear. I used expensive linear regs [noparse];)[/noparse]

CounterRotatingProps

Dave, the prop man and/or the datasheets do describe the power consumption during waits - power also varies depending on the number of cogs running, IIRC.

> Learning this stuff is a lot like learning a spoken language

Yup. They don't call 'em "programming languages" for nothing. [noparse]:)[/noparse])

- H

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

xanatos

Photomankc - are you using the regs specified as on the prop demo board (LM2937IMP-5.0 and LM2937IMP-3.3) or do you have a favorite you use?

photomankc

I'm using the Linear Technology LT-1529-5 for the 5V regulator. The 3.3 is the LT1121CN8-3.3. I had to use the DIP8 instead of the simple 3 pin TO package as that is what they had in stock at DigiKey and Linear is on crack with shipping prices they offer through their store.

I won't say they are favorites but I stopped there since they got me well under 100uA in my 'sleep' mode and the 5V included a shutdown pin to easily turn it off directly from the Propeller which my design required.

xanatos

Awesome, thanks!

Dave