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.
>
> > $ 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?
I think not supplying the SA from commandline should give you a proper default.
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 :-)
I do think the multiple ECU is an important use-case,
but something complicated cannot be made easy.
My proposal (as above) simplifies the most-used use-case.
Kurt
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
