-
Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
atman.pl!wsisiz.edu.pl!.POSTED!not-for-mail
From: Atlantis <m...@w...pl>
Newsgroups: pl.misc.elektronika
Subject: Przesyłanie większych ilości danych przez CAN
Date: Sat, 29 Mar 2014 13:39:14 +0100
Organization: http://www.wit.edu.pl
Lines: 49
Message-ID: <lh6eto$1se$1@portraits.wsisiz.edu.pl>
NNTP-Posting-Host: avs54.neoplus.adsl.tpnet.pl
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: portraits.wsisiz.edu.pl 1396096760 1934 83.27.52.54 (29 Mar 2014 12:39:20
GMT)
X-Complaints-To: a...@w...edu.pl
NNTP-Posting-Date: Sat, 29 Mar 2014 12:39:20 +0000 (UTC)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
Thunderbird/24.4.0
X-Enigmail-Version: 1.6
Xref: news-archive.icm.edu.pl pl.misc.elektronika:661805
[ ukryj nagłówki ]Kontynuuję temat, który już kiedyś tutaj poruszałem.
Jak wspominałem, potrzebuję rozwiązania, które umożliwiłoby mi
przesyłanie przez magistralę CAN danych o rozmiarze większym, niż
pozwala na to pojedyncza ramka (8 bajtów). Chciałbym skomunikować
urządzenia przy pomocy komend AT, przesyłać teksty do wyświetlenia na
zdalnym LCD itp.
Proste zapisywanie komend w jakimś buforze odbiorczym nie wchodzi w grę,
bo jak wiadomo magistrala CAN jest magistralą multimaster. Istnieje więc
możliwość, że w trakcie odbierania wiadomości od jednego urządzenia,
wtrąci się jakieś inne i poszczególne ramki przemieszają się w jednym
buforze odbiorczym. Stosowanie osobnego bufora dla każdego z odbiorców
nie wchodzi w grę w małych MCU, a więc widzę tutaj jedynie dwa rozwiązania:
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ę.
Nie chciałbym wyważać otwartych drzwi, jeśli istnieje już jakieś
rozwiązanie. Ktoś kiedyś polecał standard ISO-TP. Znalazłem dzisiaj coś
takiego:
https://github.com/openxc/isotp-c
Wikipedia mówi, że ten standard pozwala na przesyłanie 4095 bajtów
danych. To znacznie więcej, niż potrzebuję (myślę, że 200 bajtów to aż
nadto). Jednak w opisie biblioteki trafiłem na fragment, który wyowłał u
mnie konsternację:
"The current version supports only single frame ISO-TP messages. This is
fine for OBD-II diagnostic messages, for example, but this library needs
some additional work before it can support sending larger messages."
Ktoś może mi powiedzieć o co chodzi? To chyba jakaś pomyłka? Po co
tworzyć taką bibliotekę, skoro koniec końców nie potrafiłaby ona
przesłać więcej danych, niż potrafi obsłużyć sprzętowo sam kontroler
CAN? Jeśli jednak przy pomocy tej biblioteki mógłbym wysyłać i odbierać
większe porcje danych, to czy istnieje szansa, że odpalę ją na jednym z
większych ośmiobitowych AVR-ów (Mega644, Mega128, AT90CAN128)?
Następne wpisy z tego wątku
- 29.03.14 14:01 Marek
- 29.03.14 14:12 Atlantis
- 29.03.14 22:31 Marek
- 30.03.14 00:19 Atlantis
- 30.03.14 13:55 Marek
- 30.03.14 18:10 Atlantis
- 30.03.14 20:45 RtB
- 30.03.14 21:57 Atlantis
- 31.03.14 01:52 Marek
- 31.03.14 01:48 Marek
- 31.03.14 09:55 Atlantis
- 31.03.14 09:51 Atlantis
Najnowsze wątki z tej grupy
- Rapsberry Pi i synchronizacja plików
- RCD 300 mA
- rpi i moduł przekaźników
- Falownik do pompy CO
- Lampa ogrodowa rozłączała różnicówkę
- Inteligentne oświetlenie schodów
- Pytanie do Użytkownika
- Emanuel kiedyś szukał gotowca do chłodzenia leków
- Sprzęty z Lidl-a
- idzie nowe
- Wybuchające pagery
- Jak shakować windę
- Sterowanie bezprzewodowe do wbudowania
- NC vs NO
- Jak dzięki mojemu pomysłowi amerykańce z Google przyspieszyli TV
Najnowsze wątki
- 2024-10-03 Warszawa => OpenText ECM Specialist <=
- 2024-10-03 Blokowanie informacji - test
- 2024-10-02 Warszawa => Fullstack Developer <=
- 2024-10-02 Katowice => QA Engineer <=
- 2024-10-02 Gdynia => Data Scientist <=
- 2024-10-02 Warszawa => Sales Development Representative (in German) <=
- 2024-10-02 Warszawa => SAP HANA Developer (Middle) <=
- 2024-10-02 Warszawa => SAP S/4HANA FI/CO Senior Consultant <=
- 2024-10-02 Warszawa => Senior SAP HANA Developers <=
- 2024-10-02 Warszawa => Senior PHP Laravel Developer (e-commerce) <=
- 2024-10-02 Warszawa => Programista Full Stack (.Net Core) <=
- 2024-10-02 Warszawa => Software .Net Developer <=
- 2024-10-02 Warszawa => Programista Full Stack .Net <=
- 2024-10-01 Katowice => Head of Virtualization Platform Management and Operating S
- 2024-10-02 GODZINA ZERO #48 - KRZYSZTOF STANOWSKI I ZBIGNIEW KAPIŃSKI PREZES IZBY KARNEJ SĄDU NAJWYŻSZEGO