serial output on non tx/rx hardware pin

[picer]

I want to do comms between pics, easiest seems to be serial between, master talks to many slaves and slaves talk back to master. Can I use non usuart tx/rx pins to do serial between pics (then use simple printf statements). 877 will be master and probably 628 slaves, clearly the 877 doesn't have 4-5 hardware serial pins. Just need to pass data between them, maybe something else that just uses normal pins?? Thanks.

[rwyoung]

Google for RS-485, also search the forum archives.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month!

[libor]

... or you could also consider using the I2C or SPI bus (these have the advantage of a separate clock line, so unlike the USART solution there's no timing problems even at higher speeds, you can send and even receive at any rate without losing data, even when the PIC has other things to do.). CCS has internal I2C functions built into the compiler, you can easily use I2C on normal pins using only software also.
For longer distaces you can also use the industry standard CAN bus with most of the protocol problems (like collision avoidance, packet acknowledgement, error detection, etc.) already solved in the PICs hardware and in the standard. (even in a difficult multi-master multi-slave arrangement)
These busses are specially made to do what you want. (i.e. having multiple units on a single bus) Most of the PIC models have these I2C, SPI ports implemented in hardware, certain PICs have the CAN ports also.
It is also an advantage that you learn to use those solutions that are up-to-date standard in industrial control.

[picer]

Trying to keep the component count as low as possible and cost low too, see the 16F870 can do I2C and should be able to do everything the 628 can and costs about the same so can substitute that one. 877 has I2C as well so I would be set then. The slave pics have to do pwm and have a/d inputs so that should all fit the bill nicely. Thanks.

[picer]

Woops, 87 has I2c and no a/d, 870 has a/d but no I2c. Will have to look again.

[SherpaDoug]

I think what you were originally proposing is viable. One master can talk to many slaves with one TX pin if each slave has an address and only listens to messages with it's address. Or with software UARTs you can have a TX pin for each slave, if you have enough ROM space.
On the receive side you could tie all the slave TX pins to the master RX pin as long as the slaves keep their TX tristated (high impedance) when they are not talking. If two slaves talk at once you will get garbage. Or each slave could have its own software UART RX pin on the master, if the master has enough ROM space.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Mark]

[picer]

819 looks even better than what I was looking at and cheaper too.

[picer]

Thread may go in a few directions here but..if I use I2C then I could have all the pic's on the buss talk to a I2C eeprom correct? That could be very usefull to me.

[Mark]

Yes, it will just be another slave on the "network".

[libor]

There are lots of I2C devices become available to you if you get familar with this bus, you can connect many devices on the same bus (only the line capacitance is the limit = 20-30 ICs or ca. 10 m of trace), with repeaters and hubs you can also go beyond this limit.
Just a few types of ICs and sensors that are all made with I2C interface: lcd controllers, real-time clocks, eeproms, A/D converters, I/O ports, video encoder ICs, RF chips, various sensors (temperature, pressure, etc.)
I am playing nowadays with a magnetic compass IC module, this also has a I2C interface.
Philips is one of the main promoters of this bus. look here

[picer]

Does anyone have any schematic examples of I2C using the built in I2C in hardware, assume it's pretty much the same way as using an external I2C chip but those are the only examples I can find. Are there special considerations with using the pic for this, as in steps to protect the actual i/o pin, etc? Also assume the code will be somewhat different?

[libor]

No special tricks as long as you connect devices using the same supply voltage and no galvanic isolation needed. You connect the clock and data lines of all the devices to the same bus. (clock to clock, data to data, no crossing!, the data line is bidirectional itself, the clock is supplied from the master device only, though clock pulses can be stretched by a slave when he wants to read the data line slower than it is transmitted) The devices can only pull-down the line, so when two or more devices do it at the same time, this means a hardwired logical OR.
Dont forget the two pull-up resistors to make the bus high when idle (one on each bus line).

[treitmey]

I one trick I rememeber is to only address the pic with even addresses.
It is part of the protocol.
see
http://www.ccsinfo.com/forum/viewtopic.php?t=21129&highlight=i2c+address

[Mark]