Re: [RFC] K-Line protocol via SocketCAN

[Marek Vasut <marex@denx.de>]

On 06/05/2016 02:07 PM, Oliver Hartkopp wrote:
> On 06/01/2016 04:26 AM, Marek Vasut wrote:
> 
>>>> What would be the advantages to put this into kernel space (or into the
>>>> CAN networking infrastructure)?
>>>
>>> I see two for putting this into the kernel:
>>> - At faster bus speeds, you can achieve more precise timing if this is
>>>    in the kernel, both of the inter-byte delay and also for the
>>>    timestamps. Having this in the kernel even allows usage of the
>>>    realtime extensions if needed.
> 
> A topic for the serial driver infrastructure?

Can you elaborate a bit please ?

>>> - Dedicated hardware driver can plug into such K-Line infrastructure.
>>>    Such hardware might be needed to support the faster modes to further
>>>    increase the timing precision.
> 
> Which K-Line infrastructure?

The one which would be added to socketcan. The patches don't seem too
disruptive in fact.

>>> And two for using socketcan/network interface:
>>> - The addressing support of the network stack can be mapped to K-Line
>>>    bus addresses.
> 
> The K-Line addressing is totally different from CAN addressing. Why do
> you think the stuff in linux/net/can has any conjunction to K-Line
> addressing?

Let me just ask what you mean by "totally different" first ?

>>> - The rtnl can be used as an extensible interface for configuring the
>>>    K-Line parameters.
> 
> The idea of SocketCAN using the Linux networking infrastructure and
> network interfaces is the multi-user capability which is enabled through
> this layering.
> 
> IIRC K-Line is ONE point-to-point connection which is not multi-user
> capable - so what would be the benefit to implement a K-Line serial
> driver as network device and then configure it via rtnl?

I am more interested in the RTNL configuration interface, since the
kline has way too many parameters and the RTNL scales well in that
aspect.

When using the socket interface, I can also add various flags to the
packet and control the properties of the data that are to be transmitted
via the KLine interface. That's real convenient.

>> What do you think about putting the KLine support into socketcan stack ?
> 
> If I would think about your mentioned requirements and ideas I would
> start with pyOBD http://www.obdtester.com/pyobd and probably move this
> to be a PREEMPT_RT task and I would add an interface to specify
> inter-byte delays into the serial driver infrastructure.

The python overhead would be waaaay too much. The reason for putting
this into the kernel is to get better timing control.

> Even when trying to think very positively about your question I don't
> see any conjunction to SocketCAN.
> 
> Best regards,
> Oliver


-- 
Best regards,
Marek Vasut