Post by thread:how to use delay without effecting your code

>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. :)

>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 ==================================================================

>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?

On Thu, 30 Apr 1998 07:37:17 -0700 Andre Abelian <spam_OUTandreTakeThisOuTcompufire.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]

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

Mike Keitz wrote: {Quote hidden}> > On Thu, 30 Apr 1998 07:37:17 -0700 Andre Abelian <andreKILLspamcompufire.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.

>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 ==================================================================

>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?

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.

>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 ==================================================================