On Sun, 23 Feb 2003, Olin Lathrop wrote:

> I'm attacking it a little differently.  I've got two 10KHz and two 1KHz
> manchester streams to decode simultaneously.  I just can't sample at 100KHz
> and still have any cycles left for the decoding and other logic.  Instead I
> use two of the INT interrupts of the 18F set to high priority to measure the
> time between edges.  Things are scaled so that the maximum valid time
> between edges fits into 7 bits.  The rising/falling edge indicator gets
> stuffed into the 8th bit, and the byte gets pushed onto a FIFO for that
> stream.  The 1KHz edges get measured similarly by using low priority
> interrupts.  This keeps the measurement jitter for the high speed streams
> down.  Foreground code then decodes the 4 FIFO streams as it gets around to
> it.  This is done in one piece of code that has 4 pseudo-threads running in
> it.
>
> Worst case I have a little over 200 cycles average per edge, of which 45 are
> used in the interrupt to capture and measure the edge.  The remaining 155
> cycles per edge average sounds like enough to do the decoding.  I've worked
> out most of that but am only about 1/3 done writing it.  I should know in a
> few days how well everything worked together.

Interesting.

My bit stream is a little different. Instead of Manchester encoding, my
stream is On/Off encoding. Manchester is better. As I said before, the
pulse stream is ~10kHz. The width of the pulse dictates 0's and 1's. At
10kHz, the pulses are coming in at a rate of 1 every 100 uS. 25uS wide
pulses are zeroes and  75uS wide ones are ones. For Manchester encoding
at the same data rate, the narrowest pulse is only 50uS.

I decided to use the CCP module instead of a polling interrupt. I first
program the CCP module to capture every rising edge. When I capture a
rising I subtract from that the time I captured for the last rising edge.
This gives the time between rising edges and should be about 100uS. After
a rising edge is captured, I reprogram the CCP module to capture every
falling edge. When I capture one I subtract from it the time of the last
captured rising edge. This gives the pulse width.

Once the pulse time and pulse width are known, then it's trivial to
calculate 0's and 1's and validate the data. So far, the code takes about
20 cycles per edge. (But more code is still needed..)

Here's the portion that processes rising edges:

        MOVFF   CCPR1L,TC_CaptureLo     ;Save the time when the last edge
        MOVFF   CCPR1H,TC_CaptureHi     ;was captured

        BTG     CCP1CON,CCP1M0          ;Toggle the polarity we'll capture
next.

        MOVF    TC_LastRisingEdgeLo,W   ;Compute the time since the last
        SUBWF   TC_CaptureLo,F          ;rising edge
        MOVF    TC_LastRisingEdgeHi,W   ;
        SUBWFB  TC_CaptureHi,F


   ;; Rising edge. Save the time for this rising edge.

        MOVF    TC_CaptureLo,W          ;Save the time captured for this
        ADDWF   TC_LastRisingEdgeLo,F   ;rising edge. if  X = new - old
then
        MOVF    TC_CaptureHi,W          ; old + X = old + (new- old) =
new.
        ADDWFC  TC_LastRisingEdgeHi,F   ;


   ;; At this point, TC_CaptureHi:Lo = the Bit time
   ;; and TC_LastRisingEdgeHi:Lo = the capture time for the edge that
cause
   ;; this interrupt. Now we need to validate the Bit Time and the pulse
   ;; width.

That's 13 cycles, but there's a little more processing that is not ready
to be shown (i.e. it ain't done yet).

4osc cycles / instruction / (10MHz * 4[pll]) ==> 0.1uS per instruction. 20
instructions per edge corresponds to about 2uS or roughly 10% of the
narrowest pulse expected. Or for 32 pulses, which is 64 edges the percent
of time spend processing is 2us/edge*64edges / (100us/pulse * 32 pulses) =
2% of the CPU's time.

I've pretty much decided to not worry about the CCP Capture race condition
because in my case it just so happens if the CCP module is capturing a new
edge while I'm processing the last edge then it's noise. If I make a
mistake processing noise, then oh well, who cares? If the noise is
mistaken as data, then the alledgedly bad data bits still have to make it
through an error correction checker.

Scott

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body