Vitaliy wrote:
> 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?

No problem with all this, but then I wouldn't call what you're doing CAN
anymore.  You can't use your routines to do arbitrary CAN.  You gave the
impression that the app interface to CAN was as simple as that of a UART.
It's not since CAN is fundamentally different.  You have created a layer
that is similar to a UART that happens to use CAN as its low level
transport.  Your layer is no more a CAN application interface than TCP is a
IP application interface.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist