Hi,
I currently have an IMP set-up to post a HTTP request to my site every minute. But after some time this just some time this will just stop. I can’t seem to find anything in my code that would cause this to happen, as it’s pretty light weight. Is there a limit to the number of request that can me made in a specific period ? or any known issues in general?
Thanks
Anand
No, that should be working just fine. Have you put server.log’s in your imp to check the imp is still firing every minute?
Hi Hugo,
Looked into this a bit more and the issues doesn’t seem to be related to HTTP at all. The imp is waking and running the call back, however, I have some condition in there that uses the clock() function to determine if a certain amount of time has passed before the http request should happen.
Example:
`
u32UpdateTime <- 0;
function something_has_happened()
{
u32UpdateTime = clock();
}
function update_function()
{
//if more that 4 seconds have elapsed after data has been extracted (without change)
if (clock() - u32UpdateTime > 4)
{
local display1 = “”;
local display2 = “”;
output.set(display1 + display2);
server.show("Value: " + display1 + display2);
}
server.log("wakeup : " + time_stamp );
//Wake-up in 60 seconds
imp.wakeup(60, hour_update);
}
hardware.pin7.configure(DIGITAL_IN, something_has_happened);
update_function();
`
The premise here is that i’m using the clock to check that something been stable for 4 seconds before I send it out. But it appears that after some time the condition just stops evaluating to true.
To clarify, the clock() function returns a floating point number of seconds since device boot ? So wrap around shouldn’t be an issue for some time ?
Thanks
Anand
It’s reported to Squirrel as a float, but the actual system timer that it’s using, under the hood, is a U32 in microseconds. (It’s a bit pointless it being in microseconds, as it’s only actually updated every 100Hz.) This means that yes, sadly, clock() wraps horribly after about 4,295 seconds, or less than an hour and a quarter.
Which I admit makes the clock() facility not particularly useful. If you only care about the time to one-second precision, though, you could use time() instead, which returns the Unix time (seconds since 1970-Jan-1), a value which won’t wrap until 2038, and behaves nicely when it does (i.e. the test
(time() - s32UpdateTime) > 4
continues to work if performed in 32-bit integers).
Peter
Great thanks Peter!
Are there plans for an integer millisecond time that will be exposed ?.. Would be nice as I can handle wrap-around much easier in my code.
Thanks
Anand
Currently the imp only knows the time to centisecond resolution. We do have plans to implement an integer millisecond timer, indeed an int64 microsecond timer – but it’s a large task, that’s currently quite a way down the list, so I’m afraid you can’t expect it in the next release or two.
However we should at least fix clock() so it doesn’t behave so absurdly. We won’t break existing code, so it will still return a float, but if it uses the 32-bit centisecond timer it will only wrap every 497 days which is a bit more like it. Though it’s still a bit of a silly API to start with, because a 32-bit float only has enough precision to deal with 7 decimal significant figures, or 27 hours’ worth of centiseconds, before consecutive values start looking the same. Maybe we should arrange that it wraps at 24 hours; that’s at least a sensible round number.
Peter
Aha. I just tried it. The result of clock() is a clock_t, which is signed, so it wraps after the even less useful 35 minutes 47.48 seconds.
Peter
Would it be simple to expose the centisecond timer as a uint? This will be more usefull until the msec timer is implemented.
Thanks
Anand
OK, that did in fact prove easier than I thought. I expect it’s too late now to make it into the very imminent next release, but it should be in the one after that.
Peter