From: Grant on
Hi there,

Used up all the good resources of a PIC16F886 to make a high
resolution ADC (well, soon to be built, but gone through all
the required PIC resource allocation), now I need to talk to
another 16F886 (28pin) or 16F887 (40pin) PIC for RTC (32kHz
watch xtal) and system control.

The ADC chip already taken the EUSART for serial comms to PC
option. That leaves the other comms module:

"
Master Synchronous Serial Port (MSSP) Module
supporting 3-wire SPI (all 4 modes) and I2C
Master and Slave Modes with I2C Address Mask
" -- 16F886 datasheet

for talking to other chips and PICs.

I'm after suggestions for which master / slave inter-chip
protocol is easy, reliable for local (within a couple feet)
comms. Gotchas, pointers?

I'm programming in assembler with the MPLAB environment at this
time.

Thanks in anticipation,
Grant.
From: Jan Panteltje on
On a sunny day (Wed, 11 Aug 2010 09:43:09 +1000) it happened Grant
<omg(a)grrr.id.au> wrote in <sgn366hgpafktdcat78qi19vgdep0foe78(a)4ax.com>:

>Hi there,
>
>Used up all the good resources of a PIC16F886 to make a high
>resolution ADC (well, soon to be built, but gone through all
>the required PIC resource allocation), now I need to talk to
>another 16F886 (28pin) or 16F887 (40pin) PIC for RTC (32kHz
>watch xtal) and system control.
>
>The ADC chip already taken the EUSART for serial comms to PC
>option. That leaves the other comms module:
>
>"
> Master Synchronous Serial Port (MSSP) Module
> supporting 3-wire SPI (all 4 modes) and I2C
> Master and Slave Modes with I2C Address Mask
>" -- 16F886 datasheet
>
>for talking to other chips and PICs.
>
>I'm after suggestions for which master / slave inter-chip
>protocol is easy, reliable for local (within a couple feet)
>comms. Gotchas, pointers?
>
>I'm programming in assembler with the MPLAB environment at this
>time.
>
>Thanks in anticipation,
>Grant.

If you dream up some protocol, you can put everything on the same RS232
(OR the outputs).
This is sort of what I do in my PIC LED color controller.

For example PIC1 listens to commands starting with ctrlA,
PIC 2 to commands starting with ctrB, etc.
And each can reply with a sequence like ctrlX<ID><data>
There are a zillion ways.
115200 Bd is fast enough.
The alternative is to have a software RS232 output, as I am doing in a PIC project I am doing now.
You can still use interrupt on input too.
I have even done I2C in a PIC in software using an interrupt pin,
emulating a PCF8574 I/O expander (and cheaper then one :-) ).
From: Jamie on
Jan Panteltje wrote:

> On a sunny day (Wed, 11 Aug 2010 09:43:09 +1000) it happened Grant
> <omg(a)grrr.id.au> wrote in <sgn366hgpafktdcat78qi19vgdep0foe78(a)4ax.com>:
>
>
>>Hi there,
>>
>>Used up all the good resources of a PIC16F886 to make a high
>>resolution ADC (well, soon to be built, but gone through all
>>the required PIC resource allocation), now I need to talk to
>>another 16F886 (28pin) or 16F887 (40pin) PIC for RTC (32kHz
>>watch xtal) and system control.
>>
>>The ADC chip already taken the EUSART for serial comms to PC
>>option. That leaves the other comms module:
>>
>>"
>>Master Synchronous Serial Port (MSSP) Module
>>supporting 3-wire SPI (all 4 modes) and I2C
>>Master and Slave Modes with I2C Address Mask
>>" -- 16F886 datasheet
>>
>>for talking to other chips and PICs.
>>
>>I'm after suggestions for which master / slave inter-chip
>>protocol is easy, reliable for local (within a couple feet)
>>comms. Gotchas, pointers?
>>
>>I'm programming in assembler with the MPLAB environment at this
>>time.
>>
>>Thanks in anticipation,
>>Grant.
>
>
> If you dream up some protocol, you can put everything on the same RS232
> (OR the outputs).
> This is sort of what I do in my PIC LED color controller.
>
> For example PIC1 listens to commands starting with ctrlA,
> PIC 2 to commands starting with ctrB, etc.
> And each can reply with a sequence like ctrlX<ID><data>
> There are a zillion ways.
> 115200 Bd is fast enough.
> The alternative is to have a software RS232 output, as I am doing in a PIC project I am doing now.
> You can still use interrupt on input too.
> I have even done I2C in a PIC in software using an interrupt pin,
> emulating a PCF8574 I/O expander (and cheaper then one :-) ).
MODBUS/RTU on a balanced twisted pair( 485 ) works well, the MODBUS
supports 31 devices.. A well known protocol, why reinvent the wheel?


From: Tauno Voipio on
Jamie wrote:
>> emulating a PCF8574 I/O expander (and cheaper then one :-) ).
> MODBUS/RTU on a balanced twisted pair( 485 ) works well, the MODBUS
> supports 31 devices.. A well known protocol, why reinvent the wheel?

Implementing MODBUS/RTU packet timing to the specification
is a PITA. It demands tight character-to-character timing
and measurement of interpacket timings. This prevents using
the built-in FIFO's in the serial chips, and the timing is
practically impossible to implement on a PC due to the
unpredictable interrupt latencies introduced by operating
system.

Been there - bit badly by that.

--

Tauno Voipio
tauno voipio (at) iki fi

From: Grant on
On Thu, 12 Aug 2010 10:38:24 +0300, Tauno Voipio <tauno.voipio(a)notused.fi.invalid> wrote:

>Jamie wrote:
>>> emulating a PCF8574 I/O expander (and cheaper then one :-) ).
>> MODBUS/RTU on a balanced twisted pair( 485 ) works well, the MODBUS
>> supports 31 devices.. A well known protocol, why reinvent the wheel?
>
>Implementing MODBUS/RTU packet timing to the specification
>is a PITA. It demands tight character-to-character timing
>and measurement of interpacket timings. This prevents using
>the built-in FIFO's in the serial chips, and the timing is
>practically impossible to implement on a PC due to the
>unpredictable interrupt latencies introduced by operating
>system.
>
>Been there - bit badly by that.

Not where I'm heading, more likely a tiny serial <-> usb gateway
to PC for control and data logging, and separately SPI or IIC to
other chips, I don't need rs485 to talk a foot or two between
chips for this project set.

Grant.