0livaw napisał(a):
Jeden bufor=jedna ramka. Ale czy nie można jednym buforem obsłużyć kilku urządzeń?
Można, ale przeczytaj jeszcze raz moją pierwszą wypowiedź, bo w kółko wracasz do punktu wyjścia, pomijając wszystko co napisałem.
Mamy bufor odbiorczy, który pomieści jedną ramkę. Przesyłana wiadomość ma rozmiar
większy od jednej ramki. Ramki trzeba więc na bieżąco odbierać i zapisywać w jakimś większym buforze, żeby zwalniały miejsce dla następnych danych.
No i teraz mamy problem, bo w przypadku magistrali CAN zawsze może wystąpić sytuacja, kiedy
kilka urządzeń będzie nadawało wiadomość (serię ramek) do jednego odbiorcy. W takiej sytuacji albo będziemy musieli zastosować tyle osobnych buforów/tablic odbiorczych, ile mamy urządzeń (praktycznie nie do wykonania w małym MCU) albo ramki nam się przemieszają w jednej tablicy odbiorczej i w zdarzeniu uruchamianym po wykryciu otrzymania całej linii trzeba będzie jakoś wydzielić tylko te właściwe kawałki. I właśnie nie za bardzo mam pomysł, jak można by to zrealizować...
Cytuj:
A czy możesz powiedzieć co chcesz zbudować? Bo mam wrażenie że to jest błądzenie we mgle...
System automatyki domowej (sterowanie światłem, w przyszłości alarm, rolety itp.). W chwili obecnej pracuję nad wersją wykorzystującą Ethernet, w przyszłości jednak z paru względów wolałbym przerzucić się na CAN.
Tak, wiem - mógłbym przerobić to na komunikację bitową, mieszcząc całą komendę w jednej ramce. Jednak nie chcę sobie zamykać tej furtki. Jak mówiłem, istnieje spora szansa na to, że w pewnym momencie będę potrzebował funkcji przesyłania tekstu do wyświetlenia na innym urządzeniu. I co wtedy?
Zresztą w tym wypadku warstwa aplikacji nie ma nic do rzeczy. Chodzi o przesyłanie komend w postaci ciągów znaków ASCII, o rozmiarze większym niż jedna ramka CAN. To, co z tą komendą zrobi program nie ma już absolutnie nic wspólnego z zagadnieniem transmisji.