Odgrzeje temat
Buduje maly system w ktorym kilka arduino bedzie sie miedzy soba komunikowac poprzez szyne i2c .
Wszystko zaczyna ladnie dzialac, ale problem pojawia sie w momencie kiedy jedno z urzadzen zostanie
wylaczone z zasilania, ale nadal jest podlaczone do szyny danych. Efektem jest zamieranie szyny i2c.
Przy pomiarze napiec na szynie kiedy nic nie jest transmitowane utrzymuje sie mniej wiecej polowa
napiecia zasilania a wiec 2.25 V.
Jak temu zaradzic ? Jednym z pomyslow jest wpiecie w szyne szeregowo dwoch rezystorow 1 Kohma.
Ale to nie jest prawidlowe rozwiazanie. Mimo tego wszystko dziala poprawnie na przewodach dlugosci
okolo 1.5 m. Jak inaczej mozna temu zaradzic ?
Szyna I2C została wymyślona w celu łączenia układów w obrębie jednego urządzenia. Zakłada się, że wszystkie układy mają wspólne włączane zasilanie - nie przewiduje się pracy szyny przy odłączeniu zasilania niektórych układów. Problem leży w diodach technologicznych wewnątrz układów scalonych, które z grubsza zwierają niezasilane wejścia układów do masy (przez pewną rezystancję). "Prawdziwe" (a nie mikrokontrolerowe) linie I2C nie mają tej przykrej własności. Tym się różnie prawdziwe OC od symulowanego OC w mikrokontrolerach. Nic tu nie poradzisz.
No ok ale jak napisalem ... podlaczenie szeregowo do pinow i2c rezystorow pomaga ...
Molestuje przez caly dzien i jak na razie nie wykrylem zadnego bledu. Po odlaczeniu zasilania
od jednego z ukladow szyna nadal pracuje poprawnie nie wykazujac zadnego bledu ...
Czy moge tak zostawic czy szukac raczej innego rozwiazania ?
Obecnie mam przewody 2m, 3m i 30 cm. Rezystory podciagajace standardowo dalem na 4.7 K.
Te szeregowo do szyny w kazdym ukladzie po 1 K. Rozwiazanie biedne, ale dziala.
W ostatecznosci moge dobudowac jakis bufor separujacy, ale tego bym nie chcial.
Molestuje przez caly dzien i jak na razie nie wykrylem zadnego bledu.
Ten odłączony mikrokontroler jest teraz częściowo zasilany przez magistralę i te rezystory. To raczej nie jest dobre i w szczególności może prowadzić do wykonywania jakiegoś pokręconego kodu przez ten mikrokontroler, pomimo pozornego braku zasilania. Poza tym te szeregowe rezystory wprowadzają dodatkowe opóźnienia narastania zboczy sygnału, w efekcie mogą wpływać na transmisję do tego układu.
CyberDuck wrote:
Obecnie mam przewody 2m, 3m i 30 cm.
Z tymi 2-3m to pojechałeś po bandzie. I2C to jak pisał kol. @BlueDraco magistrala lokalna. To, że ci to wszystko działa przy takiej partyzantce to po prostu szczęście, nic więcej. Użyj przewidzianych do takich okazji interfejsów, np. wspomnianego RS485.
Faktycznie, I2C to magistrala lokalna. Pomimo to, będzie działać na 2...3 metrach. Tak jak wcześniej wspomnieli, nie nadaje się na dłuższe odległości. Oprócz RS485, jest jeszcze CAN.
Chyba jednak pojde w kierunku rs485 .
Duzo mniejsze moduly i tez gwarantuja dosc dobre parametry transmisji.
Duzo tansze ... i latwiejsze w wykorzystaniu.
Max polaczenia beda mialy 10 m, a z tego co wyczytalem max predkosc 500 Kbits w zupelnosci
wystarczy. Urzadzenia beda jedynie wymianiac miedzy soba rozkazy i pojedyncze bajty danych.
Can jest za bardzo rozbudowana i za drogie uklady.
Dodano po 1 [godziny] 37 [minuty]:
Nie wiem jak to wytlumaczyc, ale podlaczylem przewody 5 mb.
Wszystko polaczone na razie na pajaczka i dziala bez zarzutu.
Przewody nie ekranowane. Jedynie co zrobilem to dobra filtracja zasilania.
Pzrewody 4 zylowe. +5V. SDA. SCL, masa. Rezystory sa w poblizu urzadzenia , ktore bedzie wlaczone
caly czas, ale tez o odleglosci okolo 70 cm na przewodzie. Kazde dodatkowe urzadzenie po zaopatrzeniu
w rezystory szeregowe z magistrala odlaczone od zasilania nie powoduje zawieszania sie magistrali.
Mam podlaczone na razie 5 arduino micro pro . No zebym nie byl goloslowny to prosze :
https://www.youtube.com/watch?v=PrDaG_h9wTw to na dole jest podlaczojne na przewodzie 5mb, To z wtykami to wezel magisrali i2c. To w trzeciej rece
to jedno z urzadzen w ktorym jest arduino i zasilacz. To wygladajace jak pajak to arduino podlaczone
do komputera z ktorego moge wydawac roznego rodzaju komendy. Na ekranie widac jak wpisuje scan i kazde
sie zglasza swoja nazwa wraz z adresem.
Ale ok rozumiem i doceniam Wasze podpowiedzi i doswiadczenie. To jest bardzo cenne i na pewno przejde na jakas
inna magistrale. Jeszcze nie jest za pozno
Jednak CAN załatwia jeden podstawowy problem: ma zaimplementowany protokół i rozwiązuje problem arbitrażu (czyt. dostępu) magistrali. W RS485 będziesz musiał rozwiązać to programowo, np. przez zastosowanie protokołu MODBUS RTU. Ale z kolei ten protokół zapewnia poprawną komunikację tylko z jednym układem Master w systemie (reszta Slave). I tutaj jest przewaga CAN (tutaj mogą być wszystkie układy Master).
Max polaczenia beda mialy 10 m, a z tego co wyczytalem max predkosc 500 Kbits w zupelnosci
Są transceivery RS485 nawet na 10 Mbps.
aut0matyk wrote:
Jednak CAN załatwia jeden podstawowy problem: ma zaimplementowany protokół i rozwiązuje problem arbitrażu (czyt. dostępu) magistrali.
Jeśli autor używa na razie I2C to ma sytuację single master, multiple slaves. Przeniesienie tego na RS485 to chwilka - nie potrzeba arbitrażu, bo nie wystąpi jednoczesny dostęp do magistrali kilku urządzeń. W praktyce implementacja programowa będzie prostsza niż I2C. Wystarczy wysłać przez UART prostą ramkę danych. Oczywiście można to sobie komplikować dodając kolejne funkcjonalności, pytanie, czy autor tego potrzebuje.
aut0matyk wrote:
I tutaj jest przewaga CAN (tutaj mogą być wszystkie układy Master).
Autor używa Arduino, a to nie ma kontrolera CAN. Trzeba więc dodać kontroler (droższy niż procesor) i transceiver CAN. Do tego trzeba to oprogramować, bo o ile kontroler realizuje wiele spraw sprzętowo, to jednak coś musi tworzyć ramkę, reagować na błędy i i oprogramować sam kontroler CAN. IMHO w zastosowaniu autora, jest to strzelanie z armaty do muchy. Przy podanych założeniach, zwykły UART i RS232-TTL może być wystarczający. Piny TxD slave'ów trzbaby tylko połączyć robiąc wired-and (zapewniając tylko, aby wyjścia TxD były OC, czyli w praktyce dodatkowy tranzystor na AVR).
Dobra bo widze, ze jesli nie zaczne opisu od poczatku to nie bedzie z tego nic Rozmowy akademickie ... a chce isc do przodu.
Calosc bedzie zamontowana w samochodzie. Lubie elektronike i bajerki chociaz w moim wieku zaczynam sie
powoli tego wstydzic wiec prosze o wyrozumienie wszystkich czytajacych.
Planuje zrobic :
1. Oswietlenie do polki przy lewarku zmiany biegow. Pod radiem. Zauwazylem ze po ciemku trudno jest cokolwiek
tam dostrzec. Podreczna polka wiec uzywana. To urzadzenie ktore jest na filmie zamontowane w trzeciej rece
to mikrokontroler z dwoma diodami ws2812b na koncach. i oczywiscie przetwornica. Obudowe drukowalem sobie na drukarce 3D
dzieki magistrali mozna regulowac :
d1 x x x kolor d1
d2 x x x kolor d2
j1 x I prog jasnosci
j2 x II prog jasnosci (czuj)
t x tempo rozjazniania
tu x tempo usredniania
dlsw x dl swiecenia max
czul x czulosc/zakr reakcji
stwej x00 wej - INPUT 0
x01 wej - INPUT 1
x10 wej - PULL_UP 0
x11 wej - PULL_UP 1
1xx zawsze wlacz
czuj wyswietla wart czuj
sr wyswietla wart sred
eep wyswietlenie nastaw
dmax zapal diody z jasn II
dmin zapal diody z jasn I
reb reboot urz podrz
Ma to dzialac tak ze przy wlaczonych swiatlach beda sie bardzo delikatnie swiecic diody. Po wlozeniu reki diody sie
rozjasniaja na jakis czas. Jak widac na liscie komend mozna tam wyregulowac wszystko !!. Czas rozjasniania, poziom pierwszy
jasnosci diod, poziom drugi jasnosci diod, kolor kazdej z osobna, czulosc czujnika zblizeniowego, usrednianie ( napotkalem problem przy
oswietleniu zewnetrznym ktory wlasnie zalatwilem usrednianiem wartosci mierzonej ), i wiele innych parametow.
To akurat urzadzenie bedzie potrzebowac informacji o tym czy sa wlaczone swiatla czy nie. Ewentualnie innych danych, ktore beda
dostepne na magistrali glownej.
Jak na razie modul pracuje perfekcyjnie Wszystko w czasie rzeczywistym wlacznie z transmisja danych po szynie.
2. Oswietlenie klamek zewnetrznych . Po odblokowaniu drzi i pod warunkiem ze na zewnatrz jest ciemno rozjarza sie
klamki samochodu na zewnatrz do momentu otwarcia drzwi, ale nie dluzej niz 2 min.
I znowu modul bedzie potrzebowac na magistrali kilku informacji o oswietleniu na zewnatrz i czy drzwi zostaly
otwarte.
3. Sterowanie szybami. W wiekszosci samochodow po wylaczniu silnika sterowanie szybami jest wylaczane.
Tutaj bedzie mozna wlaczyc szyby na czas regulacji i zrobic z nimi to co sie chce.
Jeszcze sie zastanawiam nad czujnikiem poziomu otwarcia szyb ale chyba poprzestane na czasowym stopniowaniu
otwarcia czy zamkniecia.
4. Procesor glowny, ktory bedzie zbierac roznego rodzaju informacje potrzebne w systemie i udostepniac je innym modulom.
5. Czujnik deszczu docelowo sterujacy wycieraczkami, ale dzieki mozliwosci wymiany informacji bedzie mogl
np domknac szyby jesli sa otwarte jesli silnik jest wylaczony a na dworze zacznie padac deszcze nie uruchamiajac
przy tym wycieraczek. Zrobilem juz odpowiednie eksperymenty do wykonania takiego czujnika refrakcyjnego
(tak jak to jest w samochodach) i dziala fajnie Najdrozej mnie kosztowal zel do montazu czujnika.
Modul porownuje oswietlenie zewnetrzne z tym co przychodzi z diody oswietlajacej w podczerwieni.
Po zroznicowaniu i usrednieniu wyniku podejmuje decyzje co ma zrobic. Reakcja nie jest moze tak szybka
jak w pro rozwiazaniach ale to dziala !!
6. Bezkluczykowy system otwierania drzwi i bagaznika.
No nie bede opisywac wszystkich modulow, a bedzie troszke tego. Porzebuje wlasnie do tego sprawnie dzialajacej magistrali.
Dodatkowe urzadzenie do polaczenia sie w magistrale z komputerem bedzie pelnic role takiej plomby miedzy
komputerem a reszta systemu. Tez juz dziala Widac to na filmiku.
Nie mam jakiegos wypasnego na maxa samochodu i wlasnie chcialem sobie go doposazyc o rozne bajerki.
Mam jeszcze dosc duzo pomyslow.
Jak sie domyslacie nie kazde z tych modulow bedzie wlaczone caly czas. I stad problem zamierania magistrali
po wylaczeniu jakiegos modulu.
Jak na razie ide w kierunku magistrali CAN. Ale kazda sugestia jest dla mnie cenna. Calosc ma dzialac
perfekcyjnie. Jak na razie dziala ale na i2c.
Tak sobie mysle, ze jesli wszystko dziala bez zadnych problemow przy dlugosci przewodow 5 m , a sprawdzalem
to na rozne sposoby , to moze by zastosowac jakis wzmacniasz mniej wiecej w polowie drogi. Umiescic
wezel w takim miejscu zeby dlugosc przewodow nie przekroczyla 4 m i zrobic tam gniazda wraz z wzmacniaczami
sygnalowymi. Nie sprawdzalem tylko tego analizatorem stanow, ale sprawdzalem czy cos sie nie zostaje
w buforze, sprawdzalem czasy transmisji i za kazdym razem sa bardzo zblizone. Nie wypada zaden pakiet ...
Nawet probowalem w poblizu przewodow umiescic urzadzenia zaklocajace typu trafo, generatory roznych
czestotliwosci i dziala nadal. Dodam tylko ze ten przewod na ktorym to sprawdzam jest nie ekranowany.
Tak sobie mysle, ze jesli wszystko dziala bez zadnych problemow przy dlugosci przewodow 5 m , a sprawdzalem
to na rozne sposoby , to moze by zastosowac jakis wzmacniasz mniej wiecej w polowie drogi. Umiescic
wezel w takim miejscu zeby dlugosc przewodow nie przekroczyla 4 m i zrobic tam gniazda wraz z wzmacniaczami
sygnalowymi.
Ponieważ nie za bardzo jest sens o tym dyskutować, po prostu przyjmij, że I2C o długości kilku metrów i automotive nie idą w parze. Powiem więcej - arduino i automotive nie idą w parze. Z jakiegoś powodu w samochodach jest CAN i specjalne procki do automtive - nikt by nie pakował wielokrotnie droższych elementów, gdyby to nie było absolutnie konieczne.
Skoro masz tyle modułów i tak naprawdę konfiguracja multimaster mogłabybyć wygodniejsza, to można użyć CAN. Tylko wybierz MCU z CAN na pokładzie, ew. użyj RS485 i dodaj odpowiednią warstwę softwarową. BTW, to, że coś działa na biurku niewiele znaczy. W samochodzie masz wysokie temperatury, kurz, wilgoć, zakłócenia. I nie jest to delikatne zakłócenie z trafka małej mocy.
Zamowilem moduly CAN na ukladach MCP2515 TJA1050. Na razie 3 szt wiec bede experymentowac ...
Z ciekawosci podam tylko ze na i2c podnioslem czestotliwosc transmisji do 400KHz i tez wszystko idzie
bez problemu. Problem zaczal sie dopiero przy 1 MHz .
