Realistické RC modely

Výškomer (tlakomer, teplomer) so senzorom MPL3115A2 – 2.časť

V minulej časti sme sa v krátkosti zoznámili s (výškovým) senzorom MPL3115A2 od firmy NXP (FreeScale).

Sľúbili sme, že vám ukážeme tú najjednoduchšiu (a aj pre amatérov zrozumiteľnú) cestu, ako s ním pracovať.

A ukázali sme si pár riadkov kódu, ktorými sme senzor iniciovali tak, že teraz už pracuje – meria (nadmorskú) výšku a nám stačí si hotové výsledky už len „vyzdvihnúť“.

Dnes si v úvode porovnáme Hexa (šestnástkové) a Binárne (dvojkové) čísla a potom opäť pomocou len dvoch riadkov kódu si zo senzora „vyzdvihneme“ našu aktuálnu nadmorskú výšku, aby sme ju potom mohli použiť napr. v telemetrii alebo zobraziť na LCD-displeji.

autor: Janko O.

V predchádzajúcej časti sme si povedali, že skôr ako začne senzor MPL3115A2 pracovať – merať, musíme ho iniciovať, teda „povedať“ mu, čo a ako má merať. To sa robí pomocou tzv. registra, teda riadiaceho registra, s (pre nás najvyššou) dôležitosťou 1, ktorý sa volá: Control Register 1 – a má označenie: CTRL_REG1, ktorého podoba (štruktúra) je takáto:

Má Adresu AdrReg = $26   a my sme do neho poslali „povely“ $B8 (Hexa-číslo B8) a potom $B9 (Hexa-číslo B9) .

Lenže …

Povedzme si rovno, že Hexa-čísla sú také čudné – pre normálneho (počítačmi neposadnutého) človeka neprirodzené. Kto ich používa? Okrem milovníkov počítačov asi nikto!

My sme Hexa-číslom s hodnotou B8 ($B8) iniciovali náš senzor, ale akosi „potichu“ sme sa zmierili s tým, že vlastne ani poriadne nevieme, čo to Hexa-číslo B8 je a čo s takým dôležitým registrom, ako je Control Register 1 (CTRL_REG1), vlastne urobí.

Ale oveľa prehľadnejšie a zrozumiteľnejšie to začne byť, keď si to Hexa-číslo prevedieme do Binárneho (dvojkového) tvaru. PIC Basic Compiller na Binárne vyjadrenie používa prefix %, takže Hexa-hodnota B8 ($B8) bude mať dvojkovú podobu nasledujúcu:

      %10111000  je to isté ako $B8   

Možno si (pri prvom pohľade) poviete: „No to sme si pomohli!?“ 

Ale áno, pomohli sme si. Keď jednotlivým symbolom Control Registra 1 (viď obrázok hore) priradíme túto kombináciu jednotiek a núl, tak naraz presne vieme, čo sme v registri nastavili.

Poďme z ľava do prava (hoci sa to väčšinou robí skôr naopak):

• Symbol ALT bude mať hodnotu 1. To znamená, že senzor je v režime ALTIMETER – výškomer. Keby mal hodnotu 0, tak senzor je v režime PRESSURE – tlakomer.

• Symbol RAW nemá v našom super-jednoduchom nastavení miesto a preto nás nezaujíma (necháme prednastavenú 0).

• Symboly OS[2:0], teda tri symboly: OS2, OS1 a OS0 určujú mieru prevzorkovania (OverSampling) a ich význam je patrný z (nám už známej) tabuľky:

• Symboly RST a OST nevyužijeme (nepotrebujeme), takže nás opäť nezaujímajú.

• Symbol SBYB (Stand By) je však veľmi dôležitý: ako sme spomínali v minulej časti, najprv musí byť senzor v režime Stand By (SBYB = 0) a až potom sa aktivuje tak, že SBYB = 1 a senzor začne merať.
   

Keď sa teraz pozriete na (nám už známe) príkazy:

      I2cWrite SDa, SCl, AdrIO, AdrReg, [$B8] 

      I2cWrite SDa, SCl, AdrIO, AdrReg, [$B9] 

tak vidíte, že jediným rozdielom medzi nimi je to, že „povel“ $B8 (%10111000) sa zmenil na [$B9] (%10111001), teda SBYB (Stand By) sa zmenilo z 0 na 1, čiže zo stavu Čakaj - na stav Meraj. Aké jednoduché a jasné! 

Preto my v našich programoch na zobrazenie stavu registrov ZÁSADNE používame Binárne zobrazenie: je to názornejšie, prehľadnejšie a ľahšie sa tak vyhneme chybám.

Adresy obvodov a Adresy (čísla) registrov nechávame v Hexa-podobe, pretože tak sú uvádzané v datašítoch a na názornosť a prehľadnosť programov to nemá žiadny vplyv.

Toto je však len náš názor, náš postoj – naša voľba, ktorú my ale nikomu nevnucujeme! 

Keby sme teraz týmto „našim“ štýlom mali vyjadriť (v minulej časti spomínanú) subrutinu inicializácie, tak by vyzerala nasledovne:

MPL3115_Init: 

      AdrIO = $C0  

      AdrReg = $26  

      I2cWrite SDa, SCl, AdrIO, AdrReg, [%10111000] 

      I2cWrite SDa, SCl, AdrIO, AdrReg, [%10111001]  

Return 

No a teraz poďme pokročiť ďalej:

Senzor MPL3115A2 je teda Iniciovaný (nastavený) a následne Aktivovaný (už meria) a ako sme si povedali, do svojich troch (8-bitových) výstupných registrov začína „sypať“ dáta. Celočíselná (16-bitová) hodnota, teda priamo nadmorská výška v metroch, je každých 512 milisekúnd aktualizovaná v dvoch registroch: OUT_P_MSB (Horný Byte = horných 8 bitov, adresa $01) a OUT_P_CSB (Dolný Byte = dolných 8 bitov, adresa $02). Zlomky metrov sú k dispozícii v registri OUT_P_LSB (adresa $03), ktorý nás zatiaľ nemusí zaujímať (možno neskôr ).

Ešte pred stiahnutím týchto registrov zo senzora si niekde na začiatku programu „stvoríme“ (16-bitovú premennú (teda typu Word) s príznačným menom Výška :

      Vyska Var Word  

PIC Basic Compiler umožňuje v rámci „Wordovskej“ (16-bitovej) premennej pracovať s ňou buď ako s celkom, teda v našom prípade ako s (16-bitovou) premennou Vyska, alebo ako s jej „polovicami“, teda vlastne akoby samostatnými „Bytovými“ (8-bitovými) premennými: Vyska.HighByte a Vyska.LowByte.

To nám umožní elegantne do tejto „samo-druhej“ premennej potom pomocou dvoch riadkov kódu priamo uložiť (nadmorskú) výšku v metroch:

ReadDataAltitude: 

      AdrReg = $01 

      I2cRead SDa, SCl, AdrIO, AdrReg, [Vyska.HighByte] 

      AdrReg = $02 

      I2cRead SDa, SCl, AdrIO, AdrReg, [Vyska.LowByte] 

Return 

Keby sme to chceli napísať ešte v jednoduchšej (ale menej prehľadnej) forme, tak by to vyzeralo takto:

ReadDataAltitude: 

      I2cRead SDa, SCl, $C0, $01, [Vyska.HighByte] 

      I2cRead SDa, SCl, $C0, $02, [Vyska.LowByte] 

Return 

čo sa dá ľudskou rečou preložiť ako:

Prvý príkaz:

Pomocou I2C prečítaj (Read) po linkách SDa a SCl, z obvodu s Adresou $C0 (Adresa senzora MPL3115A2), konkrétne z registra s Adresou $01, hodnotu Horného Bytu (nadmorskej) výšky a ulož ju do premennej s názvom Vyska.HighByte.

Druhý príkaz:

Pomocou I2C prečítaj po linkách SDa a SCl, z obvodu s Adresou $C0, konkrétne z registra s Adresou $02, hodnotu Dolného Bytu (nadmorskej) výšky a ulož ju do premennej s názvom Vyska.LowByte.

Takto jednoducho sme zo senzora MPL3115A2 „vymámili“ aktuálnu (16-bitovú) hodnotu nadmorskej výšky (Vyska). Čo s ňou ďalej budeme robiť, je len na nás.

My, v našej PC Telemetrii, túto hodnotu pomocou doplnených hore-spomenutých riadkov kódu získavame v rámci „letového“ modulu našej PC Telemetrie. Tento modul je umiestnený v modeli, je osadený procesorom (mikrokontrolérom) PIC16F88 a riadený našim programom, vytvoreným v PIC Basic Pro Compileri:

Telemetrický modul - vpravo dole. Ďalšie dva moduly sú súčasťou Umelého horizontu.

Aktuálna (nadmorská) výška modelu (hodnota Vyska) je spolu s ďalšími „telemetrickými“ hodnotami (napätia jednotlivých článkov pohonnej LiPol batérie, odoberaný prúd, spotrebovaná energia, napätie palubnej inštalácie (BECu), prípadne: otáčky motora, letová rýchlosť modelu) „zabalená“ do nášho prenosového protokolu a odoslaná do zobrazovacieho modulu na zemi – pred oči pilota – do minipočítača BenQ:

Na nasledujúcej fotografii už je v akcii aj výškomer a rýchlomer modelu Harmony. Naša PC Telemetria už je v novom - tzv. Ratrak dizajne.

Ale kto chce, môže si túto hodnotu zobraziť na LCD displeji (pripojenom k PIC-mikrokontroléru) a to pomocou jediného príkazu PIC Basic Compilera:

      LcdOut "Vyska: ", #Vyska, " metrov nm" 

Na displeji potom uvidíme toto:

Ako pripojiť LCD-displej k mikrokontroléru a ďalšie veci, si môžeme ukázať v niektorej z budúcich častí seriálu.

Komentáre: 9

.:. Petr | www | mail

Pěkný popis!
Neodpustím si jen kacířskou reakci na "nepoužívání cizích knihoven" - snad si překladač do strojáku taky nepíšete sami . No a ty baročipy BM280, DPS310 etc. používané ve většině dronových FC, na výšková data k modelům jsou postačující i z hlediska šumu (si myslím). BTW - pro takovéto domácí hraní si s telemetrií většinou použiji baro/acc/gyro/gps na hotových mini FC destičkách k dronům (např. s iNav/Betflight firmware). Stabilizaci ani nepoužiji jen bohatá telemetrická data z FC (náklony, GPS, U/I, baro, atd.) posílám přes LoRa 433 Mhz na zem. Tam si plný stream telemdat (balený nejčastěji v seriovém protokolu LTM) modulem LoRa zase přijmu a zpracuji v MCU ESP32, ke kterému si připojím periferie co hrdlo ráčí a počty I2C/UART/SPI dovolí. Samozřejmě s využitím knihoven ) Petr

Odpoveď | 2021-07-26 15:52:32

.:. J O.

Jasné, že si prekladač nepíšem sám .

Vidím, že ste v tejto senzorovej oblasti dobre "kovaný".
Nemáte niekde na vašej web-stránke o tom nejaké "rozjímanie", prípadne nepripravujete nejaké?

Odpoveď | 2021-07-27 08:58:42

.:. Petr | www | mail

No jo telemetrie z RC modelů to je moje současná vášeň Ve výsledku hlasy "výška..tlak..teplota.." vypínám a na display se nedívám /už jsem takto ztratil model/ a létám si "na viditelnost"
Na www.dupedup.cz mám v sekci "RC" nebo "MCU" o tom nějaké povídání - s buffery se "nepářu"- pořídím nějaký levný 20x20 FC s STM32 pro drony, RAM habaděj, flashnu iNAV/Betaflight, nastavím posílání telemetrie přws MSP, přes UARTy si k FC připojím GPS a radiomodul LoRa/433 MHz /zároveň se modlím k ČTÚ - to jsou ČR telekomunikační dohlížeči/. Pro lora je ale možné použít malý výkon i bps. A na zemi si připojím LoRa k nějakému malému MCU, k němu OLED/SD nebo to celé přes Bluetooth přeposílám na nějakou pěknou grafickou appku v mobilu s hlasovým výstupem.
Pak si jdu létat.... a viz druhá věta..
Moc rád čtu vaše příspěvky a hodně zdaru s s obřími modely!
O senzorech bylo docela dobré https://hackaday.io/project/86912-explog-exploration-logger/log/123294-choosing-the-right-sensors
P.

Odpoveď | 2021-07-30 18:20:11

Meno
Web
Mail
Kontrola	Zadajte číslo päť
Text
	Tučné | Podrazené | Kurzíva  | zdroják | odkaz