[En-Nut-Discussion] RE: RFC: can_dev.c proposed changes
Henrik Maier
hmlists at focus-sw.com
Sat Oct 22 02:39:24 CEST 2005
wrote:
> Hi,
>
> I plan to have a look on this library, but I think I'll write my own
> library to connect to CAN bus by a MCP2510 with SPI interface!
>
> Franck
Hi Franck,
the Nut/OS CAN system consists of two layers:
a) An architecture specific driver for the CAN chip itself, currently
implemented are Philip SJA1000 and Atmel Full CAN controller (found in
the AT90CAN128)
and
b) an abstraction layer called can_dev which represents a CAN device in
a generic form for all architectures.
Application programs would alway use only the can_dev API as shown in
the following snippet:
NutRegisterDevice(&devAtCan, 0, 0); // CHIP level driver
CAN_SetSpeed(&devAtCan, CAN_SPEED_125K);
// Prepare a frame for sending
memset(&canFrame, 0, sizeof(canFrame));
canFrame.id = 0x123;
canFrame.len = 8;
canFrame.byte[0] = 0x11;
canFrame.byte[1] = 0x22;
canFrame.byte[2] = 0x33;
canFrame.byte[3] = 0x44;
canFrame.byte[4] = 0x55;
canFrame.byte[5] = 0x66;
canFrame.byte[6] = 0x77;
canFrame.byte[7] = 0x88;
CAN_TxFrame(&devAtCan, &canFrame);
// Check if we did receive a frame
if (CAN_TryRxFrame(&devAtCan, &canFrame))
...
I like to encourage you to make your MCP2510 driver compatible with can_dev.
The benefit would be that demo programs, applications and hi-level CAN
protocols using the can_dev layer can run with either CAN chip.
Have a look ate the sja1000.c and atcan.c drivers, you can use them as a
template for your MCP2510 driver.
Regards
Henrik
More information about the En-Nut-Discussion
mailing list