On Wed, 24 Oct 2001, Andy Meng wrote:

> I am working on a project right now to interface a PIC (16F872) to a
> Microsoft digital joystick. The joystick uses a high-speed (about 100KHz)
> synchronous serial output, with three data lines (each data line carries a
> seperate bit, 16 clocks = 48 bits total). So, on each joystick clock cycle,
> all three data lines must be read. Since I only have 5us to read three
> lines, I have had to speed up my clock from 4MHz to 24MHz (a little
> "overclocked"...), so that I can go from about 5 instruction cycles per
> clock to about 25 instruction cycles per joystick clock. I can read when the
> clock goes low with the code:
>
> btfsc    PORTB, CLK     ; test clock
> goto    $ - 1                    ; try again
>
> but this code does not work (to detect when it goes high again):
>
> btfsc    PORTB, CLK     ; test clock
> goto    $ - 1                     ; try again
> btfss    PORTB, CLK
> goto    $ - 1
>
> Immediately after both of these code segments a pin on PORTB is pulsed high
> so I can see if the code is working by looking at it on an oscilloscope. Is
> it a problem with the lines changing so quickly? I don't see why that would
> affect it, but does it? Has anyone ever done a bit-banged synchronous I/O at
> these types of speeds? Is this the normal way to check for a high to low to
> high transition?

At the cost of hugh chunk of code, you can save a clock on sampling:

;   Clock is currently low
;   Sample data on rising edge

    btfsc   PORTB,CLK     ; test clock
     goto   ClockIsHigh
    btfsc   PORTB,CLK     ; test clock
     goto   ClockIsHigh
    btfsc   PORTB,CLK     ; test clock
     goto   ClockIsHigh
    btfsc   PORTB,CLK     ; test clock
     goto   ClockIsHigh
....

error:
    ; clock didn't go high in expected time

ClockIsHigh:
..


Also, keep in mind that the "Pulsing a line on PORTB" may not ever
actually occur. For example:

This code:

     bsf    PORTB, testpin   ; Pulse line high to signal complete
     bsf    PORTB, some_other_pin
     bcf    PORTB, testpin

Has the potential of failing. Why? It's the ol'd read-modify-write "bug"
of the PIC I/O ports. The bsf will drive the line high. However, the bsf
immediately following it can inadvertantly clear it. The reason is that
the second will read the WHOLE I/O port, set the bit "some_other_pin" and
then write the whole I/O port back out. Because of capacitance on the I/O
line "testpin", the output may not of had enough time to fully switch
before the second write occurs.

You can get around this by either adding delay, strategically rearranging
I/O reads and writes, or by shadowing the I/O port.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads