NUCLEO-F411RE oraz KA-Nucleo-Weather

Postautor: **dambo** » sobota 03 wrz 2016, 16:15

Witam wszystkich!

Korzystając z kącika testerów przetestowałem zestaw NUCLEO-F411RE oraz shield KA-Nucleo-Weather. Cała akcja odbywa się dzięki uprzejmości firmy KAMAMI, która udostępniła wszystkie moduły. Swoje boje z tymi układami zacząć od teorii – krótkiego omówienia płytek, co na nich się znajduje oraz w jakim środowisku będziemy je programować. Przy okazji odejdziemy trochę od formy wrzucania treści całych programów do wpisów, ale skorzystamy z GITa i repozytorium na Bitbucket, wytłumaczę krótko jaka jest tego idea, jak utworzyć własne repozytorium i pobrać z niego aktualne wersje programów – sam dopiero odkrywam te narzędzia, więc tu będzie opis tylko niezbędnych rzeczy, może w przyszłości zrobię do tego osobny kursik jak się bardziej zapoznam. Chciałbym też zaznaczyć moje założenie, że czytelnik bawił się wcześniej mikrokontrolerami, więc nie będę od zera tłumaczył pojęć typu przerwanie, i2c itp.

Zobaczmy najpierw co mamy do dyspozycji na płytce NUCLEO- F411RE – znajduje się tam mikrokontrolerek STM32F411RE. Taki mały potworek z rdzeniem M4, sprzętową obsługą liczb zmiennoprzecinkowych, taktowany do 100MHz. Poniżej dokładniejszy opis:
STM32F411RET6 in LQFP64 package

Więcej możemy dowiedzieć się ze strony: http://www.st.com/content/st_com/en/products/microcontrollers/stm32-32-bit-arm-cortex-mcus/stm32f4-series/stm32f411/stm32f411re.html
Ładnie opisany pinout znajduje się tutaj: https://developer.mbed.org/platforms/ST-Nucleo-F411RE/
Warto zajrzeć ile mamy dostępnych do niego dokumentacji – prawie większość peryferii jest opisana dodatkowo w postaci osobnej noty.
Ogólnie NUCLEO to nazwa rodziny płytek developerskich od ST posiadających header zgodny z arduino – więc pasują wszystkie shieldy, które operują na 3,3V (w przypadku 5V trzeba dokładniej sprawdzić) oraz wbudowanym programatorem ST-LINK/v2, więc po wyjęciu z opakowania możemy już zacząć pracę/zabawę. Dodatkowo z racji tego, że złącze arduinowskie oferuje do dyspozycji o wiele mniej pinów niż jest w mikrokontrolerze, mamy też złącze ST-Morpho. I jedna mega zaleta w prównaniu do zestawów Discovery – dłuższe goldpiny na górze układu! W Discoverkach często przewody wyskakują z nich, trzeba kombinować od spodu, bardzo irytujące to było/jest

W czym to możemy programować?
Mamy tutaj dużo możliwości – zacznijmy od platformy mbed.org (https://developer.mbed.org/) – w skrócie jest to takie arduino IDE w wersji online z masą dostępnych bibliotek/płytek itp. Posiada wszystkie zalety ( dostęp do bibliotek, duża społeczność ) jak i wady zwykłego arduino ( ja osobiście nie lubię nadmiarowości kodu i tego, że nie wiem co się dokładnie dzieje w programie od strony sprzętowej – dla niektórych może to być zaleta – kwestia gustu).

W wersji offline możemy wybrać sobie darmowe środowisko spośród:
- Eclipse (odpowiednio skonfigurowany)
- CooCoox (odpowiednio skonfigurowany)
- AC6 – oficjalne środowisko do ST do programowania ich mikrokontrolerów – w praktyce jest to eclipse z nakładką, nie musimy nic konfigurować
- Atollic True Studio – też odpowiednio skonfigurowany eclipse, możliwość programowania wielu rodzin mikrokontrolerów, wersja darmowa ma tylko ograniczenie odnośnie zaawansowanych opcji debugowania

Ja w tym kursie będę korzystał z AC6, na co dzień też korzystam z Atollica do programowania STMek.

Dodatkowo będziemy wykorzystywać CubeMX – umożliwia on „wyklikanie” konfiguracji peryferii mikrokontrolera oraz STMstudio – program umożliwiający podgląd danych z mikrokontrolera.
Przewinie się naprawdę dużo różnych programów

Co do kwestii „stylu” programowania – możemy to robić bezpośrednio na rejestrach, lub wykorzystywać bibliotekę HAL.
NUCLEO można znaleźć w KAMAMI: https://kamami.pl/stm-nucleo-64/233338- ... 2f411.html cena to 59 zł. W porównaniu z arduino UNO, które oryginalne kosztuje podobnie – miażdży go możliwościami.
Przejdźmy teraz do płytki KA-Nucleo-Weather.
Obrazek

Posłużę się tu gotowym opisem ze strony KAMAMI:

Każdy układ będzie dokładniej opisany w swojej części.
Shield umożliwia nam kompleksowe przetestowanie różnych sensorów niezbędnych np. w małej stacji pogodowej zanim zaprojektujemy swój układ z ich wykorzystaniem.
Możemy go kupić na stronie: https://kamami.pl/kamod-kamami/333318-k ... iatla.html
Polecam pobrać z niej dokumentacje zrobione przez KAMAMI – wszystkie są zawsze bardzo przejrzyste i trzymają się tego samego szablonu, znanego m. in. Z MAXimatora.
W kolejnej części zajmiemy się połączeniem AC6 z CubeMX, utworzymy pierwszy projekt standardowo z migającymi diodkami, następnie zainstalujemy GITa, utworzymy repozytorium, wszystko „zcommitujemy” i udostępnimy wszystkim do pobrania

Postautor: **dambo** » sobota 03 wrz 2016, 22:11

Idźmy więc za ciosem, przygotujmy sobie wszystko na komputerze i pomigajmy diodami

Zaczynamy od zainstalowania środowiska AC6: http://www.openstm32.org/HomePage Jak już pisałem, jest to odpowiednio skonfigurowany eclipse, więc po zainstalowaniu jest już w pełni gotowy do pracy, nie potrzebujemy dodawać nic do obsługi STM32. Może jedynie poza CubeMX – program występuje w dwóch wersjach – samodzielnej oraz jako plugin do eclipse’a – dlaczego by z tego nie skorzystać? Pobieramy archiwum z pluginem ze strony: http://www.st.com/content/st_com/en/pro ... 32095.html
Jeśli ktoś korzysta z innego środowiska może pobrać samodzielną wersję z tej stronki:
http://www.st.com/content/st_com/en/pro ... ubemx.html
Otwieramy więc AC6, standardowo tworzymy gdzieś workspace, teraz dodamy CubeMX. Wchodzimy w HELP->Install new software

001.png

Podajemy ścieżkę do naszego archiwum:

002.png

Plugin się zainstaluje, zostaniemy poproszeni o restart aplikacji. Będzie on widoczny jako nowa perspektywa, aby ją uruchomić wchodzimy w Window->Perspective->Open Perspective->Other i wybieramy STM32CubeMX.

003.png

Będzie ona widoczna w tym miejscu:

004.png

Na screenach powyżej jest ona już widoczna, ponieważ miałem ją zainstalowaną wcześniej.
Ok, no to utwórzmy nasz pierwszy projekcik, klikamy New Project.

2.png

Pojawi się okienko wyboru mikrokontrolera/płytki. My posłużymy się tą drugą opcją, program będzie wiedział wtedy jakie peryferia znajdują się w zestawie, ostrzeże gdy chcemy ustawić jako wyjście pin który jest np. wyjściem przerwania akcelerometru (w zestawach Discovery znajduje się bardzo dużo takich rzeczy, Nucleo z założenia jest prawie „gołe”).

3.png

Wybieramy więc nasze Nucle-F411RE

4.png

5.png

Tu widzimy przypisanie funkcji do pinów mikrokontorlera:

7.png

W kolejnych zakładkach mamy:
Ustawienie zegarów:

8.png

Dokładniejsza konfiguracja używanych peryferii (np. baudrate uartów itp.):

9.png

Przechodzimy do zakładki z naszym mikrokontrolerem i piny D0-D7 (według numeracji arduino) ustawiamy jako GPIO_Output. Jakie to piny w mikrokontrolerze znajdziemy w dokumentacji Nucleo, lub „ulotce” dołączonej do płytki:

20160901_202956.jpg

10.png

Następnie klikamy w ustawienia projektu:

11.png

Wpisujemy tam nazwę projektu, jego ścieżkę, pod jakie środowisko ma być generowany projekt. W naszym przypadku wygląda to tak:

13.png

Jeśli nie mamy pobranych wcześniej bibliotek dla danego mikrokontrolera CubeMX zapyta się o pobranie ich.

15.png

Następnie klikamy Project->Generate Code.
Teraz musimy zaimportować projekt do naszego środowiska, zmieniamy perspektywę na C/cpp. Klikamy prawym w okienku projektów i wybieramy import.

20.png

Wybieramy import istniejącego już projektu:

21.png

Domyślna ścieżka będzie ustawiona na folder z naszym workspace i tam dokładnie znajduje się projekt. Po zaimportowaniu pojawi się on po lewej stronie i możemy podejrzeć zawartość plików i skompilować. Tutaj pojawia się mały „babol” w includach – eclipse niby nie widzi jednej nazwy i projekt się nie kompiluje, dlatego na górze dodajemy #include „stm32f4xx.h” – kompilacja przechodzi, ale eclipsowi dalej się tonie podoba, teraz nie zaprzątajmy sobie tym głowy w dalszych częściach wyjaśnię dokładniej i ten problem zniknie

30.png

Pierwsze co rzuca się w oczy to duża ilość „zbędnych” komentarzy, aż kusi, żeby je skasować, niestety nie możemy tego zrobić – są to komentarze, które są rozpoznawane przez CubeMX, nasze kody możemy umieszczać w sekcjach „user code”, co nam to daje? Gdy będziemy chcieli dodać jakąś konfigurację CubeMXem do naszego projektu np. jakiś dodatkowy pin, to nasze kody w tych sekcjach pozostaną nieruszone. Bardzo fajne moim zdaniem.
Dopiszmy szybko jakieś miganie diodkami:

40.png

Kod możemy wgrać teraz na płytkę i zobaczyć klasyczne HelloWorld w świecie mikrokontrolerów – migające diodki.
Teraz oczekuję, że użytkownik będzie podirytowany

Tym, że kod jest w screenie i nie można skopiować. I dobrze – zamierzony efekt

Przechodzimy do kwestii, którą chciałbym wam przybliżyć, ale zaznaczam, że dopiero raczkuję w tej kwestii, czyli do GITa. Co on potrafi? GIT jest narzędziem do archiwizowania postępów w projekcie, kontroli jego wersji, dzięki niemu w przypadku pracy w grupie, mamy pewność, że pracujemy na aktualnej wersji kodu, kto nie miał tak, że pracował nad jakimś kodem w grupie, a ktoś zapomniał przesłać swojej dokończonej funkcji itp. Możemy też tworzyć „gałęzie” projektu – pracować równolegle nad różnymi funkcjami, a potem ładnie to połączyć. Głównym powodem dlaczego ja tego używam jest możliwość archiwizacji na zewnętrznym serwerze. Przechodziłem już przez awarię dysku SSD i należę od wtedy do tej grupy ludzi, którzy robią kopie zapasowe. Wszyscy zapewne z GITem kojarzą GIThuba – słusznie, ale warto zaznaczyć, że GITHub jest tylko do projektów OpenSourcowych – nie zawsze chcemy, żeby nasz kod był udostępniany. Dlatego dla przykładu skorzystamy z BitBucketa – tam kody mogą być i prywatne i publiczne.
Tu chciałbym zaznaczyć jeszcze jedną kwestię – mi osobiście wcześniej GIT kojarzył się z kontrolą wersji kodu, w sensie samych plików np. *.c – jednak możemy tam przechowywać wszystko, zwłaszcza dokumentację projektu, schematy, pliki eagle, itp. Warto to robić nawet sami dla siebie, a gdy chcemy ten projekcik opisać w sieci – mamy już wszystko gotowe.
No to zaczynamy. Standardowo – najpierw instalacja - https://git-for-windows.github.io/ po niej uruchamiamy GIT CMD - nas–ą kochaną konsolę. Przechodzimy do naszego folderu z workspace (komendą cd):

60 002.png

Tworzymy tutaj nasze repozytorium – tzn wybieramy ten folder jako główny w naszym projekcie komendą „git init”, teraz możemy sprawdzić stan naszego repozytorium komendą „git status”.

61.png

Otrzymaliśmy informację, że znaleziono pliki, które nie są nadzorowane przez GITa. Dodajemy wszystko komendą „git add –A”. Otrzymamy pewnie dużo warningów odnośnie zakończeń linii – możemy to wyłączyć komendą „git config core.autocrlf true”

66 002.png

Sprawdzamy teraz „git status”

66 003.png

Otrzymaliśmy listę nowych plików jakie pojawiły się w repozytorium i są „śledzone”.
Otwórzmy teraz przeglądarkę i wejdźmy na stronę https://bitbucket.org/dashboard/overview Załóżmy sobie tam konto i zalogujmy się.
Wejdźmy w tworzenie projektu:

66 004.png

Nazywamy je odpowiednio, odklikujemy prywatność, Dodajemy jakiś opis i klikamy „Create repository”

66 007.png

Możemy teraz wejść w nasze repozytorium:

66 008.png

Na dole mamy informację jak zacząć wrzucać tam pliki:

66 011.png

Wykonujemy te instrukcję i niestety nie przechodzi ta z „git commit –m ‘initial commit with contributors’”

66 012.png

dlatego, że zamiast pojedynczego cudzysłowia powinniśmy dać podwójny – wtedy wszystko działa.

66 013.png

Teraz krótkie wyjaśnienie – co oznacza „commit” – jest to zatwierdzenie wprowadzonych zmian, ta część w cudzysłowie to jej opis, w praktyce – mamy program i dopisujemy funkcję migającą diodą, robimy potem commit z opisem „dodano funkcję migającą diodą”. Potem pracujemy dalej i okazuje się, że nasza funkcja jest do niczego/psuje działanie programu itp. to możemy przywrócić stan sprzed tego commita.
Teraz wykunujemy „git push –u origin master”

66 014.png

66 015.png

Nasze dane wrzucane, a dokładnie wszystkie commity, są wrzucane na serwer. Commity robimy lokalnie w naszym repozytorium, potem całą ich paczkę możemy przerzucić na serwer.

66 016.png

Wchodzimy teraz do repozytorium na Bitbuckecie i widzimy, że w zakładce source mamy nasze pliki z komputera. Super 

66 017.png

W zakładce commits widzimy nasze commity:

66 018.png

Teraz dla przykładu dodałem tekst w pliku contributors.txt. Komendą „git status” sprawdzamy stan naszego repozytorium:

66 020.png

Widzimy zmiany w jakimś pliku od eclipse i naszym contributors.txt. Robimy więc commit:

66 021.png

66 022.png

I wrzucamy wszystko na serwer:

66 024.png

Wchodzimy na Bitbuckecie w commity i widzimy kolejny, który przed chwilą dodaliśmy

66 025.png

W zakładce settings możemy znaleźć link do udostępnienia naszego repozytorium, mój to:
git clone https://p_michalak@bitbucket.org/dambo1 ... ra_rep.git
oczywiście wcześniej trzeba zrobić “git init” w wybranym przez nas folderze.
Mam nadzieję, że może kogoś zaciekawiła ta część. Proszę o komentarze w wątku do tego przeznaczonym – będę wiedział, czy idę w dobrą stronę z tym opisem itp. Zachęcam do pobawienia się GITem, na jego temat jest mnóstwo poradników w sieci osób o wiele bardziej doświadczonych niż ja w tej kwestii. Oczywiście pobierajcie źródła z Bitbucketa i tam będą też pliki do kolejnych części w przyszłości.

Postautor: **dambo** » niedziela 11 wrz 2016, 17:10

Przejdziemy teraz do krótkiego opisu kolejnego narzędzia - STMStudio.
Do czego ono jest? Umożliwia podgląd zmiennych podczas działania mikrokontrolera - można rysować na ich podstawie wykresy, wrzucać do excela, a ile trzeba dopisać w programie do tego? NIC

Program sam sobie wyciąga dane przez interfejs do debugowania.

Teraz przejdźmy do przedstawienia podstawowej obsługi STMStudio.
Utwórzmy najpierw nowy projekt w AC6 tym razem bez pomocy CubeMX.

obr1.png

Wybieramy naszą płytkę:

obr2.png

zaznaczamy, że chcemy korzystać z biblioteki HAL – jeśli w ten sposób robimy nasz pierwszy projekt AC6 zapyta się o jej pobranie – pozwólmy.
w międzyczasie pobieramy SMTStudio z tego linku:
http://www.st.com/content/st_com/en/pro ... stm32.html
znajdziemy tam też kompletny poradnik wydany od ST link dla leniwych:
http://www.st.com/content/ccc/resource/ ... 291015.pdf
Dzięki STMStudio odpada konieczność pisania testowych programików, które wyświetlały stany zmiennych na lcd/wysyłały przez UART na terminal/specjalna aplikację napisaną do tego celu. Oczywiście pisanie takich apek miało też charakter edukacyjny, no ale ile można :p w końcu mamy to „automatycznie” i to łącznie z wykresami.
Ok – wracamy do AC6 – po pobraniu biblioteki polecam zaznaczyć „extract all firmware in separate folder” – będą tam różne przykłady dla naszego mikrokontrolera itp. – warto skorzystać.

obr3.png

Mamy też możliwość podciągnięcia dodatkowych bibliotek np. do USB, audio lub FatFs-a.

obr4.png

Klikamy finisz i mamy kolejny projekt w explorerze.

obr5.png

Praktycznie goły projekt – nie będziemy dawać nawet migania diodą, tylko stwórzmy sobie 3 zmienne typu uint16_t i w pętli głównej je inkrementujmy.

Kod: Zaznacz cały

#include "stm32f4xx.h"
#include "stm32f4xx_nucleo.h"
         
uint8_t x = 0;
uint8_t y = 0;
uint8_t z = 0;

void Delay( unsigned int x )
{
   while(x--);
}

int main(void)
{
   for(;;)
   {
      x += 15;
      y += 20;
      z += 80;
      Delay(1000000);
   }
}

Kompilujemy i wgrywamy wszystko na nasz mikrokontroler.
Teraz uruchamiamy STMStudio, nasze główne okno wygląda tak:

obr6.png

Klikamy file import variables:

obr7.png

Wskazujemy ścieżkę do naszego projektu, a dokładniej do pliku *.elf. Pojawi się lista naszych zmiennych używanych w programie.

obr8.png

Wybieramy zmienne x,y i z i importujemy je.

obr9.png

Pojawiły się one teraz w oknie głównym:

obr10.png

Teraz każda dodajemy do naszego wykresu w ten sposób:

obr11.png

Pod wykresem mamy teraz legendę naszych zmiennych:

obr12.png

W górnym lewym rogu wybieramy nasz programator i uruchamiamy śledzenie:

obr13.png

Okazało się, ze trochę za szybko się odświeżają, więc wchodzimy w Options->Acquisition Settings i ustawmy odświeżanie np. na 200ms.

obr14.png

I widzimy „ładne” wykresy naszych funkcji

obr15.png

Po co nam ten opis - STMStudio będziemy używać do wizualizacji danych z sensorów - teraz juz widzicie jakie to łatwe.
Projekt został oczywiście dodany do naszego repozytorium na BitBuckecie.
Konfigurację ustawień w STMStudio możemy oczywiście sobie zapisać na przyszłość – nie musimy jej od nowa ustawiać przy każdym uruchomieniu.
Zachęcam do zapoznania się ze wszystkimi możliwościami STMStudio.

Postautor: **dambo** » niedziela 18 wrz 2016, 00:28

Jako pierwszy układ z Weather Shield na warsztat pójdzie sensor temperatury STLM75. W skrócie o nim:
- zakres temperatur -55 do 125 stopni
- dokładność typowo +/-0.5stopnia, max +/-2stopnie
- prąd typowo 125uA
- komunikacja i2c
- zakres zasilania od 2,7V do 5,5V
- maksymalny czas konwersji – 150ms
- komunikacja i2c
Dostępny jest w obudowach SO8 lub TSSOP8.
Oczywiście pobieramy dokumentacje układu: http://www.st.com/content/ccc/resource/technical/document/datasheet/22/c6/56/13/dd/59/4b/43/CD00153511.pdf/files/CD00153511.pdf/jcr:content/translations/en.CD00153511.pdf
Na shieldzie znajduje się tutaj:

obr20.jpg

W dokumentacji shieldu znajdziemy informację, gdzie jest on podpięty – piny i2cPB8 i PB9 i pin OS/INT PA8. Odpalamy więc CubeMx i tworzymy nowy projekt na naszą płytkę:

obr2.png

Konfigurujemy piny i2c:

obr3.png

Po lewej stronie wchodzimy w i2c i uruchamiamy je:

obr4.png

Teraz w zakładce Configuration pojawiło nam się i2c:

obr5.png

Wchodzimy w nie i możemy zmieniać parametry:

obr6.png

Przestawmy na Fast Mode:

obr7.png

Reszta pozostaje bez zmian. Potem Apply i Ok. Generujemy kod w naszym workspace. Importujemy go jak wcześniej. Teraz jest dostępny w Project Explorerze.

obr8.png

Program kompiluje się mimo krzyczenia eclipse o „SysTick_IRQn”. Napiszmy sobie teraz funkcje do komunikacji z STLM75. Zakładam, że każdy wie co to jest i2c i jak przebiega transmisja. W sekcji „USER CODE BEGIN Includes” zdefiniujmy sobie adres naszego układu – jest on zależny od zworki JP1 na module i może być 0x90 lub 0x92.
#define STLM75_ADDRESS 0x90
Zróbmy sobie tam także definicje rejestrów:
#define STLM75_REG_TEMPERATURE_REGISTER 0x00
#define STLM75_REG_CONFIGURATION_REGISTER 0x01
#define STLM75_REG_HYSTERESIS_REGISTER 0x02
#define STLM75_REG_OVERTEMPERATURE_REGISTER 0x03

W sekcji “/* USER CODE BEGIN PFP */” dodajmy funkcję odczytującą temperaturę:

Kod: Zaznacz cały

uint8_t STLM75_read_temperature( void )
{
   uint8_t buff[2];
   HAL_I2C_Mem_Read(&hi2c1, STLM75_ADDRESS, STLM75_REG_TEMPERATURE_REGISTER, I2C_MEMADD_SIZE_8BIT, &buff, 2, 100);

   return buff[0];
}

Sprawdźmy co dokładnie jest przekazane do funkcji HAL_I2C_Mem_Read:

Kod: Zaznacz cały

/**
  * @brief  Read an amount of data in blocking mode from a specific memory address
  * @param  hi2c Pointer to a I2C_HandleTypeDef structure that contains
  *         the configuration information for I2C module
  * @param  DevAddress Target device address
  * @param  MemAddress Internal memory address
  * @param  MemAddSize Size of internal memory address
  * @param  pData Pointer to data buffer
  * @param  Size Amount of data to be sent
  * @param  Timeout Timeout duration
  * @retval HAL status
  */

Zobaczmy jeszcze jak przechowywana jest temperatura w układzie:

obr21.png

„The temperature data is provided by the 9 MSBs (bits 15 through 7). Bits 6 through 0 are
unused.”
Więc jak widać nasza funkcja ogranicza się do odczytania stopni, bez wartości po przecinku – tymczasowo wystarczy.
OK, mamy sam odczyt w mikrokontrolerze, jak my ją z niego odczytamy? Albo w debugerze, albo w STMStudio generując wykresik  Nie będę już tłumaczył krok po kroku co zrobić w STMStudio – każdy już to potrafi po wcześniejszej części.
Taki efekt uzyskałem przykładając układ do wentylatora z laptopa:

obr9.png

I małe przykładanie grotu lutownicy:

obr10.png

Kod oczywiście do pobrania z repozytorium (w sumie to tylko pętla główna z odczytem i delayem).
Oczywiście samo mierzenie temperatury to nie wszystko co potrafi nasz scalaczek – w następnej części poznamy jego dalsze możliwości. Jakby coś było nie jasne - obsługa i2c lub cokolwiek innego - proszę pisać w wątku z dyskusją.

Postautor: **dambo** » niedziela 30 paź 2016, 16:28

Lecimy dalej z obsługą naszego termometru.

Pierwsze co zmieniamy w poprzednim kodzie to dodajmy sobie ładną strukturkę do trzymania wyników pomiarów:

Kod: Zaznacz cały

// temperatura po przecinku - jesli ma wartosc "1" to oznacza 0.5 stopnia.
typedef struct {
   int8_t temperatura_cale;
   uint8_t temperatura_po_przecinku;
} LM75_temp;

I modyfikujemy funkcję odczytu w taki sposób:

Kod: Zaznacz cały

void STLM75_read_temperature( LM75_temp *wsk )
{
   uint8_t buff[2];
   HAL_I2C_Mem_Read(&hi2c1, STLM75_ADDRESS, STLM75_REG_TEMPERATURE_REGISTER, I2C_MEMADD_SIZE_8BIT, &buff, 2, 100);

   wsk->temperatura_cale = buff[0];
   wsk->temperatura_po_przecinku = buff[1] >> 7;
}

Funkcja komparatora.
Oprócz zwykłego mierzenia temperatury układ STLM75 oferuje możliwość wykorzystania go jako komparatora temperatury z histerezą. Gdy temperatura osiągnie określone wartości generowany jest impuls na pinie INT – możemy go wykorzystać np. do wybudzenia naszego procka. Np w przypadku tworzenia układu regulującego temperaturę w wytrawiarce nie musimy monitorować stale temperatury (chociaż moim zdaniem tak jest jakoś „ładniej” i zazwyczaj jest to wskazane, inny przykład to jakiś system low power do alarmowania o przekroczeniu zadanej temperatury, taki temperaturowy watchdog), tylko wykorzystać LM75 w tym trybie. Screen z dokumentacji:

lm75.png

Uruchomimy teraz tryb komparatora z przerwaniami i przetestujemy jego działanie.
Pin INT na naszym shieldzie jest podłączony do D7(ard) PA8(STM). Musimy więc skonfigurować przerwanie EXTI na tym pinie, żeby nasz mikrokontrolerek ładnie zareagował na sygnał.
Otwieramy więc CubeMx z naszym projektem:

1.png

Dla PA8 dajemy ustawienie GPIO_EXTI8.

2.png

Wchodzimy w Configuration->GPIO i klikamy na PA8 – pojawiają się ustawienia dotyczące tego przerwania i pinu. Ustawmy pull-up i falling edge, przy okazji damy etykietę LM75_INT_PIN:

3.png

Cofamy się do konfiguracji, wchodzimy w NVIC i uruchamiamy nasze przerwanie EXTI:

4.png

Generujemy kod. Otrzymujemy błąd związany z brakiem „EXTI9_5_IRQn” niestety nie wiem czemu nie jest to inkludowane, zaradzimy temu za pomocą:
#define EXTI9_5_IRQn 23
Obsługa przerwania w kodzie wygląda tak:

Kod: Zaznacz cały

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin){
   if(GPIO_Pin == LM75_INT_PIN_Pin)
   {
      // kod ktory ma sie wykonac
   }
}

Napiszmy funkcję, która ustawia zadaną temperaturę i histerezę:

Kod: Zaznacz cały

// funkcja ustawiajaca wartosc zadana i histereze z dokladnoscia do jednosci (bez wartosci po przecinku)
void STLM75_set_comparator_parameters( int8_t temperatura, int8_t histereza )
{
   uint8_t buff[2];
   buff[1] = 0;
   buff[0] = temperatura;
   HAL_I2C_Mem_Write(&hi2c1, STLM75_ADDRESS, STLM75_REG_OVERTEMPERATURE_REGISTER, I2C_MEMADD_SIZE_8BIT, buff, 2, 100);

   buff[0] = histereza;
   HAL_I2C_Mem_Write(&hi2c1, STLM75_ADDRESS, STLM75_REG_HYSTERESIS_REGISTER, I2C_MEMADD_SIZE_8BIT, buff, 2, 100);

   buff[0] = 0x02;
   HAL_I2C_Mem_Write(&hi2c1, STLM75_ADDRESS, STLM75_REG_CONFIGURATION_REGISTER, I2C_MEMADD_SIZE_8BIT, buff, 1, 100);
}

I teraz uwaga – w dokumentacji pojawia się sformułowanie histereza i tu tkwi pułapka. Myślałem, że ustawiamy zadadą temperaturę i dzięki histerezie tworzymy obszar wokół niej to jednak błąd. Histereza w tym układzie to dolny próg działania. Widać to na wykresie, który był zamieszczony wcześniej.

Obecnie nasz program reaguje tylko wtedy gdy temperatura przekroczy wartość górną (temp zadaną) lub gdy spadnie poniżej histerezy.

Warto jeszcze wspomnieć o możliwości ustawienia „licznika przekroczeń”. Teraz dostajemy informację, kiedy tylko temperatura przekroczy zadaną, natychmiastowo. Możemy to jednak opóźnić i ustawić ile próbek pomiarów musi znajdować się w odpowiednim przedziale, aby układ wygenerował przerwanie. Ustawiamy to za pomocą bitów FT w rejestrze konfiguracyjnym.

Odświeżony projekt znajduje się na bitbuckecie.

Postautor: **dambo** » niedziela 27 lis 2016, 16:37

Jako kolejny układzik z naszej płytki na warsztat idzie sensor Wilgotności ( i temperatury) HTS221. Znajduje się on tutaj:

Jego główne cechy:
• Zakres pomiarowy: 0 - 100% RH (wilgotność) / 0 - 60°C (temperatura)
• Dokładność pomiaru wilgotności: ± 6% (0 - 100% RH) / ± 4.5% (20 - 80% RH)
• Dokładność pomiaru temperatury: ± 1°C (0 - 60°C) / ± 0.5°C (15 - 40°C)
• Napięcie zasilania: 2,5 - 5,5 V
• Pobór prądu: 9 mA
• Częstotliwość pomiarów (ODR): 1 - 12.5 [Hz]
• Rozdzielczość przetwornika ADC: 16 bitów
• Interfejs komunikacyjny: SPI / I2C
• Wbudowany stabilizator oraz translator poziomów napięcia (linie SDA, SCL)
• Wyjście gotowości danych (DRDY)
Zapytacie po co nam nadmiarowy sensor temperatury na shieldzie, otóż wilgotność odczyt wilgotności jest kompensowany przez pomiar temperatury. Struktura wewnętrzna układu wygląda następująco:

Widzimy, że sensor działa na zasadzie pojemnościowej.
Zróbmy sobie spis rejestrów:

Kod: Zaznacz cały

#define HTS221_ADRESS 0xBE

// rejestry HT221
#define HTS221_REG_WHO_AM_I       0x0F
#define HTS221_REG_AV_CONF          0x10
#define HTS221_REG_CTRL_REG1       0x20
#define HTS221_REG_CTRL_REG2       0x21
#define HTS221_REG_CTRL_REG3       0x22
#define HTS221_REG_STATUS_REG       0x27
#define HTS221_REG_HUMIDITY_OUT_L    0x28
#define HTS221_REG_HUMIDITY_OUT_H    0x29
#define HTS221_REG_TEMP_OUT_L       0x2A
#define HTS221_REG_TEMP_OUT_H       0x2B
#define HTS221_REG_CALIB_H0_rH_x2   0x30
#define HTS221_REG_CALIB_T1T0_MSB   0x35
#define HTS221_REG_CALIB_H1_T0_OUT   0x3A

#define HTS221_INCREMENT_MODE       0x80

Co robi "HTS221_INCREMENT_MODE"? Otóż gdy chcemy odczytać kilka danych za jednym razem do adresu musimy dodać tą wartość (tu podziękowania dla Antystatycznego).
Kalibracja – nasz sensor posiada wbudowane wartości kalibracyjne zapisywane tam w fabryce, dzięki temu uzyskujemy większą dokładność pomiarów, choć komplikuje to trochę działanie.
Musimy więc najpierw je pobrać, aby odpowiednio przeskalować wynik na użyteczną wartość. W dokumentacji znajduje się też metoda obliczeń.
Ciekawostka – wilgotność może przekroczyć 100% - spędziłem dobrą godzinkę walcząc z funkcją pomiarów a okazało się, ze wszystko jest OK – wystarczy na końcu to ograniczyć.

Tworzenie projektu jest analogiczne jak w STLM75. Kod został przygotowany jako test podstawowych funkcji układu. Napisałem następujące funkcje:

Kod: Zaznacz cały

// funkcja uruchamiajaca uklad
uint32_t HTS221_power_on( void );

// funkcja ustawiajaca rozdzielczosc pomiaru
uint32_t HTS221_rozdzielczosc( void );

// funckaj sprawdza, czy zgadza sie identyfikator urzadzenia
uint32_t HTS221_who_am_i_test( void );

// funkcja uruchamiajaca pomiar one-shot
uint32_t HTS221_pomiar_one_shot( void );

// funkcja pobierajace ustawienia kalibracyjne
uint32_t HTS221_pobierz_kalibracje( HTS221_calibration *kalibracja );

Strukturka z danymi kalibracyjnymi prezentuje się tak:

Kod: Zaznacz cały

typedef struct
{
   uint8_t H0_rH_x2;
   uint8_t H1_rH_x2;
   int16_t T0_degC_x8;
   int16_t T1_degC_x8;
   int16_t H0_T0_OUT;
   int16_t   H1_T0_OUT;
   int16_t T0_OUT;
   int16_t T1_OUT;
} HTS221_calibration;

Przedstawię teraz wyniki 2 testów, wykresy wygenerowane w STMStudio.
Pierwszy to chuchanie na sensor, a potem przyłożenie go do wentylatora z laptopa:

Co się rzuca w oczy – sensor reaguje skokowo, nie wiem, czy to wina kodu, czy „ten typ tak ma” – w następnej części rozbudujemy bibliotekę i porównamy wyniki (w trybie free run z przerwaniami zamiast one-shot).
Drugi test – grzanie suszarką i tutaj to samo się nasuwa.

Kod oczywiście dodany na BitBucket, dziś mało kodu w artykule jako zachęta do zerknięcia tam

Jeszcze jedna sprawa - kwestia błędów z numeracją przerwań itp. Przedstawię teraz najlepszą metodę radzenia sobie z tym. Błędy wynikają z tego, że w kilku plikach w projekcie znajdują się te definicje i kompilator nie wie którą wybrać.
Robimy tak:

Wchodzimy w ustawienia projektu, c/Cpp General, Indexer zaznaczamy "Enable project specific settings" i odznaczamy "Index unused headers". Po wszystkim czyścimy projekt, robimy reindeksację i wszystko ładnie działa

microgeek.eu

NUCLEO-F411RE oraz KA-Nucleo-Weather

NUCLEO-F411RE oraz KA-Nucleo-Weather

Re: NUCLEO-F411RE oraz KA-Nucleo-Weather

Re: NUCLEO-F411RE oraz KA-Nucleo-Weather

Re: NUCLEO-F411RE oraz KA-Nucleo-Weather

Re: NUCLEO-F411RE oraz KA-Nucleo-Weather

Re: NUCLEO-F411RE oraz KA-Nucleo-Weather

Kto jest online