usb-can device

usb-can device

[Max S.]

Hello,

I am developing a usb to can adapter.

Does there exist a standard usb-can interface on the linux side? Or will
I have to create my own device driver?

In the linux kernel source I see drivers/net/can/ems_usb.c which seems
to provide a way to add support for multiple devices through the
ems_usb_table. What would it take to get my vendor id and product id
into this list (assuming that the device is working with this driver).

I haven't studied the driver in great detail, so i don't know if it is
appropriate for what I am trying to do...

What are my options for getting a usb device, that exposes two can
nodes, supported under linux? I have complete access to the usb device,
so it would not be a problem for me to build a firmware that behaves a
certain standard way.

Respectfully,
Max S.

Re: usb-can device

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 2163 bytes --]

Hello Max,

On 08/26/2012 05:52 PM, Max S. wrote:
> I am developing a usb to can adapter.
> 
> Does there exist a standard usb-can interface on the linux side? Or will
> I have to create my own device driver?

There is no standard driver, however I was thinking last week that
someone should write a CDC CAN driver. CDC Ethernet is a standard to
send ethernet frames over USB.

> In the linux kernel source I see drivers/net/can/ems_usb.c which seems
> to provide a way to add support for multiple devices through the
> ems_usb_table. What would it take to get my vendor id and product id
> into this list (assuming that the device is working with this driver).
> 
> I haven't studied the driver in great detail, so i don't know if it is
> appropriate for what I am trying to do...

I don't know what the legal department of ems will do, if you "clone"
their hardware, or build something that is compatible to their hardware
on the driver level.

> What are my options for getting a usb device, that exposes two can
> nodes, supported under linux? I have complete access to the usb device,
> so it would not be a problem for me to build a firmware that behaves a
> certain standard way.

The kvaser driver basically just sends and receives binary messages.
They have a common header (len+type of message+CAN interface) and the
message itself. There are messages to send and receive a CAN frame,
TX-complete, for error handling, and for configuration. If you want to
make your device's firmware update able, implement dfu (device firmware
update). Optional stuff is abort tx of CAN frames, timestamps for rx and tx.

Oliver, do you remember the talk about the CAN in FPGA we heart at the
CAN CIA conference, do you have a link to the presentation. It was FPGA
based, but all concept mentioned there also apply to USB based devices.

cheers, Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: usb-can device

[Oliver Hartkopp]

Hello Marc,

On 26.08.2012 18:28, Marc Kleine-Budde wrote:

> Hello Max,
> 
> On 08/26/2012 05:52 PM, Max S. wrote:
>> I am developing a usb to can adapter.
>>
>> Does there exist a standard usb-can interface on the linux side? Or will
>> I have to create my own device driver?
> 
> There is no standard driver, however I was thinking last week that
> someone should write a CDC CAN driver. CDC Ethernet is a standard to
> send ethernet frames over USB.


Yes. I've been thinking about something similar for CAN USB recently too. See
below.

(..)

>> What are my options for getting a usb device, that exposes two can
>> nodes, supported under linux? I have complete access to the usb device,
>> so it would not be a problem for me to build a firmware that behaves a
>> certain standard way.
> 
> The kvaser driver basically just sends and receives binary messages.
> They have a common header (len+type of message+CAN interface) and the
> message itself. There are messages to send and receive a CAN frame,
> TX-complete, for error handling, and for configuration. If you want to
> make your device's firmware update able, implement dfu (device firmware
> update). Optional stuff is abort tx of CAN frames, timestamps for rx and tx.


Due to the lack of USB CAN Hardware, where i could implement my own firmware i
thought about using http://www.8devices.com/product/2/usb2can which is pretty
cheap and also provides schematics to be able to alter the firmware with it's
onboard JTAG interface (see schematic):

http://www.8devices.com/uploads/downloads/usb2can.pdf

The idea is to bring the USB CAN interface as near as possible to the
SocketCAN network interface:

- send struct can_frames
- receive struct can_frames (for instant CAN data forwarding)
- receive struct can_frames (for instant CAN error messages(!) forwarding)
- send an endian pattern inside the USB URB (*1)
- send skb->sk pointers along with CAN data (*2)
- define a simple interface for open/close/bitrate-setting

*1:
The idea is to reduce the CAN network driver to make simple memcpy()
operations instead of do any bitshifting or endian conversions. For that
reason an endian pattern (e.g. 0xAA00AA00) is added to the USB URB at
send/configuration, so that the CAN USB adapter switches to the host endian
mode and replies with the same endian pattern before the CAN data.
This allows to simply memcpy() the received CAN frame into skb->data.

*2:
To provide a state-of-the-art echo functionality the sk pointer (skb->sk) is
sent along with the CAN frame. This allows to skb_free() the original tx skb
and create a new one at rx time with the correct sk pointer, when the frame is
echoed after successful transmission. As we are endian safe the sk pointer can
be taken from the USB URB as-is. (For security reasons we should probably not
take the pointer directly but double check with stored echo-skbs)

So the general idea is not to design an USB CAN API and adapt this to the CAN
network interface driver - BUT to design an USB CAN API supporting the CAN
netdev driver concepts and native data structures directly. This would be
similar to the CDC Ethernet approach and could become a "standard USB-CAN
interface" - which was originally requested by Max.

Without any legal interference when using other vendors USB CAN API ;-)

@Max: If you thinking about adopting this idea it would be great to discuss
about the driver details here. If you are free in your current USB CAN API
right now, it's worth a try :-)

> Oliver, do you remember the talk about the CAN in FPGA we heart at the
> CAN CIA conference, do you have a link to the presentation. It was FPGA
> based, but all concept mentioned there also apply to USB based devices.


This was the Advanced CAN Controller from www.esd.eu :

http://www.can-cia.org/fileadmin/cia/files/icc/13/arlt.pdf

Regards,
Oliver

Re: usb-can device

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

On 08/27/2012 10:10 AM, Kurt Van Dijck wrote:
>> *2:
>> To provide a state-of-the-art echo functionality the sk pointer (skb->sk) is
>> sent along with the CAN frame. This allows to skb_free() the original tx skb
>> and create a new one at rx time with the correct sk pointer, when the frame is
>> echoed after successful transmission. As we are endian safe the sk pointer can
>> be taken from the USB URB as-is. (For security reasons we should probably not
>> take the pointer directly but double check with stored echo-skbs)

> 'sending an skb pointer' is indeed a key to cleaner design,
> but couples both systems more tight: is that pointer 32bit? 64?
> 
> I even don't know if that is a problem ...

On 64 Bit archs you need 64 bit for a pointer. However I'd like to call
this cookie or handle not pointer to some kernel internal data. And as
Oliver pointed out, don't trust the data that comes from the USB device.

regards, Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: usb-can device

[Oliver Hartkopp]

On 27.08.2012 14:40, Max S. wrote:

> On Mon, 2012-08-27 at 08:20 +0200, Oliver Hartkopp wrote:

>> The idea is to bring the USB CAN interface as near as possible to the
>> SocketCAN network interface:
> 
> Exactly. The device should know what a struct can_frame is. The device i
> have is more than powerful enough to do some extra converting, endian
> etc (its an atmel devboard).
> I have been reading the Peak CAN-USB driver source, they seem to do the
> conversion on the host with a simple
> #ifdef ENDIAN be or le ... 
> 
> compiling either the big endian or the little endian code.
> 
> but a single memcpy would be allot cleaner.


Yes. In general the content from the CAN registers needs to be copied into the
URB from the CAN USB CPU anyway. So the idea is to do it in host-byteorder.
This has a very small impact to the CAN CPU complexity and makes it really
easy on the host driver side.

>> - send struct can_frames
>> - receive struct can_frames (for instant CAN data forwarding)
>> - receive struct can_frames (for instant CAN error messages(!) forwarding)
>> - send an endian pattern inside the USB URB (*1)
>> - send skb->sk pointers along with CAN data (*2)
>> - define a simple interface for open/close/bitrate-setting
>>
>> *1:
>> The idea is to reduce the CAN network driver to make simple memcpy()
>> operations instead of do any bitshifting or endian conversions. For that
>> reason an endian pattern (e.g. 0xAA00AA00) is added to the USB URB at
>> send/configuration, so that the CAN USB adapter switches to the host endian
>> mode and replies with the same endian pattern before the CAN data.
>> This allows to simply memcpy() the received CAN frame into skb->data.
>>
>> *2:
>> To provide a state-of-the-art echo functionality the sk pointer (skb->sk) is
>> sent along with the CAN frame. This allows to skb_free() the original tx skb
>> and create a new one at rx time with the correct sk pointer, when the frame is
>> echoed after successful transmission. As we are endian safe the sk pointer can
>> be taken from the USB URB as-is. (For security reasons we should probably not
>> take the pointer directly but double check with stored echo-skbs)
> 
> hm. I also don't think it would be wise to accept a pointer from the
> outside in kernel space. maybe accept an index(that can be checked) into
> a pointer array?.. I don't know, I'm not at that point yet :P.
> 


I found a very interesting implementation in the Bosch M_CAN specification:

http://www.semiconductors.bosch.de/en/ipmodules/can/canipmodules/m_can/m_can.asp

http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/m_can/mcan_users_manual.pdf

Section 2.4.3 Tx Buffer Element (page 45)

---8<---

T1 Bits 31:24 MM[7:0]: Message Marker

Written by CPU during Tx Buffer configuration. Copied into Tx Event FIFO
element for identification of Tx message status.

---8<---

So you can see in the Tx event FIFO, which marked CAN frame has been sent.

This is probably enough to provide just a byte and to create an array of
skb pointers which is referenced by this Message Marker. Maybe 256 markers
are too much ... we could only use 8 markers IMO.

>>
>> So the general idea is not to design an USB CAN API and adapt this to the CAN
>> network interface driver - BUT to design an USB CAN API supporting the CAN
>> netdev driver concepts and native data structures directly. This would be
>> similar to the CDC Ethernet approach and could become a "standard USB-CAN
>> interface" - which was originally requested by Max.
> 
> I have started work on this, since the last email, although i am only at
> the very beginning of the task.
> 


No problem. Every journey begins with a first step. [Lao Tze]

Regards,
Oliver

Re: usb-can device

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 3795 bytes --]

Hello,

Max, please leave the mailinglist on Cc.

On 08/28/2012 01:58 PM, Oliver Hartkopp wrote:
> On 27.08.2012 14:40, Max S. wrote:
> 
>> On Mon, 2012-08-27 at 08:20 +0200, Oliver Hartkopp wrote:
> 
>>> The idea is to bring the USB CAN interface as near as possible to the
>>> SocketCAN network interface:
>>
>> Exactly. The device should know what a struct can_frame is. The device i
>> have is more than powerful enough to do some extra converting, endian
>> etc (its an atmel devboard).
>> I have been reading the Peak CAN-USB driver source, they seem to do the
>> conversion on the host with a simple
>> #ifdef ENDIAN be or le ... 
>>
>> compiling either the big endian or the little endian code.
>>
>> but a single memcpy would be allot cleaner.
> 
> 
> Yes. In general the content from the CAN registers needs to be copied into the
> URB from the CAN USB CPU anyway. So the idea is to do it in host-byteorder.
> This has a very small impact to the CAN CPU complexity and makes it really
> easy on the host driver side.
> 
>>> - send struct can_frames
>>> - receive struct can_frames (for instant CAN data forwarding)
>>> - receive struct can_frames (for instant CAN error messages(!) forwarding)
>>> - send an endian pattern inside the USB URB (*1)
>>> - send skb->sk pointers along with CAN data (*2)
>>> - define a simple interface for open/close/bitrate-setting
>>>
>>> *1:
>>> The idea is to reduce the CAN network driver to make simple memcpy()
>>> operations instead of do any bitshifting or endian conversions. For that
>>> reason an endian pattern (e.g. 0xAA00AA00) is added to the USB URB at
>>> send/configuration, so that the CAN USB adapter switches to the host endian
>>> mode and replies with the same endian pattern before the CAN data.
>>> This allows to simply memcpy() the received CAN frame into skb->data.
>>>
>>> *2:
>>> To provide a state-of-the-art echo functionality the sk pointer (skb->sk) is
>>> sent along with the CAN frame. This allows to skb_free() the original tx skb
>>> and create a new one at rx time with the correct sk pointer, when the frame is
>>> echoed after successful transmission. As we are endian safe the sk pointer can
>>> be taken from the USB URB as-is. (For security reasons we should probably not
>>> take the pointer directly but double check with stored echo-skbs)
>>
>> hm. I also don't think it would be wise to accept a pointer from the
>> outside in kernel space. maybe accept an index(that can be checked) into
>> a pointer array?.. I don't know, I'm not at that point yet :P.
>>
> 
> 
> I found a very interesting implementation in the Bosch M_CAN specification:
> 
> http://www.semiconductors.bosch.de/en/ipmodules/can/canipmodules/m_can/m_can.asp
> 
> http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/m_can/mcan_users_manual.pdf
> 
> Section 2.4.3 Tx Buffer Element (page 45)
> 
> ---8<---
> 
> T1 Bits 31:24 MM[7:0]: Message Marker
> 
> Written by CPU during Tx Buffer configuration. Copied into Tx Event FIFO
> element for identification of Tx message status.
> 
> ---8<---
> 
> So you can see in the Tx event FIFO, which marked CAN frame has been sent.
> 
> This is probably enough to provide just a byte and to create an array of
> skb pointers which is referenced by this Message Marker. Maybe 256 markers
> are too much ... we could only use 8 markers IMO.

Why not a full u32? Then you're free on the driver side to do what you
want with it.

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: usb-can device

[Oliver Hartkopp]

On 28.08.2012 14:13, Marc Kleine-Budde wrote:

> Max, please leave the mailinglist on Cc.


Acked-by me too. But i think it was an accident :-)

>>>> *2:
>>>> To provide a state-of-the-art echo functionality the sk pointer (skb->sk) is
>>>> sent along with the CAN frame. This allows to skb_free() the original tx skb
>>>> and create a new one at rx time with the correct sk pointer, when the frame is
>>>> echoed after successful transmission. As we are endian safe the sk pointer can
>>>> be taken from the USB URB as-is. (For security reasons we should probably not
>>>> take the pointer directly but double check with stored echo-skbs)
>>>
>>> hm. I also don't think it would be wise to accept a pointer from the
>>> outside in kernel space. maybe accept an index(that can be checked) into
>>> a pointer array?.. I don't know, I'm not at that point yet :P.
>>>
>>
>>
>> I found a very interesting implementation in the Bosch M_CAN specification:
>>
>> http://www.semiconductors.bosch.de/en/ipmodules/can/canipmodules/m_can/m_can.asp
>>
>> http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/m_can/mcan_users_manual.pdf
>>
>> Section 2.4.3 Tx Buffer Element (page 45)
>>
>> ---8<---
>>
>> T1 Bits 31:24 MM[7:0]: Message Marker
>>
>> Written by CPU during Tx Buffer configuration. Copied into Tx Event FIFO
>> element for identification of Tx message status.
>>
>> ---8<---
>>
>> So you can see in the Tx event FIFO, which marked CAN frame has been sent.
>>
>> This is probably enough to provide just a byte and to create an array of
>> skb pointers which is referenced by this Message Marker. Maybe 256 markers
>> are too much ... we could only use 8 markers IMO.
> 
> Why not a full u32? Then you're free on the driver side to do what you
> want with it.


Yes. You're right. It's a marker - and if i personally only want to handle an
index into an array with 8 elements with my driver it's my choice.

Regards,
Oliver

Re: usb-can device

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

On 08/28/2012 02:18 PM, Oliver Hartkopp wrote:

[...]

>>> I found a very interesting implementation in the Bosch M_CAN specification:
>>>
>>> http://www.semiconductors.bosch.de/en/ipmodules/can/canipmodules/m_can/m_can.asp
>>>
>>> http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/m_can/mcan_users_manual.pdf
>>>
>>> Section 2.4.3 Tx Buffer Element (page 45)
>>>
>>> ---8<---
>>>
>>> T1 Bits 31:24 MM[7:0]: Message Marker
>>>
>>> Written by CPU during Tx Buffer configuration. Copied into Tx Event FIFO
>>> element for identification of Tx message status.
>>>
>>> ---8<---
>>>
>>> So you can see in the Tx event FIFO, which marked CAN frame has been sent.
>>>
>>> This is probably enough to provide just a byte and to create an array of
>>> skb pointers which is referenced by this Message Marker. Maybe 256 markers
>>> are too much ... we could only use 8 markers IMO.
>>
>> Why not a full u32? Then you're free on the driver side to do what you
>> want with it.
> 
> 
> Yes. You're right. It's a marker - and if i personally only want to handle an
> index into an array with 8 elements with my driver it's my choice.
ACK :)

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

Re: usb-can device

[Max S.]

Hello Oliver,

I've been reading the USB CDC specification, but i have to admit, its
all rather dry material.

I'm feeling a little lost developing on both sides of the puzzle. Can
you provide me with a kind of lsusb printout of what the usb device is
supposed to look like?

what I've got right now is a CDC virtual com example, figured i could
modify it.

Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x03eb Atmel Corp.
  idProduct          0x2404 
  bcdDevice            1.00
  iManufacturer           1 ATMEL ASF
  iProduct                2 CDC Virtual Com
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           67
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval              16
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0001
  Self Powered

Max S.

Re: usb-can device

[Oliver Hartkopp]

On 28.08.2012 16:30, Max S. wrote:

> I've been reading the USB CDC specification, but i have to admit, its
> all rather dry material.
> 


Hm - yes. You are right ... i've looked myself. It's not very intuitive %-)

> I'm feeling a little lost developing on both sides of the puzzle. Can
> you provide me with a kind of lsusb printout of what the usb device is
> supposed to look like?
> 
> what I've got right now is a CDC virtual com example, figured i could
> modify it.


Better try to follow examples from cdc_ether, like this one:

https://bbs.archlinux.org/viewtopic.php?id=144056

Btw. a cdc_can driver would be located in linux/drivers/net/usb.

I would suggest to look into cdc-phonet.c and cdc_ncm.c which are doing
similar things as we need, e.g. PF_PHONET -> cdc-phonet => PF_CAN -> cdc_can

Regards,
Oliver


> 
> Device Descriptor:
>   bLength                18
>   bDescriptorType         1
>   bcdUSB               2.00
>   bDeviceClass            2 Communications
>   bDeviceSubClass         0 
>   bDeviceProtocol         0 
>   bMaxPacketSize0        64
>   idVendor           0x03eb Atmel Corp.
>   idProduct          0x2404 
>   bcdDevice            1.00
>   iManufacturer           1 ATMEL ASF
>   iProduct                2 CDC Virtual Com
>   iSerial                 0 
>   bNumConfigurations      1
>   Configuration Descriptor:
>     bLength                 9
>     bDescriptorType         2
>     wTotalLength           67
>     bNumInterfaces          2
>     bConfigurationValue     1
>     iConfiguration          0 
>     bmAttributes         0xc0
>       Self Powered
>     MaxPower              100mA
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        0
>       bAlternateSetting       0
>       bNumEndpoints           1
>       bInterfaceClass         2 Communications
>       bInterfaceSubClass      2 Abstract (modem)
>       bInterfaceProtocol      1 AT-commands (v.25ter)
>       iInterface              0 
>       CDC Header:
>         bcdCDC               1.10
>       CDC ACM:
>         bmCapabilities       0x02
>           line coding and serial state
>       CDC Union:
>         bMasterInterface        0
>         bSlaveInterface         1 
>       CDC Call Management:
>         bmCapabilities       0x03
>           call management
>           use DataInterface
>         bDataInterface          1
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x83  EP 3 IN
>         bmAttributes            3
>           Transfer Type            Interrupt
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval              16
>     Interface Descriptor:
>       bLength                 9
>       bDescriptorType         4
>       bInterfaceNumber        1
>       bAlternateSetting       0
>       bNumEndpoints           2
>       bInterfaceClass        10 CDC Data
>       bInterfaceSubClass      0 Unused
>       bInterfaceProtocol      0 
>       iInterface              0 
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x81  EP 1 IN
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               0
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x02  EP 2 OUT
>         bmAttributes            2
>           Transfer Type            Bulk
>           Synch Type               None
>           Usage Type               Data
>         wMaxPacketSize     0x0040  1x 64 bytes
>         bInterval               0
> Device Status:     0x0001
>   Self Powered
> 
> Max S.
> 

Re: usb-can device

[Fabio Baltieri]

Hello everyone,

On Mon, Aug 27, 2012 at 08:20:08AM +0200, Oliver Hartkopp wrote:
> > There is no standard driver, however I was thinking last week that
> > someone should write a CDC CAN driver. CDC Ethernet is a standard to
> > send ethernet frames over USB.
>
> Due to the lack of USB CAN Hardware, where i could implement my own firmware i
> thought about using http://www.8devices.com/product/2/usb2can which is pretty
> cheap and also provides schematics to be able to alter the firmware with it's
> onboard JTAG interface (see schematic):
> 
> http://www.8devices.com/uploads/downloads/usb2can.pdf
> 
> The idea is to bring the USB CAN interface as near as possible to the
> SocketCAN network interface:

Oliver, I developed an USB to CANBUS interface some months ago, that
I'm currently using for all my tests and developement.

I had the intention to release the full hardware, firmware and kernel
driver code, but I still have not had time to write a decent
documentation, a blog post, request proper USB IDs and design a rev2 -
anyway, as there seems to be some interest on the subject I pushed the
current design (hardware is in Eagle 6 format) on github at:

https://github.com/fabiobaltieri/open-usb-can

The hardware is currently based on an ATMega32U2 (yes, a 16MHz 8-bit
AVR) + MCP2515 as can controller, not exactly the best performing
hardware but really cheap and easy to hack.  Also, there are mounting
options for both normal and isolated transceiver (using an ADM3053,
should come cheaper and smaller than isolator + dc/dc + normal xcvr).

The USB stack is based on Werner Almesberger's ben-wpan code, which is
lightweight and clean, while the kernel driver is based on code from
ems_usb and esd_usb2.

In my test this design seems to perform quite well with busses up to
250kbps, and I also used it on my Toyota's 500kbps bus with very few rx
overruns.

So, this is probabily not the best bust sniffer in the world, but should
be ok for protocol development and testing.

The USB protocol I implemented at the time share some of your ideas (the
code is in the kernel-module directory):

> - send struct can_frames
> - receive struct can_frames (for instant CAN data forwarding)

I'm using a packed version of struct can_frame, that was to save some
bytes in USB messages and MCU's memory but should not really make a big
difference.

> - receive struct can_frames (for instant CAN error messages(!) forwarding)

Got it! No difference between normal and error frames in my kernel
driver.  The firmware speaks socketcan! (I stole some headers :-) )

> - send an endian pattern inside the USB URB (*1)

That should be easy to implement... sure it makes sense to do that in
the USB controller rather than the host?  That's just a le32_to_cpu per
packet...

> - send skb->sk pointers along with CAN data (*2)

That's to be implemented, I'm echoing from tx URB callback as ems, but I
have a buffer status pointer and two spare bytes in the rx message which
may be used to implement a better echo strategy.

> - define a simple interface for open/close/bitrate-setting

I'm using just some control requests for CAN_START and CAN_STOP and a
dedicated CAN_PUT_CONFIG with a specific struct open_usb_can_config for
configuration which is basically a subset of struct can_bittiming using
8-bit fields.

Oliver, Marc, do you think that this design my be used as a base to do
some generic USB-CAN (CDC CAN?) protocol development?  I would be happy
to help!

Max, does this helps you with the design?  I understand that you are
using some other Atmel MCUs... maybe you can directly re-use part of the
code.

Fabio

Re: usb-can device

[Oliver Hartkopp]

On 29.08.2012 01:34, Fabio Baltieri wrote:

> Oliver, Marc, do you think that this design my be used as a base to do
> some generic USB-CAN (CDC CAN?) protocol development?  I would be happy
> to help!


Yes. Definitely!

Really nice to have the entire project on github now.

Even if the MCP2515 is not the high performance hardware, we probably run into
problems there, we would not see on better hardware ;-)

> Max, does this helps you with the design?  I understand that you are
> using some other Atmel MCUs... maybe you can directly re-use part of the
> code.
> 
> Fabio


Tnx!

Oliver

Re: usb-can device

[Pavel Pisa]

On Wednesday 29 August 2012 13:02:15 Oliver Hartkopp wrote:
> On 29.08.2012 01:34, Fabio Baltieri wrote:
> > Oliver, Marc, do you think that this design my be used as a base to do
> > some generic USB-CAN (CDC CAN?) protocol development?  I would be happy
> > to help!
>
> Yes. Definitely!
>
> Really nice to have the entire project on github now.
>
> Even if the MCP2515 is not the high performance hardware, we probably run
> into problems there, we would not see on better hardware ;-)
>

I would like to express my interrest in the development of some generic CAN<->USB
protocol specification as well.

The main question is, if the data should be bulk messages boundaries aligned
(as done in our actual implementations) or if the USB PIPE/stream feature should be
used and USB transferred messages length to be variable.

There are some HW/code chunks which are available from our side:

1) We have used two CAN<->USB hardware setups already
    - LPC2148 + SJA1000 board (deprecated now)
    - LPC1768
   both boards was originally designed by my colleague at PiKRON Ltd.
   and are rich with other functions for their main use in our laboratory
   and medical systems.
   But we consider the circuitry required for CAN<->USB converters as
   open (GPL/MPL) and can think even about PD. If there is broader
   interrest, we would prepare and publish design optimized for CAN<->USB
   converter use.

2) the core part of the converters firmware is based on the LinCAN driver
   project which is now maintained as one of the OrtCAN GIT repositories.

   Firmware build steps are briefly documented at next page

     http://ortcan.sourceforge.net/lincan/usbcan/

   Used protocol is really simple for now, it maps each CAN message into
   little-endian formated 16-byte bulk message.
   Bitrate settings and calculations come from our LinCAN and H8S projects
   which are precursor for calculation used in SocketCAN and we extended
   our code to provide SocketCAN compatible parameters passing over USB
   in the latest version.

3) On the Linux side, the converters are primarily supported in the same
   LinCAN can-usb1 branch as firmware is located which is logical choice,
   because setup  architecture is stub chip driver/serialization replacing
   regular LinCAN chip driver on Linux side and deserialization and local
   embedded LinCAN core client on the converter side.

4) Socketcan support for the converters has been implemented in the frame
   of Jiri Vanek diploma thesis and is available in "vanekjir" branch of
   our experimental SocketCAN repo

     http://rtime.felk.cvut.cz/gitweb/socketcan-devel.git

     (the thesis full text - unfortunately Czech language only)
     http://support.dce.felk.cvut.cz/mediawiki/images/5/56/Dp_2012_vanek_jiri.pdf

5) Similar but independent USB<->CAN converter based on ST STR710
   is described in Ondrej Semler's diploma thesis. It was done
   on other CTU department and a driver side targets to Windows systems.

     (the thesis full text - Czech language only as well)
     http://support.dce.felk.cvut.cz/mediawiki/images/0/0b/Dp_2012_semmler_ondrej.pdf

As for converters based on SPI connected MCP2515 and some PIC. FTDI or other MCU
used for USB connection, I am not fan of these designs. They have tendency
to be overflown by full CAN traffic. On the other hand, my colleague has
single chip PIC with CAN based design which could serve as cheap converter
base and can handle full CAN bandwidth.

But I think that ARM based chips are cheap enough for now, that LPC17xx,
ST, AT or some other MCU based design would not mean significant contribution
to price and flexibility, FIFOs size etc. are much better. 

The protocol definition is most important for now.
There is no problem to adapt our design to different CAN messages
encapsulation and channel control.

Things to consider/decide:

A) Stream with variable length or bulk aligned
B) If and how should be Linux driver Tx side notified about CAN message
   delivery onto physical CAN bus and actual Tx time
C) how should be managed Rx and Tx timestamping, probably some free
   running time on the converter side should be used and translated
   to timespec format on Linux side
D) how should be solved prioritization of the messages, small/dicrete
   number of the priority queues or full ID based ordering
E) if more queues are used there is problem with Tx flow control,
   use more blocking USB endpoints/pipes - one for each queue,
   or use nonblocking solution with FIFOs free size reporting
   through single pipes/endpoints pair.
F) think about CAN single shot messages and rescheduling/reissuing
   higher priority message to the converter Tx buffer to prevent
   messages priority inversion problem in the converter/CAN bus
   interaction.

Best wishes,

                Pavel Pisa
    e-mail:     pisa@cmp.felk.cvut.cz
    www:        http://cmp.felk.cvut.cz/~pisa
    university: http://dce.fel.cvut.cz/