If you are interested in a full-duplex, multi-drop RS-485 circuit with collision detection, I have in a 17C756 reference design (does not rely on using the 17C756). Douglas Wood Software Engineer dbwood@kc.rr.com ----- Original Message ----- From: "Lyle Hazelwood" To: Sent: Saturday, August 17, 2002 6:57 AM Subject: Re: [PIC]: CAN or RS-485 ? > > I am planning a system with a network of PICs. The PICs will be daisy > > chained together (power and communications) in a standard office > environment > > (fluorescent lights, networked PCs, telephones, HVAC, etc.) The PICs will > > need to communicate about two bytes (status change of nine LEDs and which > > PIC sent the event) every 5-10 minutes. Two of the events are pretty > > important and would need to be acknowledged by the other PICs. Initially, > > the network will be 300' end to end with 18 PICs. The network could > expand > > to 2000' end to end and about 100-200 PICs. > > The CAN protocol is complex, but most of that is done for you in hardware. > You get "free" collision detection, error checking, re-send requests, and > even > a system that will knock a bad node offline if it makes too many mistakes. > Nodes are assigned a priority, so that higher priority ones will seldom wait > for lower priority ones. Speed can be chosen based on max length of net. > > If these features sound useful (or required), CAN might be a good choice. > One problem is the expansion to 100-200 PICs. There's plenty of > "address space" with CAN, but the specs for most can transcievers top > out at about 100 nodes per net, so a repeater will be needed to get up > around or above those levels. > > The choice of a "Higher Level Protocol" will determine if your CAN net > is "Multi-Master" where every node can transmit at will, or if a polled > system with slaves is used. Many (like myself) just ignore the existing > HLP's and work out what we need on the fly. > > CAN messages are 8 bytes or less per message, this sounds OK for > what you described. > > So far the 18Fxx8 CAN PIC's are a bit rare, though a few samples have > made it to the light of day. You can still add CAN to any pic with an SPI > port by using the MCP2510. Which ever way you go, you'll still need a > CAN transciever. Most of these transcievers are 8SOP, but I did notice > that Microchip is promising one of their own "real soon now", available > in either SOP or DIP forms. > > If you'd like to experiment, there is a pretty cool CAN developers kit > done with PICs at www.diversifiedengineering.net/devel_f.htm . > I built this one based on their documents, and it's been working great > 24/7 for a few months now. This is a good way to get started with > proven HW and SW, then edit up from there. > > [Shameless Plug] I made mine a bit prettier, let me know if you want > to see a photo. 8^) > > A wireless RF PIC CAN node is available from > http://www.autoartisans.com/documents/canrf_prod_announcement.pdf > I have not had the opportunity (yet) to play with this one, but it looks > like a lot of fun! John is a member of this list. > > Good Luck, > Lyle > > > > -- > http://www.piclist.com hint: The PICList is archived three different > ways. See http://www.piclist.com/#archives for details. > > -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.