Searching \ for 'how to use delay without effecting your code' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/timers.htm?key=delay
Search entire site for: 'how to use delay without effecting your code'.

Truncated match.
PICList Thread
'how to use delay without effecting your code'
1998\04\30@115635 by andre

flavicon
face
Hi to all engineers.

I am working on project based on multiplex display, keypad, and DAC.
Every thing is fine except one thing. I want to add blinking led like
when you hit
enter the led will blink plus it will display what you want. right now
when I hit
enter led will turn on in same loop when I add delay after led  like

   bsf    led
   call    delay
   bcf    led
   call    delay

this code will effect the display frequency  because of it is in  same
loop.

my question is .
in your code if you want to add any led to blink how do you do
this without effecting your code. if I use hardware timer TMR0,1,2
and instead of using software timer do you think it will solve this
problem.

Andre

1998\04\30@130630 by David VanHorn

flavicon
face
>I am working on project based on multiplex display, keypad, and DAC.
>Every thing is fine except one thing. I want to add blinking led like
>when you hit
>enter the led will blink plus it will display what you want. right now
>when I hit
>enter led will turn on in same loop when I add delay after led  like
>
>    bsf    led
>    call    delay
>    bcf    led
>    call    delay

You're gonna have to get friendly with interrupts.
I have a similar project, where I have several things going on at once, all
running at different speeds.
I set up a 1mS interrupt, and the ISR decrements timer registers until they
hit zero.

A given operation is waiting for it's timer register to hit zero before
continuing.
In the main loop you would be constantly checking timer registers, and if
zero, then you act on it and change the output state (or whatever) then
reload the timer register and return to the main loop.


For a non-linear solution, they DO sell self-blinking LEDs. :)

1998\04\30@132534 by Andy Kunz

flavicon
face
>You're gonna have to get friendly with interrupts.

WRONG!

I have done cable TV converters which do exactly this, plus various other
pieces of equipment.

Separate the logic to display the digits from the logic to blink them.

The key is to set up the TMR0 so that you are able to get both the blink
duration and the dwell as multiple times of TMR0 rollovers, or of some
other software timer which you decrement at an even rate.  The blink logic
should get messages from the app level as to whether it should blink or
not.  The blink level determines how many, how long, etc. by setting up
counters and state flags to message the hardware display level.

The hardware display logic should only show characters if it has permission
from the blink logic to do so.  You can do all kinds of fancy things, like
scrolls, waves, etc. if you implement it correctly.

This also works fine for audio beeps, etc.

Andy

==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\04\30@140928 by David VanHorn

flavicon
face
>WRONG!


As usual there are a number of ways to implement any given task.
I must have misunderstood, I thought he was referring to a single LED
In any case, using a timer int to provide an opsys "tick" to pace I/O
functions is perfectly
valid, and works just fine.  I suppose you could do it without ints, but if
you want to have
deterministic time intervals, that is certainly the hard way.

>The key is to set up the TMR0 so that you are able to get both the blink
>duration and the dwell as multiple times of TMR0 rollovers, or of some
>other software timer which you decrement at an even rate.  The blink logic
>should get messages from the app level as to whether it should blink or
>not.  The blink level determines how many, how long, etc. by setting up
>counters and state flags to message the hardware display level.


Perhaps we are talking about the same thing, but describing it differently?

1998\04\30@145550 by Mike Keitz

picon face
On Thu, 30 Apr 1998 07:37:17 -0700 Andre Abelian <spam_OUTandreTakeThisOuTspamcompufire.com>
writes:
>Hi to all engineers.
>
>I am working on project based on multiplex display, keypad, and DAC.
>Every thing is fine except one thing. I want to add blinking led like
>when you hit
>enter the led will blink plus it will display what you want. right now
>when I hit
>enter led will turn on in same loop when I add delay after led  like

Since you are already scanning the display at a constant rate, it is easy
to make some or all digits blink.  Add a RAM counter that increments
every time you finish scanning the display (scan the last digit) and just
rolls over freely.  When a certain bit in the counter is set (which one
to use depends on how rapid the blinking should be), blank off the digits
that should blink.  Blanking them off means that when their time to scan
comes up, ignore the value that should be displayed and write all ones or
zeros for the segment data so the segements are all off.

Using a bit in a binary counter means the display will blink on and off
at 50% duty.  For example if the display scans at 50 Hz and you use bit 4
of the counter, the blinking will be on for 320 ms and off for 320 ms.
If you use the LSB, which is incrementing very fast, you can get a "dim"
effect (blanked every other scan) which may be useful as well.  Set up
other bits in RAM to indicate which digits should blink.  If you just
want the whole display to blink like a clock that has not been set, then
only one bit is required.  The main program would set or clear the
blinking flags as needed.  The display will start and stop blinking "in
the background".

If you're talking about discrete LEDs, you can also control and time the
blinking of them with the display multiplexing routine.  They can have
their own port pins or be connected in the multiplexed array (7 or 8
discrete LEDs connected like the segments in another digit).

_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\04\30@214458 by Regulus Berdin

flavicon
face
From: Andre Abelian <.....andreKILLspamspam@spam@compufire.com>
{Quote hidden}

Make your scanning routine as a subroutine that can be called anywhere
in the program.  Then inside the delay call the scanning routine.

Example:

scan:                    ;scanning is here
       .
       .
       return

delay:
       delay here X milliseconds...
       call    scan
       delay here X milliseconds...
       call    scan
       .
       .
       return

main_loop:
       .
       .
       call    scan                ;scanning is called here at certain
interval
                                       ;X milliseconds
       .
       if time to blink
        goto blink
       .
       .
       goto    main_loop

blink:
       bsf    led
       call    delay
       bcf    led
       call    delay
       goto    main_loop


Hope this helps.

Reggie


'how to use delay without effecting your code'
1998\05\01@060303 by g.daniel.invent.design
flavicon
face
Mike Keitz wrote:
{Quote hidden}

Write a book and become famous ! (well to embedded programmers anyway)
excelent clarity Mike !
regards,
.....graham.danielKILLspamspam.....xtra.co.nz
--
I invent therefore I am.

1998\05\01@091836 by Andy Kunz

flavicon
face
>Perhaps we are talking about the same thing, but describing it differently?

Probably, but not quite.  I did mine in a '57 for a CATV settop box.  Later
moved the code to a '73 (because of growing needs elsewhere) but retained
the same implementation.  This runs off the time-of-day clock.  I use the
same thing in the FMA Einstein (http://www.fmadirect.com) and in general just
about everywhere.

It is very deterministic to do it this way.  It receives IR, tracks time
(to 2 seconds per month subject to xtal), processes IR requests, washes the
carpet, etc. all in a '57.  And it takes no CALLs (now _that's_ determinism).

Andy

==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\05\01@145207 by David VanHorn

flavicon
face
>It is very deterministic to do it this way.  It receives IR, tracks time
>(to 2 seconds per month subject to xtal), processes IR requests, washes the
>carpet, etc. all in a '57.  And it takes no CALLs (now _that's_
determinism).



Interesting.  I started out in this biz with a Z8 project, all int driven,
and really gained a lot of respect for the int mechanism. That particular
project was a barcode reader, taking data from a wand (black/white)
measuring the widths, and decoding the whole thing char by char on the fly.
Everything ran from ints, and the main program loop was Main: jmp Main  :)
The original system was written by another fellow, who I thought was really
good, but as it turned out was a total bozo.  I rebuilt everything, and
brought the minimum xtal down from 12.288 to 3.57MHz.  12.288 was actually
"overclocking" it by a bit!    My current AVR project has to deal with one
peripheral that demands IRQs in bursts at 300kIIRQs/sec (I'm not real happy
with that part, but it works!)

I've not done a lot on stack-limited machines, the Z8 has 192 ram, and stack
can be any or almost all of that.  The Atmel AVR is great that way, 512 ram
makes for loads of elbow room.  My big "limited stack" project so far is a
programmable transmitter on the '84. User program is loaded through a soft
uart, and resides in EEPROM in a tokenized language. It has an onboard
interpreter, executing the user program byte at a time.  I ended up not
using the entire second half of the ram, but ran out of rom :(  The ascii to
morse translator ate up a lot.  It's at http://www.agrelo.com/upll.html  That one
was fun indeed!

I looked on the FMA page, that's quite a nice charger! How does the IR part
fit in?

1998\05\02@030810 by paulb

flavicon
face
David VanHorn wrote:

> You're gonna have to get friendly with interrupts.

 And was chastised; and fought back.

 Fact is; there are three ways to do this and all work well.

 Top level: Use timer interrupts.  The interrupt decrements one or more
counters, re-initialising it/ them if necessary.  For greatest
flexibility, counter time-outs are used to set a flag and the IRQ
routine does no more, but the main ("background") loop in its own good
time looks at the flag(, resets it) and decides what to do with it.
Presuming this loop is actually quite fast, minor variations in the time
taken to look at the flag will cause no perceptible display flicker.

 For a multiplexed display, one counter can be used to initiate
stepping from one digit to the next, and another to implement flashing.

 Mid-level: Use timer overflow.  This method and the last can be and
have for a long time been used on PICs with no interrupts.  The main
loop passes through the various tasks, and one such task is to check for
timer overflow.  When this occurs, it is processed exactly as described
for an interrupt above.

 Both these timer-based methods are facilitated by the timer prescaler,
making the timer "tick" correspond as closely as possible to the minimum
period desired between events (such as a display multiplex step).  This
minimises the time spent updating the counters compared to all the other
processing.

 Low-level:  Use isosynchronous coding.  This can be done on most
processors, even without a timer function.  Isosynchronous code is
written so that each section of the program takes the same number of
clock cycles no matter what branches are taken.  This means that an
"IF - THEN" section is implemented as an "IF - THEN - ELSE" where the
"ELSE" contains a delay to make it equal to the "THEN" in execution
time.

 The PIC actually makes this easy for small decisions involving a
single operation as the "Skip" instructions take two cycles whether the
skip is taken or not.  Longer decision sequences are coded as:

<conditional skip> <GOTO second part> <first part> <GOTO continue>
 <second part> <continue code>

.. where the second part code must be exactly one cycle longer in
execution than the first (both encounter a GOTO, but the first part is
delayed one cycle in skipping the first GOTO).

 The flow of execution is now such that functions which must be fastest
are executed in tighter loops.  The loop counter for these becomes the
"clock".  Because these procedures may not branch out or call one
another to execute consequential functions, they must instead set flags
to each other or to "outer" routines (State Machine operation).

 The multiplex stepping is timed by a certain number of executions of
"inner" loops and is itself an isosynchronous process.  Part of the
display routine reads the "blink" flag and zeroes the display data if
required, but the display is written in the same amount of time either
way.

A loop counter outside this then toggles the "blink" flag, and another
counter outside this again can be used to count seconds, minutes, hours
etc. to keep clock time.  I don't recommend trying *this* in "C"
however!  The execution time of each of these loop routines is not
important in itself as long as the loop always makes the same number of
iterations and the time of these in cycles can be tallied.

 Does all of this make sense, Andre?

 Cheers,
       Paul B.

1998\05\04@093110 by Andy Kunz

flavicon
face
>I looked on the FMA page, that's quite a nice charger! How does the IR part
>fit in?

Thanks.  I was called in late in the project, when they were about to start
mfg'ing it and found one part had been discontinued for quite some time.
My job was to replace the LCD driver/brains as cheaply as possible.  Did it
with a 4MHz '54, a cheap ext LCD driver, and at the same time added a bunch
of features.  The power of processors!

The Einstein was based on code I did for a CATV set-top box.  That's what
used the IR, not the Einstein.

Didn't have enough I/O pins to add the IR input, or I would have liked to
have it there.

Andy

==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...