On Thu, Jan 27, 2011 at 08:07:11PM +0100, Oliver Hartkopp wrote:
> On 24.01.2011 10:07, Kurt Van Dijck wrote:
> > On Sat, Jan 22, 2011 at 08:21:09PM +0100, Oliver Hartkopp wrote:
> > To make me follow, we need some terminology:
> > ECU = logical unit sending _all_ of it j1939 traffic with the same SA, on a
> > single network
> > CHIP = 1 physical CAN network chip.
> > BOX = 1 physical box with 1 or more CHIPS.
> >> On 22.01.2011 19:42, Kurt Van Dijck wrote:
> >>> On Sat, Jan 22, 2011 at 07:07:22PM +0100, Oliver Hartkopp wrote:
> >>>>
> >>>> If you tweak your CAN protocol with addresses bound to a specific CAN
> >>>> interface this has a system-wide effect.
> >>>> So your Linux box can only act as a
> >>>> specific J1939 node as restricted by the given addresses above.
> >>> on a pure j1939 network, a box is intended to use only de addresses given
> >>> above.
> >>> I assume that a given box can use multiple addressess, each of them
> >>> configured
> >>> with '$ ip addr add ...'
> >>
> >> Yes. But the missing point is that you can ideally have multiple of these
> >> 'boxes' running on one single host to simulate a complete environment
> >> consisting of multiple nodes.
[naming ....]
s/node/ecu/g
>From j1939 point of view, there is no 'box', but only a collection of ECU's.
Reordering the collection of ECU's is allowed.
>
> 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?
>
Now we're getting somewhere.
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?
>
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 &
$ mydiag2 --dev can0 --sa 0x80 &
$ mytimestampbroadcast --dev can0 &
....
as well.
I plain CAN, each of the above applications _need_ diffenent CAN-id,
in J1939, the SA is reused within an ECU.
An ECU is then defined be a collection of applications reusing the same
SA.
Thanks,
Kurt
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
