'UART Q: -Reply'
ang (Chee Foon Tiang)
>>Also, can anyone suggest a simple protocol data transfer.
>I would also be interested in a simple "inter-pic" data transfer
>protocol. My needs suggest something capable of 75 to 150 bytes
>of data in a packet, which eliminates the CAN solutions.
A bit-banged I2C protocol would suffice.
100kHz and up to 256 bytes with the block read/write transfer.
On top of that it won't only be "inter-pic" but
"Inter IC" (IIC, get it?) as well, if you ever plan to hook
up other devices onto the bus.
|> From: "Peter Tiang (Chee Foon Tiang)" <HITACHI.COM.MY> TIANGCFOON
> >>Also, can anyone suggest a simple protocol data transfer.
> A bit-banged I2C protocol would suffice.
> 100kHz and up to 256 bytes with the block read/write transfer.
> On top of that it won't only be "inter-pic" but
> "Inter IC" (IIC, get it?) as well, if you ever plan to hook
> up other devices onto the bus.
IIC is a good solution. Be aware that the timing requirements for
the slave device are pretty severe if implementing in software. This
is because the slave has to respond to the master as the master blasts
out each byte. The master controls the clock at all times so it can
run as slowly as it likes. If you are programming the master and the
slave you can use slower rates than the normal 100 or 400kbps.
When implementing IIC in software on the PIC, be really careful that
the output port lines are always loaded with zeros, since you have to
implement an O/C driver by toggling the corresponding TRIS register.
Problems arise if a read-modify-write cycle is applied to the port
(not relating to the two IIC lines). Typically, this will reset the
IIC bits to ones which is not desirable. I got caught out with this
More... (looser matching)
- Last day of these posts
- In 1996
, 1997 only
- New search...