[STM32F0] proste CLI dla STM

Tu możesz pisać o swoich problemach z pisaniem programów w języku C/C++ dla STM.
Awatar użytkownika
dambo
Expert
Expert
Posty: 645
Rejestracja: czwartek 17 mar 2016, 17:12

[STM32F0] proste CLI dla STM

Postautor: dambo » poniedziałek 16 kwie 2018, 23:33

Witam - ostatnio jakoś mi wleciał na tapet temat testowania układów, softów testowych itp.

Jak więc przetestować swój układzik, gdy mamy wykonać jego kilka kopii i trzeba sprawdzić, czy wszystko jest dobrze polutowane? Oczywiście jest mnóstwo metod na to. Można wgrać docelowy wsad i jeśli coś będzie nie tak to to zobaczymy. Sam robiłem tak, że miałem programiki na osobne peryferia zachowane gdy pisałem kod projektu i mogłem je kolejno wgrać. Jednak zawsze przewijała się podstawowa kwestia - testowanie GPIO (output/input) oraz napięć w układzie. Tu mi wpadł pomysł - zrobienie bardziej "uniwersalnego" kodu do takich rzeczy. Wybrałem komunikację przez uart z prostymi komendami AT opartymi o moja bibliotekę z GITa, więc dla niej to kolejny test użyteczności w praktyce.

Uwaga - projekt w fazie rozwojowej, ale w sumie dość prosty, więc dużo nie zajmie, ale wolę zawsze się tu zapytać - zawsze ktoś coś fajnego podpowie :) Po posprzątaniu i przetestowaniu wszystko pójdzie na GITa.

Jak pisałem wcześniej - funkcjonalności o jakie mi chodziło najbardziej to proste GPIO i ADC. Na upartego można dodać wiele innych rzeczy - uarty, SPI itp, ale wtedy nie będzie to już "proste CLI".

Więc zacznijmy od GPIO. Do dyspozycji mamy komendy:
  • Konfiguracja danego pinu:
    AT+GPIO_INIT=<port_gpio>,<nr_pinu>,<tryb>,<parametr>
    gdzie:
    port_gpio -> GPIOA/GPIOB/GPIOC/GPIOD/GPIOF (w F030F4P6 nie ma E)
    nr_pinu -> 0-15
    tryb -> OUTPUT, INPUT, ALTERNATE, ANALOG
    parametr -> zalezny od trybu -> jeśli jest to:
    OUTPUT -> 0 - stan niski, 1 - stan wysoki
    INPUT -> 0 - no pullup/pulldown, 1 - pullup, 2 - pulldown
    ANALOG -> pomijalny
    ALTERNATE -> numer funkcji alternate, ale obecnie niewykorzystywane - może w przyszłości
    Przykład:
    AT+GPIO_INIT=GPIOA,6,OUTPUT,0

  • Ustawienie stanu pinu:
    AT+GPIO_OUT=<gpio>,<numer_pinu>,<stan(0/1)>
    tu chyba nie muszę tłumaczyć :)
    Przykład:
    AT+GPIO_OUT=GPIOA,5,1

  • Odczyt pinu:
    AT+GPIO_IN=<gpio>,<numer_pinu>
    odpowiedź od układu to:
    Stan pinu: HIGH
    lub
    Stan pinu: LOW
I z GPIO to by było na tyle. Oczywiście trzeba uważać, żeby sobie nie wyłączyć pinów aktywnego uartu.

To teraz ADC. Użyłem zwykłej konfiguracji pojedynczego pomiaru.
  • Inicjalizacja ADC:
    AT+ADC_INIT
    tu wszystko jasne.
    Oczywiście musimy ustawić wybrany pin w tryb analog komendą:
    AT+GPIO_INIT=GPIOA,5,ANALOG,0
  • I pomiar robimy w taki sposób:
    AT+ADC_START=<numer_kanału_ADC>
    kanał odczytujemy z dokumentacji.
    Przykład pomiaru:
    Wynik pomiaru ADC to: 2417
  • Ale idąc trochę dalej - sam wynik z przetwornika dla nas nie jest zbytnio przyjazny. Dlatego istnieje kolejna komenda:
    AT+ADC_START_V=<numer_kanalu>
    i ona zwraca wynik w takiej formie:
    Napięcie na ADC to: 1,946V
    Skąd to przeliczenie? Otóż wynik jest mnożony przez 3300 (bo napięcie odniesienia to 3v3), a potem dzielony przez 4096(12bitowy przetwornik). Wyświetlam najpierw ten wynik przez 1000, potem modulo i mamy ładny zapis z 3 miejscami po przecinku.
  • Nie zawsze jednak mierzymy napięcia, które toleruje ADC procka - czasem potrzebny jest dzielnik. jak więc wtedy to przeliczyć? Otóż wspomniane wyżej współczynniki są zapisane w dwóch zmiennych (A i B). Możemy zobaczyć ich wartości komendą:
    AT+ADC_GET_AB
    A=3300 B=4096
  • I możemy je ustawić jak tylko chcemy komendami:
    AT+ADC_SET_A=<wartosc_wspolczynnika_A>
    AT+ADC_SET_B=<wartosc_wspolczynnika_B>
Mamy więc w miarę uniwersalny projekt - należy jedynie dostosować pinout uarta pod siebie. Wytestuję to przy najbliższej dostawie płytak do nowych projektów.
Jak mamy kilka płytek do przetestowania mozemy to zrobić jakimś skryptem/przyciskami w programie do komunikacji z uartem na PC, czy skryptem w pythonie.
Kod wyląduje na gicie i potem go tutaj podlinkuje do zerknięcia.

Co myślicie o tym pomyśle, jakieś koncepcje na rozbudowanie/jakie jeszcze funkcjonalności mogą być przydatne? Konstruktywna krytyka mile widziana :)
Ostatnio zmieniony środa 18 kwie 2018, 23:46 przez dambo, łącznie zmieniany 1 raz.
Nowy blog o tematyce embedded -> https://www.embedownik.pl/

Awatar użytkownika
Antystatyczny
Geek
Geek
Posty: 1168
Rejestracja: czwartek 03 wrz 2015, 22:02

Re: [STM32F0] proste CLI dla STM

Postautor: Antystatyczny » poniedziałek 16 kwie 2018, 23:49

No cóż, bardzo fajny sposób na wykorzystanie parsera, który ostatnio rzeźbiłeś. Ze sprawdzeniem lutowania zazwyczaj radzę sobie prostym programikiem wrzucanym do układu docelowego, ale zdaję sobie sprawę, że nie zawsze tak można. Wystarczy pomyśleć o pinach sterujących mostkiem H :) No ale za bardzo się rozpędzam... W każdym razie takie wykorzystanie komend AT wydaje się być bardzo sensowne, choć tak naprawdę mało uniwersalne w charakterze "boundary scan". Nikt jednak nie obiecywał, że proste CLI będzie nadzwyczajnie proste. Osobiście widziałbym w tym testowym sofcie możliwość pchania pojedynczych bajtów przez SPI lub IIC - bez DMA, bo często zależy nam na wysłaniu dosłownie jednego, czy trzech bajtów (slave, address, value).
"The true sign of intelligence is not knowledge but imagination" Albert Einstein.

Awatar użytkownika
dambo
Expert
Expert
Posty: 645
Rejestracja: czwartek 17 mar 2016, 17:12

Re: [STM32F0] proste CLI dla STM

Postautor: dambo » czwartek 19 kwie 2018, 00:15

Właśnie już sam siebie hamowałem z takimi rzeczami - najprędzej bym dodał możliwość uruchomienia drugiego uartu. Dlaczego? możemy wtedy pogadać z jakimś układem na płytce "pomijając" STMkę. Ale tak samo z SPI/i2C... nie wykluczam, ze projekt się rozbuduje w przyszłości o takie rzeczy

jako update - dodałem wszystko na gita - zapraszam: https://github.com/dambo1993/STM32_CLI
Nowy blog o tematyce embedded -> https://www.embedownik.pl/

Awatar użytkownika
ZbeeGin
User
User
Posty: 492
Rejestracja: sobota 08 lip 2017, 17:16
Lokalizacja: Śląsko-Zagłębiowska Metropolia
Kontaktowanie:

Re: [STM32F0] proste CLI dla STM

Postautor: ZbeeGin » środa 29 sie 2018, 20:19

Wiem, że odkopuje stary temat, ale naszły mnie dziś takie przemyślenia jak nieco inaczej zrobić takie CLI. Sama teoria, ale powinna się dać przełożyć na kod.

1. Poszczególne komendy mamy w tablicy. Zasadniczy wymóg to tablica posortowana alfabetycznie w komórkach z zapisanymi poleceniami. Wtedy niezależnie od ilości poleceń w tablicy, stosując proste wyszukiwanie binarne za max. log2 n_poleceń iteracji - zatem błyskawicznie - znajdujemy polecenie, lub nie zwracając NULL, oznaczający błędne polecenie.
2. Następnie parser wyłuskuje wszystkie parametry jakie możemy podać danemu poleceniu - wykorzystując w tym celu funkcje strtok(). Tworzymy po prostu wskaźnik na strukturę typu lista, gdzie kolejne rekordy będą przechowywać pary: nazwa parametru i wartość - też jako wskaźniki. Oczywiście ilość poleceń na tej liście też zapamiętujemy. Jeśli polecenie nie ma argumentów to zwracamy NULL.
2. Do każdego polecenia w tablicy z pkt. 1 mamy podpięty adres funkcji obsługującej polecenie, gdzie standardowymi argumentami są zapamiętana ilość parametrów i wskaźnik na ich listę. Dana funkcja będzie już wiedziała co z nimi zrobić jak przekażemy jej sterowanie.

Awatar użytkownika
xor
User
User
Posty: 169
Rejestracja: poniedziałek 05 wrz 2016, 21:44

Re: [STM32F0] proste CLI dla STM

Postautor: xor » czwartek 06 wrz 2018, 08:53

Procesy myślowe przeprowadzone przy pisaniu swojej wersji interpretera doprowadziły mnie do mniej więcej podobnych wniosków z małymi różnicami:
ad 1. Fajnie by było ale nie znam sposobu żeby sortowanie wykonało się na etapie kompilacji. Trzeba by to sortować albo "ręcznie", co jest uciążliwe i podatne na błędy, albo run time, co uniemożliwia umieszczenie tablicy w obszarze FLASH, albo mieć jakieś dodatkowe narzędzie do tego. Przy niewielkiej ilości poleceń (a nawet i przy większej) nie wydaje mi się to warte zachodu.
ad 2. Do funkcji przekazuję tablicę wskaźników na wartości parametrów, bez nazwy parametru. Zakładam, że pozycja parametru na liście jednoznacznie wskazuje na znaczenie. Interpretacją parametrów zajmuje się całkowicie funkcja podpięta pod komendę.

Oprócz tego w interpreterze przewidziane są funkcje definiowane (lub nie, wtedy wykonują się funkcje domyśle) przez użytkownika do realizacji funkcji: czytania znaków, wyprowadzenia echa, walidacji danych wejściowych oraz obsługi błędów.


Wróć do „Programowanie STM w C/C++”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 2 gości