XB_BOARD - Opis

To ściśle tajne i tajemnicze miejsce z którego wyłania się mroczna postać
Wchodzący robią to na własne ryzyko. Prosimy zachować Ciszę i nie karmić
-- Xbary jest strasznie wybredny
ODPOWIEDZ
Awatar użytkownika
xbary
Użytkownik
Posty: 102
Rejestracja: 08 paź 2017, 19:59

XB_BOARD - Opis

Post autor: xbary » 11 sty 2019, 8:25

XBaryOS, biblioteka podstawowa a może namiastka wielozadaniowości...

Chciałbym zaprezentować pierwszą wersję biblioteki mojego autorstwa, projekt ewoluował 2 lata.
Dopiero platforma ESP32 na której ostatnio pracuje spowodowała że bibliotekę XB_BOARD można nazwać podstawą systemu,
jest to pewien sposób podejścia do pisania programów na mikrokontrolery.
Oczywiście nie jest to nic odkrywczego, są istniejące już od wielu lat systemy sprawdzone w wielu projektach,
ja natomiast poszedłem w stronę tradycyjnego podejścia do pisania programu ,
czyli to co dotychczas zostało stworzone na mikrokontrolery będzie można łatwo dostosować i uruchomić w środowisku mojej biblioteki.
Cóż to jest za cudo?, otóż biblioteka udostępnia kilka funkcji które tworzą coś z wyglądu jak wielozadaniowy system,
a cały majstersztyk polega na tym że moduł aplikacji/programu zajmujący się jaką konkretną funkcją całego projektu nie musi wiedzieć
o istnieniu sąsiadujących modułów, wymogiem jest to aby nasz program w danym module nie utknął w pętli nieskończonej.

Czyli np:
odczyt temperatury z czujników DS18b20, kiedy są podłączone na dwu żyłowych kablach czyli działają na tzw zasilaniu pasożytniczym
to odczyt kolejny musi być nie częściej niż 750ms to mikrokontroler w tym czasie może zająć się zupełnie czymś innym.

Właśnie to umożliwia w prosty sposób zaimplementowanie na mojej bibliotece.
Kolejną funkcjonalnością jest możliwość aby takie pseudo zadania mogły się komunikować,
w tym celu stworzyłem na podobieństwo windowsa system messagów.
Dotychczas spotykałem się z rozwiązaniami typu callback czyli wskaźnik na konkretną funkcje, w takim rozwiązaniu należało wiele rzeczy
pamiętać co gdzie do czego podczepić, i co gorsze jeśli pojawiło się więcej zadań które oczekiwały na jakieś jedno zdarzenie,
trzeba było tworzyć tablice callbacków które wywoływane były przy nastąpieniu danego zdarzenia...
Ja proponuje system messagów gdzie zadanie wcale nie musi czekać na dane zdarzenie,
a jak jest zainteresowane danym zdarzeniem to oczekuje określonego messaga w funkcji obsługi messagów.
Takie rozwiązanie powoduje ze wcale nie musimy w projekcie mieć podczepionej biblioteki generującej jakiejś tam zdarzenia
aby reagować na jej zdarzenia, np. biblioteka oferująca GUI na terminalu.

Dane zadanie może zdefiniować okna , menu … jeszcze zanim biblioteka GUI zostanie podczepiona do projektu.
Kolejnym usprawnieniem jest oddzielenie funkcji inicjującej zadanie, coś jak setup w arduino. Każde zadanie może mieć swoje
i podczas dodawania zadania do systemu automatycznie wywoływana jest funkcja setup, gdzie np.
inicjujemy peryferia mikrokontrolera. Jest jeszcze wiele drobniejszych a jakże funkcjonalnych usprawnień jakie oferuje biblioteka,

dla przykładu podam że do istniejącego projektu dodałem terminal pracujący na TelNet,
w aplikacji nie zmieniłem ani linijki kodu a przez dodanie modułu telnet mam możliwość przez sieć widziec na terminalu to co aplikacja
na uarta wysyłała...

Myślę że nie ma dalej sensu takiego słowotoku kontynuować w tej formie i proponuje pokazać możliwości biblioteki
opisując ją funkcja po funkcji z podaniem prostego przykładu jak użyć daną funkcjonalność, a jest tego sporo.

Ciąg dalszy nastąpi .....

ODPOWIEDZ