help - maintaining a clock without using a new cog

bozo

Hi all, I'm a newbie here and I am so impressed with how quickly I've been able write code for this chip that would have taken me weeks with a pic ... but I need·a little help with the following: I want to maintain an internal clock variable that can keep time (for a timestamp) to the millisecond for periods of up to several hours (for a datalogger).

But I've run out of cogs·so I·want to run this function alongside other code in an already-used cog. And I don't really want to have to use waitcnt since I want to be doing other jobs in the cog at the same time.

Any suggestions?

Is there a way to use the internal counters in a cog to periodically (every mS) trigger a method that bumps my timestamp without interfering with other activity in the cog? - or am I still thinking the old way? Would it be better to bump the variable, then perform the other duties I want the cog to do, then use waitcnt until the next millisecond has passed? The only problem with this approach is that I don't know how long the 'other' tasks will take and I don't want to miss updating the timestamp variable, since there will be other cogs accessing the variable to write the timestamp to my logger records ...

it seems wasteful to dedicate a cog to such a humdrum job - any ideas appreciated

cheers,

MarkW
Melbourne AU

Ariba

If you have a free pin, you can use both counters of a cog to do what you want.
Counter B outputs a 1kHz Signal on this free pin, and Counter A counts this 1ms pulses.
Set FREQA to 1 and you get in PHSA register your MilliSecondCountVariable.
PHSA is a 32bit register, so you can count up to 4 Million seconds !

Andy

Lawson

how about basing the clock directly off of CNT? If CNT is periodically logged, the ammount of clock cycles that have elapsed can be easily calculated. Clock cycles could then be converted to milliseconds and added to the register in the hub. Hm... rounding errors would kill this unless the remainder was added into the next delta calculation.

'pseudo code

old_mark_cnt := CNT  'initialise the clock code
waste_clocks := 0

repeat
  'other junk
  
  mark_cnt := CNT
  delta_clocks := ( mark_cnt - old_mark_cnt ) + carry_clocks 'number of clocks since we last looked plus what we rounded off last time
  milliseconds_delta := delta_clocks * 1000 / clkfreq            'convert to milliseconds (breaks if the loop takes longer than 25ms)
  carry_clocks := delta_clocks * 1000 // clkfreq                'calculate how many clocks were rounded off of milliseconds
  old_mark_cnt := mark_cnt                                     'the current mark is now old, shift it into old_mark_cnt
  global_milliseconds += milliseconds_delta                         'update the global millisecond counter

Now I just made this up from theory. it *should* keep good time. It might be best to build a full clock with this code and run it for a few days to be sure it won't drift too badly. Of course the precision of this will depend on how often this code is executed, but it's accuracy *should* be as good as the clock running the Prop.

My 2¢,
Marty

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?

Post Edited (Lawson) : 8/21/2007 5:56:01 PM GMT

deSilva

@bozo you have now discovered the "the dark side" of the Prop WITH a COG it's dancing and singing - WITHOUT a COG: tricks and traps!

Aribas proposal will allow you to have a very easy long term counter. And note that it does not matter WHICH COG you take, so there is a fair chance you find one with the counters unused!
You can also do it with software alone by just reading the CNT from time to time to detect it's overflows (which happens every 20 seconds, so you only will de-sync when a task takes longer than 20 seconds without a chance to check inbetween)

This however will not help you to TRIGGER some action at a fixed time. No pre-emptive multitasking with the Prop

Edit: I just see Marty did something like i proposed during the time I was writing this posting
However I am not sure whether his "clock" will be just a little bit "late" ...

My equally unchecked code would look like this:

(Edit: I removed the code, as it does not work the way I expected.... Will post it again when I fournd the bug...)

Post Edited (deSilva) : 8/22/2007 5:37:48 AM GMT

bozo

awesome ... thanks for the hints

I'm using Ariba's technique, but I'm not sure about accuracy ...

CTRA is set up for duty cycle mode, and I have system clock at 80MHz, with FRQA=53687

this causes PSHA to overflow after 80001 system clock cycles, and the carry bit goes to PINA

and CTRB is set up for pin state mode, triggering on the rising edge of PINA

Looks rock solid in tests so far, but since FRQA really needs to be set to 53687.0912 I'm not quite getting a 1kHz output.

( 1mS takes 80000 system clock cycles, and FRQA should be set to 2^32 / 80000 = 53687.0912)

I figure the inaccuracy is only one part in 80000, which works out to about 1 second per day which is plenty good enough for what I need.

After a 30-minute test run, it's out by about only 5mS!

Cheers,

MarkW


Post Edited (bozo) : 8/21/2007 5:22:09 PM GMT

deSilva

Your chrystal might say 5,000,000 but this is only half of the truth. Chrystals oscillate according to all the capacities around
them and temperature as well, and are produced for special situations not exactly in place with a micro processor.

The error comes out to less than 0.01% = 1/10.000 = 8 seconds per day; this is a more or less systematic effect!
The frequency of the crystal can be shifted using a small (30pF) trim-cap between XIN and ground.

You can also change the _XINFREQ parameter, but I think this will not influence the counters
but only the setting of the CLCKFREQ variable

Why are watches so much more precise? Well they have the "right" environment, especially when
worn or stored around 30°C

Post Edited (deSilva) : 8/21/2007 5:50:53 PM GMT

Lawson

actually since the overflow of PSHA leaves behind a remainder you accuracy is better than 1/80000. It's more like 0.0912/53687. (about 1.7e-6) So in 30min or 1.8 million milliseconds you should loose ~3 milliseconds from the math. (add in the crystal's precision and 5mS in 30min sounds about right)

Glad to hear you got it working.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?