Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Izolowany galwanicznie interfejs jednokierunkowy open-drain 10 Mb/s

28 Apr 2017 08:04 14181 92
SterControl
  • #61
    user777
    Level 11  
    Robiłem w swoim urządzeniu dla czujnika temp DS18B20. To jet wyspa do podłączania czujników ds18, jako część automatyki domowej, dodatkowo z izolowanym rs485.
  • SterControl
  • #62
    User removed account
    User removed account  
  • #63
    user777
    Level 11  
    R-MIK wrote:
    user777 wrote:
    Robiłem w swoim urządzeniu dla czujnika temp DS18B20.

    Pewnie master programowy? Jak tak to dlaczego w programie nie rozdzieliłeś pinu nadawania od odbioru? Pinów w procku brakowało?


    Procek to xmega.

    Master może być programowy, lub sprzętowy - USART. Aktualnie soft jest w trakcie pisania i master jest programowy, a docelowo będzie sprzętowy na usarcie.
  • SterControl
  • #64
    User removed account
    User removed account  
  • #65
    user777
    Level 11  
    R-MIK wrote:


    No to zero problemu aby w programie oddzielić nadawanie od odbioru. W przypadku UASRT już to masz, w przypadku operacji na PIO trzeba tylko w programie oddzielić nadawanie od odbioru. Dzięki temu izolacja galwaniczna bedzie o 10zł tańsza.


    Niby tak, ale głównie chodziło o to żeby nie mieszać w kodzie - mam działający 1wire ( nieważne czy programowy czy sprzętowy) - robię tak sprzęt żeby izolacja była "niewidoczna". Gdyby to było urządzenie komercyjne - to ten układ jest na tyle drogi że lepiej jest zmienić soft. W domu potrzebuję kilku takich urządzeń więc nie ma problemu...

    Przy 1wire mniej się ten układ opłaca niż przy I2C.

    Schemat wrzuciłem z tego powodu, że gdyby ktoś potrzebował zrobić sobie taka izolację na I2C - to są już gotowe układy wspomagające.
  • #66
    User removed account
    User removed account  
  • #67
    andre65
    Level 13  
    Czesc.
    Moze to drobiazg, ale zmien sobie rysunek schematu komponentu pt. 6N136. W obwodzie wyjsciowym ta dioda w bazie powinna byc odwrotnie. Powinna pracowac i zawsze tak sie jej w optocouplerach uzywa na pradzie wstecznym.

    Brzydko to wyglada bo wydaje sie jakby tam bylo zwarcie przez ta diode i baze tranzystora. Pozdr
  • #68
    User removed account
    User removed account  
  • #69
    User removed account
    User removed account  
  • #70
    User removed account
    User removed account  
  • #71
    Freddie Chopin
    MCUs specialist
    No więc właśnie. I2C to taki interfejs w którym zawsze komunikacja w każdej ramce (9 bitów) jest w dwie strony - master wysyła do slave'a zegar, a slave w takt tego zegara musi odesłać dane (w przypadku komunikacji typu odczyt) lub bit ACK (w przypadku komunikacji typu zapis).

    Z tego względu należy skomentować ten oto fragment napisany przez R-MIK, który niestety został usunięty ( https://www.elektroda.pl/rtvforum/viewtopic.php?p=16660796#16660796 ):

    Quote:
    Natomiast z innego źródła mam potwierdzone 3,4Mb/s na 900m.


    Gdyby to miało być prawdziwe I2C, a nie "I2C", to odległość jaką musi pokonać informacja jest 2x większa niż odległość między urządzeniami, a więc wynosiłaby 1800 metrów. Aby to więc działało, informacja musiałaby się przemieszczać z prędkością 1800 m / (1 s / 3400000) = 6120000 km / s (słownie - sześć milionów sto dwadzieścia tysięcy kilometrów na sekundę), czyli jakby na to nie patrzeć ponad 20x większą niż prędkość światła. Aby nie zaciemniać obrazu pomijam tutaj dopuszczalne przesunięcie fazowe dla I2C, które pewnie jest typu 10-20%, a więc w zasadzie to trzeba by tą prędkość pomnożyć jeszcze przez 5 albo i przez 10...

    Jeśli zaś R-MIK nie widzi problemu w tym że master tylko nadaje i nie sprawdza ACK, to mam dużo lepszy i dużo tańszy sposób na zwiększenie zasięgu I2C - po stronie mastera potrzebne jest urządzenie, które bity z I2C zapisze na kartce jako "0" i "1", w dwóch linijkach, osobno dla SDA i SCL. Następnie kartkę wsadzamy do koperty, naklejamy stosowny znaczek i wysyłamy pocztą do dowolnego miejsca na świecie. Po drugiej stronie potrzebne jest urządzenie do którego włożymy kartkę i ono odtworzy te bity z prędkością trylion gigabitów na nanosekundę. I proszę - tym oto sposobem mamy izolowany galwanicznie "I2C" trylion gigabitów na nanosekundę o teoretycznym zasięgu 20000 km (połowa obwodu Ziemi). Bezsensu? Podobnie jak rozwiązanie stworzone przez autora tego tematu...

    O ile w przypadku "tylko nadawanie i bez ACK" to rozwiązanie pewnie działa, to jest ono po prostu pozbawione jakiegokolwiek sensu praktycznego, bo taniej sobie przesłać te informacje przez radio, Ethernet, RS-485 czy cokolwiek dostosowanego do takich odległości - tak czy siak nie jest to żadne I2C. Dwa mikrokontrolery na tej odległości można połączyć czymkolwiek innym, a żadnego "typowego" układu (czujnik, termometr, pamięć, ekspander, ...) się i tak przez ten wynalazek nie połączy bo nie będzie działać.

    Maksymalny zasięg prawdziwego I2C (zakładam max 20% dopuszczalnego przesunięcia w fazie):
    - przy prędkości 3.4 Mbps - ~9 metrów,
    - przy prędkości 1Mbps - 30 metrów,
    - przy prędkości 400 kbps - 75 metrów,
    - przy prędkości 100 kbps - 300 metrów.
    Każda wartość powyżej tego nie ma prawa działać. Jeśli ktoś uważa inaczej, to Nagroda Nobla za przekroczenie prędkości światła czeka.

    Maksymalna prędkość jaką można osiągnąć przy odległości 900 metrów między urządzeniami to 33 kbps.
  • #72
    User removed account
    User removed account  
  • #73
    User removed account
    User removed account  
  • #74
    User removed account
    User removed account  
  • #75
    Freddie Chopin
    MCUs specialist
    R-MIK wrote:
    Wysyłaj dane do np PCF8574. Ignoruj ACK. PCF zmieni stan? Zmieni.
    Są układy PLL sterowane po IIC. Można do nich tylko pisać. ACK mówi tylko masterowi, że układ jest obecny na magistrali. Czy jak będe sterował takim układem na 1200m zadziała? Zadziała. Pisałeś, ze max 300m przy 100kHz.
    Jak sie odniesiesz do tego co napisałem?

    Ale z moją propozycją - zapis bitów na kartce, wysłanie ich listem tradycyjnym za pomocą poczty, odczyt z kartki w miejscu docelowym i przesłanie do urządzenia na miejscu - też zadziała, no nie? Jak się do tego odniesiesz?

    Znalazłeś dwa układy w przypadku których Twój wynalazek zadziała w ograniczonym zakresie. Bo z tego PCF8574 o którym piszesz można też odczytywać dane, wiec nawet w przypadku tego układu masz jedynie 50% funkcjonalności. Zapewne dla tych PLL jest identycznie. Dla tysięcy innych istniejących układów nie zadziała wcale albo będziesz miał ułamek prawdziwej funkcjonalności. Jak zamkniesz oczy i wciśniesz gaz do deski widząc czerwone światło na skrzyżowaniu to też jest szansa że przejedziesz bez szwanku, co jeszcze nie oznacza że jest to dobry pomysł.

    Brniesz na ślepo. Ten układ jest całkowicie pozbawiony sensu praktycznego, ponieważ funkcjonalność którą masz (wyjątkowo ograniczoną) można osiągnąć na tysiąc innych sposobów, bo i tak nie masz komunikacji dwukierunkowej. Można sobie więc te dane wysyłać przez RS-485 czy przez radio i będzie taniej oraz wygodniej. Tyle że wtedy od razu będzie wiadomo że to jest najwyżej "I2C", a nie prawdziwe I2C.
  • #76
    User removed account
    User removed account  
  • #77
    User removed account
    User removed account  
  • #78
    User removed account
    User removed account  
  • #79
    User removed account
    User removed account  
  • #80
    User removed account
    User removed account  
  • #81
    User removed account
    User removed account  
  • #82
    Freddie Chopin
    MCUs specialist
    R-MIK wrote:
    Twierdzisz, że izolacja galwaniczna dla 3,4Mb/s nie ma sensu?

    W taki sposób jak to zrobiłeś - nie. Bo tak czy siak mało ma to wspólnego z I2C.

    R-MIK wrote:
    Czy istnieje układ, który realizuje taka funkcję?

    Tak. WiFi. Ma mniej-więcej tyle wspólnego z I2C co Twoje rozwiązanie. Myślę że z dwóch popularnych układów ESP-cośtam można zrobić lepszy i tańszy izolator "I2C" niż to co zrobiłeś. Też będzie działać jedynie w jedną stronę, nie potrzeba żadnych dodatkowych części i żadnych przewodów.

    R-MIK wrote:
    Jeżeli twierdzisz, że izolacja galwaniczna IIC nie ma sensu, to po co sa produkowane ADUM125x?

    To co zrobiłeś nie jest izolatorem I2C, tylko co najwyżej izolatorem "prawie I2C". "Prawie czyni wielką różnicę".
    R-MIK wrote:
    Da sie przesłać dane na 1200m? Da.
    Max przepustowość to 10Mb/s? Tak.
    Który z tych faktów podważasz?

    To że coś ma zasięg (teoretyczny) 1200 m i (użycie spójnika "i" jest tutaj sporym nadużyciem, ale pomijam...) przepustowość (teoretyczną) 10 Mbps jeszcze nie znaczy że ma to coś ma cokolwiek wspólnego z I2C. Nazwij sobie swoje urządzenie "izolowany galwanicznie interfejs jednokierunkowy open-drain 10 Mb/s o teoretycznym zasięgu 1200 m" i nas w tym temacie już nigdy nie zobaczysz. Tylko tyle albo aż tyle.
  • #83
    dondu
    Moderator on vacation ...
    Freddie Chopin wrote:
    Nazwij sobie swoje urządzenie "izolowany galwanicznie interfejs jednokierunkowy open-drain 10 Mb/s o teoretycznym zasięgu 1200 m" i nas w tym temacie już nigdy nie zobaczysz. Tylko tyle albo aż tyle.

    Aby zakończyć stawiam pytanie: Czy tytuł zmieniony przez autora na:

    Quote:
    Izolowany galwanicznie IIC 10Mb/s o teoretycznym zasięgu 1200m.

    jest satysfakcjonujący?
  • #84
    User removed account
    User removed account  
  • #85
    Freddie Chopin
    MCUs specialist
    dondu wrote:
    Aby zakończyć stawiam pytanie: Czy tytuł zmieniony przez autora na:

    Cytat:
    Izolowany galwanicznie IIC 10Mb/s o teoretycznym zasięgu 1200m.

    jest satysfakcjonujący?

    No ale to przecież nie jest żadne I2C czy tam IIC... No chyba że autor nazwie to "I2C jednokierunkowe bez sprawdzania ACK", to niech będzie <:

    Piotrus_999 wrote:
    Proponuję: Izolowany galwanicznie IIC o teoretycznej prędkości 10Mb/s i o teoretycznym zasięgu 7.5m.

    No co Ty [; Przy 10 Mbps myślę że max teoretyczny zasięg to może ze 3 metry. Pamiętaj że rozjazd w fazie pomiędzy zegarem mastera a tym co odbiera od slave'a nie może być 100% - max teoretyczny to 50% (moment zmiany stanu linii SCL), ale lepiej aby było to mniej.
  • #86
    User removed account
    User removed account  
  • #87
    User removed account
    Level 1  
  • #88
    User removed account
    Level 1  
  • #89
    dondu
    Moderator on vacation ...
    Autor w tym poście wskazał transoptory 6N137 w wersji 10Mb/s - patrz załącznik. Pomijam inne aspekty dot. przesyłu.

    Tytuł (i częściowo decyzja o pozostawieniu tematu) zaczerpnięty z propozycji:

    Freddie Chopin wrote:
    Nazwij sobie swoje urządzenie "izolowany galwanicznie interfejs jednokierunkowy open-drain 10 Mb/s o teoretycznym zasięgu 1200 m" i nas w tym temacie już nigdy nie zobaczysz. Tylko tyle albo aż tyle.


    Należy pamiętać, że dyskusja dot. parametrów granicznych, a na mniejszych odległościach i przy mniejszych prędkościach można domniemywać, że urządzenie działa poprawnie. Nie ma więc podstaw do usunięcia artykułu, są za to podstawy do odniesienia się do maksymalnych parametrów.

    Co do zaufania i faktycznych parametrów tego urządzenia oznaczyliśmy artykuł stosownym wpisem w pierwszym poście (którego nie sposób nie zauważyć) zwracającym uwagę na wszelkie krytyczne uwagi osób oceniających projekt. Dzięki Waszej czujności projekt został wypunktowany pod kątem technicznym, dając osobom czytającym masę wiedzy i punktów zaczepienia do krytycznego podejścia do sprawy oraz własnych projektów tego typu urządzeń.

    Także dzięki Wam autor przed opisaniem kolejnego projektu zastanowi się trzy razy zanim go przedstawi, gdyż będzie świadomy, że jesteście czujni, oraz że artykuł już na wieki na Elektrodzie będzie wisiał, gdyż nie będzie usunięty do kosza, z którego zniknie. A to że w Google-u jest widoczny będzie jeszcze większą mobilizacją dla autora, by nie mijać się z prawdą.
  • #90
    User removed account
    Level 1