Kursy • Poradniki • Inspirujące DIY • Forum
Tworząc system, w którym mikrokontroler będzie współpracował z innymi urządzeniami, należy w jakiś sposób przesyłać między nimi dane.
Bardzo częstym rozwiązaniem, które implementują konstruktorzy jest UART. W tym odcinku skupimy się na opisie tego interfejsu od strony teoretycznej oraz praktycznej z użyciem kreatora Cube oraz bibliotek HAL.
USART / UART (ang. Universal Synchronous and Asynchronous Receiver and Transmitter) służy do przesyłania danych pomiędzy urządzeniami. Znaleźć można go na wyposażeniu praktycznie każdego mikrokontrolera.
Bardzo często zamiennie używane są dwie nazwy nazwy:
USART oraz UART, co może być mylące.
Litera S oznacza możliwość zrealizowania komunikacji w trybie synchronicznym, a więc takim, w którym bity przesyłane są w takt zegara podawanego na dedykowanej do tego linii sygnałowej. USART pozwala więc na komunikację zarówno synchroniczną jak i asynchroniczną.
My natomiast korzystać będziemy tylko z komunikacji asynchronicznej,
będziemy więc mówić o komunikacji przez UART.
UART pozwala na komunikację typu Full-Duplex. Oznacza to, że dane mogą być jednocześnie nadawane i odbierane. Do komunikacji w takim trybie niezbędne są (co najmniej) trzy linie. Dwie linie transmisyjne - Tx, Rx oraz wspólna masa (GND).
Żeby zrozumieć co ustawiamy w dalszej części konfiguracyjnej, powinniśmy poznać najpierw podstawy działania tego interfejsu. UART ma dwa wyprowadzenia odpowiadające za transmisję i odbieranie danych (Tx oraz Rx).
Wysyłając dane na linii transmisji (Tx) zaczną pojawiać się odpowiednio stany niskie i wysokie. Jakie, kiedy i dlaczego? Aby odpowiedzieć na te pytania, trzeba poznać budowę ramki!
Ramka danych jest odgórnie ustaloną sekwencją znaków, które muszą się pojawić w określonej kolejności podczas komunikacji. Obie strony transmisji (urządzenie nadawcze i odbiorcze) muszą znać parametry tej ramki, aby komunikacja przebiegła pomyślnie.
Ramka UART.
Mam nadzieję że przedstawiona tu teoria nie znudziła was do reszty. Jestem pewny, że dzięki tej odrobinie informacji dalsza część artykułu będzie bardziej zrozumiała.
Aby przetestować UART w praktyce będziemy potrzebować konwertera USB-UART, który możecie znaleźć na wyposażeniu zestawu przygotowanego specjalnie na potrzeby tego kursu.
Komplet elementów Gwarancja pomocy Wysyłka w 24h
Zestaw elementów do przeprowadzenia wszystkich ćwiczeń z kursu STM32 F4 można nabyć u naszego dystrybutora! Zestaw zawiera m.in. płytkę Discovery, wyświetlacz OLED, joystick oraz enkoder.
Zamów w Botland.com.pl »Przejdźmy w takim razie do rzeczy i użyjmy UARTa w praktyce!
Krok 1. Tworzymy nowy projekt i konfigurujemy zegar na maksymalną częstotliwość.
Więcej o konfiguracji zegara znaleźć można w poprzedniej części kursu.
Krok 2. Włączamy peryferium USART 1 w trybie asynchronicznym.
Uruchomienie UARTa w odpowiednim trybie.
Zauważ, że po włączeniu UARTA na podglądzie natychmiast pojawiły się wyprowadzenia TX oraz RX. Co, gdy nie podoba nam się ich umiejscowienie i chcielibyśmy wyprowadzić je gdzieś indziej?
Rodzina F4 umożliwia tzw. pin remapping, funkcja ta pozwala na wyprowadzenie peryferii w więcej niż jednym miejscu. Żeby sprawdzić gdzie jeszcze możemy wyprowadzić linie Tx oraz Rx, wystarczy wcisnąć i przytrzymać Ctrl, a następnie kliknąć lewym przyciskiem myszy na wyprowadzenie mikrokontrolera, które chcielibyśmy przenieść w inne miejsce.
Zmiana wyprowadzeń obsługujących transmisję.
Czerwonym prostokątem zaznaczony jest kliknięty z klawiszem Ctrl pin PA10. Na niebiesko oznaczono wyprowadzenia PB3 i PB7, które zostały podświetlone podczas kliknięcia.
Takie podświetlenie oznacza, że na te wyprowadzenia może zostać
przeniesiona funkcjonalność aktualnie klikniętego pinu.
Spróbujmy w takim razie przenieść Rx oraz Tx na górną stronę mikrokontrolera. Dzięki poznanemu przed chwilą mechanizmowi wiemy, które wyprowadzenia udostępniają taką możliwość. Aby to zrobić, wystarczy kliknąć na któryś z dozwolonych pinów i wybrać odpowiednią funkcjonalność.
Efekt finalny remappingu.
Wybrany tryb zostanie automatycznie wyłączony na poprzednim pinie i przeniesiony w nowe miejsce. To samo możemy zrobić z pinem Tx.
Zmiana pinów dla komunikacji przez UART.
W efekcie dokonaliśmy remappingu pinów i przenieśliśmy UARTa na górną stronę mikrokontrolera.
Krok 3. Przechodzimy do panelu konfiguracyjnego UARTa.
Panel konfiguracji UART.
Dostępne prędkości są dla nas wystarczające, pozostawiamy więc ten parametr z domyślną wartością, czyli 16.
Jak widać, konfiguracja UARTa wymaga od nas jedynie jego włączenia, ponieważ wszystkie domyślne wartości to standardowo używane w większości przypadków parametry transmisji.
Z UARTa można korzystać w 3 trybach. Blokującym, na przerwaniach oraz z wykorzystaniem DMA. Ze względu na to, że tryby wykorzystujące przerwania i DMA są o wiele wygodniejsze i łatwiejsze w użytkowaniu niż tryb blokujący, na nich skupię się w tym artykule.
Krok 4. Uruchamiamy przerwania dla UARTA.
Uruchomienie przerwań dla UARTA.
Krok 5. Konfigurujemy odpowiednie wyjście GPIO, aby móc sygnalizować zdarzenia zapalaniem i gaszeniem wybranej diody LED. Jeżeli nie wiesz jak to zrobić, wróć do artykułu na temat GPIO.
Krok 6. Konfigurujemy licznik (timer) tak, aby generował przerwanie z częstotliwością 1Hz. Jeżeli nie wiesz jak zrealizować ten punkt, wróć do artykułu o licznikach.
Krok 5. Generujemy projekt pod nazwą 04_UART i importujemy go do IDE.
Naszym pierwszym zadaniem będzie cykliczne przesyłanie wiadomości do komputera.
Krok 1. Załóżmy, że chcemy przesyłać do komputera wiadomości zawierające informację o swoim (kolejnym) numerze. Potrzebujemy więc tablicy przechowującej naszą wiadomość oraz zmienną będącą licznikiem.
|
61 62 63 |
static uint16_t cnt = 0; // Licznik wyslanych wiadomosci uint8_t data[50]; // Tablica przechowujaca wysylana wiadomosc. uint16_t size = 0; // Rozmiar wysylanej wiadomosci |
Rozmiar tablicy do przechowywania danych musi być większy od długości wiadomości, które zamierzamy przesyłać. Należy go dobrać do własnych potrzeb.
Zmienna size będzie zawierać liczbę znaków, które znajdują się w wysyłanej wiadomości. Przyda nam się to później przy samym wysyłaniu.
Krok 2. Teraz musimy zawrzeć wysyłaną wiadomości w zmiennej data. Funkcja pozwalająca na takie działania to sprintf.
|
65 66 |
++cnt; // Zwiekszenie licznika wyslanych wiadomosci. size = sprintf(data, "Liczba wyslanych wiadomosci: %d.\n\r", cnt); // Stworzenie wiadomosci do wyslania oraz przypisanie ilosci wysylanych znakow do zmiennej size. |
W linii 66 do zmiennej data wpisywana jest wiadomość "Liczba wyslanych wiadomosci: ", a następnie wpisana jest wartość zmiennej cnt. Funkcja sprintf zwraca ilość zapisanych znaków, stąd przypisanie do zmiennej size.
Składnia funkcji sprintf jest taka sama, jak używanej w języku C funkcji printf.
Co oznaczają znaki \n\r? Aby wiadomości wyświetlające się w terminalu były dla nas bardziej przejrzyste, musimy na nim wymusić zakończenie każdej wiadomości przejściem do nowej linii.
Znak \n oznacza LF - Line Feed i wymusza przejście kursora do nowej linii. Znak \r to CR - Carriage Return, czyli znak powrotu karetki. Dzięki niemu kursor po przejściu do nowej linii wraca również na jej początek.
Krok 3. Na końcu pozostało nam wysłać stworzoną wiadomość i zakomunikować rozpoczęcie transmisji zmianą stanu diody świecącej (LED).
Samodzielne odszukanie odpowiedniej funkcji do transmisji za pomocą UARTa jest bardzo proste. Wpisujemy standardowo HAL_UART, wciskamy ctrl+spacja i przeszukujemy wyświetlone podpowiedzi.
|
68 69 |
HAL_UART_Transmit_IT(&huart1, data, size); // Rozpoczecie nadawania danych z wykorzystaniem przerwan HAL_GPIO_TogglePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin); // Zmiana stanu pinu na diodzie LED |
Pierwszym parametrem funkcji HAL_UART_Transmit_IT adres struktury konfiguracyjnej. Jako drugi podajemy adres tablicy, która zawiera wiadomość do przesłania. Ostatnim parametrem jest ilość znaków, jaką należy przesłać
Krok 4. Cały powyższy kod umieszczamy w funkcji obsługi przerwania cyklicznego od timera.
|
57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 |
/* USER CODE BEGIN PFP */ /* Private function prototypes -----------------------------------------------*/ void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim) { static uint16_t cnt = 0; // Licznik wyslanych wiadomosci uint8_t data[50];// Tablica przechowujaca wysylana wiadomosc. uint16_t size = 0; // Rozmiar wysylanej wiadomosci ++cnt; // Zwiekszenie licznika wyslanych wiadomosci. ++cnt; // Zwiekszenie licznika wyslanych wiadomosci. size = sprintf(data, "Liczba wyslanych wiadomosci: %d.\n\r", cnt); // Stworzenie wiadomosci do wyslania oraz przypisanie ilosci wysylanych znakow do zmiennej size. HAL_UART_Transmit_IT(&huart1, data, size); // Rozpoczecie nadawania danych z wykorzystaniem przerwan HAL_GPIO_TogglePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin); // Zmiana stanu pinu na diodzie LED } /* USER CODE END PFP */ |
Krok 5. Pozostało nam już tylko uruchomić licznik tak, aby generował przerwania cykliczne.
|
95 96 97 |
/* USER CODE BEGIN 2 */ HAL_TIM_Base_Start_IT(&htim11); /* USER CODE END 2 */ |
Krok 6. Budujemy i wgrywamy program na płytkę. Po uruchomieniu, dioda powinna zmieniać swój stan (co sekundę).
Miganie wybranej diody - informacja o wysyłaniu danych (przykładowa animacja).
Krok 1. Łączymy linie Tx oraz Rx płytki z naszym konwerterem.
Połączenie zestawu Discovery z konwerterem UART.
Uwaga! Podłączając linie Tx/Rx zawsze należy je ze sobą zamienić. Wynika to z tego, że linia Transmit (Tx) mikrokontrolera nadaje dane, a linia Receive (Rx) konwertera będzie je odbierać. Oczywiście działa to analogicznie w drugą stronę.
Schemat połączenia linii Tx oraz Rx.
Wynika z tego, że przy obecnej konfiguracji podłączymy pin PB6 (Tx) mikrokontrolera z pinem Rx konwertera/modułu bluetooth. Linię PB7 (Rx) łączymy z wyprowadzeniem Tx konwertera.
Poza liniami transmisyjnymi trzeba połączyć ze sobą masy układów,
a więc wyprowadzenia GND.
Krok 2. Otwieramy menedżer urządzeń. Aby to zrobić klikamy prawym przyciskiem myszy na Mój komputer i wybieramy Zarządzanie komputerem. Otwieramy zakładkę:
Menedżer urządzeń > Porty (COM i LPT)
Podgląd dostępny portów COM.
Krok 3. Podłączamy konwerter do portu USB w komputerze. Sprawdzamy nazwę i numer portu COM, który się pojawił po podłączeniu sprzętu.
Pojawienie się nowego urządzenia.
W moim wypadku jest to Prolific USB-to-Serial Comm Port, któremu został przypisany numer portu COM7. Ta informacja przyda się zaraz przy konfiguracji oprogramowania.
Aby sprawdzić co wysyła mikrokontroler, musimy zaopatrzyć się w oprogramowanie umożliwiające odbieranie i wysyłanie danych poprzez port szeregowy. Skorzystamy z programu RealTerm.
Krok 1. Pobieramy najnowszą wersję programu (w momencie pisania kursu jest to 2.0.0.70).
Krok 2. Instalujemy program.
Krok 3. Uruchamiamy RealTerma jako administrator.
Uruchomienie w trybie normalnym może generować problemy.
Uruchamiamy program jako administrator.
Krok 4. Przechodzimy do zakładki Port i zmieniamy parametry transmisji na takie, które ustawiliśmy konfigurując UART w mikrokontrolerze.
Rozwijana lista dostępnych wartości Baud Rate zawiera
większość standardowo używanych prędkości transmisji.
Zmieniamy wartość Baud Rate na 115200. Port zmieniamy na ten, który został przypisany naszemu konwerterowi (sprawdzaliśmy to wcześniej w menadżerze urządzeń). Reszta ustawień domyślnie jest zgodna z tym co ustawiliśmy w Cube. Na końcu klikamy przycisk Change żeby nasze ustawienia zostały wdrożone do otwartego kanału komunikacyjnego.
Uruchomienie transmisji.
W obszarze zaznaczonym na niebiesko przedstawione są obecne parametry transmisji. Skrót 8N1 oznacza 8 bitów danych, 0 bitów parzystości i 1 bit stopu.
Taki zapis jest bardzo popularny i często stosowany
przy opisie parametrów transmisji UART.
Jeżeli wszystkie przedstawione dotąd instrukcje wykonaliśmy poprawnie, wraz z kliknięciem przycisku Change w terminalu powinny się zacząć pojawiać odbierane wiadomości.
Zauważmy, że po każdej z nich znaki nowej linii (LF - Line Feed) oraz powrotu kursora na początek linii (CR - Carriage Return) są widoczne. Aby takie znaki nie były wyświetlane, wystarczy zmienić tryb wyświetlania danych na ANSI.
Podgląd wyświetlanych danych.
Dodatkowo na powyższym obrazku zaznaczone są trzy przydatne sekcje. W zielonym prostokącie znajdują się parametry terminala wyświetlającego odebrane dane. Domyślnie jest to 16 linii o szerokości 80 znaków.
W obszarze zaznaczonym na niebiesko znajduje się pole oznaczające odbieranie danych. Zauważmy, że co sekundę rozświetla się ono na bardzo krótko. Taki sam rodzaj komunikowania stosowany jest w konwerterach UART - na naszym jest to czerwona dioda LED opisana jako RXD.
Bardzo prostą lecz przydatną funkcjonalność dostarcza oznaczony na fioletowo przycisk Clear. Pozwala on na wyczyszczenie aktualnej zawartości terminala.
Potrafimy już przesyłać dane z mikrokontrolera i wyświetlać je na komputerze. Teraz spróbujemy odebrać dane wysłane z komputera.
Krok 1. Pierwszą rzeczą jaką zrobimy będzie zadeklarowanie zmiennej do przechowywania odebranych danych.
|
45 46 47 48 |
/* USER CODE BEGIN PV */ /* Private variables ---------------------------------------------------------*/ uint8_t Received; /* USER CODE END PV */ |
Krok 2. Teraz musimy uruchomić nasłuchiwanie na kanale UART. Służy do tego funkcja Receive.
|
107 108 109 |
/* USER CODE BEGIN 2 */ HAL_UART_Receive_IT(&huart1, &Received, 1); /* USER CODE END 2 */ |
Pierwszym parametrem funkcji jest standardowo wskaźnik na strukturę konfiguracyjną. Drugim jest wskaźnik na obszar pamięci, do którego będą wpisywane dane. Trzeci parametr, to oczekiwany rozmiar wiadomości, innymi słowy - ilość odebranych znaków, po których zostanie wywołane przerwanie.
W tym miejscu mamy dwie możliwości.
W dalszej części artykułu zaprezentowane zostaną
przykłady obydwu zastosowań.
Krok 3. Po odebraniu konkretnej liczby znaków (sprecyzowanej w parametrze wywołania funkcji Receive) wywołane zostaje przerwanie, które możemy obsłużyć funkcją:
|
1 |
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) |
Poza funkcją RxCpltCallback (Receive Complete Callback), do dyspozycji mamy podobną funkcję TxCpltCallback, która zostanie wywołana po zakończeniu transmisji danych. Jeżeli dla jakiegoś zastosowania taka informacja byłaby przydatna, w ten sposób można ją otrzymać.
W tym przykładzie będziemy wysyłać do mikrokontrolera bardzo proste instrukcje sterujące. Znak 0 oznaczać będzie wiadomość STOP, a 1 oznaczać będzie START. Zadaniem programu będzie sygnalizacja obecnego stanu diodą LED oraz odesłanie odebranej instrukcji z powrotem.
Obsługa przerwania dla tego zadania będzie wyglądać następująco.
|
56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 |
/* USER CODE BEGIN PFP */ /* Private function prototypes -----------------------------------------------*/ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { uint8_t Data[50]; // Tablica przechowujaca wysylana wiadomosc. uint16_t size = 0; // Rozmiar wysylanej wiadomosci // Odebrany znak zostaje przekonwertowany na liczbe calkowita i sprawdzony // instrukcja warunkowa switch (atoi(&Received)) { case 0: // Jezeli odebrany zostanie znak 0 size = sprintf(Data, "STOP\n\r"); HAL_GPIO_WritePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin, GPIO_PIN_RESET); break; case 1: // Jezeli odebrany zostanie znak 1 size = sprintf(Data, "START\n\r"); HAL_GPIO_WritePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin, GPIO_PIN_SET); break; default: // Jezeli odebrano nieobslugiwany znak size = sprintf(Data, "Odebrano nieznany znak: %c\n\r", Received); break; } HAL_UART_Transmit_IT(&huart1, Data, size); // Rozpoczecie nadawania danych z wykorzystaniem przerwan HAL_UART_Receive_IT(&huart1, &Received, 1); // Ponowne włączenie nasłuchiwania } /* USER CODE END PFP */ |
Aby przetestować działanie powyższego mechanizmu, przechodzimy do zakładki Send w programie RealTerm. Wpisujemy wiadomość w pole zaznaczone na czerwono i wysyłamy przyciskiem Send ASCII.
Wysyłanie wiadomości z komputera.
W terminalu możemy zaobserwować działanie naszego programu. Dodatkowo dioda LED na płytce Discovery sygnalizuje w jakim stanie (START/STOP) znajduje się aktualnie nasz program.
Jaki problem wynika z takiego podejścia? Jeżeli do mikrokontrolera zostanie wysłana wiadomość składająca się z większej ilość znaków, przerwanie zostanie wywołane wielokrotnie w bardzo krótkim czasie, co spowoduje błędy. Żeby to sprawdzić, wystarczy wysłać z RealTerma wiadomość składającą się z kilku znaków.
Wysłanie zbyt długiej wiadomości.
Aby zapobiec takiej sytuacji, wystarczy sprecyzować, że przerwanie ma się wywołać po odebraniu większej ilości znaków. W takiej sytuacji najpierw odbierana jest cała wiadomość, a dopiero po zakończeniu całego procesu zostaje wywołane przerwanie.
Problem jaki się tu pojawia, to znajomość konkretnej ilości znaków,
które zostaną przesłane w wiadomości.
Czemu? Załóżmy, że uruchamiamy nasłuchiwanie i oczekujemy wiadomości o długości 10.
Tablica odbieranych danych. Żadne dane nie zostały jeszcze odebrane (pusta tablica).
Wiadomość, która jest do nas wysłana ma tylko 7 znaków. W takiej sytuacji dane zostają odebrane i zapisane w tablicy, ale przerwanie informujące nas o zakończeniu transmisji nie zostanie wywołane.
Tablica odbieranych danych. Odebrano wiadomość o długości 7. Brak przerwania.
Przypuśćmy, że zostanie do nas wysłana kolejna wiadomość. Tym razem składająca się z 2 znaków. W buforze mamy 7 znaków, więc teraz będzie ich 9. Ponieważ oczekujemy odebrania 10 znaków, przerwanie nadal się nie wywoła, chociaż mamy już dwie odebrane wiadomości w buforze.
Tablica odbieranych danych. Odebrano drugą wiadomość o długości 2. Brak przerwania.
Kolejna wiadomość, która nadejdzie ma długość 4 znaków. Co się stanie w tym momencie? Po odebraniu pierwszego znaku nowej wiadomości w buforze będzie 10 znaków, a więc tyle ile oczekujemy. Zostaje wywołane przerwanie.
Tablica odbieranych danych. Odebrano pierwszy znak trzeciej wiadomości. Przerwanie wywołane.
Tym samym bufor jest zerowany. W odbieranej wiadomości pozostały jednak jeszcze 3 znaki, które zostają wpisane do pustego bufora.
Tablica odbieranych danych. Bufor został wyzerowany. Wpisano do niego pozostałe znaki trzeciej wiadomości. Brak przerwania.
Odebraliśmy 3 wiadomości, otrzymując powiadomienie w formie przerwania w środku ostatniej. Tym samym dostajemy bufor zawierający dwie pełne i kawałek trzeciej wiadomości. Jak to teraz obsłużyć? Cała sytuacja jest zupełnie bez sensu...
Na szczęście rozwiązanie tego problemu jest bardzo proste. Wystarczy zawsze wysyłać wiadomości o tej samej, wcześniej sprecyzowanej dla obydwu stron transmisji, długości.
Zmusza nas to jednak do tworzenia ramek wiadomości o takiej samej długości, co wydaje się bardzo problematyczne. Istnieje jednak bardzo prosty mechanizm pozwalający na ominięcie tego problemu, który opisałem poniżej.
Spróbujmy więc przetestować przedstawione rozwiązanie w praktyce! Pierwszą zmianą jaką musimy dokonać jest przekształcenie zmiennej przechowującej odebrany znak w tablicę.
|
145 146 147 148 |
/* USER CODE BEGIN PV */ /* Private variables ---------------------------------------------------------*/ uint8_t Received[10]; /* USER CODE END PV */ |
Następnie modyfikujemy zawartość przerwania tak, aby odebrana wiadomość była odsyłana z krótkim dopiskiem.
|
56 57 58 59 60 61 62 63 64 65 66 67 68 69 |
/* USER CODE BEGIN PFP */ /* Private function prototypes -----------------------------------------------*/ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { uint8_t Data[40]; // Tablica przechowujaca wysylana wiadomosc. uint16_t size = 0; // Rozmiar wysylanej wiadomosci size = sprintf(Data, "Odebrana wiadomosc: %s\n\r",Received); HAL_UART_Transmit_IT(&huart1, Data, size); // Rozpoczecie nadawania danych z wykorzystaniem przerwan HAL_UART_Receive_IT(&huart1, Received, 10); // Ponowne włączenie nasłuchiwania HAL_GPIO_TogglePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin); } /* USER CODE END PFP */ |
Ostatnia modyfikacja czeka nas w funkcji main, gdzie trzeba zaktualizować parametry wywołania funkcji rozpoczynającej nasłuchiwanie do naszych aktualnych wymagań.
|
93 94 95 |
/* USER CODE BEGIN 2 */ HAL_UART_Receive_IT(&huart1, Received, 10); /* USER CODE END 2 */ |
Teraz możemy przetestować działanie nowo stworzonego mechanizmu wysyłając wiadomość o długości 10 znaków z RealTerm.
Wysyłanie większej ilości znaków.
Zauważmy, że za każdym razem wysyłamy z mikrokontrolera dokładnie tyle znaków, z ilu składa się wiadomość. Możemy tak zrobić odczytując wartość zwracaną przez funkcję sprintf i podając ją następnie jako parametr funkcji transmitującej dane.
|
1 2 |
size = sprintf(Data, "Odebrana wiadomosc: %s\n\r", Received); HAL_UART_Transmit_IT(&huart1, Data, size); // Rozpoczecie nadawania danych z wykorzystaniem przerwan |
W celu wykonania pewnego testu, zmieńmy tryb wyświetlania danych z powrotem na ASCII.
Zmiana trybu wyświetlania danych.
Dzięki temu będziemy widzieć wszystkie odbierane przez RealTerm znaki. W tym wypadku, poza znakami standardowej wiadomości będą to tylko znaki CR i LF, wyświetlane w terminalu przy ustawieniu ASCII. Dzięki temu widzimy, że wysyłamy dokładnie tyle znaków, ile mają wszystkie znaki użyteczne wiadomości plus dodane znaki nowej linii.
Podgląd odebranych danych.
Ta informacja przyda nam się zaraz w porównaniu do innego przykładu. Jeżeli jednak chcielibyśmy komunikować się z innym mikrokontrolerem, który ma ustawione odbieranie na stałą wartość, za każdym razem musielibyśmy wysyłać wiadomości o tej właśnie stałej liczbie znaków.
Aby to zrobić, wystarczy ustawić trzeci parametr w funkcji HAL_UART_Transmit_IT na stałą szerokość wiadomości.
|
56 57 58 59 60 61 62 63 64 65 66 67 |
/* USER CODE BEGIN PFP */ /* Private function prototypes -----------------------------------------------*/ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { uint8_t Data[40]; // Tablica przechowujaca wysylana wiadomosc. sprintf(Data, "Odebrana wiadomosc: %s\n\r", Received); HAL_UART_Transmit_IT(&huart1, Data, 40); // Rozpoczecie nadawania danych z wykorzystaniem przerwan HAL_UART_Receive_IT(&huart1, Received, 10); // Ponowne włączenie nasłuchiwania HAL_GPIO_TogglePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin); } /* USER CODE END PFP */ |
Zmienna size staje się w takim razie zbędna. Co się dzieje teraz z częścią wiadomości, w której nie ma żadnych informacji? Możemy to zaobserwować oglądając odbierane dane w trybie ASCII.
Podgląd odebranych danych.
Wysłana wiadomość ma dokładnie 32 znaki (włącznie ze znakami LF oraz CR). Cała reszta zostaje zapełniona znakami zerowymi \0, które RealTerm wyświetla jako NULL. Widać, że jest ich dokładnie 8, a więc tyle, ile brakuje, aby cała wiadomość miała długość 40 znaków.
Teraz w urządzeniu odbiorczym, którym mógłby być inny mikrokontroler wystarczy ustawić odbieranie na długość 40 znaków. W ten sposób w urządzeniu odbiorczym przerwanie wywoła się zawsze w odpowiednim czasie, znaki zerowe na końcu nie będą w niczym przeszkadzać i tym samym transmisja zawsze będzie przebiegać poprawnie i efektywnie. W ten właśnie sposób można w praktyce rozwiązać problem wysyłania/odbierania długich wiadomości o różnej długości.
Spróbujmy teraz zaprząc do tego wszystkiego DMA. Dzięki temu odciążymy procesor w jeszcze większym stopniu. Jak zwykle z DMA, tak i teraz, cały proces jest bajecznie prosty.
W zakładce DMA Settings panelu konfiguracyjnego UARTa dodajemy dwa kanały. Jeden dla transmisji, a drugi dla odbioru.
Ponowna konfiguracja w Cube.
DMA ma przesyłać pojedyncze bajty w trybie normalnym, więc pozostawiamy ustawienia domyślne.
W zakładce NVIC nie wyłączamy przerwań pochodzących od UARTa,
ponieważ dalej chcemy mieć informacje o momencie odebrania pełnej wiadomości.
Aby uruchomić DMA w komunikacji UART, jedyne co musimy zrobić, to zamienić wywołania funkcji do obsługi UARTa na te korzystające z DMA. Nasz ostatni program po tej drobnej modyfikacji będzie w takim razie wyglądał następująco.
|
60 61 62 63 64 65 66 67 68 69 70 71 |
/* USER CODE BEGIN PFP */ /* Private function prototypes -----------------------------------------------*/ void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { static uint8_t Data[40]; // Tablica przechowujaca wysylana wiadomosc. sprintf(Data, "Odebrana wiadomosc: %s\n\r", Received); HAL_UART_Transmit_DMA(&huart1, Data, 40); // Rozpoczecie nadawania danych z wykorzystaniem przerwan HAL_UART_Receive_DMA(&huart1, Received, 10); // Ponowne włączenie nasłuchiwania HAL_GPIO_TogglePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin); } /* USER CODE END PFP */ |
Rozpoczęcie nasłuchiwania w funkcji main też oczywiście musi zostać zamienione na funkcję wykorzystującą DMA.
|
95 96 97 |
/* USER CODE BEGIN 2 */ HAL_UART_Receive_DMA(&huart1, Received, 10); // Rozpoczecie nasluchiwania na dane z wykorzystaniem DMA /* USER CODE END 2 */ |
Po przerzuceniu poprzedniego kodu na korzystanie z DMA, na końcu transmitowanej wiadomości dodawany był jeden dodatkowy znak. Jedyne rozwiązanie tego problemu jakie znalazłem, to zmiana deklaracji zmiennej Data na zmienną globalną lub zmienną statyczną (jak w przykładzie powyżej).
Jeśli ktoś z Was znajdzie rozwiązanie tego problemu, koniecznie dajcie znać w komentarzach!
W tym odcinku nauczyliśmy się wysyłać i odbierać wiadomości za pomocą interfejsu UART. Wiemy już jak go skonfigurować tak, aby wykorzystywał w tym celu przerwania oraz DMA. Omówiliśmy także kilka problemów związanych z implementacją, które pojawiają się w praktyce.
W następnym artykule zajmiemy się bardziej zaawansowanymi możliwościami, jakie oferują nam licznik (timery) mikrokontrolerów STM32. Jak zwykle, jeśli macie jakiekolwiek problemy, pytania czy wątpliwości związane z UARTem, piszcie śmiało w komentarzach!
Autor kursu: Bartek (Popeye) Kurosz
Redakcja: Damian (Treker) Szymański
Projekty omówione w tym artykule (zip, 8 MB)
Archiwum zip ze wszystkimi projektami.
F4, komunikacja, kursSTM32F4, stm32, uart, USART
Dołącz do 20 tysięcy osób, które otrzymują powiadomienia o nowych artykułach! Zapisz się, a otrzymasz PDF-y ze ściągami (m.in. na temat mocy, tranzystorów, diod i schematów) oraz listę inspirujących DIY z Arduino i RPi.
Trwa ładowanie komentarzy...