From: Grant on 10 Aug 2010 19:43 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 11 Aug 2010 06:00 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 11 Aug 2010 20:47 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 12 Aug 2010 03:38 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 12 Aug 2010 06:12 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.
|
Pages: 1 Prev: measuring fuel efficiency Next: ? on opamp I-to-V converter schematic |