On 24.01.2011 10:07, Kurt Van Dijck wrote:
> On Sat, Jan 22, 2011 at 08:21:09PM +0100, Oliver Hartkopp wrote:
>> 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.
> Here you lost me.
Yes, and this is probably the reason, why you stick on the idea attaching
J1939 source addresses (SA) to the network interface and not to the socket.
It needed some days for me to check some J1939 concepts again ...
> It appears we have different ideas of what is called a 'box'.
> 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.
>
> Not sure is this is clear terminology. Suggestions are welcome. I will answer
> your
> remark later.
All current SocketCAN concepts with RAW/BCM oder ISO-TP 15765-2 sockets allow
to have multiple applications on one Linux host.
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?
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??
Got the problem?
Regards,
Oliver
ps. generally adding some new infrastructure to the networking stuff without
the 'user' for this infrastructure is a no-go. There had been several rejects
from Dave when people tried to integrate support for hidden out-of-tree
sources. What about contributing your current j1939 source and discussing this
here on the ML and make first steps on the SVN? Out-of-tree developments are
hard to maintain ... and surely j1939 is a non-differentiating protocol -
therefore i also added my ISO 15765-2 implementation to get a better feedback
from the community on my work.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
