14.2. Dostarczanie aplikacji¶
Działający skrypt na stanowisku testowym i gotowy produkt to nie to samo. Kamera, która trafia w teren, musi działać samodzielnie tak długo, jak produkt pozostaje zainstalowany – miesiące, lata – bez operatora przy konsoli, bez podłączonego IDE i bez eksperta od Python w pobliżu, gdy coś przestanie działać. Strony w tej sekcji omawiają, co zmienia się w aplikacji, gdy celem jest gotowy produkt, a nie demo na biurku.
14.2.1. Lista kontrolna przed startem¶
Zanim kamera opuści stanowisko testowe, oto krótka lista rzeczy, które powinny być prawdą:
Kod aplikacji znajduje się w buildzie, a nie w systemie plików. Zamrożone moduły oraz obraz ROMFS obejmują kod i zasoby. Pamięć flash i karta SD służą wyłącznie do przechowywania stanu uruchomieniowego i plików dziennika. Użytkownik końcowy nie może edytować, usuwać ani podmieniać aplikacji bez ponownego wgrania oprogramowania.
Watchdog działa nieprzerwanie.
machine.WDTjest uruchamiany na początkumain.pyi karmiony raz na iterację pętli głównej. Każde zawieszenie dłuższe niż skonfigurowany limit czasu powoduje reset sprzętowy i kamera ponownie się uruchamia.Aplikacja zapisuje dzienniki do odzyskiwalnego miejsca docelowego. Biblioteka
loggingzapisuje rekordy z poziomem, znacznikiem czasu i miejscem docelowym, które można odzyskać w terenie z karty SD.print()służy wyłącznie do celów deweloperskich – jego domyślnym miejscem docelowym jest standardowe wyjście USB, którego żaden gotowy produkt nie odczytuje.Pamięć flash i karta SD są traktowane jako mogące zawieść. Wewnętrzna pamięć flash przechowuje małe rekordy o stałym rozmiarze (konfigurację, ostatnią znaną kalibrację); karta SD przechowuje obszerne pliki o zmiennym rozmiarze (przechwycone obrazy, pliki dziennika); operacje na obu są opakowane w obsługę błędów, a aplikacja ma zdefiniowane rozwiązanie awaryjne na wypadek niedostępności któregokolwiek z nich.
14.2.2. Wkompilowanie aplikacji w build¶
Dwa uzupełniające się mechanizmy umieszczają pliki w obrazie oprogramowania układowego: