Olin and Vitaliy, Thanks for clarifying. = /Ruben > Ruben, > = > The greatest strength and arguably the greatest weakness of CAN is the fa= ct that > it is so flexible. Beyond ISO11898, there's no such thing as "CAN spec", = there > are many different implementations. > = > I am most familiar with the way CAN is used for On-Board Diagnostics = > (OBD-II) on cars and light trucks. Two flavors are in use: 11 bit and 29 = > bit, referring to the length of the CAN header. 29-bit is the most = > straightforward, the source and destination address get one byte each. > = > The automotive flavor of CAN seems very appropriate to what you described = > (perhaps, in a more simplified form). The benefit of using CAN over RS485= is > that it is more immune to noise and has built-in mechanisms for error rec= overy > (ex: messages get retransmitted automatically by the CAN peripheral). > = > Vitaliy > = > = > = > = > ----- Original Message ----- = > From: "Ruben J=F6nsson" > To: "Microcontroller discussion list - Public." > Sent: Saturday, October 03, 2009 01:10 > Subject: Re: [PIC] USB-CAN adapter. Is there a DIYable design out there? > = > = > > > > I've got enough working that I can enter commands in a test app on the = PC, > > which sends commands over the USB, which causes the host CAN controller= to > > send a frame, which is received by another board, which causes it to wi= ggle > > some I/O lines. > = > How is this generally working with USB and CAN compared to serial RS232/4= 85 > regarding commands and confirmation of the command? > = > When I do this with a master/slave protocol with RS232 or RS485, I genera= lly > have a command and a reply to that command. If I get the reply as expecte= d I can > count on that the receiver has received the command and executed it (upda= ted the > I/O lines in this case). If I don't get a reply I will generally try a co= uple of > times and then give up, assuming the receiver is not there or is broken. > = > My understanding of CAN is that the communication is oriented around the > content of the message (or message type) rather than around a particular = > master > and a slave node. Whichever node that is interested in that type of messa= ge acts > upon it. > = > So, if I want to build a network with CAN rather than RS485 and use it wi= th my > master/slave type of protocol, can I do that in similar way (at least as = seen > from the master side)? Or do I have to make another layer inbetween my > master/slave protocol and the CAN communication that reserves a couple of > message types for a command and a reply and then have the address node to= gether > with the actual data inside the CAN data frame for that message? Send the > message for the command and wait for the reply message type and check tha= t. > = > And if I have a sensor I want to read the information from, do I tell it = to send > the data or is it generally sending the data continously and I just pick = up the > message from that when I need it? > = > And what about USB? > = > /Ruben > = > = > = > = > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > Ruben J=F6nsson > AB Liros Electronic > Box 9124, 200 39 Malm=F6, Sweden > TEL INT +46 40142078 > FAX INT +46 40947388 > ruben@pp.sbbs.se > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > = > -- = > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist = > = > -- = > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Ruben J=F6nsson AB Liros Electronic Box 9124, 200 39 Malm=F6, Sweden TEL INT +46 40142078 FAX INT +46 40947388 ruben@pp.sbbs.se =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D -- = http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist