Kurs STM32L4 – #4 – komunikacja przez UART, debugger

[Komentator]

Komunikacja z mikrokontrolerem przez UART ma wiele praktycznych zastosowań. Dlatego już teraz omówimy najprostsze podejście do obsługi takiej transmisji (i połączymy ją z funkcją printf). Wskażemy też kilka częstych błędów związanych ze znakami końca linii i kodowaniem. Przy okazji skorzystamy także z debuggera.

UWAGA, to tylko wstęp! Dalsza część artykułu dostępna jest na blogu.

Przeczytaj całość »

Poniżej znajdują się komentarze powiązane z tym wpisem.

[Komentator]

Przypominamy: w komentarzach do kursów rozmawiamy wyłącznie na tematy związane z konkretnym kursem. Mile widziane są również informacje od osób, które korzystały wcześniej z naszych poradników. Wszystko po to, aby kursanci, którzy mają zamiar korzystać z tego kursu nie musieli "przedzierać" się przez dziesiątki postów na inne tematy. Tematy na pytanie, które nie są związane z kursem można zadawać na naszym forum o mikrokontrolerach.

[Treker (Damian Szymański)]

Zachęcam do lektury i samodzielnego eksperymentowania z printf! Mam nadzieję, że od teraz nikt już nie będzie miał problemów ze zrozumieniem tematu znaków końca linii. Niby prosta sprawa, ale jednak często generuje to problemy w różnych projektach.

[Elvis]

Miło, że kolejna część kursu jest już dostępna Ponownie wyszło trochę dużo tekstu, ale mam nadzieję, że czytelnicy nie będą zawiedzeni. Od siebie dodam tylko, że temat kodowania znaków końca linii oraz przygody z buforowaniem printf mogą być przyczyną błędów o wiele trudniejszych do wykrycia niż się wydaje. Ten sam program może czasem działać poprawnie, a po podłączeniu do innego urządzenia generować zaskakujące błędy. Kilka lat temu pracowałem w firmie, gdzie właśnie takie błędy były przyczyną ponad trzymiesięcznego opóźnienia wdrożenia produkcji. A biorąc pod uwagę sporą skalę produkcji, były to całkiem realne straty dla firmy. Warto więc zwracać uwagę nawet na tak pozornie nieistotne szczegóły.

[Nore21]

36 minut temu, Elvis napisał:

Ponownie wyszło trochę dużo tekstu, ale mam nadzieję, że czytelnicy nie będą zawiedzeni.

Jeszcze nie trenowałem w praktyce, bo nie mam teraz płytki pod ręką, ale z przyjemnością przeczytałem na sucho. Jak dla mnie takie informacje o znakach końca linii i dodatkowe wyjaśnienie to duża zaleta tego kursu. Przy okazji zaczynam widzieć jak wiele jeszcze nie wiem, ale cóż... Po to uczę się z kursu, aby wiedzieć więcej :) Wieczorem siadam do praktyki.

[Treker (Damian Szymański)]

@Nore21 miło słyszeć, że pierwsze wrażenia są pozytywne! A co do własnej niewiedzy... to spokojnie Elektronika jest tak ciekawym hobby, że zawsze jest coś czego się jeszcze nie wie. Trzeba do tego przywyknąć i cieszyć się, że cały czas można poznawać coś nowego. Sami też czasami uczymy się jeszcze czegoś nowego przy okazji pisania kursów.

[Nore21]

6 godzin temu, Treker napisał:

cieszyć się, że cały czas można poznawać coś nowego

Takie mam do tego nastawienie

Zakładam, że to skomplikowane zagadnienie, ale jak właściwie działa taki debugger? To wszystko wygląda świetnie, zatrzymywanie programu, podglądanie zmiennych, zmiany w pamięci itd. Jednak jak to właściwie działa w praktyce? Te zmiany wprowadza jakoś programator czy to raczej działa tak, że przez programator wysyłamy do mikrokontrolera tylko jakieś polecenia, a on ma w sobie jakiś moduł, który sam wprowadza zmiany w pamięci i zatrzymuje układ? Nie chodzi mi o szczegóły, bo pewnie jest o tym XXX stron dokumentacji. Ale możecie jakoś w 2-3 zdaniach napisać jak to działa?

Edytowano Kwiecień 23, 2021 przez Treker
Poprawa literówki.

[Treker (Damian Szymański)]

Dobrze trafiłeś, bo to faktycznie skomplikowany temat, chociażby dlatego, że istnieją różne narzędzia do debugowania programów. Różnią się one możliwościami, które zyskuje przy okazji programista. Jednak pisząc w największym skrócie to co wykorzystujemy tutaj to tzw. SWD. Jest to uniwersalny standard, dzięki któremu można debuggować mikrokontrolery z rdzeniami ARM. Aby całość zadziałała potrzebne jest środowisko z interfejsem debuggera, odpowiedni programator (sprzętowy debugger) oraz mikrokontroler z możliwością debugowania, bo nie każdy układ ma takie możliwości. Dopiero połączenie tych 3 składników pozwala na takie operacje, a za bezpośrednie manipulowanie pracą mikrokontrolera odpowiada moduł, który jest wbudowany do jego wnętrza. Odbiera informacje z programatora i wykonuje odpowiednie operacje, np. wstrzymuje działanie układu. Znacznie więcej na ten temat można się dowiedzieć np. z lektury tego hasła: https://en.wikipedia.org/wiki/JTAG Ale to już raczej w ramach ciekawostki

[Elvis]

@Nore21 Ciężko jest krótko odpowiedzieć na Twoje pytanie, ale w największym skrócie - w samym mikrokontrolerze wbudowane są odpowiednie moduły ułatwiające debugowanie programów. Nie jest to jeden moduł, ale cały ich zestaw, w dokumentacji STM32L4 znajdziemy taki diagram:

Programator ST-Link/V2 przez moduł "SWJ-DP: Serial wire / JTAG debug port" i linie SWDIO/SWCLK ma dostęp do zasobów mikrokontrolera.

[Nore21]

17 minut temu, Elvis napisał:

w samym mikrokontrolerze wbudowane są odpowiednie moduły ułatwiające debugowanie programów

Dzięki, tyle na ten moment mi wystarcza! Po prostu chciałem wiedzieć czy mikrokontroler musi mieć w sobie "coś", aby mógł być debugowany, czy to działa jakoś niezależnie od wnętrza mikrokontrolera.

[Ma_Ciej]

Ale macie szybkie tempo z tym kursem. Planowałem w niedziele poczytać początek, aby zobaczyć czy to dla mnie, a tu już czwarta część. Chyba muszę przyspieszyć i ruszyć ostro z nauką, bo wygląda bardzo ciekawie. Dzięki za te poradniki!

[Treker (Damian Szymański)]

@Ma_Ciej witam na Forbocie i dziękuję za miłe słowa. Cieszę się, że nasz nowy kurs Cię zainteresował. Gorąco zachęcam do tego, aby działać w praktyce i regularnie udzielać się na forum 

[ethanak]

W tym tempie zanim wypłata do mnie dojdzie będę już po kursie

 

[Treker (Damian Szymański)]

Obszerny kurs to i tempo musi być trochę szybsze! Jednak spokojnie, nic nie zginie - ten kurs będzie dostępny jeszcze bardzo długo 

[Matthew11]

Cytat

Kiedyś właściwie wszystkie komputery PC były wyposażone w interfejs szeregowy RS-232, obecnie USB prawie zupełnie wyparło ten sposób komunikacji.

Sam uważałem standard RS232 za archaizm, ale ostatnio słuchając podcastu Cppcast okazuje się, że stosowany jest on w robotach, które wykorzystuje się do inspekcji elektrowni atomowych. Według Davida Barra (gościa podcastu) wykorzystywany jest dlatego, że jest bardziej odporny na zakłócenia w środowisku wysokiego promieniowania. Co ciekawe wynik w postaci 10minut pracy takiego urządzenia w takim środowisku to spore osiągnięcie.

A gdyby tak sterować diodą z jakiejś aplikacji która ma interfejs graficzny? Wystarczy wykorzystać aplikację z drugiej części Forbotowego kursu Qt.

Umawiamy się, że w programie na mikrokontroler wykorzystujemy komendy "on" i "off". Więc w funkcji void line_append(uint8_t value) musimy mieć coś takiego:

void line_append(uint8_t value)
{
// ...
	if (strcmp(line_buffer, "on") == 0) {
		HAL_GPIO_WritePin(LD2_GPIO_Port, LD2_Pin, GPIO_PIN_SET);
	} else if (strcmp(line_buffer, "off") == 0) {
		HAL_GPIO_WritePin(LD2_GPIO_Port, LD2_Pin, GPIO_PIN_RESET);
// ...
}

Program napisany w Qt możemy pobrać z załącznika, który dołączony jest na końcu wpisu. W tym programie musimy zmienić tylko trzy linie (92, 147 i 152) w pliku mainwindow.cpp, pierwsza zmiana to baudrate czyli zamiast 9600 ustawiamy 115200:

// mainwindow.cpp linia 92
this->device->setBaudRate(QSerialPort::Baud115200);

Trzeba jeszcze zmienić treść wysyłanych komend z "1" i "0" na "on\n" i "off\n":

void MainWindow::on_pushButtonLedOn_clicked()
{
    // mainwindow.cpp linia 147
    this->sendMessageToDevice("on\n");
}

void MainWindow::on_pushButtonLedOff_clicked()
{
    // mainwindow.cpp linia 152
    this->sendMessageToDevice("off\n");
}

Po wgraniu programu na Nucleo, uruchomieniu aplikacji, wybraniu portu i połączeniu się z płytką możemy sterować diodą LD2 klikając w przyciski "Włącz diodę" i "Wyłącz diodę":