"Time" variable not incrementing at 1 second intervals.

David Presley

New Member
Hi,
I'm using a 14M2 (and PE 6.1.0.0) in a project that needs to transmit data every 15 minutes. After searching the forum and documentation online, it seemed the "time" variable would be perfect for the task. I set the tripwire at a value of 900, thinking 900 seconds = 15 minutes... That's where things went awry.
It took f o r e v e r for the subroutine to be called, and it only happened after I'd given up on it for the night, thinking I must have coded it wrong. Just by circumstance, I was passing by the project's display much later and saw the sub finally being called. (It changes the display to indicate it got there)
Long story, short, I dropped the 900 value down to 10 and used some sertxd calls to determine the 1-second interval was just not happening. Then, it became trial and error to figure out that a value of 75 resulted in approx. 15 minutes.

There are no calls to alter the clock speed, which defaults to 4Mhz on the M2's according to the docs.

In the main body of the code, I have these lines:

let w8 = time
if w8 > 900 then
gosub WiFi_Transmit
endif

The wifi sub is simple for now - it just changes to a dummy display to let me know it got there.

Wi_Fi_Transmit:
<send some text to the display...>
disabletime
let time = 0
enabletime
return

Is there something wrong with this approach, or can anyone shed any light on why 900 seconds took so long?

Thanks in advance.
 

AllyCat

Senior Member
Hi,
.... I dropped the 900 value down to 10 and used some sertxd calls to determine the 1-second interval was just not happening.
That seems to be an enormous reduction in counting, but adding SERTXDs was about the worst thing that you could have done! The main problem is that serial communications (SEROUT, SERTXD and their equivalent inputs are "bit-banged" and must disable the timing interrupts to retain accuracy of their bit-periods. I nearly warned of this in your previous thread, but normally serial communications to a display would span only a few percent of the total time and could be compensated accordingly. Potentially there is a similar conflict with PULSOUT, PULSIN and PAUSEUS, but here I believe it is they rather than the time variable which is corrupted.

I've discussed this previously in a number of threads, but it's late here, so for now I'll just suggest taking a look at one of my code snippets HERE , particularly paragraph 2 of post #1 and posts #2 and #3.

ADDED: To expand on the above: The "time" variable is calculated in the PICaxe Operating System by dividing the 20 ms "Servo" interrupt pulses by a "pre-scaler" value of 50 (unfortunately not accessible to the User-Programmer). These interrupts occur even if "time" and any Servo pulses are NOT Enabled, but they ARE DISabled by any ("RS232") Serial Communications, hence the potential "slowing" of the time variable. Here's a Logic Analyser screenshot which I posted previously. The "Servo" pulses continue perfectly normally during the complex Infra-Red bit-banging code, but note how a pulse is delayed by the "SerOut" diagnostics (in the 23.8 ms "grey" region between markers) and then totally corrupted by the second burst of serial data. It appears that the interrupt ("ticks") are disabled for the whole period of the SEROUT/SERTXD command, not just individual bytes.

NEC+Servo+.png

Cheers, Alan.
 
Last edited:

Flenser

Senior Member
David,

Checkout using hserout instead of serout. Hserout is not blocking like serout. I haven't tested it but I expect that hserout would not have this effect on the TIME variable.

You'll see references this advantage of hserout in the thread AllyCat has provided a link to.
 

David Presley

New Member
Thanks, guys.

Alan, to be clear, the sertxd calls were placed temporarily to allow me to see if the 'time' variable was doing anything at all, and then removed. This is my first use of 'time', and I wanted to make sure it was functioning as expected, or even at all. Thanks for the additional explanation and screenshot - they went a long way towards helping me understand what's going on under the hood. (or, bonnet, if you prefer)

Flenser, thanks for the suggestion. I think it'd be worth the effort to revisit my code with that in mind.

As you both probably surmised, I'm new to uC's and Picaxe. The insight was most helpful.

David
 

lbenson

Senior Member
We'd need your whole code to say for sure, but there's no need for DISABLETIME, ENABLETIME, or W8.

As before:
Code:
do
  time=0
  do
  ' do stuff here
  loop until time > 900
  sertxd("Sending to wifi",cr,lf)
loop
This should come pretty close to happening every 15 minutes. Reduce it to "time > 60" and use the stopwatch on your cellphone to see how close it comes to repeating once a minute.
 

David Presley

New Member
Thanks, Ibenson... I reviewed the online docs for 'time' that the idea came from and realized the disable-enable calls were in a paragraph addressing their use as a safeguard for servos, etc. Rookie mistake. I'm sure when things weren't happening as I expected them to, I started flailing code trying to get something to work.

I'll go through the code this evening to tighten it up for efficiency, and will incorporate your suggestion into that pass.
 
Top