Truncated match.
PICList
Thread
'how to use delay without effecting your code'
1998\04\30@115635
by
andre
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
>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
|
>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
>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
|
On Thu, 30 Apr 1998 07:37:17 -0700 Andre Abelian <spam_OUTandreTakeThisOuT
compufire.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
|
From: Andre Abelian <.....andreKILLspam
@spam@compufire.com>
{Quote hidden}>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.
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
|
Mike Keitz wrote:
{Quote hidden}>
> On Thu, 30 Apr 1998 07:37:17 -0700 Andre Abelian <
andre
KILLspamcompufire.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]
Write a book and become famous ! (well to embedded programmers anyway)
excelent clarity Mike !
regards,
.....graham.danielKILLspam
.....xtra.co.nz
--
I invent therefore I am.
1998\05\01@091836
by
Andy Kunz
>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
|
>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
|
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
>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...