Post by thread:[PIC] Reliable IOC?

Hi all, I'm searching the best technique to handle interrupt on change simultaneously activated on PORTA & PORTB (on a 16F690 in this case). If in the ISR (assuming there is only IOC activated) I do something like: ... movf PORTA,w movwf PORTA_IMG movf PORTB, w movwf PORTB_IMG bcf INTCON, RABIF ... Would I have a chance to loose a change on any bit? (I'm thinking about a change on PORTA that occurs between the first read and the bcf) I think there is another technique that should be used? Also the DS says that: "If a change on the I/O pin should occur when the read operation is being executed (start of the Q2 cycle), then the RABIF interrupt flag may not get set." That's confusing for me; how to handle IOC reliably in all cases? Regards, Philippe. ----- Best regards, Philippe. http://www.pmpcomp.fr Pic Micro Pascal for all! -- View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23611087.html Sent from the PIC - [PIC] mailing list archive at Nabble.com.

Hi, Phillipe! I like PMP! This should be fine, copy to another REG won't disturb the 1st reg unless the first reg is STATUS. --Bob A On Tue, May 19, 2009 at 12:27 AM, PPA <spam_OUTphilippe.paternotteTakeThisOuTpmpcomp.fr> wrote: {Quote hidden}> > Hi all, > > I'm searching the best technique to handle interrupt on change > simultaneously > activated on PORTA & PORTB (on a 16F690 in this case). > If in the ISR (assuming there is only IOC activated) I do something like: > ... > movf PORTA,w > movwf PORTA_IMG > movf PORTB, w > movwf PORTB_IMG > bcf INTCON, RABIF > ... > Would I have a chance to loose a change on any bit? > (I'm thinking about a change on PORTA that occurs between the first read and > the bcf) > I think there is another technique that should be used? > > Also the DS says that: "If a change on the I/O pin should occur when the > read > operation is being executed (start of the Q2 cycle), then the RABIF > interrupt flag > may not get set." That's confusing for me; how to handle IOC reliably in all > cases? > > Regards, > Philippe. > > > ----- > Best regards, > > Philippe. > > http://www.pmpcomp.fr Pic Micro Pascal for all! > -- > View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23611087.html > Sent from the PIC - [PIC] mailing list archive at Nabble.com. > >

Hi, I agree if there is only one PORT this is trivial; if it was the case I wouldn't ask for help... Sorry but if you read my OP, it was: You read PORTA so you reset the IOC latches to the current value. Then same thing during PORTB read. Then you reset the int flag. So if an event on PORTA occurs between read PORTA and the flag reset, the flag will not be set and the event would be lost (will not generate an interrupt). Where this is false? Rikard Bosnjakovic-2 wrote: {Quote hidden}> > On Thu, May 21, 2009 at 15:49, PPA <philippe.paternotteKILLspampmpcomp.fr> wrote: > >> What about IOC? > > What about it? > > As soon as you're in the ISR, the IOC has already occured, meaning > it's safe to copy the PORTs. > ----- Best regards, Philippe. http://www.pmpcomp.fr Pic Micro Pascal for all! -- View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23664976.html Sent from the PIC - [PIC] mailing list archive at Nabble.com.

Hi all, Still no answer... I've searched around a bit and found that IOC generates many questions from programmers... Most of them on how to use IOC, a few on reliability of IOC; some answers are speaking of specific software tricks to workaround hardware "bugs" issues... Something to be scared of... Maybe a bit of more detailed explanation of what I want to do may help to understand my questions: I would want to measure the width of continuous streams of pulses that come asynchronously to each other on 10 input pins. I dedicated PORTA/PORTB to this. Each pulse is say, like a RC model pulse 1-2 ms / 20 ms. The idea was, using TMR1 that is let running free, to measure pulse width on each channel by computing TMR1 delta value between rising and falling edges of the signals. Some jitter is acceptable (variable latency due to other interrupts) and would be filtered out after. It is easy to understand that I cannot miss any signal edge. I've tried some simple IOC mechanism before one one port only, without problems (well, I don't perform a long reliability test...), despite of what MC seems to say (see below). My question is about using two ports simultaneously. I detected some possible problematic points. Before starting to make an heavy test stand to check this with several asynchronous input streams, I would want to know if this approach is realistic or not... Also one other confusing thing for me, as I said in my OP is: In the PIC16F690 datasheet, Microchip wrote: > > "If a change on the I/O pin should occur when the read operation is being > executed (start of the Q2 cycle), then the RABIF interrupt flag may not > get set." > So the question is still: can we do reliable IOC in all cases? This sort of "small print" MC sentence seems to say NO even for a single bit. That's what is boring me. ----- Best regards, Philippe. http://www.pmpcomp.fr Pic Micro Pascal for all! -- View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23692651.html Sent from the PIC - [PIC] mailing list archive at Nabble.com.

PPA wrote: > I would want to measure the width of continuous streams of pulses that > come asynchronously to each other on 10 input pins. > I dedicated PORTA/PORTB to this. > Each pulse is say, like a RC model pulse 1-2 ms / 20 ms. I would set up a periodic interrupt as fast as you can tolerate. Check all inputs each interrupt and count ticks during the on time. I don't know what kind of PIC you're using, but with a 20MHz clock and a interrupt every 100 instructions, you get a resolution of 20uS, or one part in 50 over the 1-2mS range. This solves your problem as you didn't specify higher resolution than that. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

Hi Olin, Thanks. I though that at least I can do something like this... A /50 resolution is a bit low, I've to think about it... And I though to use internal osc @ 8MHz since I need all RA pins... And I've not said it but you may have guessed that I have to do some things with these measures, so a high int rate will put other processes to the knees; but what is "acceptable" for me? I have to think about it too... This remains a possible option. Nevertheless, do you have any advice on IOC or is it a quite significant silence? You often say that MC datasheets are well written (generally speaking I agree on that)... But on this subject I feel a little bit blind, in the total vagueness... Somebody quite rational may think that if they designed this functionality, we should find a reliable way to use it... Remember what you said: programming is not voodoo, although in that case it may help... :-) Did you find some DS/AN/whatever article that fully explains what are the known limitations and problems? At least a good tip? Olin Lathrop wrote: > > you get a resolution of 20uS, or one part in 50 over the 1-2mS > range. This solves your problem as you didn't specify higher resolution > than that. > ----- Best regards, Philippe. http://www.pmpcomp.fr Pic Micro Pascal for all! -- View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23696070.html Sent from the PIC - [PIC] mailing list archive at Nabble.com.

PPA wrote: > I'm searching the best technique to handle interrupt on change > simultaneously > activated on PORTA & PORTB (on a 16F690 in this case). > If in the ISR (assuming there is only IOC activated) I do something like: > ... > movf PORTA,w > movwf PORTA_IMG > movf PORTB, w > movwf PORTB_IMG > bcf INTCON, RABIF > ... > Would I have a chance to loose a change on any bit? > (I'm thinking about a change on PORTA that occurs between the first read and > the bcf) I think there is a chance that a change is lost with this technique. It seems that IOC is mainly thought of something that wakes a PIC up from sleep, but not necessarily as a means of detecting every change. > I think there is another technique that should be used? Polling, as Olin said. Gerhard

Hi Olin, Of course there will be a significant jitter. A bit of math: I expect an int routine global treatment time (worst case) of 100 ÂµS @ 8MHz, so we can expect a mean jitter of half of that, say 50 ÂµS. This is 5% for a 1 ms full scale; in the same time the resolution of TMR1 that I use is 1 ÂµS (1/1000th of full scale) and I use some filtering - say with 8 samples to simplify computing - so I may expect an "acceptable" result (1.5% or less with simple averaging down to 0.5% with a better method). Also with the cost of some smooth delay due to averaging... All of this without taking into account all other jitter sources... If I decide to finally use an external osc @ 20MHz, it should be better. Olin Lathrop wrote: {Quote hidden}> > PPA wrote: >> Nevertheless, do you have any advice on IOC > > Do you mean "interrupt on change". If so, then it doesn't seem > appropriate > in this case. How do you expect to handle separate asynchronous > interrupts > from so many input pins without significant jitter, and therefore loss of > resolution? > ----- Best regards, Philippe. http://www.pmpcomp.fr Pic Micro Pascal for all! -- View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23702815.html Sent from the PIC - [PIC] mailing list archive at Nabble.com.

Hi, Thanks for these explanations. as2 wrote: > > The work around is to read the port again after clearing the interrupt > flag > and use the state from that read. Occasionally although you have read > the most recent pin state the change interrupt flag will be set again and > you will immediately take another interrupt where there was apparently no > change. > I see. But in all cases I had already to determine witch edge so the logic is already present; there will be a small interrupt treatment for nothing, so it should be OK. Thanks for the tip. as2 wrote: > > Reading or RMWing the ports anywhere else in the program may cause > problems, > ... > Yes I already had such problems; I would say "will cause problems"; that's a certitude. If I need it I use only the shadow reg that is read in int routine... as2 wrote: > > Is the change 'glitch' you get when the pin changes in a cycle where you > read the port enough to set the interrupt flag? I don't know. > I'm not sure too... I think I have to be resolved to experiment. That said, I don't understand why they have latched with Q3 at pin level. In other hardware that I saw, there is a simple xor gate between input signal and the last read, the outputs are ORed and this latches the whole byte and sets int flag. That works fine and does not consume more silicon... ----- Best regards, Philippe. http://www.pmpcomp.fr Pic Micro Pascal for all! -- View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23703461.html Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009/5/24 Gerhard Fiedler <.....listsKILLspam.....connectionbrazil.com> > > > I think there is another technique that should be used? > > Polling, as Olin said. > > Gerhard > > I agree on this. My experiments on IOC for a few RC products were really disappointing. Polling is a much better technique in my experience for dealing with RC timing, and it probably becomes quickly as the only reliable option if you look at several ports at a time. With a INTOSC running at 8MHZ, you have plenty of time to process things while the PPM pulse is low -almost 20ms- and then get back to polling mode as you expect the PPM pulse high again. You may want to check the input level at intermediate points to detect noise or jitter, in any case a simple state machine, designed to do polling and processing at the right times is all you probably need. -- Ariel Rocholl Madrid, Spain

PPA (a.k.a. Phillipe) wrote: > > Hi Olin, > > Of course there will be a significant jitter. > A bit of math: > I expect an int routine global treatment time (worst case) of 100 ÂµS @ > 8MHz, > so we can expect a mean jitter of half of that, say 50 ÂµS. 100uS is a relatively slow rate. Here is a suggestion on how to approach the problem. You may wish to read the thread on RTOS's too... I would suggest setting up a timer interrupt to poll the I/O pins. This interrupt routine can read the state of the pins and store the result into a circular buffer. In addition, the circular buffer's pointer also serves as the time stamp. Meanwhile, code not running in the routine will process the data captured in the circular buffer and look for I/O pin changes. Changes are easy to detect by exclusive-or'ing the current sample with the previous. If you need to debounce spurious glitches, then check out http://www.dattalo.com/technical/software/pic/debounce.html Scott {Quote hidden}> This is 5% for a 1 ms full scale; in the same time the resolution of TMR1 > that > I use is 1 ÂµS (1/1000th of full scale) and I use some filtering - say > with 8 > samples to simplify computing - so I may expect an "acceptable" result > (1.5% > or less with simple averaging down to 0.5% with a better method). Also > with > the cost of some smooth delay due to averaging... > All of this without taking into account all other jitter sources... > If I decide to finally use an external osc @ 20MHz, it should be better. > > > Olin Lathrop wrote: >> >> PPA wrote: >>> Nevertheless, do you have any advice on IOC >> >> Do you mean "interrupt on change". If so, then it doesn't seem >> appropriate >> in this case. How do you expect to handle separate asynchronous >> interrupts >> from so many input pins without significant jitter, and therefore loss >> of >> resolution? >> > > > ----- > Best regards, > > Philippe. > > http://www.pmpcomp.fr Pic Micro Pascal for all! > -- > View this message in context: > www.nabble.com/Reliable-IOC--tp23611087p23702815.html > Sent from the PIC - [PIC] mailing list archive at Nabble.com. > > >

Hi Scott, Thanks for your response / suggestion. Scott Dattalo wrote: > > I would suggest setting up a timer interrupt to poll the I/O pins. This > interrupt routine can read the state of the pins and store the result into > a circular buffer. In addition, the circular buffer's pointer also serves > as the time stamp. > > Meanwhile, code not running in the routine will process the data captured > in the circular buffer and look for I/O pin changes. > Interesting, but I don't understand how we can do that on a PIC16F690. I think we do not have enough power (maybe @ 20 MHz) / memory to do it: If the buffer is not quite big, it will roll over very often, so the asynchronous "debounce" / filtering routine will reject many pulses. To have a chance to catch a good one (1 ms worst case), and to achieve say 10Âµs of resolution, we would need 100 bytes! And it would be difficult (not impossible) to have a 10Âµs interrupt period... And if the analysis routine recurrence is greater than 1 ms (due to fast int rate and other tasks) many pulses would be lost... That said, this technique is interesting. I used such one in the past, but it was on a PC board with DMA... What? Those PICs have no DMA? What a pity! :,( Scott Dattalo wrote: > > www.dattalo.com/technical/software/pic/debounce.html > I know it: that's my preferred debouncing routine since a long time... As well as the v adders technique... Thanks to have given it to the world! ----- Best regards, Philippe. http://www.pmpcomp.fr Pic Micro Pascal for all! -- View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23708098.html Sent from the PIC - [PIC] mailing list archive at Nabble.com.

Buenos dÃas Ariel, Â¿quÃ© tal? arocholl wrote: > > If this is an on-board project, note INTOSC is always recommended as it > has > a much reduced EMI when compared with external OSC. Only problem with > INTOSC > is low accuracy, but that is typically good enough for RC. > Yes, and for board cost too... And some small devices INTOSC can be (re)calibrated. It works fine at a relatively constant ambient temperature. That would have been too nice if they had made it for all ones... ----- Best regards, Philippe. http://www.pmpcomp.fr Pic Micro Pascal for all! -- View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23708429.html Sent from the PIC - [PIC] mailing list archive at Nabble.com.

part 1 2339 bytes content-type:text/plain; charset=UTF-8 (decoded quoted-printable) PPA escreveu: {Quote hidden}> Hi Scott, > > Thanks for your response / suggestion. > > > Scott Dattalo wrote: > >> I would suggest setting up a timer interrupt to poll the I/O pins. This >> interrupt routine can read the state of the pins and store the result into >> a circular buffer. In addition, the circular buffer's pointer also serves >> as the time stamp. >> >> Meanwhile, code not running in the routine will process the data captured >> in the circular buffer and look for I/O pin changes. >> >> > > Interesting, but I don't understand how we can do that on a PIC16F690. > I think we do not have enough power (maybe @ 20 MHz) / memory to do it: > If the buffer is not quite big, it will roll over very often, so the > asynchronous > "debounce" / filtering routine will reject many pulses. > To have a chance to catch a good one (1 ms worst case), and to achieve > say 10µs of resolution, we would need 100 bytes! And it would be difficult > (not impossible) to have a 10µs interrupt period... And if the analysis > routine > recurrence is greater than 1 ms (due to fast int rate and other tasks) many > pulses would be lost... > That said, this technique is interesting. I used such one in the past, but > it > was on a PC board with DMA... > What? Those PICs have no DMA? What a pity! :,( > > > Scott Dattalo wrote: > >> www.dattalo.com/technical/software/pic/debounce.html >> >> > I know it: that's my preferred debouncing routine since a long time... > As well as the v adders technique... > Thanks to have given it to the world! > Not need to buffer the incoming data. Just compare (XOR) the value read in each interrupt with the value read in the previous interrupt and save the value to be the previous for the next interrrupt. The result of the comparison may be ORed to a global variable which stores the pin changes. The application code (in a critical section) reads the pin changes variable and clear it. Regards, Isaac __________________________________________________ Fa訵es para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/ part 2 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)

Hi Ariel, arocholl wrote: {Quote hidden}> > 2009/5/24 Gerhard Fiedler <listsspam_OUTconnectionbrazil.com> > >> >> > I think there is another technique that should be used? >> >> Polling, as Olin said. >> >> Gerhard >> >> > I agree on this. My experiments on IOC for a few RC products were really > disappointing. > You too? :-) Is there any real application for these damned functions??? arocholl wrote: {Quote hidden}> > Polling is a much better technique in my experience for > dealing with RC timing, and it probably becomes quickly as the only > reliable > option if you look at several ports at a time. > With a INTOSC running at 8MHZ, you have plenty of time to process things > while the PPM pulse is low -almost 20ms- and then get back to polling mode > as you expect the PPM pulse high again. You may want to check the input > level at intermediate points to detect noise or jitter, in any case a > simple > state machine, designed to do polling and processing at the right times is > all you probably need. > As I said to Steve, this is not so simple nowadays... ----- Best regards, Philippe. http://www.pmpcomp.fr Pic Micro Pascal for all! -- View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23710149.html Sent from the PIC - [PIC] mailing list archive at Nabble.com.

*Bonjour Philippe, comment vas tu? * 2009/5/25 PPA @spam@philippe.paternotteKILLspampmpcomp.fr > > > > I agree on this. My experiments on IOC for a few RC products were really > > disappointing. > > > You too? :-) > Is there any real application for these damned functions??? > As someone said already, I think these are designed (and tested) more for waking up device upon single external events such as a button press or signal change, but not for continuous change detection IMHO. > > As I said to Steve, this is not so simple nowadays... > I know there is no standard for RC PPM in timing nowadays, thus what I do is detect timing for a few frames first and then use this as a parametrized state machine. It works reasonably well depending on how much processing you have to do in between pulses. There is no one answer for all applications of course. Note if you find a system repeating pulses every 5 or 10ms, that is just to drive an "analog" servo closer to that of a "digital" servo performance. You can safely ignore repeated pulses, no real need to process them all. An analog servo circuitry will benefit from more frequent pulses, but a digital logic can ignore that. HTH -- Ariel Rocholl Madrid, Spain

Isaac Marino Bavaresco wrote: >> Scott Dattalo wrote: >> >>> I would suggest setting up a timer interrupt to poll the I/O pins. This >>> interrupt routine can read the state of the pins and store the result >>> into >>> a circular buffer. In addition, the circular buffer's pointer also >>> serves >>> as the time stamp. > Not need to buffer the incoming data. Just compare (XOR) the value read > in each interrupt with the value read in the previous interrupt and save > the value to be the previous for the next interrrupt. Isaac, Your suggestion of just recording changes will work fine. In addition, the time stamp of the change may also be needed. The debouncing (if needed) could be inlined in the interrupt routine. It's only 13 cycles. Scott

Scott Dattalo escreveu: {Quote hidden}> Isaac Marino Bavaresco wrote: > > >>> Scott Dattalo wrote: >>> >>> >>>> I would suggest setting up a timer interrupt to poll the I/O pins. This >>>> interrupt routine can read the state of the pins and store the result >>>> into >>>> a circular buffer. In addition, the circular buffer's pointer also >>>> serves >>>> as the time stamp. >>>> > > >> Not need to buffer the incoming data. Just compare (XOR) the value read >> in each interrupt with the value read in the previous interrupt and save >> the value to be the previous for the next interrrupt. >> > > Isaac, > > Your suggestion of just recording changes will work fine. In addition, the > time stamp of the change may also be needed. The debouncing (if needed) > could be inlined in the interrupt routine. It's only 13 cycles. > > Scott > The OP said he is trying to decode R/C servo pulses. These pulses usually range from 0.8ms to 2.2ms maximum (nominal 1.0ms to 2.0ms). To get a good resolution he will need a very high sampling rate (tens of microseconds perhaps). A better solution would be to get the PPM signal before the channels are separated. In the PPM signal all channels are sent in sequence and with just one CCP module it is possible to decode all channels, with much less effort and much higher resolution. An important note is that only one channel pulse is present at the outputs at any given time (on old systems at least, I don't know how the new PCM systems behave). This may simplify things, because there is no need to worry about more than one input changing at any given time. Regards, Isaac __________________________________________________ Faça ligações para outros computadores com o novo Yahoo! Messenger http://br.beta.messenger.yahoo.com/

Ariel Rocholl wrote: >>> I agree on this. My experiments on IOC for a few RC products were >>> really disappointing. >>> >> You too? :-) >> Is there any real application for these damned functions??? > > As someone said already, I think these are designed (and tested) more > for waking up device upon single external events such as a button > press or signal change, but not for continuous change detection IMHO. Yup, that was me. You enable the IOC and go to sleep. The IOC will wake the PIC up when there is a change (that is, one or more changes). Then you resume polling and detect how many pins did change. Think of keypads or similar devices where the PIC can sleep most of the time if all it has to do is some quick reactions to users pressing buttons. It doesn't matter that it has to figure out what exactly has been pressed while awake; the important thing is that it did wake up. This of course may not fit your application... :) I also wished already they had a better implementation of this IOC. Gerhard

Hi Isaac, Isaac Marino Bavaresco wrote: > > A better solution would be to get the PPM signal before the channels are > separated. In the PPM signal all channels are sent in sequence and with > just one CCP module it is possible to decode all channels, with much > less effort and much higher resolution. > I've explored this for a partial solution. Unfortunately: - Some channels do not come from the receiver (there is other devices like a gyro). - Some modern receivers cannot be easily opened, some seem to be all in one chip, etc... The target is any receiver / gyro / other without the need of reverse engineering or surgery, thus the direct pulse capture should stay the objective. ----- Best regards, Philippe. http://www.pmpcomp.fr Pic Micro Pascal for all! -- View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23717361.html Sent from the PIC - [PIC] mailing list archive at Nabble.com.

Here is the skeleton of a (untested) program to read 8 RC servo inputs at once. The interrupt level code stores the most recent 'high' time seen on each of 8 PORTB input pins in the COUNT array. The interrupt handler takes 64 instruction times. If we set up the timer to interrupt every 80 instructions (using TIMER2) then our sample rate can be computed as: 80 instructions / 5 instructions/microsecond = 16 uSec. Task level is equivalent to about 1MIPS performance A PIC18 at 10MIPs would be a little better than twice as fast (due to more efficient interrupt handler entry/exit). -- Bob Ammerman RAm Systems radix dec #include P16F628A.INC CFG = _BOREN_ON & _CP_OFF & _DATA_CP_OFF & _PWRTE_ON CFG = CFG & _WDT_OFF & _LVP_OFF & _MCLRE_OFF & _HS_OSC __CONFIG CFG VARS udata 20h ; keep all vars in bank 0. we have room for ; 80h-20h = 60h = 96 of them ; Status saved by interrupt handler SAVE_W res 1 ; saved WREG SAVE_S res 1 ; saved STATUS ; Variables used by interrupt handler PREV res 1 ; previous input value DELTA res 1 ; change since last time RISING res 1 ; rising edge since last time ICOUNT res 8 ; interrupt level counters ; Variables set by interrupt handler and read by ; 'task level' code. These will always contain the width ; of the most recent high pulse seen. COUNT res 8 ; most recent high counts for each pin ; Reset vector - jump to start of 'task' level code RESETV code 0 goto START ; Interrupt handler IHAND code 4 ; Save state. This can be simplified because we know we are in bank 0 ; and page 0 (because the program never leaves either of them with ; interrupts enabled). movwf SAVE_W ;1 Save W without changing STATUS movf STATUS,W ;2 Get STATUS (which changes STATUS!) movwf SAVE_STATUS ;3 Save original value of STATUS ; Process the input. Note that we work with the complement of the ; actual input to save an instruction (it is easier to compute ; which bits are RISING than which bits are falling) ; We have to compute two values ; DELTA - Has 1 bits for any input which changed ; RISING - Has 1 bits for any input which went from 0 to 1 comf PORTB,W ;4 Get current input (complemented) xorwf PREV,W ;5 Compute and store delta movwf DELTA ;6 xorwf PREV,W ;7 Restore complemented input movwf PREV ;8 Save current input for next time andwf DELTA,W ;9 Compute and save rising edge mask movwf RISING ;10 ; Define a macro to process a single bit. Each invocation of the macro takes ; only 6 instruction times. DOBIT MACRO bit incf ICOUNT+bit,W ;1 update interrupt level count btfsc RISING,bit ;2 rising edge? movwf COUNT+bit ;3 yes: save length of low time btfsc DELTA,bit ;4 did bit change? clrw ;5 yes: zero count movwf ICOUNT+bit ;6 save updated or zeroed count ENDM ; Invoke the macro once for each bit DOBIT 0 ;11-16 DOBIT 1 ;17-22 DOBIT 2 ;23-28 DOBIT 3 ;29-34 DOBIT 4 ;35-40 DOBIT 5 ;41-46 DOBIT 6 ;47-52 DOBIT 7 ;53-58 ; We are ready to exit the interrupt handler movf SAVE_STATUS,W ;59 restore original value of status movwf STATUS ;60 swapf SAVE_W,F ;61 restore W without changing status swapf SAVE_W,W ;62 retfie ;63-64 back to our regularly scheduled program START code ;<initialize> ;<enable timer interrupt> ; loop processing values in COUNT array, which are most ; recent times for each input pin END

Hi Bob, Bob Ammerman wrote: > > Here is the skeleton of a (untested) program to read 8 RC servo inputs at > once. > I did not ask for so much! I was just starting to think about how to give up on IOC, you fired faster! Thanks. It seems a very good code, I didn't find anything wrong. 64 instructions is worst case (all bits are rising), 48 is best case, so main program will have "plenty" of time. Result gives ~1/62 accuracy for a 1 ms delta. I think that's enough for the prototype / demo, where I will limit to 8 channels. What is also interesting is that it is short enough so that I can add the output pulses generation in the same frame so that it will not introduce any jitter caused by another interrupt; and time bases will be the same... Very good code, thanks again. I still think IOC can be useable if we can accept to miss a pulse, with a good filtering method (I'm thinking to better accuracy). But I let it aside for now. Also thanks to everybody to have spent time on my problem. That was an really interesting / valuable discussion. ----- Best regards, Philippe. http://www.pmpcomp.fr Pic Micro Pascal for all! -- View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23721972.html Sent from the PIC - [PIC] mailing list archive at Nabble.com.

> Bob Ammerman wrote: >> >> Here is the skeleton of a (untested) program to read 8 RC servo inputs at >> once. >> > I did not ask for so much! > I was just starting to think about how to give up on IOC, you fired > faster! > Thanks. It seems a very good code, I didn't find anything wrong. > 64 instructions is worst case (all bits are rising), 48 is best case, so > main > program will have "plenty" of time. Actually, if you count the BTFSx instructions correctly you will see that the interrupt handler is always exactly the same length. For example, given... btfss somereg,somebit movlw 1 Then, if the btfss skips then it takes two cycles, if it doesn't skip it takes 1 cycle and the movlw takes 1 cycle. In either case 2 cycles are used. -- Bob Ammerman RAm Systems