Jednym z najbardziej popularnych interfejsów komunikacji jest RS-232. Większość mikrokontrolerów wyposażona jest w co najmniej jeden taki moduł.
Podstawową zaletą RS-232 jest możliwość komunikacji na duże odległości nawet ponad jednego kilometra. Wadą natomiast radykalnie zmniejszająca się przepustowość łącza, wraz ze wzrostem odległości. Coś, za coś :-)
Nie będę tutaj omawiał dokładnie zasad komunikacji pokażę jedynie jak w praktyce połączyć mikrokontroler z komputerem i jak zrealizować łączność z prędkością 57,6kbps z wykorzystaniem przerwań.
Dowiesz się także jakie błędy popełniane są najczęściej w temacie wykorzystania tego interfejsu.
Przeczytaj także jak wykorzystać interfejs RS-232 za pomocą Bletooth: Bluetooth + mikrokontroler
Krzyżowe połączenie
W przypadku RS-232 (w przeciwieństwie do innych interfejsów) urządzenia łączy się krzyżowo, czyli w taki sposób, by wyjście jednego trafiało na wejście drugiego:
Należy o tym pamiętać w szczególności, że standardowe przewody łączące mogą być dwojakiego rodzaju:
Jeżeli więc podwójnie skrzyżujesz sygnały RxD i TxD (raz w urządzeniu i drugi raz w przewodzie łączącym), to de facto krzyżowania nie będzie i komunikacji także :-)
Pinologia
W komputerach znajdziesz gniazda RS-232 w formie wtyku typu D-SUB o 9 pinach w wersji męskiej.
Źródło |
Każdy pin ma numerek (patrz przez lupę - mogą być słabo widoczne). Numerki są zgodne z wersją damską złącza. Innymi słowy damskie jest lustrzanym odbiciem męskiego, przez co piny o tych samych numerach wzajemnie się łączą.
W starszych urządzeniach można znaleźć gniazda w wersji 25 pinowej.
Warto zerknąć na tę stronę: RS232 Connector Pin Assignment lub w wersji PDF.
Prędkości transmisji
RS-232 oferuje bardzo szeroki zakres możliwych prędkości transmisji. Pozwala to na dobranie odpowiedniej do danych warunków (możliwości obu połączonych urządzeń) oraz odległości i innych warunków zewnętrznych (zakłócenia, rodzaj i jakość przewodów, itp). Zerknijmy na tabelę zawartą w datasheet ATmega8 dla zegara taktującego mikrokontroler od 16MHz wzwyż:
Baud rate, to jednostka prędkości łącza wyrażona w bitach na sekundę (ang. bits per second). Jak każdą jednostkę także i tę możemy wyrażać za pomocą przedrostków wielokrotności jednostki miary. Stąd:
- kbps - oznacza kilo bitów na sekundę,
- Mbps - mega bitów na sekundę.
Takich tabel jak powyższa w datasheet znajdziesz więcej (także dla niższych częstotliwości zegara mikrokontrolera). Za pomocą nich możesz wybrać i ustawić odpowiednio interfejs USART (UART) mikrokontrolera.
Zauważysz w nich, że w trybie asynchronicznym niektóre częstotliwości taktowania mikrokontrolera pozwalają uzyskać znacznie większe prędkości transmisji danych, niż inne częstotliwości. Na pierwszy rzut oka może dziwić fakt, że dla częstotliwości taktowania mikrokontrolera 8MHz, można osiągnąć 1Mbps, podczas gdy z zegarem 20MHz zaledwie 0,5Mbps.
Wytłumaczenie tego faktu znajdziesz tutaj:
Podczas obliczania wartości jaką należy ustawić w rejestrze UBRR, zamiast tabelek możesz skorzystać ze wzorów, które także w datasheet znajdziesz:
Efektywna prędkość transmisji
Moduł USART umożliwia wybranie jednej z 30 możliwych kombinacji ramki danych, czyli pakietu przesyłającego jedną daną. Parametry ramki danych zależne są od tego
- bit startu (jest zawsze jeden),
- bity danych (może być od 5 do 9),
- bit parzystości (może lecz nie musi występować),
- bity stopu (co najmniej jeden lub nawet dwa).
Ramka danych przedstawia się więc następująco:
Rys. RS-232 - Ramka danych modułu USART. |
Bity zaznaczone na czerwono występują zawsze.
Pozostałe (zaznaczone na zielono) w zależności jak ustawisz parametry transmisji.
Jak widzisz ramka może mieć od 7, aż do 13 bitów.
Skoro ramka może mieć różną długość, a BAUD RATE jest stały np. 9600bps, to efektywna prędkość transmisji danych (Data bits) będzie różna dla różnych ustawień długości ramki.
Obliczeń efektywnej prędkości transmisji danych możesz dokonać za pomocą poniższego kalkulatora:
Kalkulator efektywnej prędkości transmisji danych (USART) |
|
---|---|
Baud rate | bps |
Bit startu | |
Bitów danych | |
Bit parzystości | |
Bit stopu | |
Długość ramki | bitów |
Efektywna prędkość transmisji | bps % |
Odległości
Odległości uzyskiwane za pomocą tego interfejsu orientacyjnie wynoszą:
Prędkość [bps] | Odległość [m] |
---|---|
19200 | 16 |
9600 | 160 |
4800 | 320 |
2400 | 1000 |
Źródło: Tomasz Francuz: Język C dla mikrokontrolerów AVR.
Od podstaw do zaawansowanych aplikacji. str. 369
Faktyczne osiągi zależą oczywiście od wielu czynników jak zastosowane przewody, wersja nadajnika i odbiornika oraz środowiska w jakim pracuje tak zrealizowana linia komunikacyjna.
Niezbędna elektronika
W przypadku wykorzystania RS-232 do komunikacji pomiędzy dwoma mikrokontrolerami na niewielkich odległościach np. w tym samym urządzeniu nie ma potrzeby korzystania z dodatkowych układów i można operować napięciami w standardzie mikrokontrolerów.
Jednakże w przypadku łączenia mikrokontolera z urządzeniem pracującym w standardzie napięć RS-232, musisz wiedzieć o tym, że standard poziomów napięć RS-232 znacząco odbiega od poziomów napięć, którymi operują mikrokontrolery. Właśnie dzięki temu możliwe jest osiąganie znacznych odległości. Ceną takiego rozwiązania jest potrzeba stosowania dodatkowych układów pośredniczących.
Mogą być nimi dedykowane do tych zadań układy scalone lub można zbudować własny za pomocą niewielkiej ilości elementów. Układ ten powinien znajdować się po obu stronach linii, czyli na wejściach i wyjściach obu komunikujących się ze sobą urządzeń.
Dedykowane układy RS-232
Podstawowym, powszechnie stosowanym i tanim układem jest MAX232:
Biblioteka Eagle: maxim.lbr
Fakt, że mikrokontroler może osiągnąć prędkość np. 1Mbps nie oznacza, że możesz z taką prędkością komunikację prowadzić za pomocą MAX232, czy innych tego typu układów, ponieważ układy te mają swoje górne granice prędkości transmisji. W przypadku MAX232 jest to zaledwie 120kbps.
Ale jest także wiele innych układów, które mają znacznie większe prędkości i/lub inne parametry, które mogą być istotne dla Ciebie, jak na przykład pobór prądu w stanie spoczynku w przypadku urządzeń zasilanych z baterii, czy akumulatora:
Często jak w przypadku MAX232 w jednym układzie zawarte są dwa komplety nadajników i odbiorników. Jeżeli nie wykorzystujesz obu nadajników i odbiorników, warto jest zadbać o wymuszenie stanu niskiego na nieużywanych wejściach, by te części układu nie "łapały" zakłóceń:
MAX'y vs kondensatory
Częstym problemem początkujących jest sprawa kondensatorów używanych w tej rodzinie układów. Trzeba zwrócić uwagę na dwa ważne aspekty:
- kondensator C4 ma z pozoru nieprawidłową polaryzację, ale wynika ona z faktu, że na pinie V- jest napięcie ujemne(!).
- wartość i rodzaj kondensatorów zależy od typu zastosowanego układu MAX. Dokładną informację znajdziesz w datasheet danego układu. W przypadku MAX232 kondensatory powinny mieć 1µF i mogą być elektrolityczne, tantalowe, a nawet ceramiczne. W przypadku MAX202 kondensatory mają wartość 0,1µF. Zawsze sprawdzaj w datasheet:
Rys. MAX232 - wymagania dot. kondensatorów. |
Nie mam pod ręką MAX'a !
Transmisję z wykorzystaniem RS-232 można także prowadzić za pomocą prostego intrerfejsu zrealizowanego za pomocą dwóch tranzystorów i kilku dodatkowych elementów:
Tak wykonany interfejs jest bezpieczną wersją o całkiem dobrych parametrach transmisji danych, chociaż mogą wystąpić problemy przy dłuższych przewodach. Innymi słowy rozwiązanie to należy traktować jako awaryjne, testowe, doświadczalne lub świadomy kompromis.
Dodatkową zaletą jest fakt, iż użyte tranzystory i diody mają wiele zamienników, więc praktycznie zawsze pod ręką jakieś znajdziesz. Także rezystory mogą przybierać różne wartości od 2,2k do 10k.
Przykład "koprocesora matematycznego" :-)
Czas przejść do zadania praktycznego. Zbudujemy taki układ:
Poniżej program pokazujący transmisję danych z wykorzystaniem przerwań, by nie blokować mikrokontrolera. Program ma za zadanie:
- odebrać liczbę wysłaną z komputera za pomocą RS-232,
- dokonać obliczeń funkcji kwadratowej podstawiając odebraną liczbę za X,
- wysłać za pomocą RS-232 do komputera ciąg znaków reprezentujących obliczony wynik funkcji.
Rezultat działania programu, możesz zobaczyć na filmie umieszczonym pod koniec artykułu.
/* Program realizujący obliczanie i wysłanie przez RS-232 wyniku funkcji kwadratowej y = 0.3187x^2 + 2x - 7 na podstawie x odebranego wcześniej także za pomocą RS-232. Szczegóły: http://mikrokontrolery.blogspot.com/2011/03/rs-232-atmega8-komputer-terminal.html Mikrokontroler: Atmega8 Autor: Dondu Data: 2012.11.30 */ //#include <stddef.h> #include <avr\io.h> #include <stdio.h> #include <avr/interrupt.h> #include <util/delay.h> //zmienne dot. odbioru danych volatile unsigned char odb_x; //odebrana liczba X volatile unsigned char odb_flaga =0;//flaga informująca main o odebraniu liczby //bufor znaków ze wzorem funkcji, który wysyłamy po starcie programu volatile unsigned int usart_bufor_ind; //indeks bufora nadawania char usart_bufor[30] = "y = 0.3187x^2 + 2x - 7"; //bufor nadawania void usart_inicjuj(void) { //definiowanie parametrów transmisji za pomocą makr zawartych w pliku //nagłówkowym setbaud.h. Jeżeli wybierzesz prędkość, która nie będzie //możliwa do realizacji otrzymasz ostrzeżenie: //#warning "Baud rate achieved is higher than allowed" #define BAUD 57600 //tutaj podaj żądaną prędkość transmisji #include <util/setbaud.h> //linkowanie tego pliku musi być //po zdefiniowaniu BAUD //ustaw obliczone przez makro wartości UBRRH = UBRRH_VALUE; UBRRL = UBRRL_VALUE; #if USE_2X UCSRA |= (1<<U2X); #else UCSRA &= ~(1<<U2X); #endif //Ustawiamy pozostałe parametry moduł USART //U W A G A !!! //W ATmega8, aby zapisać do rejestru UCSRC należy ustawiać bit URSEL //zobacz także: http://mikrokontrolery.blogspot.com/2011/04/avr-czyhajace-pulapki.html#avr_pulapka_2 UCSRC = (1<<URSEL) | (1<<UCSZ1) | (1<<UCSZ0); //bitów danych: 8 //bity stopu: 1 //parzystość: brak //włącz nadajnik i odbiornik oraz ich przerwania odbiornika //przerwania nadajnika włączamy w funkcji wyslij_wynik() UCSRB = (1<<TXEN) | (1<<RXEN) | (1<<RXCIE); } //-------------------------------------------------------------- ISR(USART_RXC_vect) { //przerwanie generowane po odebraniu bajtu odb_x = UDR; //zapamiętaj odebraną liczbę odb_flaga = 1; //ustaw flagę odbioru liczby dla main() } //-------------------------------------------------------------- ISR(USART_UDRE_vect){ //przerwanie generowane, gdy bufor nadawania jest już pusty, //odpowiedzialne za wysłanie wszystkich znaków z tablicy usart_bufor[] //sprawdzamy, czy bajt do wysłania jest znakiem końca tekstu, czyli zerem if(usart_bufor[usart_bufor_ind]!= 0){ //załaduj znak do rejestru wysyłki i ustaw indeks na następny znak UDR = usart_bufor[usart_bufor_ind++]; }else{ //osiągnięto koniec napisu w tablicy usart_bufor[] UCSRB &= ~(1<<UDRIE); //wyłącz przerwania pustego bufora nadawania } } //-------------------------------------------------------------- void wyslij_wynik(void){ //funkcja rozpoczyna wysyłanie, wysyłając pierwszy znak znajdujący się //w tablicy usart_bufor[]. Pozostałe wyśle funkcja przerwania, //która zostanie wywołana automatycznie po wysłaniu każdego znaku. //dodaj do tekstu wyniku znaki końca linii (CR+LF), by na //ekranie terminala wyniki pojawiały się w nowych liniach unsigned char z; for(z=0; z<30; z++){ if(usart_bufor[z]==0){ //czy to koniec takstu w tablicy //tak znaleziono koniec tekstu, dodajemy znak CR usart_bufor[z] = 13; //znak powrotu karetki CR (Carrige Return) usart_bufor[z+1] = 10; //znak nowej linii LF (Line Feed) usart_bufor[z+2] = 0; //znak końca ciągu tekstu w tablicy break; } } //Zaczekaj, aż bufor nadawania będzie pusty while (!(UCSRA & (1<<UDRE))); //bufor jest pusty można wysłać //następny znak do wysyłki to znak nr 1 usart_bufor_ind = 0; //włącz przerwania pustego bufora UDR, co rozpocznie transmisję //aktualnej zawartości bufora UCSRB |= (1<<UDRIE); } //-------------------------------------------------------------- int main(void) { usart_inicjuj(); //inicjuj moduł USART (RS-232) sei(); //włącz przerwania globalne wyslij_wynik(); //na początku wysyłamy text wzoru, który po //resecie jest w tablicy usart_bufor[] while(1){ //tutaj Twój program .... //czekamy na informację o odebraniu danej nie blokując mikrokontrolera if(odb_flaga){ odb_flaga = 0; //zgaś flagę //wykonaj obliczenia i wynik przekształć na znaki ładując do //bufora usart_bufor[] sprintf(usart_bufor, "%f", 0.3187 * odb_x * odb_x + 2 * odb_x - 7); wyslij_wynik(); //rozpocznij wysyłanie wyniku przez RS-232 } //w tym czasie można wykonywać dowolny program //umieść go tutaj lub przed if() powyżej } }
Do pobrania: Kompletny projekt AVR Studio 4 + plik HEX dla 16MHz
Testujemy programem terminala
Do kontroli komunikacji oraz wysyłania i odbierania danych na komputerze wykorzystamy program Realterm. To bardzo rozbudowany w porównaniu z zawartym w systemie Windows Hyper Terminal'u.
Możesz oczywiście wykorzystać dowolny inny program terminala.
Po uruchomieniu programu musisz ustawić parę opcji. Zaczniemy od zakładki Display:
Następnie w zakładce Port ustawiamy takie same parametry transmisji jakie ustawiliśmy w programie mikrokontrolera:
Włączamy nasz mikrokontroler i naszym oczom powinien ukazać się przesłany przez niego tekst wzoru:
Jeżeli napis się nie ukazał, powinieneś sprawdzić swój projekt dokładnie. Poniżej opisałem najczęściej występujące problemy.
Zanim zaczniemy testować dalej włączymy opcję Display as: Ansi w zakładce Display, po to by nie było widać znaków sterujących.
Czas wypróbować jak działa nasza projekt. W tym celu za pomocą zakładki Send wyślemy liczbę z zakresu od 0 do 255. Mikrokontroler odbierze liczbę, obliczy wartość funkcji i zwróci wynik:
Za każdym razem, gdy wyślesz liczbę, natychmiast otrzymasz wynik funkcji. Oznacza to, że komunikacja przebiega prawidłowo.
Działanie układu możesz zobaczyć na poniższym filmie (ustaw sobie najwyższą rozdzielczość z możliwych):
Pozostałe tryby pracy USART
Moduł USART ma spore możliwości i wiele różnych ustawień, nie będę się na ten temat rozpisywał, bo musiałbym napisać książkę, a ponieważ jest już sporo literatury na ten temat więc pozwolicie, że swój czas poświęcę na inne ważniejsze artykuły. Bardzo dokładnie opisał to Tomek Francuz w swojej książce. Można także posiłkować się dokumentacją mikrokontrolera.
Najczęściej występujące problemy
W trakcie projektowania i testów, możesz się natknąć na kilka problemów.
Brak lub niepoprawna komunikacja
Z tym interfejsem wieże się spora ilość miejsc, w których można popełnić błąd skutkujący brakiem komunikacji. Oto najważniejsze z nich:
- zapominanie o tym, iż w niektórych mikrokontrolerach dwa różne rejestry mogą być pod tym samym adresem, patrz: Pułapki AVR'ów,
- ustawienie różnych parametrów transmisji w obu urządzeniach,
- stosowanie niestabilnego (niedokładnego) źródła zegara taktującego mikrokontroler, szczególnie w przypadku pracy USART w trybie asynchronicznym,
- błędne połączenie urządzeń w zależności od posiadanego przewodu (prosty lub krzyżowy),
- zbyt długi przewód łączący oba urządzenia w stosunku do wybranej prędkości transmisji,
- kiepskiej jakości przewody,
- zbyt duże zakłócenia zewnętrzne.
Jeżeli coś będzie sygnalizowane na czerwono powinieneś się nad tym zastanowić.
Problem liczb i znaku zapytania w terminalu
Jeżeli wysyłasz do terminala liczby w postaci kodów ASCII, możesz się natknąć na problem pojawiającego się w zamian jedynie znaku zapytania. Rozwiązanie problemu znajdziesz tutaj: Problem znaku zapytania podczas konwersji float do znaków ASCII
To teraz proszę dla USB przez układ FT232 :)
OdpowiedzUsuńWitam, świetny artykuł.
OdpowiedzUsuńJa także dołączam się do prośby o tekst objaśniający komunikację przez USB, pozdrawiam
Witam,
OdpowiedzUsuńBardzo fajny artykuł, jednak jest w nim jedna nieścisłość.
Baud rate - to nie liczba bitów na sekundę a ilość zmian stanu na magistrali. Więc jeśli mamy ustawiony np. tryb transmisji na 8bit + stop przy Baud rate 9600 jesteśmy w stanie wysłać tylko 7680b/s a nie 9600b/s(sygnał start + 8bit + sygnał stop), czyli około 20% mniej niż zakładaliśmy.
Co do definicji BAUD RATE, to jest taka jak napisałem w artykule, czyli bity na sekundę. Określa ona z jaką prędkością przesyłane są dane, a bity startu i stopu także są danymi. Ale skoro zrozumiałeś ją inaczej niż tego się spodziewałem, to znaczy, że powinienem ją uściślić, by nie było wątpliwości.
OdpowiedzUsuńFragment datasheet ATmega8:
"Table 52 contains equations for calculating the baud rate (in bits per second) ..."
co w tej tabelce jest dodatkowo opisane w notatce pod nią.
Widoczne jest to także w tabelce prędkości vs ustawienia UBRR (tab. 65) - nagłówek kolumny pierwszej.
Obie tabelki są w artykule.
Dziękuję natomiast za wskazanie tematu, który powinien uzupełnić ten artykuł, czyli efektywną szybkość transmisji danych, bo z punktu widzenia użytkownika, to ona jest istotna. Dopiszę ten punkt.
Dopisałem i dodałem kalkulator.
OdpowiedzUsuńTen koprocesor, to istny wymiatacz ;-)
OdpowiedzUsuńFajny artykuł, prosiłbym tylko o umieszczenie tego "NEW" na głównej stronie:)
OdpowiedzUsuńTo część Drzaśkowego pamiętnika więc nie bardzo. Ale mogę zrobić temat "RS-232" wraz z NEW, i w nim umieścić ten link. Pomyślę nad tym.
OdpowiedzUsuńOd paru dni walczę z interfejsem rs232 pod Atmegą8. Moim celem jest nawiązanie komunikacji między uC a modułem GSM (Motorola D15) i sterowanie tym ostatnim przy pomocy komend AT. Zarówno płytkę z Atmegą, jak i moduł GSM bez problemu obsługuję za pomocą komputera (HyperTerminal). Dopracowałem program i wydawało mi się, że wszystko jest ok... Niestety, problemy zaczęły się, gdy połączyłem ze sobą obydwie płytki. Nic nie działało jak powinno. Za pomocą modułu z max3232 spróbowałem więc "podsłuchać" komunikaty przesyłane na liniach RX i TX.
OdpowiedzUsuńOkazało się przede wszystkim, że bardzo często (ale nie zawsze) do odpowiedzi wysyłanej przed moduł dołączana jest jedna linijka zawierająca "krzaczek" (zawsze ten sam - na HT składają się na niego dwa znaki - kwadracik i litera "K", Programmer's Notepad w zapisanym pliku sesji pokazuje w tym miejscu "t" z ogonkiem u dołu). Pojawia się on szczególnie przed odpowiedzią "+CPIN: SIM PIN" na komendę "AT+CPIN?". Nic takiego nigdy nie działo się, gdy moduł był podpięty do komputera przez max3232
Jest też problem z komunikacją w drugą stronę, także bardzo konkretny. Mianowicie bardzo często atmega odmawia wysłania polecenia nawiązania połączenia ("AT*Dnumer"). Komunikat nie zostaje wysłany wcale - nie widać go na terminalu, gdy podsłuchuję tę linię. Byłbym skłonny uznać to za błąd w programie, gdyby znowu nie fakt, że nigdy nie występuje, gdy Atmega podłączona była tylko do komputera.
Parametry połączenia na obydwu urządzeniach się zgadzają. Filtrowanie zasilania mam raczej w porządku (zgodnie z wytycznymi z tej strony). Mikrosterownik jest taktowany kwarcem. Układ zmontowany na płytce uniwersalnej, połączenia wykonane tymczasowo kabelkami do goldpinów.
Ktoś ma jakiś pomysł gdzie jeszcze mogę szukać przyczyny?
Jakie masz napięcia zasilania modemu i uC?
OdpowiedzUsuńCzy masz jakiś konwerter poziomów napięć?
Do komunikacji z modemem spróbuj używać tego terminala https://sites.google.com/site/terminalbpp/
Próbowałem korzystać z tego terminala, ale miałem z nim jakieś problemy (komunikował się z wbudowanym w laptopa modemem, ale urządzeniami na COM1 już jakoś nie chciał). Wróciłem do HT. ;)
OdpowiedzUsuńCo do pierwszego pytania, to Atmega i modem są zasilane 5V ze stabilizatora 78T05. Żadnego level shiftera między nimi nie ma.
W przypadku komunikacji z komputerem używam max3232.
Spieszę wyjaśnić, że winny okazał się błąd w programie. Mianowicie przez moje niedopatrzenie dochodziło do sytuacji, kiedy mikrosterownik zaczynał nadawać nowe polecenie, kiedy jeszcze przychodziły znaki wchodzące w skład odpowiedzi na poprzednie. Taka sytuacja powodowała wadliwą pracę modułu GSM, która objawiała się błędami transmisji.
OdpowiedzUsuńPorządny artykuł, ale mam pytanie. Tutaj kondensator C3 (na pierwszym schemacie z MAXem jest podłączony do GND, a w datasheecie jest podłączony do +5V. Jak to jest?
OdpowiedzUsuńJako pierwszy jest pokazany fragment datasheet. Jako drugi schemat Eagle. W obu przypadkach C3 jest podłączony do GND. Dlatego nie bardzo rozumie, co masz na myśli?
OdpowiedzUsuńTutaj datasheet ze strony Maxim Integrated:
OdpowiedzUsuńhttp://datasheets.maximintegrated.com/en/ds/MAX220-MAX249.pdf
Na stronie 17 widać, że C3 jest podłączony do +5V
Witam wszystkich. Mam mały problem z komunikacją po rs232. Wysyłanie liczby i zwrocenie wyniku działa. Jednak po podłączeniu uC nie wyświetla mi się wzór funkcji kwadratwej. Wydaje mi się, że sprawdziłem juz wszystkie mozliwości i nadal nic. Ma ktoś może jakiś pomysł co może być nie tak?
OdpowiedzUsuńHmm, czyli komunikacja w obie strony jest, bo wysyłasz liczbę z terminala, i wynik otrzymujesz? A jedyne co, to nie wyświetla się wzór po włączeniu zasilania? Czy tak?
OdpowiedzUsuńDokładnie tak jak piszesz:)
OdpowiedzUsuńHmm, nie ma jak teraz sprawdzić programu, ale do artykułów zawsze załączam wersję dokładnie tą, która jest na filmie. Skoro komunikacja działa w obie strony, to wysłanie wzory na początku także powinno. Nie wiem co Ci na szybko podpowiedzieć - powinno działać :-)
OdpowiedzUsuńNigdzie nie jest napisane gdzie podłączyć pozostałe piny we wtyczce RSa :/
OdpowiedzUsuńBo w tym przykładzie nie trzeba :-)
OdpowiedzUsuńPrzydałby się jakiś opis pozostałych pinów bo z nazw ciężko się domyślić :)
OdpowiedzUsuńMam spory problem z tym kodem wrzucam go uP atmega8 16Mhz. Fusbity ustawione. Wyświetla mi się tylko początkowy wzór do obliczeń a później już nic nie reaguje próbuje wysyłać i nic nie wyświetla. Dobrze wszytko podłączone sprawdzałem kilka razy. Od czego mogę zacząć debugowanie tego problemu ? Trochę już nad tym siedzę :( . Mam Linux'a postawionego i pracuje na eclipse.
OdpowiedzUsuńSkoro śmiga w jedną stronę poprawnie, a nie odbiera to wskazuje na prawidłowe ustawienia USART i prawidłowe podłączenie w jedną stronę.
OdpowiedzUsuńNależałoby więc dokładnie sprawdzić tor odbiorczy począwszy od wtyczki RS-232 wkładanej do komputera.
Niecałe 2 tygodnie temu wykorzystywałem ten program na ustawionym wewnętrznym generatorze 1MHz, dla prędkości transmisji 9600bps - śmigało poprawnie. Spróbuj na wszelki wypadek ustawić takie parametry - choć to nie powinno mieć znaczenia.
Próbowałem na początku z 1Mhz i to samo było. To tak jakby uP nie reagował na przerwania z ISR(USART_RXC_vect) w ogóle flagi nie ustawia. Dopiero gdy w stawie np. do pętli głównej UDR=0; cały czas wysyła zera nie widać tego w ASCII dopiero w HEX pokazuje że wysyła całą masę danych "00" trochę to bez sensu no ale tak działa , wtedy dopiero flagę ustawia i np. gaszę i zapalam diodę na przemian gdy wysyłam np literę. Widać że połączenie jest ok. Jak masz może jakiś pomysł to spróbujemy bo już parę godzin z przerwami przy tym siedzę :(.
OdpowiedzUsuńZaraz sprawdzę załączony projekt AVR i dam znać.
OdpowiedzUsuńPobrałem kompletny projekt AVR Studio (takiego użyuwam dla AVR'ów) załączony powyżej. Zmieniłem ustawienia w opcjach częstotliwość na 1MHz (tak mam ustawioną ATmegę) oraz ustawienie prędkości transmisji na: #define BAUD 9600
OdpowiedzUsuńSkompilowałem (żadnych warningów) i wgrałem do mikrokontrolera.
Następnie w Realterm ustawiłem 9600bps i działa prawidłowo - zarówno wysyłanie jak i odbieranie danych.
Jeżeli więc zrobisz dokładnie to samo, to musi działać. Jeżeli nadal nie będzie działać to upieram się, przy problemie sprzętowym - sprawdzałeś to o czym pisałem wcześniej?
Tak sprawdziłem tylko że pracuje na układzie AN232JN zamiast max232 trochę inne ma pojemności kondensatorów ale dobrałem takie jak w nocie. Ogólnie to jak wrzucę while(1){UDR = 0x00;} to nawet działa bo mogę zrobić echo.
OdpowiedzUsuńJa mam konwerter na tranzystorach jak na schemacie w artykule - spróbuj zlutować "na pająka" :-)
OdpowiedzUsuńTeraz uciekam - będę dopiero jutro wieczorem. Napisz o rezultatach. Hej!
mam podobny problem który kolega opisał w poście powyżej tzn. poprawnie odbieram wzor rownania na terminalu realterm ale potem podczas proby wysylania cyfry w wyniku otrzymuje wyswietlony na ekranie znak zapytania. probowałem podstawic pod rownianie nawet zwykla cyfre nie wymagajaca poprawnego odebrania cyfry z komputera ale to tez nie pomaga.
OdpowiedzUsuńkorzystam z atmega8 i konwertera usb<->rs232 na ukladzie ft232r.
Jezeli ktos ma pomysl jak to rozwiazac bede bardo wdzieczny.
Nadrabiam zaległość w odpowiedzi dot. znaku zapytania: Problem znaku zapytania podczas konwersji float do znaków ASCII w celu wyświetlenia na np. LCD itp.
UsuńChyba problem w moim przypadku polega na błędnej obłudze funkcji sprintf, ponieważ gdy wywalilem linijke z wpisywaniem do usart_bufor obliczanej wartosci, to uklad odsyla mi poprawnie wartosc tekstu rownania.
OdpowiedzUsuńZatem moje pytanie czy ktos wie dlaczego funkcja sprintf moze nie dzialac prawidlowo?
Nieprawidłowe działanie sprintf pozostaw na sam koniec. Na razie zastanów się, czy używasz ją prawidłowo: Printf() i funkcje pochodne
UsuńNic nie zmieniałem w linijce z funkcją sprintf więc raczej chyba powinna działać dobrze. Wydaje mi się że może to być błąd wysyłania wiadomości z komputera na Atmege.
UsuńJedna rzecz mnie zdziwiła o której nie wspomniałem.
Otóż gdy podłączam linie Rx(korzystam z modułu ze sklepu avt- AVTMOD09) z linią Tx Atmegi to nie ma komunikacji a gdy podłącze Rx z Rx oraz Tx i Tx to jest komunikacja jak opisałem powyżej. Wydaje się że dla "ułatwienia" opisali linie na odwrót.
Jeszcze sobie myślę że może to być błąd konwersji ze strony USB na RS232 choć Atmega przecież odbiera sygnał z komputera bo odpowiada.
Pozdrawiam,
Piotrek
Co do Tx-Rx, to faktycznie tak może być jak piszesz. Dokumentacja tego konwertera nie jest jednoznaczna. Zawsze można spróbować zapytać sprzedawcę lub producenta.
UsuńCo do reszty problemu, to proponuję abyś założył temat na forum i tam wkleił cały swój program. Wtedy będzie możliwość przeanalizowania pod kątem jego poprawności.
Witam, nie miałem wcześniej czasu zająć się problemem. Okazało się że błąd polega na użyciu funkcji sprintf, nie wiem czemu działa błędnie, nic nie zmieniałem w kodzie. Programuje w środowisku WinAvr v.2.0.8.718-basie pod winxp.
OdpowiedzUsuńCo do komunikacji po rs działa poprawnie, zmieniłem troche kod tak ze przesyłam liczbe i całe działanie polega na dodaniu stałej i odesłaniu przez rs'a do komputera, przesyłane wyniki sa poprawne.
Dzięki za pomoc,
pozdrawiam
Sprintf() na 100% działa poprawnie. Błąd leży w Twoim programie. Szkoda, że nie zdecydowałeś się, an jego pokazanie na forum, tak jak radziłem.
UsuńPozdrawiam.
Witam.Bardzo dobry i przydatny projekt czy można prosić o przerobienie na Atmege 32.Używam Eclipse.
OdpowiedzUsuńPozdrawiam serdecznie.
Witaj.
UsuńNie mam pod ręką ATmega32, ale program powinien działać także na tym mikrokontrolerze. Sprawdzałeś?
Jeżeli tak, i nie działa, to opisz objawy i wklej komunikaty z kompilacji.
Witam.Uruchomiłem na A32 kwarc zew.16MHz ale nie działa prawidłowo objawy:
OdpowiedzUsuń- wrzuca wzór ale kończy "krzaczkiem"CrLf
- wysłanie liczby wyświetla ? + CrLf
Pozdrawiam serdecznie.
Ps.Jak wkleić zrzut ekr.
CrLf to znak specjalny nowej linii (Carriage Return oraz Line Feed) zgodnie z kodami ASCII. Aby się nie wyświetlały należy wybrać Display as: Ansi Zobacz pierwszy zrzut ekranu terminala w artykule.
UsuńPliki proponuję wrzucić na imageshack.com a tutaj podać link. Niestety nie ma innej możliwości.
... zobacz także trzeci zrzut ekranu terminala w artykule powyżej.
UsuńKrzaczki usunięte ale wysłanie liczby daje efekt w postaci "?"
UsuńSpróbuje wrzucić pliki z kompilacji i zrzut ekr. jak podałeś.
Ja również mam taki problem, próbuję odpalić kod na ATmega328P, poniżej przerobiony kod z przykładu (tylko i wyłącznie nazwy rejestrów i wektorów żeby pasowały do m328)
Usuńhttp://pastebin.com/wk0Fa5Va
Jak uruchamiam program z atmegi to w terminalu wyświetla wzór, kończy go CrLf a kiedy chcę wysłać liczbę to przeskakuje do nowej linii, wyświetla się znak zapytania i CrLf.
[IMG]http://imageshack.us/a/img836/7462/etqu.jpg[/IMG]
OdpowiedzUsuń[IMG]http://imageshack.us/a/img46/4686/0a94.jpg[/IMG]
W terminalu masz ustawioną prędkość transmisji na 4800. W przykładowym programie jest ustawiona na 57600. Czy zmieniałeś ustawienia definicji BAUD w programie?
UsuńTak są ustawione na 4800 , spróbuję na 57600 i odpowiem.
UsuńTak samo
UsuńWitam,
OdpowiedzUsuńPróbuję uruchomić komunikację usart między komputerem i uC niestety coś nie działa.
Użyłem program z przykładu i próbuję go uruchomić na ATmega328P (zmieniałem nazwy rejestrów i wektorów na zgodne z ATmega328P). Program sprawdzam w RealTerm i wygląda to tak. Po podpięciu zasilania do UC wyświetla się wzór funkcji kwadratowej y=0.3187x^2+2x-7 ale kiedy chcę wysłać liczbę to na terminalu wyświetla się tylko ?
Sprawdzałem połączenia i wszystko powinno być dobrze (podłączony z max232 ze schematu z przykładu).
Poniżej kod który z przykłądu przerobiony na ATmega328P http://pastebin.com/wk0Fa5Va
Będę niezmiernie wdzięczny za pomoc.
OMG, właśnie przypomniałem sobie co powoduje ten ? znak zapytania (zapomniałem że już taki problem miałem jak używałem printf do wyświetlania na LCD).
OdpowiedzUsuńW AVR Studio 6 trzeba w 'project properties' pod AVR/GNU Linker w General zaznaczyć "Use vprintf library(-Wl,-u,vprintf)" a następnie w libraries dodać "printf_flt" oraz "m" (może działać tylko z printf_min)
źródło http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html
Jeśli do komunikacji za pomocą USART wykorzystujemy przerwania USART_RXC_vect i USART_UDRE_vect, to nie jest potrzebne czekanie na
OdpowiedzUsuńpusty bufor w funkcji wyslij_wynik().
"
//Zaczekaj, aż bufor nadawania będzie pusty
while (!(UCSRA & (1<<UDRE)));
"
Kod ten jest zaś niezbędny wtedy, kiedy chcemy wysłać poprzez USART dane z pominięciem przerwań , czyli zgodnie z przykładem z PDF:
"
void USART_Transmit( unsigned char data )
{
/* Wait for empty transmit buffer */
while ( !( UCSRA & (1<<UDRE)) )
;
/* Put data into buffer, sends the data */
UDR = data;
}
"
W sumie przykład działa poprawnie z funkcją:
"
void wyslij_wynik(void){
//funkcja rozpoczyna wysyłanie, wysyłając pierwszy znak znajdujący się
//w tablicy usart_bufor[]. Pozostałe wyśle funkcja przerwania,
//która zostanie wywołana automatycznie po wysłaniu każdego znaku.
//dodaj do tekstu wyniku znaki końca linii (CR+LF), by na
//ekranie terminala wyniki pojawiały się w nowych liniach
unsigned char z;
for(z=0; z<30; z++){
if(usart_bufor[z]==0){ //czy to koniec takstu w tablicy
//tak znaleziono koniec tekstu, dodajemy znak CR
usart_bufor[z] = 13; //znak powrotu karetki CR (Carrige Return)
usart_bufor[z+1] = 10; //znak nowej linii LF (Line Feed)
usart_bufor[z+2] = 0; //znak końca ciągu tekstu w tablicy
break;
}
}
//następny znak do wysyłki to znak nr 1
usart_bufor_ind = 0;
//włącz przerwania pustego bufora UDR, co rozpocznie transmisję
//aktualnej zawartości bufora
UCSRB |= (1<<UDRIE);
}
"
Testowane na Atmega16. W miarę wolnego czasu sprawdzę z innymi uC.
Grzegorz
Pętla o której piszesz umieszczona w funkcji wyslij_wynik() ma tylko jedno zadanie - wykluczenie przypadku, w którym rozpoczynamy transmisję w sytuacji, w której poprzednia transmisja jeszcze nie została zakończona, a w buforze UDR czeka kolejna dana.
UsuńJest to istotne właśnie podczas wykorzystania USART opartego o przerwania, tak jak w powyższym artykule.
Dlaczego? Ponieważ:
cyt: "The buffered data in the transmit buffer will be moved to the Shift Register when the Shift Register is ready to send a new frame."
Powyższy fragment datasheet mówi, że dana zapisana w rejestrze UDR, jest przepisywana do rejestru przesuwnego (nadającego szeregowo) w momencie, w którym rejestr ten zakończył przesyłanie poprzedniej danej i może przyjąć nową daną.
Stan ten jest określany właśnie przez bit UDRE:
cyt. "The Data Register Empty (UDRE) Flag indicates whether the transmit buffer is ready to receive new data. This bit is set when the transmit buffer is empty, and cleared when the transmit buffer contains data to be transmitted that has not yet been moved into the Shift Register."
Dlatego:
cyt: "The transmit buffer can only be written when the UDRE Flag in the UCSRA Register is set."
Teraz zastanów się, co się stanie, gdy pozbawisz funkcję wyslij_wynik() owej pętli i wywołasz tę funkcję kilka razy w czasie X podczas, gdy wysyłanie jednego bajtu danych trwa dłużej niż czas X?
Odpowiedź:
cyt: "Data written to UDR when the UDRE Flag is not set, will be ignored by the USART Transmitter."
czyli nastąpi utrata danych ponieważ bufor UDR składa się tylko z jednego bajtu.
Czy wyjaśniłem wystarczająco zrozumiale?
Zrobiłbyś artykuł o bezprzewodowym RS232? Pozdrawiam
OdpowiedzUsuńProszę o skorygowanie informacji na temat przesyłu informacji w standardzie RS232. To nie kilometr! To zaledwie 15 metrów przy bardzo dobrze wykonanym i ekranowanym kablu. Może autorowi chodziło o RS422/RS485, który rzeczywiście przy odpowiednim przekonwertowaniu napięć umożliwia transmisję na takie odległości :)
OdpowiedzUsuńPozdrawiam
Stosując kable lepszej jakości np. skrętkę UTP kat. 5e o pojemności około 17 pF/m(pojemność magistrali nie może przekroczyć 2,5 nF), można wydłużyć kabel do około 50 m. Zmniejszając jeszcze prędkość może wyjść 1000 m.
UsuńTak przynajmniej jest napisane w książce pana Francuza "Język C dla mikrokontrolerów AVR", a to raczej sprawdzona pozycja.
Witam używam konwertera USART=>USB (MPC2200). Mam do wyboru dwa porty 3 i 6. Przy wuborze 3 portu świecą się na zieloną ikonki CTS i DSR. Mikrokontroler nie odpowiada. Przy wyborze portu 6 nie świecą się ikony, ale również mikrokontroler nie odpowiada. Co może być tego przyczyną?
OdpowiedzUsuńWitam serdecznie! Przede wszystkim dziękuję Autorowi bloga za wspaniałą robotę, dzięki której osoba totalnie zielona z elektroniki (tzn. ja) mogła w krótkim czasie zacząć budować pierwsze układy :) Mam pytanie: czy pokazany w przykładzie sposób nadawania (w przerwaniu) da się zastosować w przypadku SPI? SPI nie ma chyba flagi i przerwania pustego bufora-odpowiednika USART_UDRE_vect (albo ja nie znalazłem). Próbowałem użyć flagi SPIF do sprawdzenia czy bufor jest pusty (while (!(SPSR & (1<<SPIF))); ale na symulatorze nie działało - program na tym etapie się zatrzymywał.
OdpowiedzUsuńSPI nie ma takiej flagi bo nie ma bufora co znacznie utrudnia sprawę. Ale ma przerwanie. Możesz SPDR ładować nowymi danymi w przerwaniu SPI. Tu pojawia się problem - przy max szybkości wysłanie bajtu po SPI trwa 16 taktów zegara - w efekcie przerwania nie mają tu sensu, bo prolog i epilog handlera zajmie więcej czasu. Można też użyć USART w trybie SPI - wtedy masz bufor, lecz problem podstawowy pozostaje taki sam. Rozwiązaniem jest przejść np. na XMEGA i wykorzystać DMA - wtedy transmisja jest realizowana praktycznie sprzętowo a procek odpoczywa lub robi inne sensowniejsze niż czekanie na nadanie/odbiór znaku rzeczy.
UsuńDziękuję za szybką odpowiedź. W takim razie chyba zrezygnuję z przerwań i nadawanie zrobię w pętli głównej. W zasadzie SPI służy mi tylko do ładowania rejestrów przesuwnych.
UsuńWitam. Mam pytanie, w tej tabelce z błędami są dwie kolumny dla każdej z częstotliwości U2X = 0 oraz U2X = 1. Rozumiem że to jest bit jakiegoś rejestru ale do czego to służy?
OdpowiedzUsuńUmożliwia podwojenie częstotliwości nadawania, czyli jeśli ustawiłeś UART w uC pod dajmy na to 2400bps to po ustawienie bitu U2X na 1 UART będzie nadawał z prędkością 4800bps
Usuń... a konkretnie:
Usuń"Double Speed Operation (U2X)
The transfer rate can be doubled by setting the U2X bit in UCSRA. Setting this bit only has effect for the asynchronous operation. Set this bit to zero when using synchronous operation.
Setting this bit will reduce the divisor of the baud rate divider from 16 to 8, effectively doubling the transfer rate for asynchronous communication. Note however that the Receiver will in this case only use half the number of samples (reduced from 16 to 8) for data sampling and clock recovery, and therefore a more accurate baud rate setting and system clock are required when this mode is used. For the Transmitter, there are no downsides."
Hej, mam pytanie. Z jednego uC wysyłam do drugiego zmienną int przez UART. Oczywiscie przed wysłaniem rozbijam zmienną int na dwie części w ten sposób:
OdpowiedzUsuńchar INT_L = zmienna_int;
char INT_H = zmienna_int >> 8;
Teraz drugi uC odbiera te dwie dane. Jak z tych dwóch połówek zrobić znowu jednego int-a?
P.S. Piszę w C.
Albo coś namieszałem przy odchudzaniu kodu albo przerwanie USART_UDRE_vect nie wykona się gdy bufor jest pusty i włączone zostaną przerwania. Przerwanie wykonuje się tylko jeśli wysłana zostanie cała ramka, tylko raz. Więc do poprawnego działania w wyslij_wynik trzeba zapisać pierwszą daną do wysłania do rejestru UDR. I nie trzeba całej tej zabawy z włączaniem/wyłączaniem przerwań z USART_UDRE_vect
OdpowiedzUsuńTen komentarz został usunięty przez autora.
UsuńPrzepraszam, mój błąd :) Zapomniałem o sei()
OdpowiedzUsuńChociaż nie do końca. Wpisywanie do rejestru UDR w funkcji wysyłającej jest znacznie bardziej pewne. Bez tego u mnie działa tylko jeśli w szybkim czasie wyśle się kolejny bajt
UsuńA jak wygląda połączenie po stronie komputera? Bo na początku jest napisane że MAX232 ma być po obu stronach komunikacji. Więc do komputera po prostu wpinamy się zwykłym kablem rs232, czy trzeba coś dorabiać?
OdpowiedzUsuńNormalnie zwykłym kablem. Układ konwertujący poziom napięć RS232 znajduje się już w komputerze :)
UsuńMam dwa pytania.
OdpowiedzUsuńW jaki sposób można obsłużyć takie połączenie używając linuxa?
Złożyłem układ i testowałem na windowsie. Jest jednak problem ponieważ procesor transmituje (świecą się kontrolki RXD i TXD) jednak świeci się też kontrolka BREAK. Terminal wyświetla tylko coś takiego: https://dl.dropboxusercontent.com/s/40cp9ldsof2gou0/terminal.PNG
Próbowałem zmniejszać Baud rate ale nic to nie zmienia.
Co do linuxa - nie wiem ale na pewno są jakieś terminale działające w tym systemie.
UsuńCo do drugiego problemu taki efekt jak pokazałeś na screenie (wrzucam kopię, by nie zniknął: ekran terminala), sugeruje błąd polegający na niedopasowaniu boud rate.
Przede wszystkim należy więc sprawdzić, czy prawidłowo ustawiłeś F_CPU w opcjach projektu.
Obecnie pracuję nad projektem zegara RTC, potrzebuję wrzucić sekundy, minuty godziny, dni miesiace, i lata. Z wszystkim oprócz liczby lat sobie radzę, bo zmienne są 8 bitowe ale zmienna year mam w formacie uint16. Jak mógłbym rozwiać ten problem?
OdpowiedzUsuńA konkretnie co chcesz z rokiem zrobić? Przesłać go w formie bajtów, czy tekstu?
UsuńPanowie bardzo wazna rzecz - polaczyc masy komputera i budowanego układu! Czyli w tej wtyczce rs232 puścić oprócz RXD i TXD jeszcze GND. Bez tego, po odłączeniu programatora układ przestaje działać poprawnie!
OdpowiedzUsuńA czego dotyczy Twój komentarza, bo nie bardzo rozumiem?
UsuńNa rysunkach w artykule widać połączenie mas (pin nr 5).
Czy ATmega musi być taktowana zewnętrznych oscylatorem 16MHz?
OdpowiedzUsuńNie, może być inny. Obserwuj warningi - jeżeli ustawisz prędkość transmisji, która przy danym kwarcu będzie powodowała zbyt duży błąd kompilator powiadomi Ciebie o tym właśnie warningiem. Wtedy po prostu wybierz inną prędkość.
UsuńCzy program ten będzie działał również pod FT232R , czyli konwerterze na USB? Z góry dziękuję za pomoc ;)
OdpowiedzUsuńTak, będzie działał.
UsuńUruchamiałem program na ATmega8 i wszystko działa, natomiast na ATmega16 już nie działa. Nawet nie wysyła stringa przy starcie, dlaczego?
OdpowiedzUsuńWitam chętnie również przydałoby sie komunikacja przez porty ethernet. Np z wykorzystaniem modułów ENC28J60
OdpowiedzUsuńPozdrawiam
Dojdziemy i do tego ale nieprędko, bo rozgrzebanych tematów mamy sporo, a czytelnicy już parę razy wytknęli opóźnienia w ich kończeniu :-)
UsuńWitam,
OdpowiedzUsuńmęczę i nie potrafię wymęczyć. Jak za pomocą powyższych funkcji odebrać stringa?
Z góry dziękuję za pomoc! :)
Witam,
OdpowiedzUsuńJa zatem mecze się z tym że w terminalu otrzymuję zamiast liczb jakiedz dziwne szlaczki i przy transmisji swieci mi na czerwono error, układ zmontowany jak powinno być a dupa wszystko. :(
Poradziłeś sobie? Ja walcze z tym samym....
UsuńOpisz konkretniej.
UsuńJuż sobie poradziłem. Chodziło głównie o odpowiednie ustawienie F_CPU i BAUD - w celu zmniejszenia błędu. (8MHz, 9600). Ramka 8N1.
UsuńPojawił się kolejny problem, mianowicie, funkcja nie zwraca mi obliczonej liczby, a znak zapytania. Moduł RS232 działa poprawnie, testowałem go zgodnie z funkcjami w nocie katalogowej Atmegi (str. 135-140 - topornie, bez przerwań).
Przeczytaj ostatni punkt w artykule powyżej :)
Usuńi dlatego na duże odległości ze względu na wyżej opisane problemy zaleca się protokół RS485 znacznie bardziej odporny na zakłócenia, a z punktu widzenia samego UART'a niczym się nie różniący
OdpowiedzUsuńRóżniący się dosyć znacznie - bo jako half-duplex wymaga on sterowania kierunkiem transmisji. Można go zrobić full-duplex ale wymaga to dwóch transceiverów, 4 linii sygnałowych i właściwie tworzymy RS-422.
UsuńTen komentarz został usunięty przez autora.
OdpowiedzUsuńUżyłem wewnętrznego oscylatora 8 MHz, program zostawiłem normalnie. W terminalu dostaje krzaczki.
OdpowiedzUsuńW zakładce Status mam na zielono: CTS, DCD, DSR i Error na czerwono
Gdy coś wysyłam RXD i TXD migają na żółto
Używam przejściówki USB -> RS232 //numer przejsciowki: PL2303HX
Mój problem wynika ze złego taktowania procesora czy z tej przejściówki ?
Dobra to jednak wina konwersji z funkcja dtostrf() dizala poprawnie
UsuńMam przejściówkę USB-TTL USB-STC-ISP z wbudowanym zegarem 12 kHz, ale nie mam akurat kwarcu 16 MHz, żeby podłączyć go do Atmegi, mam tylko 8 MHz. Co zrobić, żeby to działało? I jeszcze program nie chciał się skompilować przez "#include ", musiałem zamienić "\" na "/", po czym nie było errorów, ale były dwa warningi.
OdpowiedzUsuń1. Co może powodować problem "UART receiver framing error". Próbuję się połączyć na ATMEGA8A-PU. Wysyła tylko jakieś śmieci.
OdpowiedzUsuń2. Czy masy zasilania uC i USB-TTL mają być połączone ?
Najczęściej nieprawidłowe taktowanie MCU. A masy zawsze muszą być połączone.
UsuńUżywał ktoś może tego moda firmwaru do USBasp? http://www.ullihome.de/wiki/USBAVRLab/index
OdpowiedzUsuńwygląda dość interesująco: obsługa USART przez USB, oscyloskop i wiele innych zainstalowanych w programatorze funkcjonalności.
ATMEGA8 jest chyba jednym z lepszych mikrokontrolerów do nauki.
OdpowiedzUsuń