Hi All,
A simple 'survey' of how you speed up time (NOT TIME$).

That is, how do you get test code to run apparently faster so you don't get bored waiting for faults?

My usage:
I'm changing some code of mine (2,000 + lines) that does something each second, minute, 15 minutes and hour.
At present I have a SETTICK interrupt every second, a MOD test on TIME$ for minutes every 1, 15 and 60 minutes.

I want to speed it up to avoid having to wait say an hour (or even 15 minutes) to see if it works or not.

One option is to increment a counter every call to the SETTICK interrupt and do my MOD tests on it (so its not linked to TIME$).

I can then speed up "time" by reducing the SETTICK time from 1000 to say 100.
(I'll need to watch for any processes that take a finite time to complete).

That should work - what do you do?

Cheers,

Andrew

---

Hi, Andrew - Sounds like you're implementing a clock.

You might want to have constants defined at the top of your code for the SETTICK and tests that get performed to take actions. That way, you can pop in and edit just a few lines to change the timing behavior of your code.

If you're using a PicoW and requesting network time, you might want to set up error handling in advance, and also measure the typical response time so you don't perform that action more often than the response time allows (in my clock code, I only do that on the hour, and if it fails, continue to use DATE$ and TIME$ as previously determined. I also switch between an indicator character that shows a computer for net time, vs. a stick figure for manually-set time).

Best of luck!

Hi NPH,
Thanks.
Yes part of it is a clock and I'll continue to use the Pico's TIME$ for that.

Do you speed up "time" for testing code - or do you have more patience than me . . .?

Cheers,

Andrew

(It is actually a PICO and a PICO-W side by side.
It is one of BigMik's devices with Humidity, Barometric Pressure, HC-12, SD card, DS19B20, audio plus more, including a 4" LCD - all run off a rechargeable battery in a 124x79x33mm enclosure).
Most of the sensors pass on their readings every 15mins and are graphed each 15 minutes over 4 hours and then hourly over 7 days - hence my need to speed it up.)

This is my system for my aquarium controller. A complete cycle is only 24hrs. In your case you may need to run the SETTICK interrupt far faster for some tests.

I use tim$ = Time$ if a debug flag is off.
If the debug flag is on I use a 1s SETTICK to increment a value that I convert into tim$ (watch out for leading zeros!). Next to the debug flag setting I preload the SETTICK counter with a value, which is the time that I want my debug time to start. That way I don't have to wait hours for something to happen. All the time comparisons are done on tim$, of course.

I was setting time$ using NTP on a WebMite, but I ended up taking that out because of general internet-related reliability issues. So far the cheapest RTC module I could get feeding a Chinese Pico clone is fine and cost far less than the WebMite in total. :)
Edited 2024-05-04 17:57 by Mixtel90

Create a alternate time$

With 10 seconds per minute
With 2 minutes per hour
And 2 hours per day

Volhout

My super-fast method for bug detection is to let someone else use my program for a few seconds

Hehe....  I know that one!