Using SEROUT changes TIME count?

[Dave E]

Hello All,
I was using an 08M2 for a project that required a lot of SEROUT info being sent to an LCD. I noticed that when using the TIME command that each second was a bit long. Checking it with a stop watch showed that a 5 second TIME count took almost 7 seconds.

My question: Does using the SEROUT command stop or otherwise affect the TIME count in the M2 chips? Where can I find info on using the TIME command such as how it works, what things / other commands will affect it?

Thanks,
Dave E

 

[Goeytex]

See Manual 2 - Appendix 4 "Possible Conflicting Commands".

 

[Buzby]

I was going to say that !.

But then I looked at Appendix 4, and TIME is not mentioned, but 'timer' is.

Looked back at page 14 'Variables - Special Functions', where TIME is defined. It doesn't say which timer it depends on.

Looked at 'settimer', but no mention of TIME.

So which timer does TIME use ?

 

[Goeytex]

"TIME" is simply a system word variable related to the enabletime and disabletime commands.

 

[hippy]

To answer the original question; yes, SEROUT can cause the 'time' variable to slow down.

The PICAXE keeps count of ticks and increments 'time'. When it's busy doing other timing operations multiple ticks may pass before it sees a tick event flagged, so some ticks may be missed, time runs slower.

If the time loss is consistent it may be possible to simply increment the time variable to make it closer to what it should be.

 

[Buzby]

"TIME" is simply a system word variable related to the enabletime and disabletime commands.

Manual 2, System Variables, says -

"The M2 parts have 8 word variables which are reserved for system hardware use.
However if that piece of system hardware is not used within a program.. "

It would not be wrong to interpret this text as meaning 'time', aka 's_w7' is updated by a hardware function, i.e. not dependent on firmware.

Now I'm not saying 'time / s_w7' *should* be a hardware function, I'm just saying the manual should be a bit clearer.

Cheers,

Buzby

 

[Dave E]

Thanks All.
I assumed that was happening but you know what they say about that.
I also agree that the referenced info could be a bit clearer. I suggest that TIME should have it's own place in the command reference section of Manual 2 eventhough it is not an actual command.

Thanks again,
Dave E

 

[Buzby]

Hi Dave,

Could you use the hserout ?

There are no interrupt timing issues with the hardware serial.

Cheers,

Buzby

 

[hippy]

Manual 2, System Variables, says -

"The M2 parts have 8 word variables which are reserved for system hardware use.
However if that piece of system hardware is not used within a program.. "

It would not be wrong to interpret this text as meaning 'time', aka 's_w7' is updated by a hardware function, i.e. not dependent on firmware.

Now I'm not saying 'time / s_w7' *should* be a hardware function, I'm just saying the manual should be a bit clearer.

Perhaps, but as all of the system variables are firmware reflections of some hardware activity, the question would be how better to describe them in any absolutely correct way that is easily understood by everyone.

'Time' is update by the firmware in response to hardware events, so in that respect it is used by system hardware.

 

[Buzby]

Hi hippy,
There is a difference between 'repeating' a hardware register and 'responding' to one. If the firmware was repeating a register there would not be an increasing error, just a tiny one now and then.

My issue is that the underlying mechanksm of ' time' is not explained anywhere.

 

[Dave E]

Buzby, that is a good suggestion. I will investigate that to see if I can use it.

Dave E

 

[AllyCat]

My issue is that the underlying mechanksm of ' time' is not explained anywhere.

Hi Buzby,

Yes, that applies to quite a few PICaxe functions, but I guess they're not considered relevant to the target (educational) market. So, ....

The only hardware used for TIME appears to be Timer1. With a 4MHz clock it increments at 1MHz but effectively wraps on overflow to 45,536, so that it cycles with a 20ms period (or 20,000 PIC instruction cycles). Some micros have "auto-pre-loading" counter/timers, but not the PIC so this must be done by a firmware interrupt. I would hope that the routine adds, rather than loads, 45,536 to the timer registers, but time (increments) could still be lost if the interrupt is disabled by a higher priority function for longer than 20ms.

Surprisingly, if one uses DISABLETIME and then re-enables Timer 1 by setting the relevant SFR bit, then it still cycles in 20ms. However, I did eventually find another SFR flag which does restore a normal wraparound to zero, but I don't have the exact location to hand. From the documentation, I imagine that PWM and Servo commands will also disturb the accuracy of TIME, but I haven't tested it.

What would be useful is if we had access to the interrupt's divide by 50 TIME prescaler register.

Cheers, Alan.

 

[Technical]

It would not be wrong to interpret this text as meaning 'time', aka 's_w7' is updated by a hardware function, i.e. not dependent on firmware.

There is no such thing as a totally hardware function. All silicon functions trigger, or are triggered by, a section of PICAXE firmware that processes that event.
Internal silicon timers overflow very quickly, and when they overflow that 'tick' needs to be counted. That is a firmware job.
s_w7 is not an internal timer SFR - it can't be as the internal timers work far too quickly to count elapsed seconds.

We'll try to clarify this in the next manual.

 

[Technical]

Surprisingly, if one uses DISABLETIME and then re-enables Timer 1 by setting the relevant SFR bit, then it still cycles in 20ms.

Not surprsing if you also want to use the servo command.
Many PICAXE timers are shared by multiple functions. Servo does not disrupt TIME, in fact they use the very same timer. and other timeouts in other commands also use it. Therefore when in use that timer maintains the 20ms pulse interval regardless of whether TIME is incrementing or not, as the 20ms interval is needed in other commands as well. pwmout doesn't use timer1 at all, so does not disrupt TIME.

 

[Dave E]

Using HSEROUT to communicate with an LCD seems to work well. I set up a dedicated 20M2 as a clock while also sending just a incremented count(multiple HSEROUT commands per second) to the LCD and the clock stayed right on. After setting CALICFREQ to +4, the clock was within one minute in 5 hours. Plenty for what I need.
Thanks for the suggestion.

Dave E