Strange problem... any ideas?

CarlosFandango

I'v written a power monitoring routine but for some unknown reason it's giving me grief. The problem seem fairly self-contained to this routine, so I'm not posting the whole code; that would be pretty huge and incomprehensible anyway. External functions ARE called, but they are very minimal in nature. I've been hacking away at it for several hours now and it's one of those problems that probably has a simple solution, but I just can't see it. So if anyone can spot an obvious problem.... PLEASE TELL ME!!! (as you can see I am getting a bit frustrated!)

Here's the issue: all works exactly as it's supposed to as long as one line is in the code, but all this does is report the current state of a variable via RS232. So it shouldn't have any impact on the code at all, should it? Effectively, what appears to be happening is that the variable 'uptime' doesn't update - cycling the power results in "Up time was 0" over the serial line, as per the last few lines in the code....

grrrr

-CF

Mike Green

It's hard to tell because the logic is not simple and there's a lot missing in what you've posted.

The most obvious effect would be some kind of timing problem. You might try shortening the text string one character at a time to see if there's a threshold where 'uptime' updates again. This string might be long enough to cause the FullDuplexSerial buffer to become full and result in a few milliseconds of delay.

CarlosFandango

Hi MIke, thanks for the reply... yes, I agree there's a lot missing there and I did only post the minimum but this isn't always helpful, I do realise. I thought it might be a timing issue and that's where I've been focusing a lot of my attention today but I haven't tracked anything down yet. I'm actually using Mirror's SerialMirror object (something again not clear in my original post!) and have extended the buffer here to the maximum, so it's unlikely that this is the exact problem... but I will revisit the timing thing and try what you suggest. Still haven't tracked it down obviously!

Christof Eb.

Hi CF,

I am not sure, that I could understand the problem. You get zero results for uptime? Nor do I understand your program.
There ist a
uptime~
in the loop at line 98?

We do not see the code, where uptime is added:
_UP : uptime += glob.TimeDiff(@upstart)

Good luck,
Christof

CarlosFandango

uptime~ is a post-clear operation - it sets uptime to zero, this is a quick way to do this (I understand!)

As Mike suggested there are some wacky timing things going on for some reason - if I relace the comms code with a 10ms wait instruction, it all works fine. I still haven't worked out why, but there is going to be a perfectly sensible explanation when I do track it down!

Yes, I left a few things out to try and keep things simple - this has downsides as well.... these are the timing functions (sorry about any lost indentation)

PUB GetTimeStamp | clkptr

return cnt


PUB TimeDiff(p_TimeVar) | RightNow, ClockTicks

' Written by StefanL38
' Updated so that the value passed is now a pointer to a long,
' which is automatically updated to the current value of cnt.
' This should simplify usage

RightNow := cnt

if RightNow < p_TimeVar
ClockTicks := ||($FFFFFFFF - RightNow + LONG[noparse][[/noparse]p_TimeVar])
else
ClockTicks := ||(RightNow - LONG[noparse][[/noparse]p_TimeVar])

LONG[noparse][[/noparse]p_TimeVar] := RightNow

result := ClockTicks / (clkfreq / 1_000) 'calculate milliseconds