[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