Scaling Up A Delay

[jbell]

I’m trying to implement an accurate time delay to turn an I/O pin on and off which is adjustable from 40uS to 20mS in 40uS steps. I’m presently using a 16F876A with a crystal running at 20MHz, but I’m open to change if needed. I’ve tried a number of scenarios including timer overflow interrupts (on TMR2) and counting an external 1uS clock. I can’t seem to get any of them to scale accurately. That is, if I get it to delay accurately at 40uS, when I loop that 100 times, it doesn’t come out to 4.0mS.

In the attached sample code I use an external button to trigger RB0 and then a loop in the interrupt macro. If I loop 27 times I get a 40.5uS pulse. If I scale that up by 5X to 135 loops, it comes out to 191.8uS instead of 202.5uS.

My programming ability is very limited, with no real in-depth experience with either Assembly or C. If anyone has any suggestions I’d greatly appreciate the help.

Thanks,

Jim Bell

40uS INT.fcf

(4.5 KiB) Downloaded 345 times

[medelec35]

Hi Jim,
Try this version.
It uses timer2, but unfortunately Flowcode does not simulate timers1 or 2

Technically, correct timer2 rollover value for 40us is 200. Due to some overheads within timer2 I have set rollover to 199 to compensate.
You could try both values.
Basically the value of Time is the multiples of 40us. So if Time is set for 50, then A0 will be high for 50 x 40us = 2ms


Hope this helps

Martin

[jbell]

Martin,

Thanks very much for sharing your expertise in trying to solve this problem. I loaded your code into my test hardware and it compiles and runs just fine. The actual results weren’t quite as expected tho’. When I hit the button to trigger the interrupt while looking at pin A0 with a ‘scope, I get delays between 912uS and 960uS. I tried to attach a scopeshot, but can't figure out how to do it without linking to a public site. At first I thought I might be getting multiple interrupt triggers from switch bounce, so now I’m driving RB0 with a 10uS pulse from a pulse generator. I was also beginning to be concerned about the stability of my clock since the pulse width was changing with every trigger, until I remembered the output from my original primitive circuit was 40.6uS +/- .03uS every time I pulsed the interrupt. So the clock must be reasonably stable. The repeatability of my primitive code also indicates to me that the system is capable of the precision I need, I just have to find a way to bring it out.

Anticipating setup questions: in VIEW/PROJECT OPTIONS the target is set for 16F876A, clock speed is 20000000, no boxes are checked. In CHIP/CONFIGURE, the chip number is correct, the oscillator is set for XTAL, watchdog is off. In the EXPERT screen, oscillator is HS, everything else is off or disabled. In the TMR2 PROPERTIES, both ratios are 1:1, rollover value is 199, clock speed is 20000000, and the interrupt frequency is 25125.628Hz.

Thanks,

Jim Bell

[jbell]

Well this thread just kinda died out, but I've still got the problem and at this point I'm up against some time deadlines. If I can't find something that works soon I'll have to abandon Flowcode for a hardware oriented solution. I hate to do that, it's a lot more complicated and expensive, but I've got to have SOMETHING that works.

I've been playing around with embedding some assembly code thinking there would be less "overhead" and that would minimize the magnifing effect of up-scaling. I've got a nice clever bit of code but have been unsuccessful at getting it to compile. I suspect there are some setup commands I don't know about. I've attached the code, and the compile errors look like this:


FirstASMtest.c
Starting preprocessor: c:\PROGRA~1\MATRIX~1\FLOWCO~1\boostc\pp.exe FirstASMtest.c -i c:\PROGRA~1\MATRIX~1\FLOWCO~1\boostc\include -d _PIC16F876A -la -c2 -o FirstASMtest.pp -v -d _BOOSTC -d _PIC16 -d _CHAR_INDEX


...............

FirstASMtest.c(115): error: unknown assembly identifier 'd'
FirstASMtest.c(117:34): error: error in built-in assembly
FirstASMtest.c(118:38): error: error in built-in assembly
FirstASMtest.c(119): error: undefined label 'loop1ms'
FirstASMtest.c success

failure.
Return code = 1

Flowcode was unable to compile the flowchart's C code due to the following errors:


If your flowchart contains C code, please review this carefully. If your flowchart contains no C-code or you have thoroughly reviewed the code, contact Technical Support.

FINISHED



If anybody has any ideas on how to do this, I'd really appreciate a shout....

Thanks,

Jim Bell

FirstASMtest.fcf

(5 KiB) Downloaded 339 times

[Benj]

Hi Jim,

The program is now compiling correctly. BoostC requires that register names are lowercase and when referenced from assembly they should be prefixed with an underscore.

[jbell]

Thanks, Ben, I'll give it a try...

Jim Bell

[Gary Freegard]

Hi

I have attached a modified version of your code, the changes I have made are:
used timer1
load different values into timer1hi and lo, using C
timer1 is running continuously, just for calibration
A0 has a square wave output (approx 80usec) on it, when the delay hasn’t been started, useful for calibration
A1 is the switched output.
B0 starts the delay.
B1 is used to reset the unit
In main I have included multiple If statements, these will aid in making the delays as accurate as possible
depending on the number of loops required.

Hope this helps.

Gary

[jbell]

Gary,

WOW! Thanks very much for sharing this. My efforts at embeding ASM code did not work out as well as I'd hoped, so I'm very eager to try your code.

It's late Friday afternoon here tho', so I won't get a chance to try it out until Monday, but I will give you some feedback.

Thanks,

Jim Bell

[jbell]

Gary,

Your program works better than anything else I've tried.

Without any special attention to the "tweaking" adjustments provided for TMR1 I was able to get pretty close.
1X=42uS, 10X=400uS, 100X=3.96mS, 1000x=39.6mS.

The clever thing about your approach is that one can put in as many tweaks as necessary (or as many as you can stand to do or have the memory for) depending on how much accuracy you need.

What I need to do now is really understand how the control part of the program works so that I can integrate it into my main program as a macro.

I really appreciate your help, hopefully this will do the trick and I can avoid a lot of extra hardware.

Thanks Again,

Jim Bell