Git - Globalny Tropiciel Informacji (Ang

Procesory osadzone ETD 7211

W8 – 25.11.2019 Maciej Rudek Programowanie tradcyjne (?)

System kontroli wersji (VCS)

VCS (ang. version/revision control system) - jest to oprogramowanie, którego głównym celem jest śledzenie zmian w tworzonym oprogramowaniu – kodzie źródłowym. Ponadto, może łączyć, zmiany w plikach, dokonane przez wielu programistów na raz w różnym czasie. VCS można podzielić ze względu na: architekturę oprogramowania, sposób oceny zmian, licencję. Historia systemów VCS

1972 r. – SCCS - System kontroli kodu źródłowego ang. Source Code Control System 1980 r. – RCS - System nadzorowania wydań ang. Revision Control System 2000 r. – CVS - Współbieżny system wersji ang. Concurrent Version System: 2001 r. – SVN system kontroli wersji ang. System Subversion 2005 r. – Git - globalny tropiciel informacji (ang. Global Information Tracker), Mercurial

Podział systemów VCS

Ze względu na działanie, VCS można podzielić na: • lokalne - zapis danych odbywa się jedynie na lokalnym komputerze • scentralizowane - architektura klient- serwer • rozproszone - architektura osoba do osoby (P2P) RCS (Revision Control System)

Lokalny komputer wykorzystywany jest do kontrolowania wersji oprogramowania.

• RCS • GNU Source Code Control System CVCS (Centralized Version Control System) - Scentralizowane systemy kontroli wersji – zewnętrzny, centralny serwer, przechowuje wszystkie wersje plików. Zaletą jest zarządzanie uprawnieniami z jednego miejsca, Jednak jest podatny na awarie.

• CVS • Subversion - SVN • GNU CSSC • JEDI VCS DVCS (Distributed Version Control System) Rozproszone systemy kontroli wersji – pobierane jest całe repozytoriów a nie tylko zmiany. Każdy klient może pełnić rolę serwera i umożliwia pracę z wieloma różnymi serwerami na raz. System ten odporny jest na awarie. • Bazaar • Codeville • Darcs • Git • GNU Arch • Mercurial • Monotone Funkcje systemów kontroli wersji

Funkcje systemu kontroli wersji • przechowywanie i kontrola dostępu do plików projektu, • Zapisywanie zmian w historii, • śledzenie zmian w poszczególnych plikach, • dokumentowanie wprowadzanych zmian w projekcie, • Śledzenie i tworzenia konfiguracji oprogramowania, • Udostępnianie innym użytkownikom kolejnych wersji poszczególnych plików –synchronizacja zmian, • kontrola rozwijania projektu, • usuwanie konfliktów pomiędzy wprowadzonymi zmianami.

GIT – głupiec / ladaco…

GIT powstał w 7 kwietnia 2005 roku przez Linusa Torvaldsa w celu wspomagania rozwoju jądra Linuxa. Prace nad GIT’em zostały rozpoczęte po zmianie warunków używania systemu BitKeeper. Do celów nowego systemu należały: • Szybkość • Prosta konstrukcja • Silne wsparcie dla nieliniowego rozwoju (tysięcy równoległych gałęzi) • Pełne rozproszenie • Wydajna obsługa dużych projektów – jądro Linuxa

GIT - historia

• 3 kwietnia 2005 – rozpoczęcie prac nad GIT’em • 6 kwietnia – ogłoszenie projektu • 7 kwietnia – obsługa kontroli wersji własnego projektu • 18 kwietnia – wykonanie łączenia gałęzi • 27 kwietnia – testowanie pod względem prędkości • 16 czerwca 2005 roku - Linux 2.6.12 był hostowany przez Gita. Zalety systemu GIT

• ułatwianie prac w środowisku rozproszonym • zdolność do obsługi tysięcy wykonawców • szybkość i skuteczność działania • wymuszanie odpowiedzialności • stałość archiwum • wielotorowość prac rozwojowych • kompletność archiwów Podstawowe cechy:

Większość systemów (np. CVS i Subversion) przechowuje informacje o nowej wersji jako różnicową listę zmian dla plików. GIT w lokalnej bazie przechowywane zmiany danych w formie migawki (ang. snapshot).

Podstawowe cechy:

Większość operacji wykonywanych jest lokalnie. Co znacznie przyspiesza przeglądanie historii zmian plików i ich edycję. Dopiero na koniec pracy potrzebne jest połączenie z serwerem, w celu wysłania swojej pracy lub aktualizacji projektu z innymi użytkownikami.

Przykładowo w Perforce, nie możesz wiele zdziałać bez połączenia z serwerem; w Subversion, albo CVS możesz edytować pliki, ale nie masz możliwości zatwierdzania zmian w repozytorium (ponieważ nie masz do niego dostępu).

Podstawowe cechy:

Wbudowany mechanizm spójności danych w postaci sumy kontrolnej, co pozwala na odnoszenie się do danego obiektu. Nie można zmienić treści pliku bez reakcji oprogramowania kontroli wersji. Mechanizmem wspomagającym jest zastosowanie sumy kontrolnej SHA-1. Jest to 40 znakowy łańcuch liczb szesnastkowych. Wylicza się go na podstawie treści pliku i struktury katalogów.

Jakie są inne sumy kontrolne ?

SHA1: 24b9da6552252 987aa493b52f8696cd6d 3b00373 Podstawowe cechy:

W GIT plik może znajdować się w jednym z trzech stanów: zatwierdzony, zmodyfikowany i śledzony.

• Zatwierdzony - dane zostały bezpiecznie zachowane w lokalnej bazie danych. • Zmodyfikowany - plik został zmieniony, ale zmiany nie zostały wprowadzone do bazy danych. • Śledzony - zmodyfikowany plik został przeznaczony do zatwierdzenia w bieżącej postaci w następnej operacji commit. Podstawowe cechy:

Wyróżniamy trzy sekcje projektu: katalog GIT, katalog roboczy i przechowalnia (ang. stage) Git – podstawowe pojecia

• repozytorium -‘kontener’ na określony zbiór kodu, najczęściej jeden projekt. Można rozróżnić repozytoria: origin, remote • branch – gałąź, rozwiązanie dla wykonywania oddzielnych zadań na projekcie • HEAD – wskaźnik na lokalną gałąź • working area / working directory / katalog roboczy – miejsce projektu z widocznymi zmianami. • master – zazwyczaj jest to nazwa głównej gałęzi • fork - kopia repozytorium; najczęściej rozwijana niezależnie - popularne w przypadku projektów open- source Czy znacie jakieś forki?

https://en.wikipedia.org/wiki/Linux_distribution#/media/File:Linux_Distribution_Timeline.svg Git-Flow

Git-Flow jest zbiorem rozszerzeń gita dostarczającym wysokopoziomowe operacje na repozytorium, wspierającym strategię rozgałęziania – autor: Vincent Driessen. Git-Flow

https://nvie.com/posts/a-successful-git-branching-model/ Podstawowe pojęcia cz.2

• commit – opis zmian w projekcie • merge – łączenie wielu źródeł • pull/push – pobranie i wysłanie zmian do repozytorium • diff – sprawdzanie dokonanych zmian,

Podstawowe polecenia

• git init – tworzy nowe repozytorium • git config – globalne ustawienia GIT’a • git clone – pobiera zdalne repozytorium • git fetch – pobiera obiekty z innego repozytorium • git pull – pobiera i integruje zdalne repozytorium • git push – aktualizuje zdalne repozytorium • git status – pokazuje status katalogu roboczego i poczekalni • git add/rm/mv – dodaje/usuwa/przenosi plik • git commit – zapisuje zmiany do repo • git log – wyświetla logi z commit’a

Podstawowe polecenia

• git branch – wyświetla gałęzie • git checkout – przełączanie się między gałęziami • git merge – łączy ze sobą podane gałęzie • git rebase – przebudowanie gałęzi • git reset – RESET !  • git status – stan plików na gałęzi • git stash – zapisuje/odczytuje zmiany z przestrzeni • git diff – pokazuje dokonane zmiany

Hosting

Istnieje wiele popularnych serwisów wykorzystujących repozytorium GIT:

• GitHub, • GitLab, • Bitbucket, • SourceForge, • Gitorious, • …

Github.com

https://github.com/ Github.com

https://github.com/maciej-PWr/myARM Klient GIT

https://git-scm.com/downloads Git - konsola

Git - konsola

https://git-scm.com/book/pl/v2 Podstawowe operacje

Integracja katalogi z GIT’em $ git init

$ git clone https://github.com/maciej- PWr/myARM.git Podstawowe operacje

https://github.com/maciej-PWr/myARM Podstawowe operacje

Integracja katalogi z GIT’em

https://github.com/maciej-PWr/myARM.git GIT + Linux

Podstawowe obsługa

Podstawowa obsługa

$ git commit

*** Please tell me who you are.

Run git config --global user.email "[email protected]" git config --global user.name "Your Name" Co się stało

Praca na dwóch mazynach

$ git push GIT – konflikt wersji

GIT – konflikt wersji

Dlaczego są różnice?

Gdzie są różnice?

Liczba pustych linijek … GIT - naprawa

GIT - naprawa

Dwie nowe spacje

Brak spacji w starym pliku […] <<<<<<< HEAD NOWE zmiany ======Co powinniśmy zrobić? STARY plik >>>>>>> local:NoweRzeczy GIT - naprawa

Kolejne kroki: • Zapisujemy zmiany • Wychodzimy z edycji plików • Przechodzimy do konsoli w celu akceptacji zmian GIT - naprawa

GIT - naprawa

GIT – co się stało

GIT - naprawa

$ git tig GIT - naprawa

$ git tig Git diff

$ git diff d49.. 75a.. GIT – pull –r (Win)

Git branch

Zmiany w plikach README, main

README.md

main.c Git branch Git branch

$ git checkout -b iss53 $ git commit -a -m 'nowa stopka [#53]'

$ git branch iss53 $ git checkout iss53 https://git-scm.com/book/pl/v1/Ga%C5%82%C4%99zie-Gita-Podstawy-rozga%C5%82%C4%99ziania-i-scalania Git branch

$ git commit -a -m 'nowa stopka [#53]' $ git checkout master $ git checkout -b 'hotfix‚ $ [poprawki] $ git commit -a -m 'poprawiony’

https://git-scm.com/book/pl/v1/Ga%C5%82%C4%99zie-Gita-Podstawy-rozga%C5%82%C4%99ziania-i-scalania Git branch + merge

$ git checkout master $ git checkout iss53 $ git merge hotfix $ vim index.html $ git commit -a -m 'skończona'

https://git-scm.com/book/pl/v1/Ga%C5%82%C4%99zie-Gita-Podstawy-rozga%C5%82%C4%99ziania-i-scalania Git merge

$ git checkout master $ git merge iss53

https://git-scm.com/book/pl/v1/Ga%C5%82%C4%99zie-Gita-Podstawy-rozga%C5%82%C4%99ziania-i-scalania Literatura

• Włodzimierz Gajda, Git. Rozproszony system kontroli wersji • RICHARD E. SILVERMAN, GIT. LEKSYKON KIESZONKOWY • Peter Bell, Brent Beer, GitHub. Przyjazny przewodnik • Scott Chacon, Ben Straub, Pro Git book • https://git-scm.com/book/pl/v2 Systemy czasu rzeczywistego System czasu rzeczywistego RTOS – Real Time Operating System

wg. standardu IEEE/ANSI

Zastosowanie

6 Wydajność 4 System czasu rzeczywistego RTOS – Real Time Operating System

System – to zorganizowany zbiór obiektów, które są od siebie zależne i stanowią zamkniętą jednostkę.

System czasu rzeczywistego: • wynik działania programu zależy od czasu, • ciągły związek pomiędzy asynchronicznym środowiskiem, • czas reakcji systemu jest niezauważalny przez proces – decyzja podjęta we właściwym czasie, • system odpowiada w sposób przewidywalny na bodźce zewnętrzne

Krótko mówiąc … … program do zarządzania pracą innych programów

6 5 Podział systemów czasu rzeczywistego

System o twardych (ostrych) wymaganiach czasowych: • odpowiedz systemu musi zostać wypracowana przed upływem określonego czasu, • odpowiedź systemu powinna być przesłana dokładnie Hard RTS w danym momencie czasu.

System o solidnych wymaganiach Firm RTS czasowych: • definiuje się pewien krótki czas reakcji systemu , który powinien być spełniony miękko oraz dłuższy czas reakcji systemu, który powinien być spełniony twardo. Soft RTS System o miękkich (łagodnych) wymaganiach czasowych: • zadania wykonywane są tak szybko jak to możliwe ale nie muszą zakończyć się w określonym czasie. 6 6 Hard RTS Soft RTS

6 7 Po co ten hard …. soft ….

• W systemie czasu rzeczywistego nie tylko istotny jest otrzymany wynik, niemniej ważny jest czas jego otrzymania.

• Istnieją sytuacje, gdy otrzymany zbyt późno nawet poprawny rezultat jest bezużyteczny.

odl. 1 m

6 szybkość ruchu 1 m/s 8 Po co ten hard …. soft ….

• W systemie czasu rzeczywistego nie tylko istotny jest otrzymany wynik, niemniej ważny jest czas jego otrzymania.

• Istnieją sytuacje, gdy otrzymany zbyt późno nawet poprawny rezultat jest bezużyteczny.

odl. 1 m

6 szybkość ruchu 1 m/s 9 Cechy systemów RTOS

• ciągłość działania, • zależność systemu od otoczenia, • współbieżność, Główne cechy • przewidywalność, systemów czasu rzeczywistego: • punktualność

7 0 7 1 KaRTOS – dla 8-bitowych RISC-ów

72 Budowa RTOS

Jądro – zbiór procedur realizujących m.in.: • inicjalizacja mikroprocesora/mikrokontrolera, Aplikacja • inicjalizacja zadań, • szeregowanie zadań, • zarządzanie kolejkami.

Timer systemowy - blok wykorzystujący sprzętowy biblioteki C, C++ licznik i zegar systemowy do odmierzania jednostkowych odcinków czasu – tzw. minimalnych kwantów czasu.

Pamięć systemowa – to obszar pamięci danych zawierający zmienne systemowe oraz stos systemowy.

Protokoły Sterowniki komunikacyjne urządzeń Stos – obszar pamięci RAM zawierający adresy powrotu przy wykonywaniu skoków do funkcji, zmienne tymczasowe, kontekst zadania niezbędny podczas przełączania. Rozmiar definiuje użytkownik, a zależy m.in. od stopnia zagnieżdzenia.

SPRZĘT

73 Budowa RTOS

74 Przydział czasu - algorytm karuzelowy

Czas procesora

75 Obsługa zadań

Szeregowanie zadań: • round robin, • algorytm karuzelowy,

• synchronizacja zadań T

76 czas [ms] po upływie czasu oczekiwania zadanie 2 zostaje przerwane i wznowione 1

10 20 15 czas [ms]

Po co bezczynnie czekać ? 77 W tym czasie wykonajmy zadanie 2 Zadanie 1 Zadanie 2 Zadanie 3

SYSTEM OPERACYJNY - RTOS

PAMIĘĆ KOPROCESOR UART ADC DAC PWM USB 78 Planista – szeregowanie zadań - scheduler

Zadania: • optymalnie rozdzielić czas procesora oraz zasoby systemu pomiędzy uruchomione zadania, • uwzględniać priorytety zadań, • uwzględniać czasy realizacji

W systemach z wywłaszczaniem, zadania mogą być przerywane i wstrzymywane na rzecz innych zadań. 79 Daje to iluzję równoległego wykonywania zadań Planista – szeregowanie zadań - scheduler

Planista działa m.in. w tzw. przerwaniu systemowym (ang. system tick), ktore najczęściej jest wywoływane cyklicznie (10-1000Hz).

Im częstsze przerwanie tym precyzyjniej można kontrolować czas 80 mechanizmami RTOS, ale więcej czasu „tracimy” na obsługę przerwania. Planista – szeregowanie zadań - scheduler

Planista podejmuje decyzję, które zadanie ma otrzymać czas CPU w następnym cyklu. • Wybierane jest zadanie o najwyższym priorytecie z kolejki zadań o statusie („ready”). • Aktualnie wykonywane zadanie jest przesuwane na koniec kolejki.

zadanie o wyższym zadania o tym samym priorytecie są priorytecie zawsze ma wykonywane naprzemiennie (tzw. 81 pierwszeństwo round-robin scheduling) Planista stan bezczynności

TASK3 zakończyło działanie i żadne inne zadanie nie jest gotowe do działania (są zablokowane lub zawieszone)

Jeżeli żadne z zadań nie jest gotowe do działania, uruchamiane jest tzw. zadanie bezczynne (idle task), które jest zawsze domyślnie 82 tworzone przez system. FreeRTOS

• darmowe narzędzie open source, • możliwość stosowania w aplikacjach komercyjnych, • brak pewności, co do stabilności działania i braku błędów

System operacyjny w swej podstawowej formie jest niezależny od sprzętu.

http://www.freertos.org/

• jądro systemu • interfejs, konfiguracja

83 Opóźnione wykonanie zadania

Aby wprowadzić opóźnienie w zadaniu należy po prostu poinformować planistę, że zadanie rezygnuje z wykonywania się na zadany okres czasu.

W FreeRTOS służą do tego dwie funkcje:

void vTaskDelay (portTickType xTicksToDelay);

void vTaskDelayUntil (portTickType *pxPreviousWakeTime, portTickType xTimeIncrement);

Opóźnienie wyrażone jest w ilości „ticków” systemowych. 84 Opóźnione wykonanie zadania

Chcemy napisać zadanie wysyłające ramkę danych o zmiennej długości dokładnie co 100ms.

Ten blok kodu wykonuje się w czasie zależnym od zmiennej data_size

85 Opóźnione wykonanie zadania

Ten blok kodu wykonuje się w czasie zależnym od zmiennej data_size

...ale tu go kompensujemy

86 Zwolnienie planisty …

Aby ochronić sekcję kodu zadania przed wywłaszczeniem, można też zawiesić działanie planisty.

87 Realizacja procesów, programów

Współprogramy Zadania (tasks) (Co-routines) • każde zadanie • dzielą jeden stos, posiada swój własny • do swego działania kontekst, stos potrzebują • wszystkie rejestry i mniejszej ilości stos należą tylko do pamięci RAM niego

Zadania i współprogramy nie mogą się komunikować między sobą za pomocą kolejek i semaforów, a zadania zawsze są ważniejsze od współprogramów 88 Zadania

Zadania (inaczej wątki) są elementarną jednostką aplikacji. Można je traktować jak małe, niezależne programy realizowane „równolegle” przez ten sam mikrokontroler. Są to funkcje o zdefiniowanym typie, często realizowane w postaci nieskończonych pętli.

W systemie FreeRTOS zadanie nie może się skończyć jak zwykła funkcja instrukcją return. Zamiast tego zadanie może być jednak usunięte poprzez 89 wywołanie vTaskDelete(). Zadania mogą być tworzone podczas inicjalizacji systemu lub później w trakcie pracy przez inne zadania.

90 Zadania – etapy realizacji

Wyróżniamy cztery możliwe stany, w których zadanie może się znajdować:

Wykonywane (Running) – zadanie Wstrzymane aktualnie korzysta z zasobów mikrokontrolera

Gotowe do wykonania (Ready) – może być wykonywane ale czeka na zwolnienie zasobów przez inne zadanie GOTOWE Wykonywane Zablokowane (Blocked) – zadanie czeka na zdarzenie, np. koniec czasu lub przerwanie

Wstrzymane (Suspended) – zadanie Zablokowane zostało wstrzymane, nie jest uwzględnione przez planistę, może być wznowione 91 Zadania – etapy realizacji

Wstrzymane

()

xTaskCreate() GOTOWE Wykonywane

event vTaskSuspend

Zablokowane

Z każdym zadaniem związany jest priorytet. W systemie FreeRTOS kilka zadań może mieć taki sam priorytet. Inne systemy (np. uC/OS-II) wymagają unikalnych 92 wartości priorytetów. Zadania STOS

Każde zadanie ma przydzielony własny obszar pamięci operacyjnej na stos. Przydział ten następuje podczas tworzenia zadania.

93 Zadania – etapy realizacji

Każde zadanie w systemie operacyjnym jest zazwyczaj funkcją, pisaną wg. określonych standardów.

void vTaskX(void * pvParameters) { for(;;) kod zadania musi być umieszczony, { w pętli nieskończonej for lub while, // kod realizowanego zadania czyli raz wywołane zdanie nigdy samoczynnie nie powróci do } miejsca swojego wywołania. }

94 Główna funkcja programu main()

Każde zadanie w systemie operacyjnym jest zazwyczaj funkcją, pisaną wg. określonych standardów.

int main( void ) { // Konfiguracja sprzętu prvSetupHardware();

// Uruchomienie zadań vStartLDTasks(TASK_PRIORITY ); uruchomienie zadań oraz planisty

// Uruchomienie planisty vTaskStartScheduler();

return 0; } 95 Zadania – etapy realizacji

void vStartLEDTasks(unsigned portBASE_TYPE uxPriority) { xTaskHandle xHandleTaskLED;

// Tworzenie zadania xTaskCreate (vTaskLED, ( signed portCHAR * ) „LED”, STACK_SIZE, NULL, uxPriority, &xHandleTaskLED);

// Usuwanie zadania vTaskDelete(xHandleTaskLED);

}

96 FreeRTOS

System operacyjny czasu rzeczywistego FreeRTOS udostępnia programistom w sumie pięć mechanizmów wykorzystywanych do komunikacji pomiędzy zadaniami (lub przerwaniami i zadaniami) oraz do zabezpieczania zasobów mikrokontrolera. Są to: • semafory binarne, • kolejki, • semafory licznikowe, • muteksy, • muteksy rekurencyjne.

„MUTEX” - mutual exclusion”

97 xSemaphoreHandle xSemaphoreCreateMutex(void);

Dziękuję za uwagę