Podłączenie attiny do atmega

[matt90]

W jaki sposób mogę podłączyć płytkę z procesorem attiny do płytki z procesorem atmega? Chciałbym aby na attinie były podłączone czujniki i po wykryciu obiektu dawały sygnał na główną płytkę z atmega. Czy da się tak zrobić?

[Tolo]

Owszem można to zrobić na wiele sposobów poczytaj o USART

[matt90]

A jakiś inny i prostszy sposób?

[Carpe Diem]

Użyć zwykłych I/O - proste ale chyba mija się z celem dorzucania drugiego procka.

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[Tolo]

Nie wiem w czym piszesz ale w BASCOMIE USART to raptem dwie trzy linijki kodu ...

[marek1707]

USART, USART.. Trzeba ten USART mieć. Jeden z wymienionych procesorków owszem ma ale drugi nie i wtedy jego implementacja to nie są już trzy linijki kodu.

Poza tym moim zdaniem USART jest zbyt cennym zasobem - tym bardziej, że jest zwykle tylko jeden, by marnować go na komunikację między procesorami gdy z drugiej strony i tak trzeba się narobić. Ja bym go zostawił na komunikację z PC i debugowanie. System dwuprocesorowy uruchomić jest o wiele trudniej niż jedno- i dlatego wszelkie wsparcie bardzo się na etapie tworzenia kodu przyda.

Pozostaje SPI - w ATtiny jest USI - który od biedy może prawdziwe SPI udawać.

Można też zrobić to całkowicie programowo i tu nie ma jakiegoś cudownego przepisu. Trzeba tylko wyobrazić sobie jak informację przesyłać a potem to zaimplementować w oprogramowaniu. Może być synchronicznie, może być asynchronicznie, można próbować coś podobnego do I2C (tylko dwa druty) albo jeszcze inaczej.. Poza tym nie rozumiem tej tendencji do oszczędzania i krojenia jednostkowo wykonywanych projektów dokładnie na miarę. Jeśli porównasz ilość roboty, jaką włożysz w system dwuprocesorowy z tym, jak szybko i bezboleśnie odpalisz jeden trochę większy procek to przestaję rozumieć. Czemu to ma służyć? Nauce? Na etapie na którym jesteś masz wiele innych, pilniejszych rzeczy do nauczenia się. Oszczędności kasy? Sorry ale dwa procki nie będą tańsze niż jeden troszkę większy a nawet dlaczego nie zrobić tego na jednej ATmedze? Za mało drutów? To dokup multiplekser za 50 groszy i masz tyle wejść ile dusza zapragnie. Analogowych albo cyfrowych, do wyboru. Że będziesz musiał go obsłużyć? Wysłać dodatkowe 3 bity na port? Bez przesady, i tak miałeś się czegoś uczyć. Stara zasada: jeśli masz młotek to spraw, by Twój problem wyglądał jak gwóźdź. Jak wspomniał tu już Kolega, nie porywaj się na dwa procesory skoro do podłączenia kilku czujników wystarczy trywialny układzik z kiosku za rogiem. Nie wstawiaj na siłę dwóch procków skoro ledwo ogarniasz problem z jednym. Świat nie kończy się na procesorkach AVR. Ludzie już dawno wymyślili mnóstwo fajnych układów scalonych, które nie potrzebują programowania a spełniają wiele pożytecznych funkcji. Prawie na pewno wśród rodzin 740xx lub 4xxx znajdą się takie, które Tobie przypasują w każdej prostej funkcji logicznej. I nie wymagają pisania programu, złącza programatora itd..

Podział funkcji w większym systemie na mniejsze procesory jest fajny i przejrzysty tylko pierwszego dnia i dobrze wygląda tylko na schemacie. Ten robi silniki, ten czujniki a ten odpowiada za wyświetlacz. Bzdura. Osobno tak, łatwo takie klocki popełnić ale za chwilę okaże się, że zysk (na prędkości? prostocie kodu?) zostaje całkowicie zjedzony przez poświęcenie drutów na połączenia, zjadanie cennych zasobów na komunikację, narzuty czasowe na transmisje, protokoły połączeń, obsługę błędów, formatowanie danych, sumy kontrolne itd itp. Owszem, jestem w stanie wyobrazić sobie zadanie, które wymaga pełnej mocy obliczeniowej (lub np. wszystkich timerów lub PWM) i po prostu nie zostaje już nic na resztę zadań a w dodatku moduł robi ktoś w większym zespole - OK. Wcześniej dogadujemy się co do zasilania, sposobów komunikacji, formatu danych i każdy równolegle grzebie na swoim biurku ale tutaj?

Napisz dokładnie o jakich czujnikach myślisz i co to za projekt a prawie na pewno okaże się, że jeden procesor obsłuży to "w międzyczasie" i jeszcze w IDLE trochę postoi, cenny prąd oszczędzając.

EDIT: literówki, chyba jeszcze się nie obudziłem...

[matt90]

Masz racje, nie bede się w to bawił bo nie ogarnę tego i szkoda czasu, muszę zrobić nową płytkę z większym prockiem i wszystko na jednego wsadzić 😉

[Tolo]

W sumie nie został podany typ procesora ale wydawało mi się że chodzi o Attiny 2313 a on owszem ma USART...

[matt90]

Chodziło o Attiny 13A. Niestety nie dam rady podłączyć tego do tego samego procka co roszta, bo ma to być czujnik który steruje nateżeniem diody za pomoca PWM, a w głównej płytce wyjścia PWM'a mam zajęte przez silnik. Więc zostaje tylko USART? Multiplekser w tym przypadku nic nie pomoże, prawda?

[marek1707]

Multiplekser był tylko przykładem. Nie jest oczywiście lekarstwem na każdą przypadłość 🙂

Nie wiem czy istnieje ATmega mająca tylko dwa wyjścia PWM, więc może najpierw napisz o czym dokładnie mówimy a dopiero później zaczniemy się zastanawiać jak rozwiązać Twój problem. Nie bardzo rozumiem też zdanie:

"ma to być czujnik który steruje nateżeniem diody".

Czujnik steruje natężeniem diody? Czujnik to raczej coś wykrywa ale może ten ma jakąś diodę (nadawczą? oświetlającą?) i to jej jasność chcesz zmieniać, tak? Zwykle te bardziej skomplikowane czujniki pracują jakimś swoim rytmem i oświetlanie im obiektów za pomocą mrugającej diody nie jest dobrym pomysłem. Podobnie proste czujniki optyczne w których sygnał "powrotny" obsługiwany jest przez ADC procesora też nie bardzo chciałyby dostać oświetlenie PWM. Napisz dokładnie co to ma być za czujnik i jaką rolę pełnić w Twoim urządzeniu. Być może trzeba będzie diodę sterować prądem stałym, liniowo zależnym od czegoś wychodzącego z procesora.

[matt90]

Chcę zrobić zabawkę która reaguje na zbliżenie się ręki do niej, zbudowałem czujnik optyczny ktorego schemat znalazłem tutaj na forum, ale oparty jest on o attiny13A, a moja zabawka na Atmega8, więc na wyjściu PWM mam podłączone silniki i nie mam gdzie podpiąć tego czujnika, który też potrzebuje PWM'a

[sailo]

Zawsze możesz zamienić mikrokontroler na Atmega88, który posiada więcej kanałów PWM. Kolejnym rozwiązaniem jest napisanie programowej obsługi PWM z wyjściem na dowolnym pinie I/O - jest to zdecydowanie mniej skomplikowane i tańsze rozwiązanie niż korzystanie z dwóch mikrokontrolerów.

[marek1707]

Acha, to teraz już rozumiem. Rozumiem też, że przeczytałeś cały artykuł o tym czujniku i wiesz, że procesor jest tam używany jako zwykły generator przebiegu prostokątnego o określonej częstotliwości. Częstotliwości takiej, by leżała w paśmie odbieranym detektora podczerwieni SFH_cośtam, czyli ok. 36kHz. Nie ma tam mowy o żadnym "PWM" na diodzie IR a sygnał wyjściowy z czujnika nie jest w żaden sposób obrabiany tylko przenoszony co jakiś czas z wejścia na wyjście procesora. Opóźnienie wstawione przez Autora w żadnym stopniu nie eliminuje zakłóceń tylko zmienia ich charakter. Co innego jakiś filtr dolnoprzepustowy ale tego w rozwiązaniu zabrakło.

Co możesz w tej ciekawej sytuacji zrobić? Mam kilka pomysłów:

1. Mając już na pokładzie procesor ATmega8 masz do dyspozycji Timer2 wyposażony w możliwość sprzętowego generowania faili prostokątnej. Wystarczy podpiąć - najlepiej przez tranzystor - diodę nadawczą IR do wyjścia OC2, zaprogramować odpowiednio timer i załatwione.

2. Możesz zbudować "na piechotę" odpowiedni generator. Narzucającym się tu rozwiązaniem jest słynny układ 555 którego tysiące aplikacji leżą w sieci ale Tobie wystarczy najprostszy generator astabilny z przerysowany wprost z karty katalogowej producenta. Zaletą tego rozwiązania jest to, że zwykle układy 555 mają całkiem niezłe wyjście, mogące wysterować np. 200mA co spokojnie wystarcza do bezpośredniego napędzenia diody IR. Oczywiście generatorów jak mrówków - możesz zbudować na tranzystorach, bramkach cyfrowych typu 74HC00 itd. Tylko brać i wybierać. No i nie pochłania wyjścia procesora a ATmega8 zbyt dużo ich nie ma. Wyjście OC2 może posłużyć do generowania np. jakichś dźwięków i tym samym uatrakcyjnić Twoją zabawkę o odgłosy R2D2 itp

3. Zrobić detekcję synchroniczną - było już o tym na Forum. Zwykła dioda IR zapalana ze zwykłej nóżki procesora (jak zwykle przez tranzystor) plus zwykły fototranzystor na wejściu ADC jako czujnik i prosty algorytm korelacji odbieranych wyników z zapalniem diody nadawaczej IR. Raczej odporne na niewielkie zakłócenia ale z uwagi na brak automatyki wzmocnienia podda się przy próbie "bezpośredniego trafienia" Słońcem lub silnym źródłem śmiecia np. lampami wyładowczymi.

4. Użyć innego czujnika, np. mierzącego odległość analogowo. Robi to autonomicznie, nie trzeba niczego dodatkowo oświetlać a wyjście analogowe, po zmierzeniu przez ADC mogłoby dać ciekawsze reakcje w zależności od odleglości. Robot mógłby być "zaskoczony" i "zdenerwowany" gdyby ręka z nienancka zbliżyła się za bardzo a spokojny lub nawet "chętny do zabawy" gdyby odległość była w "strefie komfortu psychicznego". Nie wiem jaki jest cel tego projektu ale rozwiązań może być wiele.

Może ktoś ma jeszcze jakieś pomysły? Pomijam rozwiązania "stałoprądowe" bo te z definicji nieodporne są na oświetlenie zewnętrzne itp.

[matt90]

Głównym założeniem jest to żeby koszt czujnika był jak najniższy, a sharp analogowy to jest ok.40 zł, a ten oparty na diodzie IR i TSOP-ie to ok.10zł. Wejście OC2 to też MOSI, czy nie będzie przeszkadzało zaprogramowanie Timera do diody, bo chce programować procka przez ISP? 3 sposób wydaje mi się w miarę prosty, diodę IR podłączam do jakiejkolwiek nóżki procka, a TSOP do ADC i wtedy to wyjście ADC programuję na częstotliwość 36kHz?

[marek1707]

Najniższy, ale czujnik ma spełniać pewne wymagania. Tylko Ty je znasz i jeśli nie potrzebujesz pomiaru analogowego to nie ma sensu wstawiać coś na siłę. Z drugiej strony byłoby to istotne rozszerzenie możliwości pomiarowych więc może warto to przemyśleć.

A wracając do pozostałych opcji. 36kHz dla diody oświetlającej musisz generować tylko wtedy, gdy użyjesz jako detektora jakiegoś układu dedykowanego do sterowania podczerwienią, np. już tu wymienionego SFH. Tam w środku jest kilka fajnych rozwiązań które nie tylko poprawiają czułość (a więc i zasięg przy danej mocy promieniowanej) ale też zwiększają odporność na zakłócenia. Właśnie zakodowanie sygnału IR jako fali 36kHz jest jednym z takich pomysłów bo ani w świetle słonecznym ani w tym co dają żarówki czy świetlówki raczej nie ma takiej częstotliwości. Wśród tego wszystkiego co będzie przychodziło do jego fotodiody odbiorczej, SFH będzie poszukiwał sygnału 36kHz i jeśli go nie będzie, wyśle do procesora stan wysoki. Jak poziom sygnału 36kHz przekroczy pewien próg, procesor dostanie stan niski. Ponieważ jednak układy te są dedykowane do przesyłania podczerwienią pewnych komend a nie tylko stałego sygnału "jest-nie ma", mają wbudowane też pewne ograniczenia. W każdym razie wybierając konkretny odbiornik IR warto sprawdzić, czy może pracować z sygnałem ciągłym 36kHz. Czasami, żeby dobrze działało trzeba będzie tę falę jakoś przerywać np. kilkadziesiąt razy na sekundę ale w sumie nie jest to jakaś wielka trudność.

Podłączając diodę nadawczą do OC2/MOSI (oczywiście przez tranzystor 🙂 ) możesz zrobić dwie rzeczy: zapomnieć o problemie i mieć jedynie swiadomość, że Twoja dioda świeci (mruga) gdy programujesz procesor albo wymyślić proste zabezpieczenie po to, by tak się nie działo. Podpowiem, że wystarczy jedna zwykła dioda w odpowiednim miejscu i Twój nadajnik IR będzie martwy gdy programator będzie gadał z procesorem. Dopiero po ruszeniu procesora, zaprogramowaniu tego pinu jako wyjście oraz odpowiednim ustawieniu Timera2 tranzystor się załączy i generacja fali 36kHz wystartuje. Przypominam o ewentualnej konieczności częstego przerywania nadawania tej fali - to już wyczytasz w danych konkretnego odbiornika IR. Możesz to prosto zrobić na jakimś przerwaniu od "wolnego" timera. Może Ci jeszcze jakiś został.

Co do sposobu trzeciego to chyba nie zrozumiałeś. Pomysł opiera się na tym, że diodę IR podłączasz jak zwykle do procesora przez tranzystor. Nie musisz mieć żadnych 36kHz bo to jest potrzebne przy stosowaniu specjalnego odbiornika. Tutaj wstawiasz zwykły (tani) fototranzystor jako odbiornik i podłączasz go do któregoś wejścia ADC. Teraz robisz tak: załączasz diodę IR - normalnie przez wysłanie jedynki na port, mierzysz co widzi fototranzystor i zapamiętujesz to. Teraz wyłączasz nadawanie IR (wysyłasz 0 na port) i znów mierzysz a potem obliczasz różnicę wyników pomiarów i tak w kółko. Jeśli różnica jest zerowa lub jakaś bardzo mała to fototranzystor praktycznie nie widzi tego co nadaje dioda IR czyli: przeszkody/odbicia nie ma. Jeśli natomiast różnica wyjdzie odpowiednio duża to znaczy, że pomiary zmieniają się synchronicznie z tym co nadajesz a więc jest jakieś optyczne sprzężenie nadajnika z odbiornikiem czyli: odbicie. W tej metodzie stałe oświetlenie nie przeszkadza bo dla procesora ważna jest różnica a nie wielkość bezwzględna pomiaru. Stałe zakłócenie (np. światło z okna) spowoduje wzrost obu wyników ADC ale różnica pozostanie nadal mała. Twoim zadaniem będzie tylko eksperymentalne dobranie wielkości progowej tej różnicy, powyżej którego uznasz, że przeszkoda jest wykryta.

To ciekawe, że temat o dwóch procesorach sprowadził się do prostego podłączenia czujnika IR..