bsf PORTA,1 ; set the data valid flag
ToBB2: ;wait for BigBro
btfss PORTA,2 ;when BigBro has read the data A2 is set
goto ToBB2 ;wait for BigBro to read data
bcf PORTA,1 ;clear data valid flag, BigBro should now clear A2
incf Count1,f ;update counter
incf FSR,f ;and the pointer
btfsc PORTA,2 ;wait for BigBro to clear Read flag on A2
>From the above I can see that there is ***NO*** guarentee as to what is on A2
when you set A1. I would be tempted to put a wait ***BEFORE*** setting A1 (wait
for A2 to be low for a ***FEW*** consecutive cycles). Then I would wait for A2
to be high for a ***FEW*** consecutive cycles (you cannot guarentee that
setting A1 is not glitching A2).
If "BigBro" is just pulsing A2, try getting "BigBro" to stretch the pulse.
On Mon, 22 Jun 2020, BT 4000 wrote:
> Ok I regret to say I admit defeat, the 16F627 is not supported by the
> debugger in MPLAB X or 8.91 and PICkit3 is not supported in MPLAB 8.10, so
> why am I using it? After a long break from electronics due to eyesight
> problems the abundance of modules attracted me back and I rummaged in my
> ditty box and found these chips which were ideal for the task.
> It’s a simple program so it was back to the bug chasing techniques I learnt
> on the Nascom 1 but now I have heavy assistance in the form of a Saleae logic
> analyser. So it runs for 5 loops, identifying one GPS message each loop, at
> the end of each loop, data valid is high then Data Read read goes high, 8usec
> later Data Valid goes low, 9usec later Data Read goes low then finally Data
> Ready goes low. But after loop 5 there are no further flag changes.
> If I rem out the two references which test PORTA-2 eg
> btfss PORTA,2 ;when BigBro has read the data A2 is set
> goto ToBB2 ;wait for BigBro to read and
> btfsc PORTA,2 ;wait for BigBro to clear Read flag on A2
> goto ToBB3
> The program runs forever with the correct decoding and flags, if I uncomment
> just the first pair the program locks up as above. I’ve sprayed NOPs
> liberally all around the loop with no effect apart from timing.
> So I can’t see what else to do so I guess it’s move onto a supported chip and
> assume I found out why Microchip dropped this beast.
> Thanks to all who provided help, I certainly needed reminders on a few
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at