Searching \ for '[PIC] Reliable IOC?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Reliable IOC?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Reliable IOC?'
2009\05\19@032739 by PPA

flavicon
face

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.

2009\05\20@182059 by Bob Axtell

face picon face
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.paternotteTakeThisOuTspampmpcomp.fr> wrote:
{Quote hidden}

>

2009\05\21@094936 by PPA

flavicon
face

Hi Bob,

Thanks but I don't understand what your answer is to???
What about IOC?


Bob Axtell-3 wrote:
>
> This should be fine, copy to another REG won't disturb the 1st reg
> unless the first reg is STATUS.
>


-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23653356.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\05\21@184125 by Rikard Bosnjakovic

picon face
On Thu, May 21, 2009 at 15:49, PPA <.....philippe.paternotteKILLspamspam@spam@pmpcomp.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.


--
- Rikard - http://bos.hack.org/cv/

2009\05\22@021205 by PPA

flavicon
face

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}

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

2009\05\24@072221 by PPA

flavicon
face

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.

2009\05\24@085706 by olin piclist

face picon face
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.

2009\05\24@133701 by PPA

flavicon
face

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.

2009\05\24@134159 by Gerhard Fiedler

picon face
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

2009\05\24@163737 by olin piclist

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


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\25@035722 by PPA

flavicon
face


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}

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

2009\05\25@044551 by PPA

flavicon
face

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\05\25@045143 by Ariel Rocholl

flavicon
face
2009/5/24 Gerhard Fiedler <.....listsKILLspamspam.....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

2009\05\25@045703 by Ariel Rocholl

flavicon
face
2009/5/24 PPA <EraseMEphilippe.paternottespam_OUTspamTakeThisOuTpmpcomp.fr>

>
>  And I though to use internal osc @ 8MHz since I need all RA pins...
>

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.

--
Ariel Rocholl
Madrid, Spain

2009\05\25@084725 by Scott Dattalo

face
flavicon
face
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}

>

2009\05\25@104207 by PPA

flavicon
face


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.

2009\05\25@105416 by Steve Smith

flavicon
face
Just remember that if you have 8 RC signals (usually one after the other)
then inside the 20mS frame you have a 4mS back porch to do the processing
after the acquiring the whole frame. So there is quite a bit of free time
available to post process.

Just a thought did you consider a capture input for each of the signals. I
have 3 working reliably with 1us resolution at 4mhz I am sure there is a
device with 8 capture inputs (might be an 18F I think)

Steve

{Original Message removed}

2009\05\25@110353 by PPA

flavicon
face


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.

2009\05\25@130208 by Isaac Marino Bavaresco

flavicon
face
part 1 2339 bytes content-type:text/plain; charset=UTF-8 (decoded quoted-printable)

PPA escreveu:
{Quote hidden}

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)

2009\05\25@130846 by PPA

flavicon
face

Hi Ariel,


arocholl wrote:
{Quote hidden}

You too? :-)
Is there any real application for these damned functions???


arocholl wrote:
{Quote hidden}

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.

2009\05\25@153847 by Ariel Rocholl

flavicon
face
*Bonjour Philippe, comment vas tu? *

2009/5/25 PPA @spam@philippe.paternotteKILLspamspampmpcomp.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

2009\05\25@155201 by Scott Dattalo

face
flavicon
face
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

2009\05\25@174940 by Isaac Marino Bavaresco

flavicon
face
Scott Dattalo escreveu:
{Quote hidden}

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/

2009\05\25@181625 by Gerhard Fiedler

picon face
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

2009\05\25@183949 by Jinx

face picon face
>> Is there any real application for these damned functions???
>>
> Think of keypads

Pretty sure IOC is a legacy function of the earliest PICs for interfacing
a 4 x 4 keypad on PortB. Drive from the lower nybble and detection
by the upper. I've considered using it a few times but found it would be
troublesome. Plan B usually is something like diode-OR inputs to an
interrupt pin and then poll

2009\05\26@022116 by PPA

flavicon
face

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.

2009\05\26@042748 by Bob Ammerman

picon face
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


2009\05\26@081935 by PPA

flavicon
face

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.

2009\05\26@093025 by Bob Ammerman

picon face
> 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


2009\05\26@135151 by PPA

flavicon
face



Bob Ammerman wrote:
>
> 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.
>
Yes, I forgot that in my enthusiasm...
Thus I have "less" time... But a constant int routine timing.


-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/Reliable-IOC--tp23611087p23728183.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

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