logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

Jak najlepiej zrealizować komunikację Atmega32 z 6x Atmega8 w Bascom? SPI czy I2C?

smithpl 24 Maj 2009 20:30 2163 8
REKLAMA
  • #1 6570199
    smithpl
    Poziom 15  
    Posty: 186
    Witam,

    mam plan ktory powoli wdrazam.

    Projektuje sobie pod układy działające niezależnie w oparciu o atmega8, atmega161, atmega32. Jednak podczas projektu chciałbym uwzględnić opcje wymiany danych do punktu centralnego który też zaprojektuje w oparciu o Atmega32.

    Docelowo liczę 6-8 niezależnych urządzeń spiętych do punktu centralnego który to będzie komunikował się z komputerem.

    Głównie będzie to odczyt danych z końcówek do punktu centralnego który będzie je przechowywał. Komunikacja w drugą stronę będzie zawierać jedynie informacje zmiany parametrów zmiennych.

    Wszystkie końcówki i moduł centralny będą połączone kablem maksymalnie 0,5 - 1 metr (chyba że to problem to może być maksymalnie 0,5m)

    W tym momencie chciałbym od osób bardziej zorientowanych uzyskać informacje jak je między sobą komunikować programując w Bascomie?
    SPI? UART( to raczej odpada )? I2C ?

    Dzieki za wsparcie, nie chciałbym wyważać otwartych już drzwi :-)

    Fajnie by było jakby urządzenia podpinać w oparciu o magistrale równolegle..
  • REKLAMA
  • #2 6570297
    Dawid_20
    Poziom 17  
    Posty: 184
    Pomógł: 21
    Ocena: 25
    Większość osób zaproponowało by RS-485, ja jednak bardziej bym namawiał na SPI, chodź by dla tego, że nie potrzebne są żadne dodatkowe układy do fizycznej realizacji transmisji. Przy SPI można niejako "sprzętowo" uniknąć kolizji na magistrali wykorzystując linie SS, czyli mamy z głowy programową obsługę arbitrażu. Dla przykładu: układy pracują w trybie multi-master, wszystkie układu nasłuchują magistrali(linia SS ma stan wysoki). Gdy któryś chce nadawać sprawdza czy inny tego nie robi badając właśnie linie SS, gdy cały czas jest na wysokim, to on wprowadza ją w stan niski zajmując magistrale(tutaj jest gwarancja że każdy pozostały układ nie wetnie nam się w transmisje). Ja robiłem małą sieć na czymś takim i polegało to na tym, że każdy był konfigurowany jako slave, a gdy chciał nadawać to rekonfigurował się na mastera, a po zakończeniu nadawania znowu na slave. Linia MISO w ogóle nie była wykorzystywana.
  • REKLAMA
  • #3 6570664
    janbernat
    Poziom 38  
    Posty: 3954
    Pomógł: 468
    Ocena: 51
    Jeśli można "poświęcić" 6 końcówek w Atmega32 na "SS"-to rozwiązanie Dawid_20 jest dobre.
    Szybkie i proste.
    Jeśli końcówek mało-I2C-podrzędne procesory jako "slave"
    Coś za coś.

    Dodano po 4 [minuty]:

    "Fajnie by było jakby urządzenia podpinać w oparciu o magistrale równolegle.."
    Ale to jest najbardziej klasyczne rozwiązanie.
    Na Atmega8515-szyna danych.

    Dodano po 1 [minuty]:

    I zatrzask i dekoder.
  • #4 6571052
    Dawid_20
    Poziom 17  
    Posty: 184
    Pomógł: 21
    Ocena: 25
    Cytat:
    Jeśli można "poświęcić" 6 końcówek w Atmega32 na "SS"-to rozwiązanie Dawid_20 jest dobre.
    Szybkie i proste.
    Jeśli końcówek mało-I2C-podrzędne procesory jako "slave"
    Coś za coś.


    No właśnie ja proponuje trochę inaczej niż klasyczny układ z wyborem sleva przez końcówkę SS. Wszystkie układy nasłuchują(SS jest wolne), gdy jeden chce nadawać to ją zajmuje, inny układ nie ma prawa wtedy nadawać(a gdy chce to czeka aż magistrala zostanie zwolniona). Nie ma tu konkretnego mastera, a identyfikacja układów opiera się o jakiś zapisany adres(choćby nawet 1 bajt), ale to już szczegóły zawarte w ramce wiadomości. Ogólnie preferuje sieć multi-master(bardziej elastyczne w rozbudowie i działaniu), niż odpytywanie przez jeden układ(pada master to pada wszystko). Ale jeżeli to ma być coś prostego i małego to chyba byłby to trochę przerost formy nad treścią:)
  • REKLAMA
  • #5 6571212
    smithpl
    Poziom 15  
    Posty: 186
    Dzięki za wstępne info,

    akurat w tym wypadku będzie to tak ze układy będą działały same, kontakt z układem centralnym będzie tylko zbierał dane lub dystrybułował zmiany konfiguracji poszczególnych nodów.

    Brak komunikacji z układem centralnym nie powinien wpływać na prace slave'ow

    Na koniec dodam ze układ 3-4 żyłowy jest o tyle idealny ze nie mamy ograniczeń ilości nodów ilością nóżek procka, wiec wolałbym wyeliminować sytuacje ograniczeń ilości slave'ow na podstawie ilości wolnych wyprowadzeń...
  • REKLAMA
  • #6 6574412
    janbernat
    Poziom 38  
    Posty: 3954
    Pomógł: 468
    Ocena: 51
    Dawid_20-zrobiłeś to w Bascomie?
  • #7 6575576
    Dawid_20
    Poziom 17  
    Posty: 184
    Pomógł: 21
    Ocena: 25
    Robiłem to w C, jakoś staram się unikać bascoma.
  • #8 6576736
    adambehnke
    Poziom 24  
    Posty: 882
    Pomógł: 23
    Ocena: 40
    Pozwolicie że się wetnę w temat.Mnie także interesuje taka wymiana danych.Jak by to miało wyglądać bardziej szczegółowo. Jakiś przykład -schemat podłączenia i może jakiś kodzik dla przykładu? Ja niestety w Bascomie.Ja chciałbym się komunikować między jednym urządzeniem Z atmegą32 a PC.
  • #9 6578485
    janbernat
    Poziom 38  
    Posty: 3954
    Pomógł: 468
    Ocena: 51
    Tak smithpl masz takie możliwości:
    Nauczyć się ASM i napisać program(y).
    Nauczyć się C i jak wyżej.
    Użyć Bascomowych "gotowców" do SPI poświęcając ileś nóżek procesora master-SPIslave są w standardzie Bascoma.
    Kupić Bascomową bibliotekę I2Cslave, zainstalować i spróbować z procesorów podrzędnych zrobić "slave-y"-to pozwala na użycie tylko dwu końcówek mastera.

Podsumowanie tematu

✨ Dyskusja dotyczy wyboru najlepszej metody komunikacji między mikrokontrolerem Atmega32 a 6-8 układami Atmega8 w środowisku Bascom. Głównym celem jest wymiana danych pomiędzy niezależnymi urządzeniami a centralnym punktem opartym na Atmega32, z komunikacją na odległość do 0,5-1 metra. Rozważane są interfejsy SPI i I2C, z wykluczeniem UART. Propozycje wskazują na preferencję SPI ze względu na prostotę sprzętową i brak konieczności dodatkowych układów, a także możliwość sprzętowego uniknięcia kolizji na magistrali poprzez wykorzystanie linii SS. Sugerowane jest podejście multi-master, gdzie każdy układ może przełączać się między trybem slave i master, zajmując magistralę poprzez linię SS, co eliminuje potrzebę arbitrażu programowego. Wskazano, że linia MISO może pozostać niewykorzystana. Alternatywnie, gdy liczba dostępnych linii SS jest ograniczona, można rozważyć I2C z układami slave, co pozwala na komunikację przy użyciu tylko dwóch przewodów, ale wymaga poświęcenia funkcjonalności i jest bardziej złożone programowo. Autor projektu preferuje rozwiązanie 3-4 żyłowe, aby nie ograniczać liczby nodów liczbą wolnych pinów procesora. W Bascomie dostępne są gotowe biblioteki SPI i I2C slave, co ułatwia implementację. W dyskusji pojawiła się także sugestia RS-485, jednak ze względu na prostotę i brak dodatkowych układów, SPI jest rekomendowane. Przykłady implementacji w Bascom są poszukiwane, choć jeden z uczestników realizował podobny projekt w języku C.
Podsumowanie wygenerowane przez AI na podstawie treści dyskusji.
REKLAMA