Best way to wait

Discussion about the ZBasic language including the System Library. If you're not sure where to post your message, do it here. However, do not make test posts here; that's the purpose of the Sandbox.
Post Reply
FFMan
Posts: 502
Joined: 09 January 2010, 12:52 PM

Best way to wait

Post by FFMan »

I'm building a Nixie clock/thermometer display, using 8 nixie tubes driven by 2 x 7414 ICs so multiplexing 4 tubes in a group.

my multiplex routines turns on the appropriate anode and uses delayMicroseconds to allow time for it to light up and the nixie element to glow.

Have i read the documentation correctly in that delaymicroseconds effectively suspends other tasks from running (except interrupt driven) which isn't very desirable as i have a main task and potentially another one or two task.

i want to achieve the approx wait time but yield to other processes ideally.

what is the best way to achieve this ?

As its written currently does incoming serial data on a s/w uart count as interrupt driven or would it be lost ?
dkinzer
Site Admin
Posts: 3120
Joined: 03 September 2005, 13:53 PM
Location: Portland, OR

Re: Best way to wait

Post by dkinzer »

FFMan wrote:what is the best way to achieve [a delay like] this ?
Much depends on the length of the delay and the precision/accuracy that is required. If the delays are multiples of the RTC tick and not much precision is required you can use the RTC stopwatch to regulate the delays. Simply clear the stopwatch value and then check it from time to time, yielding to other tasks until the desired value is reached.

If smaller delays are required, you can essentially do the same thing by using a hardware timer. Set it to run at a suitable frequency and then watch the ticks accumulate until the threshold is reached. One problem with doing this is dealing with the possibility of missing the threshold and wrapping the count. You can try to detect the wrap by keeping track of the last known value. If the current timer value is less than the last, you know that the timer wrapped at least once. You might also be able to use an ISR on the timer to alert you to a wrap.
FFMan wrote:As its written currently does incoming serial data on a s/w uart count as interrupt driven or would it be lost ?
Yes. If you block interrupts for less than approximately half of the bit time you likely won't interfere with serial transmission or reception. Reception on a S/W channel is more sensitive because it relies on sampling as close to the bit window of the start bit as possible in order to arrange for sampling near the middle of the subsequent bit windows as possible. The more off-center you get, the more likely it is to be sampling at the wrong time, especially if the sender isn't generating the bit windows accurately or consistently.
- Don Kinzer
FFMan
Posts: 502
Joined: 09 January 2010, 12:52 PM

Post by FFMan »

> Much depends on the length of the delay and the precision/accuracy that is required. If the delays are multiples of the RTC tick and not much precision is required you can use the RTC stopwatch to regulate the delays. Simply clear the stopwatch value and then check it from time to time, yielding to other tasks until the desired value is reached.

the delay is in the order of 700 microseconds - accuracy really not an issue.

are the RTC routines available through the zbasic library ?
dkinzer
Site Admin
Posts: 3120
Joined: 03 September 2005, 13:53 PM
Location: Portland, OR

Post by dkinzer »

FFMan wrote:are the RTC routines available through the zbasic library ?
The RTC stopwatch is accessible via Register.RTCStopwatch. It is readable and writable, you reset it by assigning zero to Register.RTCStopWatch.

More information here:
www.zbasic.net/doc/ZBasicRef.php?page=79

The RTC stopwatch changes 512 times per second on a ZX device (which value is given by Register.RTCTickFrequency).

However, this may be too coarse for your application since it changes about every 2 milliseconds. For finer resolution, you may be able to use the value of the RTC timer register itself (TCNT) as it changes at a rate of 230.4KHz on ZX devices running at 14.7MHz. The value for any particular device is given by Register.RTCTimerFrequency. You would have to deal with the TCNT register rolling over from its maximum to zero.

Yet another option, and a simpler one, is to use the GetElapsedMicroTime() function. The resolution is the same as the RTC timer frequency (typically 4 uS) and it properly handles at most one midnight rollover.

GetElapsedMicroTime()
www.zbasic.net/doc/ZBasicSysLib.php?page=155
- Don Kinzer
FFMan
Posts: 502
Joined: 09 January 2010, 12:52 PM

Post by FFMan »

thanks don - that gives me some things to explore.
FFMan
Posts: 502
Joined: 09 January 2010, 12:52 PM

Post by FFMan »

> GetElapsedMicroTime()

this looks like the simplest method.

When written should i just loop with Yield checking for time expiry ?
dkinzer
Site Admin
Posts: 3120
Joined: 03 September 2005, 13:53 PM
Location: Portland, OR

Post by dkinzer »

FFMan wrote:When written should i just loop with Yield checking for time expiry ?
Yes.
- Don Kinzer
Post Reply