hi,
please help me in this topic,
how to create a small microcontroller network(CAN),and how to create a communication protocol for the individual
controller chips,and how to connect them as a network??? pleae explain practical server client system on these network.
plse help me with a circuit model of this network.

 

http://en.wikipedia.org/wiki/Controller_area_network

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011694

http://www.computer-solutions.co.uk/info/Embedded_tutorials/can_tutorial.htm

http://electrosofts.com/can/

 

but these links are explaining CAN protocol,i am asking basics for creating a protocol for small R&D projects,like a low end protocol.

 

Must you use CAN? It's the fashion at the moment, but there are lots of simpler ways to connect processors.

 

but these links are explaining CAN protocol,i am asking basics for creating a protocol for small R&D projects,like a low end protocol.

BUT CAN is what you asked for!!!

please help me in this topic,
how to create a small microcontroller network(CAN),

Words within parentheses give more additional information; therefore, you are asking for information on how to create a small uC CAN network. Had you written " a small microcontroller network like CAN" you may have gotten better information. Have you tried Googling? Or, maybe you can study CAN to get some ideas.

Also, you will need to answer these questions for yourself:
-- how many microcontrollers are to be on the network? If it is just two uCs, it will be a lot easier than with 3 or more. Will it be more than 255 uCs? Then you'll need address data larger than a byte.
-- What size information will you be passing? 3 bytes? 300 bytes?
-- How many different commands will be passed?
-- Will you want to talk to more than 1 uC at a time?
-- Will this be Master/Slave or Peer-to-Peer? And if P2P, what do you do if there is a data collision -- two devices trying to speak at the same time?
-- How will you detect that a device wants to communicate?
-- How do you insure data integrity?
--And don't forget timing -- if a device does not respond within a certain period of time, what do you do?
-- What happens at power-up? What happens if one device loses power, then it gets restored?

Et cetera, et cetera, et cetera.

--Rich

 

There is a system here on this page that lets you connect LOTs of PICs (or other micros) together very easily. It's an informal standard that takes care of the devices clashing with each other, so they don't clash, and you can send or receive any format of data you like;

See this page; http://www.romanblack.com/blacknet/blacknet.htm

 

ya my fault

 

thank u very mch sir

 

I said there are simpler ways to connect processors than CAN, and BlackNet is about as simple as you can get! However, it could be simplified still further in the case of a processor which uses bit-banging rather than a hardware UART. In that case, it would be possible to use only one processor pin, changing it from input to output as needed. In fact the transmission function could be used to send the output data. In PIC usage, you'd write a 0 to the port pin and then manipulate the relevant bit of the TRIS register to send 1's and 0's.

 

Another way (and I've done this before) is to use the I2C hardware inside many PICs.

This needs one to play master and the rest as slaves, and everything should be in the same box as I2C is not for long distances, but the only hardware necessary is two resistors.

 

i2c??
ok.....
please suggest an identity format for each processor??

 

I would think that a bidirectional uart line, combined with an arbitration line could work fine. Many micros have built in address recognition allowing direct or broadcast messaging. The arbitration line controls data direction.

if you look at the many formats that are out there, you'll get a feel for what is important in your system. you'll need to map out some strategies and basic needs of your percieved system.

 

I've used I2C plenty of times when it was required, but it is an unpleasant protocol.

It wastes a lot of time addressing and has the requirement that all devices are required to receive everything on the bus and constantly decode addressing etc.

Sometimes you just need a simple system to connect a lot of PIC sensors etc and each sensor just needs to send 1 data byte every now and then. I2C is about the worst system for doing something simple like that!

 

sir could u provide with a block or something?? plse...

 

can i use a single RTC to trigger every controllers in the n/w??
is that reliable???some protocol based on that??
please do replay...

 

The I2C bus was designed by Philips in the early '80s to allow easy communication between components which reside on the same circuit board.

CAN (also referred to as CANbus or CAN bus) is a network used in many every-day products consisting of multiple microcontrollers that need to communicate with each other. CAN is implemented in hardware in microcontrollers of more than 22 chip manufacturers.

I would take a look at the can bus http://www.gaw.ru/data/Interface/CAN_BUS.PDF

some more reading http://en.wikipedia.org/wiki/Controller_area_network

 

Just to be sure, one of them would be Master and the rest slaves?

Do all the nodes have to talk to anyone in the network? Or the master speaks and the others only listen and do what they are required?

Do they speak to Master? If so, when the Master question them or at any time they need to?

How fast the traffic should be? Is there any kind of "timing" (master clock) involved?

You should put in writing all this and it would be easier to suggest some topologies and much easier for you to have a clear idea in your mind, first of all.

First thing that came to mind was I2R.

 

krishnanvsalim, you still there buddy? Have we totally confused you yet?

There are lots of replies here as there are lots of ways to do this. There is not one best way.

It would help us make better suggestions if you tell us a bit more about how you intend to use the network.

How much data will it carry?
How fast?
How many computers connected?
How far apart are they?

 

I've been thinking some more about BlackNet. The one thing I don't like about it is the use of a single-ended bus driven by (essentially) open collector outputs. Suppose there were two differential lines, as in RS-485? That would suggest use of a transceiver chip like an SN75176, but if the object is to do the thing with minimal hardware, maybe 2 pins of a PIC processor could be used.

I'm not sure what the firmware would need to do. Look for a change in one line, and if found, check that the other one is complementary? Or perhaps use a built-in analog comparator for input, if the processor has one. I'm trying to keep the idea of what differential transmission really does, which is reduce pickup of noise.

As Conrad said, this wouldn't be a system for fast distribution of lots of data. But for occasional readings, it might be an elegantly simple way to do it.

One other thing, it seems as if "Unit Zero" needs to make a transmission for every cycle, to start the other processors communicating. But if that unit had a computer interface, it could be the one sending data out to the network, and passing it back to the computer. And as with RS-485, there would need to be pullup/pulldown resistors to keep the bus at an inactive state when no processor is driving it.

 

To Atferrari- good point. I think krishnanvsalim needs to start with a concept and basic drawing board stuff like flowchart the order of operations then decide on a master (if one is used) then decide what info needs to be sent and that will lead to the overall solution. Of if he is using a specific RTC device then that will dictate much of the way the comms is done.

To JohnP- Sure differential lines can be of benefit, but mostly for very high data comms rates. For lower speed stuff a data wire and return wire works fine. Most cheap cabling these days is twisted pair anyway and baudrates of 56 kbaud and under are extremely reliable with a standard serial (ie PIC USART) and a twisted pair cable like any CAT5 cable or even cheap telecomms 'phone cable.

The Blacknet thing is about simple and cheap, for apps that benefit from simple and cheap. So even non-USART PICs can be used, or devices that only listen to the data line when they want to. Or only transmit if/when they want to. Most of the multidrop modern protocols use a system where all devices MUST constantly listen and respond, which fills up the bus AND requires devices capable of doing their job at the same time as listening and talking.