Wpis z mikrobloga

@atehxx: @zetisdead: Tak, komunikacja ma być dwustronna. UART może być o tyle problematyczny, że atmegi już go wykorzystują w celu komunikacji z innymi układami, więc pomiędzy nimi bym musiał robić jakiś dodatkowy SoftwareSerial, czy coś takiego. A po I2C nie mógłbym non stop wysyłać zapytania czy nie ma nowego info dla mastera? Czy to się raczej nie opłaca?
@zwei: na pinach mi nie zależy, natomiast potrzebuję, żeby to była
@mikson123: Po co komplikować życie? I2C jest do takich rzeczy... Masz hardware I2C w uC i nic cie nie obchodzi. Jeden i tak musi być masterem i odpytywać inne, niezależnie czy użyjesz i2c czy zrobisz sobie jakiś inny wynalazek.
UART nie zrobisz bo to jest 1-1 komunikacja.
Możesz jeszcze pospinać wszystko w gwiazdę - tyle portów ile uC-1 podpiąć do różnych portów tych innych uC i tak każdy z każdym na
Jak najlepiej zrealizować komunikację pomiędzy kilkoma atmegami na jednej płytce drukowanej?


@mikson123: wszystko zależy co i w jakiej prędkości i ilości mają wymieniać między sobą. Czy tylko synchronizacja wartości, czy bardziej interaktywna komunikacja itd.

Jak chcesz egzotycznei to możesz np. spiąć 1:1 każdą z każdą w pętli na pinach /INT - i podłączyć pod wspólną magistralę (i2c czy uart). Każdy avr wysyła co ma wysłać na magistralę (i wszystkie tego słuchają,
via Wykop Mobilny (Android)
  • 0
UART nie zrobisz bo to jest 1-1 komunikacja.


@atehxx: nie jest. Nadawca jest jeden, odbiorców może być wielu. Wystarczy zrobić iloczyn nadajników (bramkami AND, diodami lub iloczyn na drucie jeśli wyjścia TXD mogą pracować jako OC) i dorobić detekcję kolizji. Albo połączyć nadajniki i odbiorniki w pierścień.
via Wykop Mobilny (Android)
  • 0
@atehxx: jak ustawienie wyjścia TXD jako OC i połączenie wielu wyjść drutem jest zbyt skomplikowane to są prostsze zajęcia. Nie każdy musi być elektronikiem.