Hej.

Moje pytanie jest w kontekście ATTiny1604, ale wiem, że to mało znany procek. Jeśli go nie znacie, to dajcie mi info z doświadczeń z innym z rodziny, prawdopodobnie rozwiązanie będzie podobne.

Co chcę zrobić? Mam N czujników na I2C o identycznej konstrukcji. By uniknąć programowego nadawania im adresów, pomyślałem, że wykorzystam General Call (adres 0), w którym prześlę komendę (bajt) i adres, jaki ma czujnik otrzymać. Wszystkie czujniki odczytają ten adres, ale tylko ten, w którym nacisnę jakiś przycisk, zapamięta go jako swój własny.

Idea pozornie prosta, ale za diabła nie wiem czy czujnik (klient TWI) został wywołany po jego własnym adresie, czy po General Call. Da się to jakoś sprawdzić? Chciałbym odseparować logikę General Call i wywołań po konkretnym adresie.

Ale to jeszcze nie koniec wątpliwości. Zanim w ogóle się za to zabiorę, to czy w General Call można przesłać dowolną ilość bajtów? Master nie otrzymuje w tym trybie ACK od klientów. W opisie standardu nie ma jednoznacznej odpowiedzi.

No to zaraz zaraz - to ty wiesz co robisz czy nie wiesz? Jak można tak pisać skoro to ty piszesz program ... i nie wiesz jak wywołujesz (adresujesz) klienta????


Bo szukasz w standardzie zamiast w PDF układu slave. Oczywiście że można w generall call przesłać bajtów ile chcesz, a że nie ma ack to nie masz pojęcia czy ktoś je odbiera czy informacje lecą w kosmos. Próby robienia urządzeń z komunikacją danych krytycznych po general call to średnio dobre rozwiązanie

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No wiem jak klienta wywołuję: np. po adresie 0 lub np 0x8. Ale klient nie wie po jakim adresie został wywołany, a takich adresów może posiadać sporo, nawet 127 na upartego. Zapytałem o możliwość dowiedzenia się przez klienta, nie przez mastera, po jakim adresie został wywołany.

Uruchomiłem komunikację z klientem póki co na sztywnym adresie, tylko w ramach sprawdzenia, czy komunikacja działa. Docelowo tak nie ma być. Może innymi słowy opiszę... Chciałbym, by klient zaraz po zmonitowaniu nie miał prywatnego adresu. Zyska go w trakcie konfiguracji i najlepiej - bez użycia lutownicy. Jaki to będzie adres - tylko płyta główna wie. Właśnie podczas konfigurowania czujników płyta przekaże klientowi/klientom w General Call (o ile się da) tenże adres. Tak jak pisałem - adres zostanie zaakceptowany przez czujnik po naciśnięciu na nim przycisku, lub czegoś tam innego. Taką mam ideę. Nie wiem, czy słuszną.


Tak, wiem. Ale uznałem, że robienie N takich samych czujników i programowe nadawanie każdemu z nich na sztywno innego adresu - czyli przypisywanie go z góry do miejsca instalacji, to jeszcze bardziej słabe podejście. Na WiFi też łączysz routery przyciskiem a'la Generall Call. Pomyślałem, że zrobię podobnie na TWI.

to że ty uznajesz że nie warto trzymać się standardu I2C to wiesz - kogo to interesuje - rób jak chcesz, jakie ci się tylko bzdury przyśnią i nie opowiadaj mi tu o setkach jakichś wyimaginowanych czujników na I2C. Toż przy 7-bitowych adresach można ich podłączyć mnóstwo i nikt nigdy nie podłącza ich w praktyce nawet więcej niż połowę - a ty tu zmyślasz jakieś teorie z kosmosu i fantasmagorie

ja nie mam zamiaru dalej brać udziału w twoich fantasmagoriach - już ci mówiłem, pisz konkretnie co chcesz uzyskać zamiast fantazjować

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

A tak z czystej ciekawości na jakiej odległości zamierzasz gadać z tymi slave'ami po I2C?

Orientacyjnie ok 30 cm. Ubiegając pytania: czujników będzie 5, czy 6.

Zresztą nie chodzi mi o konkretny projekt, gdyż wcześniej użyłem ich w innej aplikacji. Chodzi mi bardziej o to, że chciałbym uniknąć programowania ich na stałe adresami. Ostatecznie zrobię zwory na każdym z nich, skoro nie da się inaczej.