Jinx wrote:
>> http://www.ian.org/HD-Clock/
>>     
>
> Cool. I'll have a proper look later though
>
>   
>> Anyone have a good suggestion on how to communicate to
>> the 16F88?
>>     
>
> I think 8-bit parallel with a "data ready" line. That line could be
> bi-directional. For example, F88 starts with its end as i/p, and
> waits for the data ready signal. F252 starts with its end as o/p.
> Data ready is set high for valid data available, F252 switches to
> i/p and the F88 switches to o/p, sending the line low, which the
> F252 detects (perhaps use INT pins at each end). A pullup on
> the line should avoid false positive pick-up
>
>   
I missed the main message somehow. But I use interrupt-driven methods 
that are quite reliable.
There are two methods: (1) clock and data (two pins), and the data pin 
is reversible, or (2)
single-pin version (just one direction, but it could be adapted  for 
two-way).  The second version
is normally used as a debug  tool (memory dump).

The first method is quite fast, transferring data at a rate up to 30uS 
per bit. I use it to transfer 20bits
of data + 2 CRC bits, starting w/ 2 start bits, for a total of  24 bits. 
30uS works if both PICs have a
fast clock, slower if 4mHz clock on one PIC.

The second method is a memory dump, starting from register 00 to end of 
register memory. Each bit
requires 4mS, but uses a Manchester protocol, where a '1' is where over 
50% of the bit time is spent
HIGH, and a '0' is where over 50% of the time is spent LOW. Its 
advantage is that it is slow enough
for even a slow PC to extract and display the information. It requires  
a special program to extract, but
a small PIC could convert  the data to RS232 and drive a MAX232C with a 
tiny PCB (suggested on
this list but not done yet).  This works especially well for small PICs 
which don't work with the ICD2;
it acts as a great code debugging tool.

--Bob A
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist