Mikrokontrolery - Jak zacząć?

... czyli zbiór praktycznej wiedzy dot. mikrokontrolerów.

wtorek, 29 marca 2011

RS-232: Komunikacja ATmega8 z komputerem

Autor: Dondu

Interfejs RS-232 na USART.
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:

Interfejs RS-232 - Krzyżowanie sygnałów RxD i TxD.


Należy o tym pamiętać w szczególności, że standardowe przewody łączące mogą być dwojakiego rodzaju:

Interfejs RS-232 - Rodzaje przewodów łączących.

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.

Pinologia złącza RS-232 w wersji D-SUB 9.
Ź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ż:

RS-232 - ATmega8 - Prędkości transmisji zależnie od częstotliwości zegara taktującego mikrokontroler.

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:


RS-232 - ATmega8 - Wzory obliczania wartości rejestru UBRR.


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:

RS-232 - Ramka danych modułu USART.
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]
1920016
9600160
4800320
24001000

Ź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:


MAX232 - Schemat blokowy.

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ń:


MAX232 - Prawidłowe podłączenie układu.


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:
  1. kondensator C4 ma z pozoru nieprawidłową polaryzację, ale wynika ona z faktu, że na pinie V- jest napięcie ujemne(!).
  2. 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:
MAX232 - wymagania dot. kondensatorów.
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:

RS-232 - Konwerter napięć na tranzystorach.


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:

ATmega 8 - przykład wykorzystania interfejsu RS-232 do komunikacji z komputerem.


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.
Czyli będzie to prosty koprocesor.


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:

RealTerm - Ustawienia w zakładce Display.

Następnie w zakładce Port ustawiamy takie same parametry transmisji jakie ustawiliśmy w programie mikrokontrolera:

RealTerm - Ustawienia w zakładce Port.

Włączamy nasz mikrokontroler i naszym oczom powinien ukazać się przesłany przez niego tekst wzoru:

RealTerm - Odbiór danych z mikrokontrolera.

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:

RealTerm - Wysłanie danej do mikrokontrolera.

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:
  1. zapominanie o tym, iż w niektórych mikrokontrolerach dwa różne rejestry mogą być pod tym samym adresem, patrz: Pułapki AVR'ów,
  2. ustawienie różnych parametrów transmisji w obu urządzeniach,
  3. stosowanie niestabilnego (niedokładnego) źródła zegara taktującego mikrokontroler, szczególnie w przypadku pracy USART w trybie asynchronicznym,
  4. błędne połączenie urządzeń w zależności od posiadanego przewodu (prosty lub krzyżowy),
  5. zbyt długi przewód łączący oba urządzenia w stosunku do wybranej prędkości transmisji,
  6. kiepskiej jakości przewody,
  7. zbyt duże zakłócenia zewnętrzne.
Pomocne w rozwiązywaniu problemów komunikacji jest okienko Status:

RealTerm - Okienko statusu linni RS-232.

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

Oceń artykuł.
Wasze opinie są dla nas ważne, gdyż pozwalają dopracować poszczególne artykuły.
Pozdrawiamy, Autorzy
Ten artykuł oceniam na:

98 komentarzy:

  1. To teraz proszę dla USB przez układ FT232 :)

    OdpowiedzUsuń
  2. Witam, świetny artykuł.
    Ja także dołączam się do prośby o tekst objaśniający komunikację przez USB, pozdrawiam

    OdpowiedzUsuń
  3. Witam,

    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.

    OdpowiedzUsuń
  4. 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.

    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.

    OdpowiedzUsuń
  5. Dopisałem i dodałem kalkulator.

    OdpowiedzUsuń
  6. Ten koprocesor, to istny wymiatacz ;-)

    OdpowiedzUsuń
  7. Fajny artykuł, prosiłbym tylko o umieszczenie tego "NEW" na głównej stronie:)

    OdpowiedzUsuń
  8. 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ń
  9. 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.

    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?

    OdpowiedzUsuń
  10. Jakie masz napięcia zasilania modemu i uC?
    Czy masz jakiś konwerter poziomów napięć?

    Do komunikacji z modemem spróbuj używać tego terminala https://sites.google.com/site/terminalbpp/

    OdpowiedzUsuń
  11. 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. ;)

    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.

    OdpowiedzUsuń
  12. 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ń
  13. 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ń
  14. 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ń
  15. Tutaj datasheet ze strony Maxim Integrated:
    http://datasheets.maximintegrated.com/en/ds/MAX220-MAX249.pdf
    Na stronie 17 widać, że C3 jest podłączony do +5V

    OdpowiedzUsuń
  16. 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ń
  17. 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ń
  18. Dokładnie tak jak piszesz:)

    OdpowiedzUsuń
  19. 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ń
  20. Nigdzie nie jest napisane gdzie podłączyć pozostałe piny we wtyczce RSa :/

    OdpowiedzUsuń
  21. Bo w tym przykładzie nie trzeba :-)

    OdpowiedzUsuń
  22. Przydałby się jakiś opis pozostałych pinów bo z nazw ciężko się domyślić :)

    OdpowiedzUsuń
  23. 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ń
  24. Skoro śmiga w jedną stronę poprawnie, a nie odbiera to wskazuje na prawidłowe ustawienia USART i prawidłowe podłączenie w jedną stronę.

    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.

    OdpowiedzUsuń
  25. 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ń
  26. Zaraz sprawdzę załączony projekt AVR i dam znać.

    OdpowiedzUsuń
  27. 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

    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?

    OdpowiedzUsuń
  28. 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ń
  29. Ja mam konwerter na tranzystorach jak na schemacie w artykule - spróbuj zlutować "na pająka" :-)

    Teraz uciekam - będę dopiero jutro wieczorem. Napisz o rezultatach. Hej!

    OdpowiedzUsuń
  30. 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.

    korzystam z atmega8 i konwertera usb<->rs232 na ukladzie ft232r.

    Jezeli ktos ma pomysl jak to rozwiazac bede bardo wdzieczny.

    OdpowiedzUsuń
  31. 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.

    Zatem moje pytanie czy ktos wie dlaczego funkcja sprintf moze nie dzialac prawidlowo?

    OdpowiedzUsuń
    Odpowiedzi
    1. 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ń
    2. 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.

      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

      Usuń
    3. 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.

      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.

      Usuń
  32. 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.

    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

    OdpowiedzUsuń
    Odpowiedzi
    1. 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.
      Pozdrawiam.

      Usuń
  33. Witam.Bardzo dobry i przydatny projekt czy można prosić o przerobienie na Atmege 32.Używam Eclipse.
    Pozdrawiam serdecznie.

    OdpowiedzUsuń
    Odpowiedzi
    1. Witaj.

      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.

      Usuń
  34. Witam.Uruchomiłem na A32 kwarc zew.16MHz ale nie działa prawidłowo objawy:
    - wrzuca wzór ale kończy "krzaczkiem"CrLf
    - wysłanie liczby wyświetla ? + CrLf
    Pozdrawiam serdecznie.
    Ps.Jak wkleić zrzut ekr.

    OdpowiedzUsuń
    Odpowiedzi
    1. 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.

      Pliki proponuję wrzucić na imageshack.com a tutaj podać link. Niestety nie ma innej możliwości.

      Usuń
    2. ... zobacz także trzeci zrzut ekranu terminala w artykule powyżej.

      Usuń
    3. Krzaczki usunięte ale wysłanie liczby daje efekt w postaci "?"
      Spróbuje wrzucić pliki z kompilacji i zrzut ekr. jak podałeś.

      Usuń
    4. 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)

      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.

      Usuń
  35. [IMG]http://imageshack.us/a/img836/7462/etqu.jpg[/IMG]
    [IMG]http://imageshack.us/a/img46/4686/0a94.jpg[/IMG]

    OdpowiedzUsuń
    Odpowiedzi
    1. 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ń
    2. Tak są ustawione na 4800 , spróbuję na 57600 i odpowiem.

      Usuń
  36. Witam,

    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.

    OdpowiedzUsuń
  37. 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).

    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

    OdpowiedzUsuń
  38. Jeśli do komunikacji za pomocą USART wykorzystujemy przerwania USART_RXC_vect i USART_UDRE_vect, to nie jest potrzebne czekanie na
    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

    OdpowiedzUsuń
    Odpowiedzi
    1. 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.

      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?

      Usuń
  39. Zrobiłbyś artykuł o bezprzewodowym RS232? Pozdrawiam

    OdpowiedzUsuń
  40. 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 :)
    Pozdrawiam

    OdpowiedzUsuń
    Odpowiedzi
    1. 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.
      Tak przynajmniej jest napisane w książce pana Francuza "Język C dla mikrokontrolerów AVR", a to raczej sprawdzona pozycja.

      Usuń
  41. 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ń
  42. 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ń
    Odpowiedzi
    1. 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ń
    2. 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ń
  43. 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ń
    Odpowiedzi
    1. 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ń
    2. ... a konkretnie:

      "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."

      Usuń
  44. 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:

    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.

    OdpowiedzUsuń
  45. 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ń
  46. Przepraszam, mój błąd :) Zapomniałem o sei()

    OdpowiedzUsuń
    Odpowiedzi
    1. 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ń
  47. 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ń
    Odpowiedzi
    1. Normalnie zwykłym kablem. Układ konwertujący poziom napięć RS232 znajduje się już w komputerze :)

      Usuń
  48. Mam dwa pytania.
    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.

    OdpowiedzUsuń
    Odpowiedzi
    1. Co do linuxa - nie wiem ale na pewno są jakieś terminale działające w tym systemie.

      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.

      Usuń
  49. 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ń
    Odpowiedzi
    1. A konkretnie co chcesz z rokiem zrobić? Przesłać go w formie bajtów, czy tekstu?

      Usuń
  50. 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ń
    Odpowiedzi
    1. A czego dotyczy Twój komentarza, bo nie bardzo rozumiem?
      Na rysunkach w artykule widać połączenie mas (pin nr 5).

      Usuń
  51. Czy ATmega musi być taktowana zewnętrznych oscylatorem 16MHz?

    OdpowiedzUsuń
    Odpowiedzi
    1. 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ń
  52. Czy program ten będzie działał również pod FT232R , czyli konwerterze na USB? Z góry dziękuję za pomoc ;)

    OdpowiedzUsuń
  53. 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ń
  54. Witam chętnie również przydałoby sie komunikacja przez porty ethernet. Np z wykorzystaniem modułów ENC28J60

    Pozdrawiam

    OdpowiedzUsuń
    Odpowiedzi
    1. 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ń
  55. Witam,

    męczę i nie potrafię wymęczyć. Jak za pomocą powyższych funkcji odebrać stringa?

    Z góry dziękuję za pomoc! :)

    OdpowiedzUsuń
  56. Witam,
    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. :(

    OdpowiedzUsuń
    Odpowiedzi
    1. Poradziłeś sobie? Ja walcze z tym samym....

      Usuń
    2. Już sobie poradziłem. Chodziło głównie o odpowiednie ustawienie F_CPU i BAUD - w celu zmniejszenia błędu. (8MHz, 9600). Ramka 8N1.

      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ń).

      Usuń
    3. Przeczytaj ostatni punkt w artykule powyżej :)

      Usuń
  57. 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ń
    Odpowiedzi
    1. 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ń
  58. Ten komentarz został usunięty przez autora.

    OdpowiedzUsuń
  59. Użyłem wewnętrznego oscylatora 8 MHz, program zostawiłem normalnie. W terminalu dostaje krzaczki.

    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 ?

    OdpowiedzUsuń
    Odpowiedzi
    1. Dobra to jednak wina konwersji z funkcja dtostrf() dizala poprawnie

      Usuń
  60. 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ń
  61. 1. Co może powodować problem "UART receiver framing error". Próbuję się połączyć na ATMEGA8A-PU. Wysyła tylko jakieś śmieci.
    2. Czy masy zasilania uC i USB-TTL mają być połączone ?

    OdpowiedzUsuń
    Odpowiedzi
    1. Najczęściej nieprawidłowe taktowanie MCU. A masy zawsze muszą być połączone.

      Usuń
  62. Używał ktoś może tego moda firmwaru do USBasp? http://www.ullihome.de/wiki/USBAVRLab/index
    wygląda dość interesująco: obsługa USART przez USB, oscyloskop i wiele innych zainstalowanych w programatorze funkcjonalności.

    OdpowiedzUsuń
  63. ATMEGA8 jest chyba jednym z lepszych mikrokontrolerów do nauki.

    OdpowiedzUsuń

Działy
Działy dodatkowe
Inne
O blogu




Dzisiaj
--> za darmo!!! <--
1. USBasp
2. microBOARD M8


Napisz artykuł
--> i wygraj nagrodę. <--


Co nowego na blogu?
Śledź naszego Facebook-a



Co nowego na blogu?
Śledź nas na Google+

/* 20140911 Wyłączona prawa kolumna */
  • 00

    dni

  • 00

    godzin

  • :
  • 00

    minut

  • :
  • 00

    sekund

Nie czekaj do ostatniego dnia!
Jakość opisu projektu także jest istotna (pkt 9.2 regulaminu).

Sponsorzy:

Zapamiętaj ten artykuł w moim prywatnym spisie treści.