Visszaállítási és indítási folyamat¶

A MicroPython-t futtató eszköz egy meghatározott indítási folyamatot követ, hogy egy visszaállítás után elinduljon és inicializálja önmagát.

Megjegyzés

Az alább leírt _boot.py → boot.py → main.py → REPL folyamat az, amit a firmware minden visszaállításkor lefuttat, függetlenül attól, hogyan csatlakozol — tehát mindig érvényes. Amikor egy szkriptet az OpenMV IDE-ből futtatsz, az IDE megszakítja az éppen futó main.py-t, és a szerkesztőben megnyitott szkriptet futtatja helyette, a saját hibakeresési protokollján keresztül. Nem használja az eszközön lévő REPL-t, ezért az ezen az oldalon szereplő REPL-specifikus hivatkozások (az interaktív parancssor, a Ctrl-D / Ctrl-C egy soros terminálon stb.) az önálló működésre és a közvetlen soros terminálos munkamenetekre vonatkoznak — de maga az indítási folyamat minden esetben érvényes.

Hardveres visszaállítás¶

A hardveres visszaállításból való indulás akkor történik, amikor egy panel először kap áramot, vagyis hideg indításkor. Ez az MCU hardver teljes visszaállítása.

A MicroPython port kódja inicializálja az összes alapvető hardvert (beleértve a beágyazott órajeleket és feszültségszabályozókat, a belső soros UART-ot stb.), majd elindítja a MicroPython környezetet. A meglévő RTC konfiguráció megőrződhet egy hardveres visszaállítás után, de minden más hardverállapot törlődik.

Ugyanezt a hardveres visszaállítási indítási folyamatot számos esemény kiválthatja, például:

A machine.reset() futtatása Python kódból.
A felhasználó megnyom egy fizikai Reset gombot a panelen (ahol van ilyen).
Felébredés mélyalvásból (a legtöbb porton).
Az MCU hardveres figyelőáramkörének (watchdog) visszaállítása.
Az MCU hardveres feszültségesés-érzékelője (brown out detector).

A hardverspecifikus visszaállítási kiváltók részletei a porttól és a hozzá tartozó hardvertől függenek. A machine.reset_cause() függvénnyel tovább lehet meghatározni a visszaállítás okát.

Szoftveres visszaállítás¶

Amikor a MicroPython már fut, lehetőség van szoftveres visszaállítás kiváltására a Ctrl-D beírásával a REPL-be vagy a machine.soft_reset() futtatásával.

A szoftveres visszaállítás kitörli a Python értelmezőt, felszabadítja az összes Python memóriát, és újraindítja a MicroPython környezetet.

A szoftveres visszaállítás által törölt állapotok közé tartozik:

Minden Python változó, objektum, importált modul stb.
A machine modul használatával konfigurált legtöbb periféria. Nagyon korlátozott kivételek vannak, például a machine.Pin üzemmódjai (vagyis hogy egy láb bemenet vagy kimenet, magas vagy alacsony) a legtöbb porton nem állnak vissza. A fejlettebb konfiguráció, mint például a Pin.irq(), mindig visszaáll.
Bluetooth.
Hálózati socketek. A nyitott TCP socketek a másik fél felé tisztán zárulnak be.
Nyitott fájlok. A fájlrendszer érvényes állapotban marad.

Néhány rendszerállapot változatlan marad egy szoftveres visszaállítás után, beleértve:

A meglévő hálózati kapcsolatok (Ethernet, Wi-Fi stb.) az IP-hálózati rétegen aktívak maradnak. A hálózati interfész kódból történő lekérdezése azt mutathatja, hogy a hálózati interfész továbbra is aktív, beállított IP-címmel stb.
Egy aktív REPL folytonosnak tűnik a szoftveres visszaállítás előtt és után, kivéve néhány szokatlan esetet:
- Egy soros UART REPL visszaállítja az alapértelmezett hardverkonfigurációját (átviteli sebesség (baud) stb.).
A CPU órajel sebességét a szoftveres visszaállítás általában nem változtatja meg.
A RTC konfigurációját (vagyis az aktuális idő beállítását) a szoftveres visszaállítás nem változtatja meg.

Indítási folyamat¶

Amikor a MicroPython egy hardveres vagy szoftveres visszaállítás után elindul, a következő indítási folyamatot követi sorrendben:

_boot.py¶

Ez egy belső szkript, amely be van fagyasztva a MicroPython firmware-be. A MicroPython számos porton biztosítja az alapvető inicializálás elvégzésére.

Például a legtöbb porton a _boot.py érzékeli egy új eszköz első indítását, és megformázza a belső flash fájlrendszert, hogy az használatra kész legyen.

Hacsak nem készítesz egyéni MicroPython buildet vagy adsz hozzá új portot, valószínűleg nem kell foglalkoznod a _boot.py-val. Legjobb nem megváltoztatni a tartalmát, hacsak nem tudod pontosan, mit csinálsz.

boot.py¶

Egy boot.py nevű fájlt a panel belső fájlrendszerébe lehet másolni az mpremote segítségével.

Ha a boot.py megtalálható, akkor lefut. A boot.py-ba kódot adhatsz egyéni, egyszeri inicializálás elvégzésére (például a panel hardverének konfigurálására).

Gyakori gyakorlat a panel hálózati kapcsolatának konfigurálása a boot.py-ban, hogy az mindig elérhető legyen a visszaállítás után a REPL-lel, az mpremote-tal stb. való használathoz.

Figyelem

A boot.py-nak mindig ki kell lépnie, és nem szabad határozatlan ideig futnia.

A paneltől függően egyes hardverinicializálások a boot.py kilépéséig el vannak halasztva. Ez magában foglalja az USB inicializálását az STM32-alapú OpenMV Cam-eken. Ezeken a paneleken a boot.py-ból kiírt kimenet a beépített USB soros porton csak a boot.py futásának befejezése után válhat láthatóvá.

Ennek a kései inicializálásnak az a célja, hogy lehetséges legyen egy adott hardver előzetes konfigurálása a boot.py-ban, majd annak elindítása a megfelelő konfigurációval.

Megjegyzés

Néha egyszerűbb nem használni boot.py fájlt, és bármilyen inicializáló kódot inkább a main.py elejére helyezni.

main.py¶

A boot.py-hoz hasonlóan egy main.py nevű fájlt is be lehet másolni a panel belső fájlrendszerébe. Ha megtalálható, akkor az indítási folyamatban ez fut le következőnek.

A main.py bármilyen Python kódhoz való, amelyet minden alkalommal le szeretnél futtatni, amikor az eszköz elindul.

Néhány tipp a main.py használatához:

A main.py-nak nem kell kilépnie, nyugodtan tehetsz bele egy végtelen while True ciklust.
Összetett Python alkalmazások esetén nem kell az összes kódot a main.py-ba tenned. A main.py lehet egy egyszerű belépési pont, amely importálja az alkalmazásodat és elindítja a végrehajtást:
```
import my_app
my_app.main()
```
Ez segíthet áttekinthetően tartani az alkalmazásod szerkezetét. Emellett megkönnyíti több alkalmazás telepítését egy panelre és a köztük való váltást.

Robusztus alkalmazások írásakor jó gyakorlat a main.py-ban lévő kódot kivételkezelővel körbevenni, hogy megfelelő lépéseket tegyen, ha a kód összeomlik. Például:

import machine, sys
import my_app
try:
    my_app.main()
except Exception as e:
    print("Fatal error in main:")
    sys.print_exception(e)

# Following a normal Exception or main() exiting, reset the board.
# Following a non-Exception error such as KeyboardInterrupt (Ctrl-C),
# this code will drop to a REPL. Place machine.reset() in a finally
# block to always reset, instead.
machine.reset()

Ellenkező esetben a MicroPython bármilyen összeomlás után, vagy ha a main kilép, visszatér a REPL-hez (lásd alább).

Bármely globális változó, amely a boot.py-ban lett beállítva, a main.py globális kontextusában is be lesz állítva.
A flash memória használatának és a memóriafogyasztásnak a teljes optimalizálásához előre lefordított main.mpy és/vagy boot.mpy fájlokat másolhatsz a fájlrendszerbe, vagy akár be is fagyaszthatod őket a firmware buildbe.
A main.py végrehajtása kimarad, amikor a szoftveres visszaállítás a nyers REPL módból indul (például amikor az mpremote vagy egy másik program közvetlenül kommunikál a MicroPython-nal).

Interaktív értelmező (REPL)¶

Ha a main.py nem található, vagy ha a main.py kilép, akkor azonnal elindul a A MicroPython interaktív értelmező mód (más néven REPL).

Megjegyzés

Még ha a main.py végtelen ciklust is tartalmaz, a Ctrl-C beírása a REPL soros porton egy KeyboardInterrupt-ot vált ki. Ha egyetlen kivételkezelő sem kapja el, akkor a main.py kilép, és elindul a REPL.

Bármely globális változó, amely a boot.py-ban és a main.py-ban lett beállítva, a REPL globális kontextusában is be lesz állítva.

A REPL addig folytatja a végrehajtást, amíg a Python kód ki nem vált egy hardveres vagy szoftveres visszaállítást.

Szoftveres lefagyás (indítási hiba)¶

Ritka, de előfordulhat, hogy a MicroPython az indítás során nem válaszol, ezt az állapotot néha „szoftveresen lefagyottnak” (soft bricked) nevezik. Például:

Ha a boot.py végrehajtása elakad, és a natív USB soros port soha nem inicializálódik.
Ha a Python kód újrakonfigurálja a REPL interfészt, így az hozzáférhetetlenné válik.

Nyugodj meg, a helyreállítás lehetséges!

Ha az OpenMV IDE-t használod, gyakran elég csak csatlakozni — az IDE leállítja a futó main.py-t és átveszi az irányítást. Ha a kamera egyáltalán nem csatlakozik, használd az alábbi Gyári visszaállítást. A következőként ismertetett Ctrl-C módszer a közvetlen soros terminálos munkamenetekhez való — az eszközön lévő REPL-re támaszkodik, amelyet az OpenMV IDE nem használ.

KeyboardInterrupt¶

Sok esetben a REPL soros port megnyitása és a Ctrl-C beírása egy KeyboardInterrupt-ot vált ki, és okozhatja a futó szkript kilépését és egy REPL elindulását. A REPL-ből az os.remove() segítségével eltávolíthatod a rendellenesen működő Python fájlt:

import os
os.remove('main.py')

Annak megerősítéséhez, hogy mely fájlok vannak még jelen a belső fájlrendszerben:

import os
os.listdir()

Gyári visszaállítás¶

Ha a fenti módszerrel nem tudsz eljutni a REPL-hez, a fennmaradó lehetőség egy gyári visszaállítás: a belső flash fájlrendszer teljes tartalmának törlése. Ez egyben a megoldás akkor is, ha a belső fájlrendszer megsérült.

Az OpenMV IDE-nek több beépített módja is van erre. Először tedd a kamerát helyreállítási/rendszerbetöltő módba — a módszer panelenként eltér, ezért a panelnek a gyors referenciájában lévő Recovery and debug pins szakaszban nézd meg, hogyan léphetsz be ebbe. Ezután kattints a csatlakoztatás gombra az OpenMV IDE-ben, és kövesd az utasításokat a fájlrendszer törléséhez és a firmware újraflashleséhez.

Figyelem

A firmware újraflashelése a fájlrendszer törlése nélkül általában nem állítja helyre a szoftveres lefagyást, mivel egy normál firmware-frissítés megőrzi a fájlrendszer tartalmát. Ügyelj rá, hogy a törlési lehetőséget válaszd, amikor az OpenMV IDE rákérdez.

Ha elakadsz, kérdezz az OpenMV fórumokon.