Myślę, że należy tutaj rozwiązać dwie kwestie:
- Niektóre systemy nie mają systemu plików - czy to znaczy, że nie mają systemu operacyjnego?
- Gdzie można zapisać konfigurację, jeśli nie ma systemu plików (lub jest on tylko do odczytu)
Czystego metalu
Niektóre systemy nie mają systemu operacyjnego - jest jedna aplikacja, a oprogramowanie aplikacyjne łączy się bezpośrednio ze sprzętem. Jest to powszechne w małych systemach mikrokontrolerów, w których złożoność jest niewielka. W tym scenariuszu oprogramowanie jest zazwyczaj przygotowywane na zamówienie, a zespół programistów pisze od zera sterowniki i abstrakcję lub używa kodu dostawcy, aby ułatwić sobie osiągnięcie celu projektowego.
To powiedziawszy, takie systemy mogą obsługiwać system plików. Proste systemy plików, takie jak FAT, są powszechnie używane do przechowywania dzienników i zapewniania aktualizacji oprogramowania układowego.
Konfiguracja często jest formatowana i zapisywana bezpośrednio w surowym nieulotnym magazynie, bez użycia systemu plików.
Embedded Systems - Scheduler
Idąc na wyższy poziom, znajdujemy nieco większe systemy i wzrost złożoności. W tym momencie znajdziemy systemy operacyjne czasu rzeczywistego (RTOS) - choć nie wszystkie mają wymagania czasu rzeczywistego - zaprojektowane z określonym zestawem funkcji. Systemy te zostaną zbudowane z zestawem „ zadań ” zaplanowanych do wykonania - zwykle nie można uruchomić innych / dowolnych zadań. Systemy te często wspierają systemy plików, sieci itp. Za pomocą kodu dostawcy lub kodu społeczności.
Konfiguracja może być zapisana w surowym magazynie lub zapisana jako plik w systemie plików.
Zajrzyj do FreeRTOS , ThreadX itp.
Systemy wbudowane
Teraz znajdujemy systemy osadzone, które są jeszcze większe. Wzrosła złożoność i na tym poziomie znajdujemy zależność od systemu plików w celu organizacji konfiguracji systemu i aplikacji / oprogramowania. Jesteśmy teraz w stanie wykonywać dowolne aplikacje, a jądra będą miały mnóstwo sterowników dla różnych urządzeń.
Tutaj patrzymy na Linux , QNX , „ Windows Embedded Compact ” itp.
Oprogramowanie będzie zwykle budowane dla systemu, wzywając projekty takie jak busybox, aby zapewnić dużą część funkcjonalności, i wykorzystując projekty takie jak buildroot i Yocto do budowania różnych aplikacji i tworzenia obrazu.
Konfiguracja najprawdopodobniej zostanie zapisana do pliku - choć nie jest to niczym, co powstrzymuje deweloperów przed używaniem surowej pamięci masowej, ponieważ systemy te zwykle działają na niestandardowym sprzęcie.
System plików jest wymagany, ale może nie być zapisywalny i może być wyłącznie „ w pamięci ” - ma ograniczony rozmiar, a wszystkie zmiany (jeśli RW) zostaną utracone przy ponownym uruchomieniu.
Pełne systemy użytkownika / serwera
Tutaj patrzymy na komputery stacjonarne z systemem okienkowym, systemy plików do odczytu i zapisu (zwykle na dużych dyskach), mnóstwo wykonywania dowolnego kodu, konfiguracja jest zdecydowanie przechowywana jako plik - jest to typ systemu, który znasz. Serwery są ogólnie bardzo podobne do komputerów stacjonarnych w warunkach, o których tu mówimy.
W świecie Linuksa byłaby to „ dystrybucja ”. Zazwyczaj znajdziesz jakąś formę zarządzania pakietami, więc instalowanie / odinstalowywanie aplikacji polega na pobieraniu i rozpakowywaniu (kompilacja również, jeśli używasz Gentoo ).
Tutaj patrzymy na Linux, Windows , Windows Server itp.
Powyżej wspominałem, że mniejsze systemy zazwyczaj przechowują konfigurację w surowym nieulotnym magazynie. Odbywa się to poprzez podjęcie decyzji, co chcesz przechowywać, zestawienie danych i zapisanie ich w pamięci.
Na przykład możemy chcieć zapisać następującą prostą konfigurację:
- Kołnierz ma ściśle określone
52458
kroki obrotu
- Kołnierz należy obrócić do pozycji
5547
o05:00
- Kołnierz musi zostać obrócony do pozytonu
49885
o18:00
Wszystkie liczby pasują do 16-bitowej liczby całkowitej, więc użyjmy tego do przedstawienia kroków. Czasami decydujemy się na przechowywanie w BCD dla lepszej kompatybilności z RTC, więc to tyle.
Mamy następujące dane:
- 52458 ->
0xCCEA
- 5547 ->
0x15AB
- 05:00 ->
0x0500
- 49885 ->
0xC2DD
- 18:00 ->
0x1800
Wartości mogą być zestawiane i zapisywane w pamięci jako 10 bajtów:
0x00000000 CC EA 15 AB 05 00 C2 DD 18 00
Aplikacja wie, jak to interpretować, więc nie potrzebuje wsparcia. Przez wsparcie mam na myśli lokalizowanie obszaru pamięci według nazwy (np .: nazwa systemu plików i nazwa pliku) oraz dzielenie się zrozumieniem konfiguracji z człowiekiem (np .: JSON / XML / YAML / TOML ).