"Olin Lathrop" wrote:
> I'm just starting to get into CAN now, but I don't see how CAN maps to a
> UART nicely.  A UART is just a bi-directional stream of bytes.  In most
> cases there is no out of band control information (RTS/CTS are rarely used
> these days, for example).
>
> CAN on the other hand is based on discrete messages coming asynchronously
> from multiple sources on the bus.  You don't send a stream of bytes of
> arbitrary length from here to there.  You broadcast and listen to short
> packets, each identified by its meaning.

It sounds like you're describing a specific implementation of CAN. In fact, 
it is possible to send a stream of bytes over CAN, split over multiple 
frames. Packets do not necessarily have to have any intrinsic "meaning", you 
can pack ASCII messages into CAN frames, then reassemble them on the other 
end.


> CAN is a very different peer to peer networking strategy from multiple 
> point
> to point streams of bytes, like TCP or a UART.  You could put a wrapper
> around basic CAN to give you that, but then you're not programming to CAN
> anymore and I wouldn't call it a CAN interface.

That's actually exactly what I did: I put a wrapper around the low-level CAN 
routines. Once you set up the CAN peripheral, configure masks and filters, 
you basically have two operations left: SendMessage() and GetMessage(), very 
similar to UART or any other protocol. The only difference is that you are 
dealing with one message at a time, instead of one byte at a time.

It's true that messages come asynchronously, but the PIC processes them one 
message at a time anyway, so why not have the low-level CAN routines put 
them in a buffer (using interrupts or DMA), and then use a GetMessage() 
function to retrieve them?

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist