Jak zrealizować komunikację 1-Wire między mikrokontrolerami AVR Tiny13?

Zastanawiam się jak zrealizowac komunikacja pomiędzy dwoma mikrokontrolerami AVR (np pomiędzy tiny 13 a tiny 13). Czy można wykorzystać do tego 1wire? Ogólnie komunikacja musi się odbywać poprzez tylko jedno łącze sygnałowe. Czyli [zasilanie | dane | masa]

pewnie, że można to zrealizować w ten sposób

No to w takim razie jak ustawić jeden z procesorów na master a drugi na slave?
W sumie chciałbym aby był jeden procesor jakiś większy np attiny 2313 a jako slave'y pracowały małe procesorki np właśnie tiny13.

A dało by się zrealizować kumunikację w jedną stronę (bo o taką mi chodzi) np prze rs-232? wykorzystują w jednym procesorze tylko TxD a w drugim tylko RxD?

no rozumiem, że zrobienie mastera to mniejszy problem a jeśli chodzi o slave'a to musi korzystać z któregoś przerwania aby wykrywać początek transmisji, i w tym przerwaniu obsługiwać odbiór danych jeśli został odpytany za pomocą wcześniej w nim zdefiniowanego adresu

Cały system który chcę zbudować to sieć procesorków (powiedzmy kilka) które po podłączeniu ich do układu automatycznie wyślą do głównego procesora jakiś kod (np liczbę) tak więc to ten główny procesor musi korzystać z przerwań a slavy tylko wysyłają jakies tam bity.

no to stawiasz problem na głowie niestety, ... w takim przypadku potrzebujesz zorganizować sobie sieć z wieloma MASTERAMI.... nie wiem co chcesz na końcu osiągnąć, ale w większości prostych rozwiązań tego typu, stosując 1Wire, I2C, czy RS485 można to co mówisz zorganizować w ten sposób , że robisz jedak jednego MASTERA, który cyklicznie co jakiś krótki odcinek czasu odpytuje pozostałe procki(moduły) w sieci i prosi je łaskawie o podanie danych, które dla niego zebrały i to jest o wieeele prostsze do zorganizowania programowo....
i bardziej racjonalne, jeśli tych twoich wiele układów ma pełnić tylko rolę jakichś tam czujników i co jakiś czas ich zadaniem będzie przekazanie danych do jednego procka

Tiny13 mają pracowac w roli kluczy który podłaczajac do system komunikują sie z głównym procesorem i jeśli numer który wyśle taki tiny 13 bedzie sie zgadzać z tym w głownej bazie (głownym procku) to jakiś tam zamek zostanie otwarty czy coś...

No w usmie moze byc tak ze wszystkie procki będą masterami a główny to slave...

i2c odpada bo przeciez sa potzrebne dwie linie sda i scl a nei moze być wiecej niż jedna linia danych.
najbardziej odpowiadalo y mi rs-232 ale znowu tiny 13 nie ma rs'a a realizując go programowo nie zmieścił by się w pamięci...

nigdy nie będzie tak ze dwa procki tiny 13 będa naraz podłaczone.

a no skoro nie będą nigdy naraz podłączone to pewnie, że nie będzie problemu aby to główny był SLAVE (najwyżej jak raz na 100 się zdarzy, że 2 ludzi włoży klucz to wystąpi kolizja - ale przecież nie będą ciągle go wkładali w tym samym czasie co do milisekundy

... no tak to 1Wire w takiej sytuacji wydaje się być najbardziej optymalnym rozwiązaniem

Ok to w takim razie jak skonfigurowac procki zeby działały z 1wire? Aha! A jak jest z odległością? Jak długie mogą być max kable pomiedzy tymi prockami?

mirekk36 napisał:

no to stawiasz problem na głowie niestety, ... w takim przypadku potrzebujesz zorganizować sobie sieć z wieloma MASTERAMI.... nie wiem co chcesz na końcu osiągnąć, ale w większości prostych rozwiązań tego typu, stosując 1Wire, I2C, czy RS485 można to co mówisz zorganizować w ten sposób , że robisz jedak jednego MASTERA...

Nie do końca się zgodzę. I2C ze swojej zasady działania ma możliwość pracy przy wielu masterach na linii - było to jedno z zalożeń przy opracowywaniu tego standardu. Co ciekawe arbitraż jest zrobiony na tyle pomysłowo, że nie powoduje straty czasu na magistrali - w przypadku kolizji master, ktory wygrywa arbitraż nie musi nawet powtarzać ramki. I2C wymaga jednak dwóch linii i masy.

Z tym 1wire to bym się tak nie napalał - standard znacznie obciąża procesory (z uwagi na koniecznośc dokładnego pomiaru czasu). Jeżeli całość robisz dla siebie to proponuję wymyśliś jakiś swój własny protokół, wbrew pozorom jak się wie czego się chce to wcale nie takie trudne.

do kolegi Tdv ... no tak w I2C można tak jak piszesz i może nie do końca o tym wiedziałem ale kolega autor napisał , że to chodzi o jakieś dłuższe magistrale więc chociażby z tego tytułu I2C odpada - tak mi się wydaje ..... a co do pomysłu aby zamiast 1Wire wymyśleć swój protokół to też fajny pomysł - z tym, że ja chyba właśnie gdybym miał to robić dla siebie i te układy zewn miałyby tylko przesyłać ew odebrać jakiś tam kod i potwierdzenie to użyłbym chyba już gotowych procedurek do 1Wire i się nie szczypał w wymyślenie w takim przypadku własnego rodzaju transmisji.... masz rację, że trzeba troszkę czasu procka poświęcić na obsługę 1Wire ale jak on nie ma nic w zasadzie innego do roboty to po co go tak oszczędzać?

pozdrawiam

Jeżeli już kierować się w strone 1wire to może skorzystać z gotowych "kluczy" czyli pastylek dallasa z 1 wire, z ktorych każda ma zapisany unikalny kod.
Do tego wystarczy uC jako master na 1wire, który w sposób cykliczny będzie skanował magistralę.

o tak, pastylki to już by było to w przypadku kolegi autora ... wogóle chyba najlepsze rozwiązanie - tylko ja akurat nie mogę porównać kosztów takiego rozwiązania do zrobienia tego na tiny13 - ale chyba dużo drożej by nie wyszło?

pastylki są dośc tanie bo chyba 2,3 dollara za sztukę, Znajomy ma takei pastylki w firmie i może opchnac taką za 10 zeta. ALe tu chodzi ze ja chce zrealizowac własny pomysł.

Pth napisał:

pastylki są dośc tanie bo chyba 2,3 dollara za sztukę, Znajomy ma takei pastylki w firmie i może opchnac taką za 10 zeta. ALe tu chodzi ze ja chce zrealizowac własny pomysł.

No to chyba i protokół warto własny wymyślić...

a może lin? sprytny protokół, łatwy do zaimplementowania w oparciu o uarty no i jeden kabel sygnałowy i komunikacja master - slave'y rozwiązana

uart odpada bo tiny 13 nie ma wbudowanego spzretowego uarta a programowy uart przekroczyl by pojemnosc tiny13 (1kb)

Prosty protokół można zrobić tak:
1. Właczony do linii klucz sprawdza przez okres np 10ms czy na lini jest stan wysoki.
2. Jeżeli jest stan niski to siedzi cicho przez np. 50ms, po czym znowu testuje stan lini j.w. (bo to znaczy, że własnie inny klucz się "przedstawia").
3. Jeżeli na linii panuje stan wysoki (wszystkie wyjścia na linię muszą być typu otwarty kolektor/dren, przy uC głównym pullup do 5V), wystawia na nią stan niski.
2. Od zbocza opadającego na lini uC główny liczy czas do zbocza narastającego.
3. Klucz po odpowiednim czasie (ściśle okerślonym dla danego klucza np. w zakresie 50 do 100ms) zmiania stan wyjścia na wysoki.
4. uC główny rejestruje tę zmianę i zapamiętuje czas oraz zaczyna liczyć czas stanu wysokiego.
5. Klucz odlicza np. 5ms i ponownie ustawia stan linii na niski.
6. Zbocze opadające rejestruje uC główny i zaczyna ponownie zliczać czas.
7. Klucz odlicza czas np. o połowę krótszy niż poprzednio i zmienia stan linni na wysoki.
8. uC główny rejestruje czas i ma 3 czasy, stanu niskiego, wysokiego i ponownie niskiego. Sprawdza czy czas stanu wysokiego jest prawidłowy (wyżej przyjęte 5ms), jeżeli tak to sprawdza czy proporcja drugiego czasu stanu niskiego do pierwszego jest prawidłowa (wyżej załozona 1/2).
9. Jeżeli zależności czasowe odpowiadają zapisanemu w pamięci kluczowi to uC główny daje dostęp, czy co tam ma robić.

Algorytm można skrócić do punktu 4, późniejsze punkty zwiększają tylko odporność protokołu na przypadkowe przekłamania.
Dodatkowo można proporcję między dwoma stanami niskimi w jakiś sposób uzależnić od czasu trwania pierwszego stanu, tak, żeby nie musiało to być stale 1/2. Tu już można cuda, wianki wymyślać.