On 31.01.2011 09:52, Kurt Van Dijck wrote:
> On Fri, Jan 28, 2011 at 08:46:58PM +0100, Oliver Hartkopp wrote:
>> On 28.01.2011 11:44, Kurt Van Dijck wrote:
>>
>>>> An example:
>>>>
>>>> I implement a vehicle diagnosis application called 'mydiag' that
>>>> communicates
>>>> with a CAN ECU (e.g. an instrument cluster) using the ISO 15765-2 transport
>>>> protocol sockets.
>>>>
>>>> Then i can do a real diag session like this:
>>>>
>>>> mydiag -s 123 -d 321 can0
>>>>
>>>> assuming the instrument cluster ECU is connected to can0 and the CAN IDs
>>>> 123
>>>> and 321 are used for the ISO-TP transport protocol channel.
>>>>
>>>> And now i write a simulation for the instrument cluster ECU called
>>>> 'myecusim'.
>>>>
>>>> From now, i can simulate, test and develop the diagnosis application with
>>>> the
>>>> ECU simulation on my Linux host without any real hardware:
>>>>
>>>> Start simulation
>>>>
>>>> myecusim -s 321 -d 123 vcan0 &
>>>>
>>>> Start diagnosis application
>>>>
>>>> mydiag -s 123 -d 321 vcan0
>>>>
>>>> Finally i can simulate e.g. 30 different ECUs at the same time on my Linux
>>>> host to test and develop my diagnosis application (on a business trip
>>>> without
>>>> hardware!).
>>>>
>>>> If you attach the source address SA to the CAN interface, this means that
>>>> you
>>>> Linux host can only act as ONE ECU, right?
>>>>
>>> in my j1939 view:
>>>
>>> regular setup:
>>> $ ip addr add j1939 0x80 dev can0
>>> $ mydiag --dev can0 --sa 0x80 --da 0x81
>>>
>>> and simulated:
>>> $ ip addr add j1939 0x80 dev vcan0
>>> $ ip addr add j1939 0x81 dev vcan0
>>> $ myecusim --dev vcan0 --sa 0x81
>>> $ mydiag --dev vcan0 --sa 0x80 --da 0x81
>>>
>>>>
>>>> And if you put multiple SAs on the network interface, how could it be made
>>>> clear for the different processes / applications on the host, on which SA
>>>> they
>>>> are working??
>>> struct sockaddr_can saddr;
>>>
>>> saddr.can_ifindex = ifindex("vcan0");
>>> saddr.can_addr.j1939.sa = 0x80;
>>> bind(sock, &saddr, ...);
>>>>
>>>> Got the problem?
>>> I hope I explained the answer well?
>>
>> See my question below ...
>>
>>> This example did not show the full power of SA bound to interfaces, since
>>> only 1 application per ECU was run.
>>>
>>> Within J1939, and that I think is the major difference, the CAN id is split
>>> in a SA & PGN. 2 apps can/may/must use the same SA, with different PGN.
>>> I could so run:
>>>
>>> $ mydiag --dev can0 --sa 0x80 --da 0x81 &
>>> $ mydiag --dev can0 --sa 0x80 --da 0x82 &
>>
>> Why is the SA bound to the netdevice needed, if you set all the addresses by
>> commandline here?
> I intended not to change too much at a time in my example.
> I indeed would prefer not giving 0x80 as sa explicitely.
Ok, when you add (only one) SA to a CAN interface this would be possible.
Then it looks a bit like a bound address in UDP as you stated below.
For me it's just a question of consistency if you are forced to do the
addressing completely different, when implementing more than one ECU on the
host at the same time ...
>>
>>> $ mydiag2 --dev can0 --sa 0x80 &
>>
>> and here?
>>
>>> $ mytimestampbroadcast --dev can0 &
>>
>> ok - here you left out the '--sa <addr>' as you have set a default on the
>> netdevice, right?
>>
>> But what address is used here as SA? 0x80 or 0x81 (both set by 'ip addr add'
>> above)?
> I added 0x80 & 0x81 to vcan0, not can0.
> But your question is yet valid, I could have added 0x80 & 0x81 to can0 as
> well.
> In that case, well, I refer to UDP yet again. If you add
> both 192.168.0.1/24 & 192.168.0.2/24 to the same device, then which is the
> default?
The first one? ;-)
> I think not supplying the SA from commandline should give you a proper
> default.
See above - works fine implementing one ECU, right?
> In such case, any of both is good.
> IMHO, this is j1939 for advanced users.
> In that regard, I recently met some people that implemented multiple ECU's.
> It was a distaster wrt. transport protocol violations :-)
Yes, i'm looking forward to see your implementation for this and the BAM and
CON implementation of j1939 - and the Socket-API for all that.
> I do think the multiple ECU is an important use-case,
> but something complicated cannot be made easy.
Ack.
> My proposal (as above) simplifies the most-used use-case.
Yes. At least for the one-ECU use-case.
Regards,
Oliver
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
