Parallax Forums

Parallax Forums > Public Forums > Propeller Chip > complete and total n00b to multiprocessor/ OOP coding

Forum Quick Jump

[ << Previous Thread | Next Thread >> ] | Show Newest Post First ]

firestorm.v1
Registered Member

Date Joined Jan 2006
Total Posts : 79

Posted 11/3/2009 11:45 AM (GMT -8)

Hello fellow Propellerheads.. :P (sorry, been waiting to use that one).

After a lot of chaos, I finally picked up my propeller education kit and started working on it again. I'm a little fuzzy on some of the language in the book but want to make sure I have a clear understanding before I move on to the next chapter.

In Chapter 4, "IO and Timing Basics Lab" I understand the use of the cnt and the clkfreq variables, however in page 62 where the book discusses the difference between using waitcnt(clkfreq + cnt) and another method.

''File: TimekeepingGood.spin

CON
  _xinfreq = 5_000_000
  _clkmode = xtal1+pll1x

VAR
  long seconds, dT, T

PUB GoodTimeCount
  dira[9..4]~~

  dT := clkfreq
  T := cnt

  repeat
    T += dT
    waitcnt(T)
    seconds ++
    outa[9..4] := seconds

To make sure I understand, dT is set to 5,000,000 and when ran, T always has the count from the internal counter about the serialized clock ticks (cnt).
If dT is clkfreq and T is clk, then what is the difference between using T += dT // waitcnt(T) then it is waitcnt(clkfreq + clk) to obtain the same 1sec delay?

Isn't when waitcnt invoked, does clkfreq and clk get added together to form the destination count that waitcnt must wait for before continuing program execution?

--------

In Chapter 5 "Methods and Cogs", I tried but I think I'm failing to grasp the concept of the @stack parameter to cognew. In the example code on page 71, they use a variable array of 30 long elements to pass RAM addresses to the new cogs as in the code snippet shown below:

VAR
   long stack[30]

PUB LaunchBlinkCogs
  cognew(Blink(4.clkfreq/3,9),@stack[0])
  cognew(Blink(5,clkfreq/7,21), @stack[10])

We'll say forinstance that the RAM address for stack[0] is 00A0 and for stack[10] is 00B0 (although I'm sure it's probably not), does that mean that cog1 is launched with the "Blink" process in it with 00A0-00AF RAM allocated to it and that 00B0-00BF is allocated to cog2?

Being that it appears that the @stack[?] variable sets the "floor" for the cog's RAM address space, what sets the upper limit of RAM for the cog? Is the amount of system memory or the end address of the "stack" variable (is it stack[30] or the stack[30]+7FFF FFFF (one long) )?

I know it sounds like a lot of questions and may not be well written, but I'm very new to anything beyond the BS2 as far as microprocessors are concerned. I want to make sure I understand it now before I start working on a project later and am beating my head over something I should have understood earlier. :)

Thank you all for your time. I hope I can get this sorted out, I'm really up a tree here.

Mike Green
Registered Member

Date Joined Oct 2004
Total Posts : 13558

Posted 11/3/2009 12:04 PM (GMT -8)

The stack parameter to COGNEW provides the starting address of an area of memory for the cog to use for the stack for the new Spin program to be started. The first instance of Blink will use stack[ 0 ] and up (hopefully no more than 10 stack locations) and the second instance of Blink will use stack[ 10 ] and up. Blink will use the first 3 stack locations for the parameter values, one for the result value (even if it's not used), one for a return address (which would return to something that will stop the cog), and I think 2 more for internal information for the Spin interpreter.

The actual space for "stack" is allocated somewhere past the end of the program code in hub memory. The compiler allocates space beyond the program code for all the variables in your part of the program plus any needed by the objects referenced by your program. The main program's stack starts at the end of the variables area.

For the timing bit ... T gets set to the current time by the "T := cnt". Dt is set to the number of clock ticks in a second. In the loop, you calculate a time ("T += dT") one second in the future, then you wait for the system clock to reach that time ("waitcnt(T)"). You could do a "waitcnt(clkfreq + cnt)" to wait for one second, but there would be additional delays for the execution of the waitcnt statement itself and any other statements in that loop. By keeping track of the actual system time value to wait for, the waits always end exactly one second from the last one without being affected by other statements in the loop.

Pavel
Registered Member

Date Joined Jul 2007
Total Posts : 37

Posted 11/3/2009 12:08 PM (GMT -8)

If dT is clkfreq and T is clk, then what is the difference between using T += dT // waitcnt(T) then it is waitcnt(clkfreq + clk) to obtain the same 1sec delay?

I believe this lesson shows you how to avoid clock drift. If you use

seconds := 0

repeat
    waitcnt (cnt + clkfreq)
    seconds++
    outa[4..9] := seconds

the code will

1) wait 1 second exactly
2) increment second counter (that takes some time)
3) sets the LED display (that takes some more time)
4) loops back to wait another second

Note that the whole cycle takes more than one second. Using the code as shown in the lesson prevents that.

Being that it appears that the @stack[?] variable sets the "floor" for the cog's RAM address space, what sets the upper limit of RAM for the cog? Is the amount of system memory or the end address of the "stack" variable (is it stack[30] or the stack[30]+7FFF FFFF (one long) )?

Nothing sets the upper limit of stack space, you only supply the floor address and pray that you have allocated enough space so the stack will not grow past the allocated space and clobber something else. Setting the stack space needs careful consideration, there are ways to measure the stack space needs empirically but as far as I know the Spin compiler cannot analyze the code and compute the stack space exactly.

The memory management in Spin has no protective feature against writing beyond the end of allocated space, the programmer needs to assure that.

[ << Previous Thread | Next Thread >> ]

Forum Information

Currently it is Saturday, November 21, 2009 11:27 AM (GMT -8)
There are a total of 393,853 posts in 55,536 threads.
In the last 3 days there were 84 new threads and 704 reply posts. View Active Threads