Schemat lf Nowy/Sprawdzenie/Poprawa

[BlackSkill]

Jeżeli wszystko zrozumiałem to robię tak.

Kupuję dwa 74HC595 - REJESTRY i dwa CD4051 - MULTIPLEKSERY.

Robię rejestr 16bitowy na płytce czujników ( Na płytce również multipleksery). 10 bitów przeznaczam na sterowanie diodami, a 3 przeznaczam na wybór adresu multiplekserów (Jednocześnie adres będę wysyłał na dwa multipleksery).

Z rejestru mam jeden kabelek mosi jeden do sck i jeden do obojętnego portu aby wysłać sygnał 0-1-0. Z multiplekserów idą dwa kabelki do komparatorów, a z komparatorów na dwa piny procka.

Łącznie idzie 7 kabelków (Jeszcze GND i +5v) z płytki czujników.

Ze strony programowej przez SPI wysyłam równolegle stany 10 diodek oraz adres multiplekserów a następnie "uwalniam" stany z rejestru. Diody "zmieniają swój stan" lub nie ,a na multiplekserach zostaje wybrany adres i dostaję stan dwóch czujników na komparatory , a potem przetworzony sygnał na piny procka.

Pytanka/Stwierdzenia 😃 :

1. Piny Vee Vss i /E (Lub INH jak według ds'a cd4051) multipleksera zwieram do masy .

2. Co z opóźnieniem ? Nie będzie za duże do prędkości dajmy 1,5m/s ? Chodzi mi o odczyt czujników.Wydaje mi się że będzie znacznie dłuższy niż "normalnie".

3. Żeby odczytać dane z czujników muszę 5 razy "napełnić" rejestr.

4. Chyba zwiększę liczbę czujników do 12 bo zostają 3 wolne miejsca w rejestrze.

5. Napisałbyś jak sterować komparatorami z PWM ? Coś mniej więcej wiem , ale ty wiesz na pewno więcej 😃

[marek1707]

Naprawdę jestem pod wrażeniem. Mimo moich mętnych opowieści zrobiłeś całkiem fajny projekt. Tak, to będzie działać 🙂

A teraz o szczegółach. Widzę, że najbardziej obawiasz się o szybkość - no to policzmy. Najpierw, żeby mieć łatwe odniesienie do czasów jakie nam wyjdą, przeliczmy prędkość robota na inne jednostki:

1.5m/s = 660µs/mm

To znaczy, że procesor ma 660us na to, by robot przesunął się o 1mm. Na pierwszy rzut oka - dużo. Z punktu widzenia elektroniki roboty stoją w miejscu?

No to teraz prześledźmy działanie tego SPI-owego zestawu. Jak sam słusznie napisałeś, jeden odczyt stanu czujników w pseudokodzie będzie wyglądał następująco:

for (n=0; n<6; n++)
{
wyślij stan diodek i wartość n jako adres multipleksera
wczytaj stan dwóch linii wejściowych z komparatorów
}

Jeżeli procesor będzie taktowany 8MHz a Ty ustawisz podzielnik tak, by zegar SPI wynosił np. 2MHz (zupełnie przyzwoita i możliwa prędkość) to masz 8*0.5µs = 4µs na bajt. Uwzględniając pewne opóźnienie programu związane z czasem reakcji na gotowość interfejsu możemy założyć, że wysłanie dwóch bajtów to 10µs. Jeżeli w każdej pętli będziesz musiał przygotować dane do wysłania składając jakoś 10-bitowy stan diodek z 3 bitowym adresem to zużyjesz na to pewnie kolejne 2-3µs. Tak więc mamy 13µs plus organizacja samej pętli, razem z gruba 14µs. To razy 5 daje 70µs. Po takim czasie masz zgromadzony w jakiejś zmiennej 16-bitowej stan wszystkich czujników. To dużo czy mało? Biorąc pod uwagę, że wczytanie tego samego z portu równoległego zajęłoby 1us to mnóstwo czasu, ale porównując to do dystansu przebytego przez robota (1.5*70E-6=0.1mm) to jakoś tak mało.

Moim zdaniem zupełnie spokojnie możesz zrobić przerwanie od timera np. 1kHz czy coś koło tego i w nim wywoływać funkcję odczytu stanu czujników. Zakładając nawet jakieś inne operacje wykonywane w przerwaniu (liczenie czasu, obsługa przetwornika ADC) i dociągając czasem wykonania do 100us procesor będzie na to zużywał 10% swojej mocy a dostajesz:

1. Automatyczną modyfikację stanu diodek - wystarczy wpisać coś do np. 16-bitowej zmiennej "diodki" a najpóźniej za 1ms pokaże się to na prawdziwych LEDach bo przerwanie pobierze to i wyśle "najbliższym pociągiem" po SPI.

2. Zawsze masz dostępny w innej zmiennej, np. 16-bitowej "czujniki" aktualny stan czujników. Program może do woli z tego korzystać nie wywołując w kółko jakichś funkcji odczytów.

Jeżeli z jakichś powodów martwi Cię 100µs czas wykonywania przerwania (np. obsługa enkoderów nie może tak długo czekać), to zawsze możesz rozłożyć jedną operację z 5 obrotami pętli na 5 kolejnych przerwań. Po prostu za każdym przerwaniem wysyłasz tylko 2 bajty i wczytujesz 2 czujniki. Co 5 przerwań aktualizujesz globalną zmienną "czujniki" tym co zebrałeś sobie lokalnie podczas 5 ostatnich odczytów. Jeżeli jednocześnie podkręcisz timer do 5kHz, nawet nie zauważysz zmiany opóźnienia.

Gdyby wg Ciebie policzone przeze mnie czasy miały jeszcze jakiś zapas (tzn. gdyby można to było robić wolniej bez straty na czasach reakcji robota) to możesz pójść o krok dalej. Dwa multipleksery mogą przecież pracować na jeden kabelek - od tego mają wejścia INH. Łączysz każe z nich osobno do wyjścia rejestru (teraz będzie już potrzeba 5 linii: 3 na adresowanie i 2 na osobne wejścia INH). Odpowiednio załączając na przemian jeden a potem drugi multiplekser masz zrobiony odczyt czujników po jednym drucie, za to dwa razy dłużej. W tym wypadku jako komparatora możesz użyć tego wbudowanego w procesor. Jest tylko jeden, ale teraz wystarczy 🙂

Z elektronicznym sterowaniem poziomu dyskryminacji komparatora to na pewno się domyślasz. Przebieg PWM ma wartość średnią proporcjonalną do napięcia impulsów i do współczynnika wypełnienia. Napięcie impulsów na wyjściu portu bierze się z zasilania procesora a więc jest stałe ok. +5V. Drugi czynnik sam regulujesz liczbą ładowaną do odpowiedniego rejestru timera, tak więc na wyjściu dostajesz przebieg, którego wartość średnia zależy jedynie od ustawionego wypełnienia. Jeżeli dobudujesz prosty filtr dolnoprzepustowy (np. dwa oporniki i dwa kondensatory) który wytnie prostokąty, zostanie napięcie "stałe". Będzie się trochę wahać - im lepszy filtr zrobisz i im wyższą częstotliwość PWM wybierzesz tym mniejsze będą pozostałości prostokąta, ale tym wolniej napięcie będzie się zmieniać. Ty nie potrzebujesz przebiegów zmiennych (to nie wyjście audio np) więc możesz zrobić prawie dowolnie nisko tnący filtr i tym co z niego wyjdzie karmić komparator(y). Zamiast potencjometru masz regulację z procesora. Możesz teraz zrobić procedurę autokalibracji - stawiasz robota na linii jakby stał na starcie do biegu i naciskając guzik zmuszasz procesor do takiego dobrania poziomu odcinania komparatorów by jak najdalej było od błędów zarówno na białym jak i na czarnym. Niby proste a cieszy 🙂

[BlackSkill]

Dwa multipleksery mogą przecież pracować na jeden kabelek - od tego mają wejścia INH. Łączysz każe z nich osobno do wyjścia rejestru (teraz będzie już potrzeba 5 linii: 3 na adresowanie i 2 na osobne wejścia INH).

3 na adresowanie i jeden z multipleksera 🙂 Czyli 4 do tego gnd i +5v 🙂 I wychodzi 6.

Enkoderów nie będzie bo nie było mnie stać ;/

@edit

Nie mam za bardzo porównania. Czy to na pewno nie będzie za wolno ? W ile czasu wykonuje się program u "klasycznego/normalnego" lf'a z członami regulatora PID ?

[marek1707]

Miałem na myśli druty łączące rejestr z multiplekserami. Tam będzie użytych 5 linii: 3 na jednoczesne adresowanie multiplekserów i 2 na osobne ich załączanie poprzez INH. Gdybyś dospawał jeszcze inwerter na tranzystorze npn, mógłbyś użyć tylko jednego bitu rejestru do wyboru multiplekserów: pierwsze INH sterować wprost z rejestru a drugie INH przez inwerter. Wtedy na diodki zostaje 16-4=12 linii 🙂 a multipleksery są włączane na zmianę w zależności od bitu wyboru. Zabierając jedno wyjście LEDom (i tak jest dużo) można jedna linię przeznaczyć na sterowanie tranzystorem załączającym diody IR w KTIRach. Teraz to procesor będzie panował nad ich załączaniem i zrobi to gdy będzie potrzebował sygnałów z czujników. Można zaoszczędzić trochę prądu a nie zawsze próby robota będą wymagały działania czujników.

Tak, na tasiemce łączącej płytki zostaje 6 linii: 2 zasilania, 1 linia analogowa z multiplekserów, 2 linie SPI (SCK + MOSI) i jeden impuls przepisujący dane na wyjścia rejestrów.

[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

[BlackSkill]

Co do tego inwetera to zostawię to w spokoju . Wiedzę wole przyswajać stopniowo i zobaczyć jak to działa.

Nasuwa mi się tylko pytanie co do tego:

Pierwszy nadawany bajt trafi do rejestru będącego na końcu łańcuszka a ostatni do tego najbliżej linii MOSI. Fajne, prawda?

Rejestr jest napełniany tak jakby od "końca" do "początku" ?

Myślę że to tyle. Reszta wyjdzie w "praniu".

[marek1707]

Dane wysyłane po SPI trafiają do rejestru odbiorczego tak jak pociąg wjeżdża na peron. Lokomotywa (pierwszy nadawany bajt) która jedzie na czele pociągu musi przejechać przez całą długość stacji żeby znaleźć się w sektorze pierwszym. Kolejne wagony wtaczając się na peron "przepychają" poprzednie i wreszcie cały pociąg stoi. Ostatni wagon (ostatni nadawany bajt) znajduje się w ostatnim sektorze - przyjechał na końcu i stanął zaraz na początku peronu, w miejscu skąd najlepiej było widać zbliżający się pociąg (dane na linii MOSI).

Czas wykonywania procedury regulatora PID naprawdę nie jest krytyczną rzeczą w takich konstrukcjach. Owszem, jeśli napiszesz go wprost, używając obliczeń zmiennoprzecinkowych to może zająć nawet i milisekundę, ale to wciąż - w porównaniu z mechaniką, silnikami, trakcją, bezwładnościami itp rzeczami - nie jest wiele. Stałoprzecinkowy, pełny PID opisany w nocie ATMELa:

"AVR221: Discrete PID Controller"

wykonuje się ok. 120us na zegarze 8MHz. Jeżeli założysz sobie czas głównego cyklu obliczeń równy 1ms i w tym nawet 100us zużyjesz na odczyt czujników, to zostaje 900us na zrozumienie co odczytałeś, wykonanie PIDa i przeskalowanie jego wartości wyjściowej na PWMy silników. Trochę czasu potrzeba na obsługę sytuacji specjalnych (np. utrata linii na kącie prostym), ale spoko, wtedy nie wykonujesz kilku innych funkcji. Nie przejmuj się teraz procesorem. Dobierz odpowiednie napędy, kup/odlej dobre opony, przemyśl rozłożenie mas i geometrię pojazdu - TO są kluczowe rzeczy.

Na Księżyc poleciał komputer mający czas cyklu pamięci ponad 10us (100kHz) a niektóre co bardziej skomplikowane instrukcje wykonywał w.. 20ms. Poleciał, wrócił a dziś można podziwiać jego tranzystorowe bramki. Na swoim pokładzie będziesz miał komputer o jakim programistom Apollo nawet się nie śniło. Jeżeli kompletnie nie skopiesz kodu (zawsze można), procesor AVR mogący wykonywać do 16 milionów instrukcji/s zdąży, wierz mi.

[BlackSkill]

Dzięki ci za wszystko ; D Nie wiedziałem że mam tak dobrego kompa 😃 Nie długo będę brać się do roboty ;D

Równolegle będę też robić swoje pierwsze minisumo. Więc jeśli miałbyś ochotę coś ciekawego wtrącić to dodam schemat.

Niepotrzebnie brałem procka z tyloma nóżkami ;/

[marek1707]

Najpierw pokaż kompletny schemat LFa po zmianach. Jest tam jeszcze kilka szczegółów o których warto wspomnieć.

Cieszę się, że się dobrze bawisz 🙂 W końcu o to tu chodzi, nie?

[BlackSkill]

Poprawiłem 😃 Tylko znalazłem taki mały problem. Ugotuję stabilizator 😃 Same diody na płytce czujników ciągną 480mw. Do tego rezystory i wychodzi ponad 1A 😃

Co robić 😃 ? Mogę użyć dwóch stabilizatorów ? Jak zmostkować ? Posiadam ten: http://electropark.pl/stabilizatory-napiecia-liniowe-jednonapieciowe/424-lm1117-5v-1a-stabilizator-napiecia-ldo-to252-5901000424009.html

Schematy:

[marek1707]

Dziwnie liczysz. Przecież sumujesz prądy a nie moce, bo stabilizator widzi prąd pobierany przez obciążenie. Przede wszystkim nie wiem jakie masz diody. Jeżeli już je kupiłeś, to sprawdź jakim prądem musisz je karmić by uzyskać wystarczającą jasność. Rzeczywiście najtańsze LEDy przewlekane pochodzące sprzed kilku(nastu?) lat potrzebują 20mA żeby coś było widać ale obecnie tak nie jest. Diodki SMD wielkości 805 czy nawet 1206 jasno świecą z 1-2mA. Musisz tylko wziąć takie z jasnością kilkuset mcd: kilka przykładów

Chyba nie będziesz nimi oświetlał trasy? Z resztą diody 20mA nie dadzą się zasilać z wyjść układów serii 74HC.

No to mamy 12x2=24mA. Liczmy 30mA na LEDy z przodu.

Do tego KTIRy: tu masz 4 komplety po 20mA czyli 80mA.

Układów 74xxx i 4xxx nie liczę, to jakieś pojedyncze mA.

Płyta główna to procesor (20mA?) jego diodki (12mA), TSOP (kilka mA), komparatory (następne kilka mA) i mostki (podobnie). Moim zdaniem nie wyjdzie więcej jak 200-250mA. Tak, wiele zależy od diodek. Kup jakieś porządne.

Prąd 300mA przy spadku napięcia 8.4-5V=3.4V daje moc ok. 1W na stabilizatorze. I tak będzie potrzebny niezły radiatorek z miedzi wokół scalaka.

Łączenie równoległe stabilizatorów nie jest wskazane, bo przecież nigdy nie będą miały równych napięć wyjściowych. Tak więc w miarę wzrostu prądu najpierw będzie pracował jeden aż do przeciążenia a dopiero potem podejmie pracę drugi. Mógłbyś dać rezystory wyrównujące na wyjściach (np. 0.1R), ale lepiej już rozdzielić obwody, np. dać jeden na płytę główną a drugi na czujniki. Na szczęście to nie jest ten przypadek.

Dobra, a teraz o poważniejszych rzeczach.

Komparatory nie umieją przetwarzać napięć bliskich ich zasilaniu. Jeżeli na wejściu spodziewasz się 5V (a tak będzie przy czujniku widzącym ciemność) musisz je zasilać wprost z baterii lub ograniczyć napięcia wejściowe.

Każdy układ cyfrowy wymaga blokowania zasilania kondensatorem. Oprócz procesora masz teraz rejestry przesuwające i każdemu należy się 100nF. Oprócz tego na płytce czujników powinno znaleźć się min 10uF choćby z uwagi na SHARPa. Nie zaszkodzi więcej, ale w granicach rozsądku (10-47uF). Multipleksery przeżyją bez swoich kondensatorów, oczywiście możesz im także dać po 100nF.

Wysyłając sygnał w długi kabel (a tasiemka do czujników już taki zaczyna przypominać) musisz zadbać o spójność sygnałów. W szczególności dotyczy to sygnału zegarowego SCK, bo przecież rejestry 595 są czułe na zbocza. Nie chcesz przecież, by za każdym zegarem SCK przesuwały o 2 lub więcej bitów, prawda? Długi kabel to odbicia z powodu niedopasowania nadajników i odbiorników do impedancji linii przesyłowej. Przy procesorze wstaw między jego piny SCK, MOSI i STCP a złącze tasiemki oporniki szeregowe 33R. To powinno pomóc.

Jak rozumiem rezygnujesz z elektronicznego ustawiania napięcia odcięcia komparatorów. To tylko napisz czy z powodu obaw, że tego nie ogarniesz (a PWM do silników będzie? bo to to samo), czy że nie wiesz jak to narysować. Jeżeli to drugie - nie ma problemu, zaraz coś wymyślimy.

Bardzo dobrze się stało, że obie linie analogowe z multiplekserów idą po tasiemce wzdłuż masy i wyjścia SHARPa. Nie zmieniaj tego, a w szczególności pod żadnym pozorem nie puszczaj ich obok cyfrowych SCK i MOSI.

O histerezie komparatorów następnym razem 🙂

[BlackSkill]

Co do diodek to brałem http://electropark.pl/led-smd-0805/453-dioda-led-zielona-120-0805-5901000453009.html

I policzyłem sobie 12 razy 20mA itd. Głupi ja 😋

Komparatory podłączyć tak ?Nie będzie z tego żadnych zakłóceń ? Dorzucić tam 100nf ? Rozumiem że potencjometr zostawiam w spokoju bo steruję nim tylko "próg" wykrywania lini.

Kondensatory ceramiczne do układów dodałem. A co do elektrolita 10uF nie może on być na płytce głównej ? Przy wejściu tasiemki ?

Nie rozumiem jak wstawić mam oporniki SCK, MOSI i STCP. Szeregowo ?

Co do pwm do komparatorów myślę że nie ogarnę. Potencjometr nie jest zły 😋

@edit

Nie wiem czy zauważyłeś i nie wiem czy będzie dobrze. Rejestr podłączyłem pod mosi inne niż to do programowania (Nie wiem jak to nazwać). Według noty katalogowej niby mogę przez to również wysyłać dane. O ile dobrze to zrozumiałem.

[marek1707]

To nie są najlepsze na świecie diodki, ale już w miarę. Sprawdź prąd przez dobranie opornika przy 5V z jakiegoś zasilacza tak, żeby świeciła jak Ci się podoba a potem wlutuj na całą płytkę. Wszystkie będą zielone? Bo każdy kolor ma inne napięcie przewodzenia i będzie płynął inny prąd przy tym samym oporniku. No i jasność odczuwalna może być przy innych kolorach (i tym bardziej prądach) inna.

Komparatory możesz tak podłączyć. Daj jeszcze 100nF między środek potencjometru a masę oraz 100nF na zasilanie 339.

Po to dajesz kondensator tuż przy scalaku, by ten mógł czerpać z niego prąd gdy nagle tego potrzebuje. Dlatego 100nF muszą być bardzo blisko a wspólny 10uF tylko blisko. Jeżeli dasz go po drugiej stronie tasiemki to równie dobrze może go nie być w ogóle.

Ma być tak: pin procesora - odejście w bok do złącza programatora - szeregowy opornik 33R - złącze taśmy.

Tak, potencjometr nie jest zły.. 😐 Histerezę Ci odpuszczam, bo zaczynam czuć zmęczenie materiału. Jeżeli się mylę, daj znać.

No a teraz o uruchamianiu kodu i całego robota. Czy już rozmawialiśmy o złączu UART? Czy już wiesz jak będziesz podglądał zmienne w programie? Jak planujesz pisanie, debugowanie i testowanie programu? Wypisywanie w oknie terminala PC informacji z wnętrza programu to naprawdę fajna sprawa. Na razie zmarnowałeś nóżki komunikacyjne na diodki WSKAŹNIK, ale wciąż możesz je przesunąć gdzie indziej - to duży procesor 🙂

EDIT: Spoko, podłączyłeś dobrze - to jest jedyne prawdziwe MOSI wewnętrznego interfejsu SPI dostępnego dla programu. PDI i PDO służą tylko do programowania i tylko z rozpędu nazywamy je MISO/MOSI, bo tak nazywają się linie programatora.

[BlackSkill]

Diody nie będą wszystkie takie same. Jeszcze wybiorę. Ważne żeby pokazywała stan czujnika .

Połączenia miso,sck,stcp:

Co do histerzy , jeśli nie jest to bardzo ważne mógłbym na razie odpuścić, trochę dużo materiału naraz.

Bardzo interesuje mnie ten UART ,wiem że mógłbym widzieć co się dzieje w programie jak zachowują się czujniki. Bardzo fajna sprawa widziałem u innych na Robotic Area. Tylko jest taki mały problem nie wiem jak za to się zabrać, jak to działa... Wiem ze jest interfejs RS-232 ale co dalej 😋 A co do pisania programu to napiszę i ma działać 😃

[marek1707]

Połączenia oporników 33R są OK. To taka mała magia, ale warto o niej pamiętać przy wysłaniu sygnałów cyfrowych na większe odległości.

Kondensator C14 powinien być między środkiem potencjometru (pin 3) a masą. Teraz dałeś go po prostu na zasilaniu a ma filtrować napięcie odniesienia komparatorów.

Na pewno jest mnóstwo Kolegów którzy podzielą się z Tobą informacjami o sposobie podłączenia i używania UARTów. Generalnie to bardzo stary (dalekopisy, 50 bitów/s), ale wciąż używany interfejs komunikacyjny. Masz takie coś w procesorze (a nawet dwa niezależne), więc jeden z nich możesz przeznaczyć na dogadywanie się np. z komputerem. Po odpowiednim zaprogramowaniu obu stron (musisz ustawić takie same prędkości bo nie przesyłamy zegara, tylko bajty danych) wysyłanie sprowadza się - podobnie jak w SPI - do załadowania kodu znaku do odpowiedniego rejestru i poczekania aż się samo wyśle. Chociaż UART łyka i wysyła cokolwiek mu każesz, żeby druga strona (np. program terminalowy w PC) pokazała to jako sensowny tekst, musisz wysłać bajty zgodne z tzw. kodem ASCII:

http://www.asciitable.com/

Dalej to już prosto: jeśli chcesz napisać na ekranie komputera "Hej", wysyłasz kolejno 0x48, 0x65 i 0x6A. Ponieważ kompilatory C także pracują w ASCII 🙂 nie musisz kombinować z kodami szesnastkowymi - wystarczy podefiniować w programie odpowiednie napisy jako stałe, a potem je wysyłać. No ale to już wykład o C.

Wszystkie kody poniżej spacji (czyli 0x00..0x1F) znaczą dla terminala coś specjalnego, np. przesuwają kursor do nowej linii, cofają o 1 znak itp - warto je znać.

UART może oczywiście zgłaszać przerwania. Dostajesz je od nadania znaku (znaczy, że nadajnik jest pusty i możesz załadować kolejny znak) i od odebrania znaku (znaczy, że coś przyszło z komputera i możesz to odczytać z rejestru danych UARTa).

PC działa z pewnymi typowymi prędkościami i musisz mieć możliwość ustawienia takiej samej u siebie. UART ma rejestr do którego wpisujesz podzielnik zegara procesora, więc zwykle daje się znaleźć taką liczbę, żeby dawała odpowiednią prędkość. Jest oczywiste, że im wyższa prędkość tym trudniej bo liczby robią się coraz mniejsze i rosną błędy zaokrągleń. Acha, ten interfejs w PC używa standardu RS232 a to oznacza, że wysyła do Ciebie sygnał ±12V i Ty musisz robić to samo w drugą stronę. Absolutnie nie możesz linii RS232 podłączyć wprost do procesora. Na szczęście są odpowiednie scalaki do konwersji w obie strony, np. MAX202 i cała masa podobnych. Od biedy konwersję można to zrobić na dwóch tranzystorach.

Ostatnio komputery nie mają już portów COM (tak się nazywały) więc i protokół UART trochę odszedł w zapomnienie. Na szczęście pojawiły się tanie przejściówki z USB na UART. Niektóre silą się na zgodność z dawnymi czasami (i urządzeniami) i po stronie UARTa mają sygnały prawdziwego RS232 (czyli ±12V) a inne są prostsze i wypuszczają sygnały 0-3V lub 0-5V. Taka byłaby idealna. Oczywiście są też scalaki robiące takie przejście, np. FT232R. Z jednej strony wchodzisz swoim UARTem (dwa druty z procesora) a drugiej stronie masz USB pasujące wprost do PC. Co ciekawe oprogramowanie PC widzi to jak zwykły port COM więc i program terminalowy "myśli", że rozmawia z kimś przez taki port - bo tylko przez taki umie. I wszyscy są zadowoleni 🙂

[BlackSkill]

Marku brakuje mi takiej podstawowej wiedzy z zakresu avr i programowania na nie. Warto kupić jakąś ksiażkę ? Polecasz jakieś źródła z internetu ?