W dniu 2014-03-29 13:39, Atlantis pisze:
[...]
> 1. Jakieś sprytne wydzielanie z bufora tylko tego, czego nam potrzeba,
> już po stwierdzeniu odebrania końca wiadomości. Ramki składające się na
> przychodzące wiadomości od niepasujących nadawców trzeba by wtedy
> przepisywać do innych komórek, robiąc coś w rodzaju "defragmentacji",
> uważając jednocześnie, by nic nie zostało nadpisane w momencie
> jednoczesnego przyjścia przerwania RX.
> 2. Upewnienie się, że nic nie zacznie nadawać kolejnej wiadomości, zanim
> nie skończymy odbierać obecnej. Innymi słowy urządzenie wysyła prośbę o
> nawiązanie połączenia. Jeśli mamy wolną linię (i pusty bufor) wysyłamy
> mu ACK. Od tego momentu do otrzymania końca wiadomości (albo timeoutu) w
> buforze zapisywane są tylko ramki z tego adresu. Zapytania od innych
> chętnych do nawiązania transmisji skutkują prośbą o chwilowe wstrzymanie
> się.
[...]

Widzę jeszcze jedno:
3. Jeśli to jest system automatyki domowej, to i tak zapewne będzie miał
centralkę. Zorganizować komunikację tak, że węzły odpowiadają tylko na
zapytania centralki. Większość problemów rozwiązuje się sama w takim
układzie. Gdyby to nie było służbowe, mógłbym Ci podrzucić specyfikację
takiego rozwiązania - niestety, jest.

A ad. 1 - kontrolery CAN mają wbudowane filtry sprzętowo maskujące ID.
Wystarczy wykorzystać - po prośbie o nawiązanie połączenia ustawić filtr
i voila - słychać tylko żądany ID. Jednak w zależności od kontrolera CAN
może to mieć tę wadę, że do zmiany maski w filtrze potrzebne jest
chwilowe wyłączenie kontrolera (vide ECAN w PIC32).

I apropos ISO-TP - nie powinien być trudny do obsłużenia samemu. Nie
wiem, czy gdzieś na Sieci będą otwarte biblioteki do tego protokołu -
jego główne (jedyne?) zastosowanie jest w systemach automotive.

Pozdrawiam,

Piotr