On 09/08/2009 03:48 PM, Sebastian Haas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Wolfgang Grandegger schrieb:
>> On 09/08/2009 03:10 PM, Oliver Hartkopp wrote:
>>> Sebastian Haas wrote:
>>> static struct can_bittiming_const ems_usb_m16_bittiming_const = {
>>> .name = "ems_usb_m16",
>>> .tseg1_min = 1,
>>> (..)
>>> };
>>>
>>> @Wolfgang: would this be a correct naming scheme as the ems_usb driver
>>> has
>>> different hardware types?
>>
>> The name should be "sja1000" in case there is no difference to the other
>> SJA1000 CAN controllers. What is "m16"?
> Should be named m16c, it is a CAN controller from Mitsubishi.
Ah, I see, the driver supports two types of CAN controllers. Then the
SJA1000 directory is not the right place, I think. Maybe
/drivers/net/can/usb would be more appropriate.
>>>> Any ideas? I hope I'm using the candev interface correctly.
>>>>
>>>
>>> This was a really good start to merge the stuff!
>>>
>>> The missing parts should be connectable by the time.
>>
>> There are more issues, e.g. "__u8" -> "u8", no typedefs, lowercase names
>> for structs, ...
> I've already fixed most issues (I've also moved cpc.h into ems_usb.c,
> Oliver). I'm currently working on improving Tx/Rx performance. Error
If the header part is quite long/big, consider putting it into ems_usb.h
(in the same directory).
> handling, state changing and overrun handling is also include. I guess
> someone should take a look at to be sure I'm using it correctly.
>
>> Also I don't like that we introduce another set of SJA1000 register
>> definitions and offsets. Furthermore, there are many UBS based SJA1000
>> devices on the market and we should think if we could provide a common
>> interface for these, if feasible. E.g. sja1000_usb.c similar to sja1000.c.
> Most USB SJA1000 interfaces are using a FTDI to access the registers.
> Each register access are 2 USB transfers (request& response). This make
> sense for really cheap devices, but they are horrible slow.
You mean the EMS devices use a proprietary superior interface and it
makes little sense to share code with other (more or less) similar devices.
Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
