One of the first serial connections I looked at when I started was the CAN BUs. At the time I couldn't understand what the protocal standards meant. BUt I just went back to reading them again now and it's amazing how it works! How identical messages are transmitted until a higher priority identifier takes over. ANd if something is requested at the same time that something is sent, then the whole identifier stream is the same from both requester and requestee until the RTR bit which then lets the data transmission continue "ride over top" of the request transmission effectivelly cancelling the data request since the data is already on it's way.
And then there's the ACK bit that gets sent with the transmitter's bitstream, but is in reality a placeholder that allows the receivers to send back a true/false in the opposite direction, effectively allowing receivers to "manipulate" that bit in the middle of the transmitter bistream to indicate whether the message was received correctly. And if the transmitter sees this bit is not the right value, or if after the transmission is complete the receivers realize the CRC (which is inherent and automatically done!) doesn't check out and send an error frame message repeatedly, it causes the transmitter to repeat! But a limit's put on the error message a faulty receiver can't lock up the bus with error messages! Brilliant!
Then there's the bit stuffing that lets the entire asynchronous message keep itself in sync during long bitstreams. But, also, probably more importantly the violation of the bit stuffing rule IS the error message which destroys traffic on the bus and causes the the other nodes to also send their own error frame, which results in a repeat of the original transmission. Cool.
And then there's the ACK bit that gets sent with the transmitter's bitstream, but is in reality a placeholder that allows the receivers to send back a true/false in the opposite direction, effectively allowing receivers to "manipulate" that bit in the middle of the transmitter bistream to indicate whether the message was received correctly. And if the transmitter sees this bit is not the right value, or if after the transmission is complete the receivers realize the CRC (which is inherent and automatically done!) doesn't check out and send an error frame message repeatedly, it causes the transmitter to repeat! But a limit's put on the error message a faulty receiver can't lock up the bus with error messages! Brilliant!
Then there's the bit stuffing that lets the entire asynchronous message keep itself in sync during long bitstreams. But, also, probably more importantly the violation of the bit stuffing rule IS the error message which destroys traffic on the bus and causes the the other nodes to also send their own error frame, which results in a repeat of the original transmission. Cool.
Last edited: