View previous topic :: View next topic |
Author |
Message |
Gordon
Joined: 14 Jun 2006 Posts: 3
|
A CAN scenario... |
Posted: Wed Jun 14, 2006 2:43 am |
|
|
I'm just getting in to this embedded lark and have a question about CAN operation:
If 2 PICs on a network have an identical filter initialised and transmit a message to that filter at the same time (on power up for example), should each PIC receive the message, or could it assume it sent the message in the first place and not receive it as the message and filter are identical?
I hope the question makes sense! Could a work around be to insert random timer values in the out going data so the message appears different, or am i barking up the wrong tree completely??
Thanks |
|
|
sjbaxter
Joined: 26 Jan 2006 Posts: 141 Location: Cheshire, UK
|
|
Posted: Wed Jun 14, 2006 4:49 am |
|
|
Gordon,
Filters are used during message reception not transmission.
It's not usually good practice for 2 nodes on the same network to send messages with the same ID (unless you have some mechanism that only allows 1 node to use the ID at a time). i.e. during polling of the nodes from a master node. In this case the message would have an address in the data so that only the node at that address would transmit the message with the shared ID.
As you mention powerup in you question, I am assuming that 'any' node can transmit this message (such as in a 'here I am' scenario). In that case you won't know who sent the message anyway (unless the senders address is in the data packet), but bus arbitration WILL cause many bus errors and cause you big problems.
It is usual for multiple nodes that send the same ID to use extended IDs (29bit) and part of the ID is the node address (i.e. 0x00 to 0xFF) with the other bits being the shared ID. So in reallity the ID's of all messages are different.
The filter on the recieving node needs to mask out the senders address bits (to accept any sender) and thus matching on the true message ID.
This way any bus collisions and bus arbitration is carried out at the hardware level (of which you have no control), yet all the messages from the nodes will be sent recieved without causing any bus errors and loss of data.
Code: |
i.e. messages
first 8 bits are the sender (source) address
last 21 bits are the shared message ID
bits 0 7 8 29
node 1 : 1000 0000 0000 0001 0000 0000 0000 0
node 2 : 0100 0000 0000 0001 0000 0000 0000 0
node 255 : 1111 1111 0000 0001 0000 0000 0000 0
|
mask to ignore the first 8 bits. You can use the first 8 bits in your node, once that hardware has filtered out the message from the bus.
some protocols (i.e. J1939) also include the target address in the 29bit ID so that the receiving node filters out messages only intended for that node. This uses 0xFF as a reserved node number meaning ALL nodes are the target (i.e. a network broadcast).
Hope that makes sense !!!!!!!! and hasn't deviated too far off the topic. _________________ Regards,
Simon. |
|
|
Guest
|
|
Posted: Wed Jun 14, 2006 6:16 am |
|
|
Thanks for the reply. Each of my nodes (i have 12) generates a random address and sets its filter ID to that address. It then listens for anyone else on that address to determine if the ID is unique. If it hears something on that filter, it chooses a new address and restarts the process. I was having issues from boot up when two PICs chose the same ID, they would never receive a message on the filter it had set, even though another PIC was transmitting on it.
Can a node receive its own message if it transmits on a filter than is open to receive? (I would assume it can as it doesn't know who sent the message, although i was told it couldn't).
Hmmm, I'm even confusign myself now!!!!! |
|
|
sjbaxter
Joined: 26 Jan 2006 Posts: 141 Location: Cheshire, UK
|
|
Posted: Wed Jun 14, 2006 10:05 am |
|
|
I don't believe a node will receive a message sent by itself (unless the controller has a loopback feature .. like the PIC CAN module has).
The protocol J1939 has a feature called 'Address Claiming' which does exactly what you are after. I know you probably don't want to implement the protocol, but if you do a search on google you may find and explination on how this negotiates the addresses. (ref. J1939-81)
Microchip App Note _________________ Regards,
Simon. |
|
|
Gordon
Joined: 14 Jun 2006 Posts: 3
|
|
Posted: Thu Jun 15, 2006 1:50 am |
|
|
Thanks again, I'll look in to that protocol for future applications. |
|
|
|