Turnigy 9X - nowy firmware: RadioClone

[rafit]

Odnośnie telemetrii, zastanawiałem się nawet aby zmienić sposób połączenia interfejsu SD (przeniesienie linii CS w lewo) - są zdaje się nawet ślady tych działań w moim kodzie. Projekt został jednak zarzucony. I tak nie miałbym miejsca aby wcisnąć obsługę telemetrii (brak pamięci FLASH).

 

Odpowiedź więc brzmi, trzeba wybrać: albo używasz ER9X ze wsparciem do telemetrii, albo RadioClone z SD...

 

Przy okazji Gruvin ma własny hardware... oparty o ATMega2560. Ciekawa platforma ze wsparciem SD i telemetrii ale jakoś ostatnio brakuje mi motywacji aby dostosować RadioClone pod tą platformę.

[Gites]

Taka tam jeszcze moja dygresja...

Można by kod do obsługi telemetrii i kod do obsługi kart SD kompilować warunkowo. Tak więc powstałyby niejako trzy wersje binarki:

- z obsługą kart SD

- z obsługą telemetrii

- z obsługą i kart SD i telemetrii - jako ukłon w stronę posiadaczy ATmega128 i jednoczesna zachęta do podjęcia wyzwania podmiany mikrokontrolera na wersję 128.

Pytaniem jest tylko czy wystarczy portów w mikrokontrolerze, żeby to wszystko podłączyć, tzn. złącze programatora, sterowanie podświetleniem, moduł czytnika kart SD, telemetria - fizycznie da się?

No i podstawowe pytanie czy Ty jako pomysłodawca i autor zechcesz generować trzy buildy dla tego samego releasu - więcej pracy, więcej do ogarnięcia, a nie każdy ma na to czas.

[Arek12127]

Punkt1)

ad 1) Trymery zmieniają długości impulsów sterujących PPM wysyłanych do nadajnika POZA zdefiniowane limity. Jeżeli są one bardzo krótkie / długie, to niektóre tory radiowe mogą je błędnie interpretować. Może zajść interakcja pomiędzy sąsiednimi kanałami (lub nawet kanały nie spełniające "założeń" producenta toru radiowego zostaną zignorowanie). Z drugiej strony jeżeli potrzebujesz tak bardzo wychylić trymer, to przypuszczam, że nie ustawiłeś wcześniej mechaniczne sterów w odpowiedniej pozycji.

 

Rozwiązań tego problemu może być kilka. Najprostsze np ograniczenie działania trymerów, może jednak niekorzystnie wpłynąć na inne tory radiowe.

 

Sprawdziłem oscyloskopem sygnał PPM w chwili, gdy serwo wraca do neutrum, a silnik załącza się (przy wychyleniu prawego drązka - kierunek/wysokość):

Jak to wcześniej wyjaśnił Rafit, impulsy PPM były poza prawidłowym zakresem.

 

Punkt2)

ad 2) Rozmiar skompilowanego pliku zależy od wersji AVRStudio (i wersji używanego przez nią gcc). Pliki które kompilujesz są zapewne poprawne.

 

Znowu masz rację.

Wgrałem skompilowany u siebie plik.hex i wszystko działa poprawnie .

Dziękuję Rafit.

 

Punkt3)

Mając więcej wolnego czasu postanowiłem zmienić działanie trymerów ingerując bezpośrednio w soft.

 

"Symfonia C++ standard" Jerzego Grębosza pomogła "wgryźć się" w temat.

 

Trymery dodałem przed ograniczeniem wartości wyjść do zakresu (-100,100).

Dodatkowo trymery są ograniczone do zakresu (-zakres%, zakres%), gdzie zakres% = 30..70 jest ustawiany w menu trymerów i zapisywany w pamięci EEPROM jak pozostałe parametry.

 

Poszerzyłem też zakres opóźnienia trymera z (5..30) na (1..30).

 

Procedurę PPMSave przeniosłem przed procedury appLoop_Display i appLoop_Menu.

 

 

Zmiany spowodowały, że generowana ramka PPM zawsze mieści się w ustalonych limitach.

 

Dodatkowo w oknie wizualizacji widać wpływ trymerów na wyjścia.

 

 

Nie wiem, czy wprowadzone zmiany, nie odbiją się negatywnie na którejś z funkcjonalności nadajnika. Brak mi doświadczenia zarówno, jeśli chodzi o programowanie w C, jak i doświadczenia typowo modelarskiego. Wszystko wyjdzie, jak to się mówi, w praniu.

 

Przy okazji tego doświadczenia, nie dało się nie zauważyć ogromu pracy jaki w napisanie softu włożył Rafit. Program jest bardzo rozbudowany, a specyfika języka C dodatkowo wszystko komplikuje (jak dla mnie).

Wielki szacun dla Rafita.

 

Punkt4)

Miałem problem z odczytem modelu z SD => menu PAMIĘĆ / ODCZYT MODELU Z SD.

Kursor przeskakiwał o dwie pozycje zamiast o jedną, znikał zupełnie wraz z listą katalogów i plików,

wyświetlana lista plików i katalogów co chwilę się odświerzała i było widać w tle napis "karta SD wykryta" itp.

 

Rozwiązanie problemu okazało się bardzo proste.

Wystarczyło zmienić dzielnik w menu Ustaw prędkość SD z 128 na 16.

(przy dzielniku 8 karta nie została wykryta).

Po zmianie dzielnika menu ODCZYT MODELU Z SD działa poprawnie.

 

Punkt5)

 

Dołączam się do głosów za zmianą procesora na Atmega128 i dalszym rozwijaniu softu na tym procku.

 

 

Pozdrawiam

Arek12127

[rafit]

@Arek12127 złączony plik konfiguracji modelu na forum nie jest zgodny z opisem, to chyba nie ten? W tym nie ma śladu po konfiguracji trymerów.

 

Odnośnie zaproponowanego rozwiązania, obawiam się że jest bardziej niebezpieczne od choroby. Trymery w radiu działają poza i trochę z boku systemu mikserów. Jeżeli "wbijesz" modyfikacje trymerów do zmiennych OutX spowodujesz, że wszystkie konfiguracje bazujące na wartościach wyjść przestaną działać! (od zegarów sterowanych wartością Out3 na moim "kotku" skończywszy)

 

Wracając do podstaw, o ile wiem trymery mają na celu "drobne" korekty ustawienia sterów w trakcie lotu, tak aby model latał prosto. Trymowanie jest równoważne z funkcją "PODSTAWY -> Centrowanie serw" i tak też je należy traktować. Dodatkowo trymery są zapisywane w pamięci modelu (3 sekundy po ostatniej zmianie) ale TYLKO jeżeli zmiana nastąpiła przy użyciu klawiszy.

 

Paradoksalnie to co chciałeś uzyskać modyfikując trymery, dałoby się najprawdopodobniej zrobić prostym mikserem dodając odczyty z odpowiednich pokręteł do MELE i MAIL... Tyle, że wtedy nie znalazłbyś problemu z trymerami Wszystko ma więc swoje dobre strony.

 

Przemyślałem jeszcze raz sprawę trymerów i ogólnie ograniczania sygnału PPM wysyłanego do modułu radiowego. Przyznam się że sam używam FrSky, a tam opisane problemy nie występowały... Wydaje się że sensowne byłoby następujące rozwiązanie:

- trymery działają jak do tej pory

- przed generacją sygnału PPM jest on porównywany z wartościami ustawionymi w opcji "KONFIG -> Tor radiowy". Wartości "Domyś.min" i "Domyś.max" będą NIEPRZEKRACZALNE. Jeżeli sygnał je przekroczy zostanie bezwarunkowo obcięty.

- opcja "MODEL -> Wizualizacja" została przebudowana. Od teraz nie pokazuje już stanu zmiennych OutX tylko rzeczywiste wartości sygnałów PPM wyskalowane w zakresie (min - max) zdefiniowanym w konfiguracji toru radiowego.

 

Takie rozwiązanie ma jednak swoje reperkusje:

- przy obecnej domyślnej konfiguracji nawet trymer nie będzie wstanie przesunąć zakresu ruchu serwa poza zdefiniowaną w ustawieniach toru radiowego

- obecne domyślne ustawienia toru radiowego zostały zmienione i są dość asekuracyjne (długość impulsu od 0,4 do 1,6 ms, a odstęp 0,45 ms).

- konfiguracja nowego modelu nie pobiera już wartości domyślnych z ustawień toru radiowego, a wpisane są one na stałe 500-1000-1500

 

Teraz prośba o przetestowanie nowego rozwiązania zanim wystawię je jako powszechne i określenie minimalnych / maksymalnych wartości dla toru radiowego dołączanego do Turnigy 9X

 

PS. zniosłem ustawienia opóźnienia trymerów (można je ustawić od "1"), choć nie jestem przekonany czy to użyteczne.

 

EDIT:

Jeszcze kwestia telemetrii. Tak szczerze do czego chcecie jej użyć? Możecie podać jakiś przykład co chcecie osiągnąć (rzeczywista konfiguracja i zastosowanie telemetrii).

 

Ja to kiepski jestem, ale jakoś trudno mi sobie wyobrazić zerkanie na ekran jak samolot jest w powietrzu .

[Arek12127]

@Arek12127 złączony plik konfiguracji modelu na forum nie jest zgodny z opisem, to chyba nie ten? W tym nie ma śladu po konfiguracji trymerów.

 

W same trymery nie ingerowałem.

Natomiast potencjometry hov.pit i hov.thr działają analogicznie do potencjometrów na drążku wysokość/kierunek.

Przy drążku w pozycji neutralnej, zmiana ustawienia potencjometrów "hov.---" daje ten sam efekt, co użycie odpowiednich trymerów.

[Arek12127]

Wgrałem soft wer.0.75, ustawiłem czysty model, wykonałem kalibrację oraz serwa ustawiłem na maksymalne wychylenia.

 

Graniczne wartości dla toru radiowego to min=255 i max=1745.

Przy tych wartościach odbiornik działa jeszcze OK.

 

Natomiast zauważyłem, że przy trymerze wysokości ustawionym maksymalnie w dół i wychyleniu drążka w dół, przy pewnym wychyleniu serwo obraca się w przeciwne połóżenie. Widać to także na wizualizacji, więc to nie kwestia błednego działania odbiornika.

 

pozdrawiam

Arek12127

 

EDIT: przy wychyleniu drążka w lewo drugie serwo wykonuje podobny manewr.

[rafit]

Z takim testerem to można pracować Gdzie byłeś jak pisałem ten soft ?

 

Przy okazji poprawiłem jeszcze:

- domyślne wartości toru radiowego to: 260 - 1740 (tak dla bezpieczeństwa, aby działały też na innych egzemplarzach)

- ograniczenie w ustawienia centrowania serw i zakresów tak aby nie przekraczały ustawień w torze radiowym.

- "Wizualizacja" przemianowana na "Wizualizacja PPM"

- nowy model ma wpisane wartości w zależności od ustawienia toru radiowego (centrum) +/- 500 us.

 

W załączeniu kolejny soft do testów (ten już nieaktualny, dlatego został usunięty patrz błędy poniżej). Jak będzie ok wystawię go we we wszystkich wersjach językowych na stronie

[Arek12127]

Staram się , dzięki.

 

Punkt A/ To co znalazłem w 0.76:

 

1) Model / Wyjścia => było: min centr max

jest: max centr min => 1740<1000>0

Zamiast 260 jest 0, przy próbie zmniejszenia ustawia się na 260.

(1740 i 260 brane z toru radiowego i to jest OK)

 

2) Centrowanie serw => też zamiana min<>max i dodatkowo brak jakiejkolwiek regulacji.

 

3) Wizualizacja PPM => OUT3 wyświetlane w rewersie.

 

4) Tor radiowy => Maksimim zamiast Maksimum.

Wersja programu => Informacja wersji zamiast Informacja o wersji.

 

 

Punkt B/ Do przemyślenia:

 

1) Czy funkcja centrowania serw jest nam do czegoś potrzebna?

To samo można uzyskać w menu model/wyjscia.

 

2) W menu tor radiowy ustalamy min i max sygnału PPM, tak aby odbiornik poprawnie interpretował sygnał.

Te wartości są granicznymi w menu model/wyjścia.

Generowany sygnał PPM powinien być ograniczany dla każdego wyjścia z osobna zgodnie z wartościami min i max ustawionymi w menu model/wyjścia, a nie granicznymi dla sygnału PPM

(menu tor radiowy).

 

Te wartości min i max mogą być przecież wymuszone przez konstrukcję modelu i nie powinny być przekraczane, aby nie uszkodzić serw, czy samego modelu.

 

Daj znać jak będziesz miał dość tego marudzenia .

[rafit]

Odnośnie :

Punkt A

1-3... wszystko spowodowane przez głupi błąd wprowadzony poprawką, która miała być "banalnie prosta" więc dodałem ją bez sprawdzania. Poprawione.

4) poprawione

 

Punkt B

1) To prawda, ale centrowanie serw ułatwia i bardzo przyśpiesza konfigurację modelu. Centrowanie serw zachowuje liniowość ruchu serwa (nie zmienia proporcji wychylenia). Jeżeli potrzebujesz przestawić czegoś więcej - przestawiasz wtedy w opcji MODEL->Wyjścia. Tam można wymusić nieliniowość wychyleń (np aby skorygować działanie serw różnych producentów), rozszerzyć zakres ruchu itp.

W skrócie aby ustawić "subtrims" znane z innych aparatur używasz "centrowanie serw". Można to samo oczywiście zrobić przez "Wyjścia" ale wymaga to więcej uwagi i dużo więcej klikania.

 

2) "Generowany sygnał PPM powinien być ograniczany dla każdego wyjścia z osobna zgodnie z wartościami min i max ustawionymi w menu model/wyjścia, a nie granicznymi dla sygnału PPM (menu tor radiowy)."

Też tak kiedyś myślałem, ale to niepraktyczne... Po prostu nie sprawdza się przy konfiguracji rzeczywistych modeli. Zwykle po ustawieniu lub odczytaniu konfiguracji modelu z pliku dostosowuje ją do konkretnego modelu właśnie przez "Centrowanie serw". Standardowo powierzchnie sterowe i tak nie wychylają się zwykle w pełnym zakresie więc zostaje jeszcze miejsce na ewentualną regulację trymerami (zwykle starcza kilka "piknięć").

 

Jeżeli faktycznie jakieś serwa nie pozwalają na większy ruch - zawsze możesz wyłączyć dla nich trymery, lub zmniejszyć zakres ruchu tak aby uwzględnić "luz" dla trymerów.

Można też wyłączyć trymery w mikserach i dodać je bezpośrednio do odpowiednich kanałów np. MAIL,MELE,MRUD. Takie ustawienie wymaga jednak przestawienia ustawienia "Tryb zaawansowany" dla mikserów w tryb Expert. To pozwoli na użycie jako wejść "TriA-D" czyli trymerów.

 

 

Odnośnie "marudzenia" proszę bardzo - to bardzo konstruktywne, ale i tak wszyscy się szybko wykruszają (niestety)

[kacper_80]

EDIT:

Jeszcze kwestia telemetrii. Tak szczerze do czego chcecie jej użyć? Możecie podać jakiś przykład co chcecie osiągnąć (rzeczywista konfiguracja i zastosowanie telemetrii).

 

 

Ja to kiepski jestem, ale jakoś trudno mi sobie wyobrazić zerkanie na ekran jak samolot jest w powietrzu .

 

Przy modelu szybowca nie ma problemu z zerkaniem. Możesz kontrolować poziom rozładowania pakietu, wysokość, wariometr. Dodatkowo zawsze można wprowadzić system alarmów dźwiękowych np. poziom rozładowania akumulatorów, przekroczony prąd regulatora, temperatura, niski poziom paliwa itp. jeśli wykracza poza wartości zadane zgłasza alarm dźwiękowy i wyświetla info co się dzieje.

[Arek12127]

Wgrałem soft 0.77 i wydaje się być OK. Dobra robota .

 

Edit:

Zapomniałem jeszcze o jednym: proponuję przy wgrywaniu modelu z SD i po zapisaniu go w EEPROMie zrobić reset atmegi (ustawić watchdoga na 16 ms i petle while(1)).

[rafit]

Przy modelu szybowca nie ma problemu z zerkaniem. Możesz kontrolować poziom rozładowania pakietu, wysokość, wariometr. Dodatkowo zawsze można wprowadzić system alarmów dźwiękowych np. poziom rozładowania akumulatorów, przekroczony prąd regulatora, temperatura, niski poziom paliwa itp. jeśli wykracza poza wartości zadane zgłasza alarm dźwiękowy i wyświetla info co się dzieje.

 

Właśnie - alarmy dźwiękowe. Tu jest tylko "bzyczek" który można włączyć i wyłączyć.

Odnośnie szybowców - nie latałem więc się nie wypowiem. Rozumiem z twojej wypowiedzi, że byłby wtedy czas z popatrzeniem na ekran.

Czyli potrzebowałbyś zdefiniować akceptowalne wartości i odpowiednie zachowanie dla nich + alarmy i komunikaty które mają się pokazywać. Dużo do przemyślenia. Macie może jakiś system telemetrii który uważacie za "wzorcowy" o którym można poczytać?

 

Wprowadzenie telemetrii wiązałoby się jednak z koniecznością zmiany platformy sprzętowej...

 

Zapomniałem jeszcze o jednym: proponuję przy wgrywaniu modelu z SD i po zapisaniu go w EEPROMie zrobić reset atmegi (ustawić watchdoga na 16 ms i petle while(1)).

 

Zostało teraz 355 bajtów chyba nie wcisnę. (Pisałeś że masz nowe AVR Studio. Jak duży masz program po kompilacji? /nowa wersja źródeł już jest w repozytorium/)

 

Wstyd przyznać, ale obecnie nie ma nawet obsługi watchdoga

 

Z drugiej strony masz jakiś powód dla którego chcesz restartować procesor?

[Arek12127]

Co do Watchdoga, to kompilator C chyba się nim zajmuje. Zdaje się, że u mnie watchdog jest włączony w fusebitach, a resetów brak, więc watchdog musi być kasowany.

 

***********************************************************************************************************************************

*EDIT:

*Sprawdziłem to jeszcze raz i jednak WDTON jest odznaczony, więc watchdog jest wyłączony. Coś mi się

* musiało wcześniej przewidzieć .

*Sorki za wprowadzanie w błąd.

*Poniższe instrukcje poprostu włączają watchdoga

***********************************************************************************************************************************

 

Tak czy siak, aby resetować atmegę po wczytaniu modelu z SD wystarczy zmienić fragment w pliku menu.c:

 

 

// save loaded model to eeprom

EEPROM_saveModel();

 

fatFclose();

sdClose();

 

linijki niepotrzene

//menu_mode=0; // exit menu

//menu_sel2=0;

//Clock_Init(10); // reinitialize all clocks

 

nowe linijki

// Write logical one to WDCE and WDE

asm("ldi r16,0x18");

asm("out 0x21, r16");

// Set WDT 16ms

asm("ldi r16,0x08");

asm("out 0x21, r16");

 

while (1); //reset

 

return;

Zmiana powinna się bez problemu zmieścić.

 

wersja 0.77 zajmuje 65054 + data 3805

 

Powód resetowania:

 

Mając wczytany model startowy, który ustawia stany 5,6 lub 7 i wczytując inny model, który nie używa i nie ustawia żadnego stanu, ale ma w opcjach wyświetlacza debugger, to na ekranie nadal jest wyświetlany stan 5,6 lub 7.

Po wyłączeniu i włączeniu zasilacza linia debugger jest pusta.

Oczywiście można wyłączyć debugger, ale nie w tym rzecz. Nie mamy pewności jakie inne zmienne nie są wyzerowane i czy to nie wpłynie na działanie aparatury.

 

EDIT: zapomniałem dodać, że w wersji 0.74 sam wprowadziłem takie resetowanie i działalo, więc metoda sprawdzona.

[kacper_80]

Jeśli chodzi o "wzorcową" telemetrie to nie mam w tym zakresie doświadczenia, Z mojego punktu widzenia piszczek powinien wystarczyć, wariometr da się jakoś na nim wymyśleć a do sygnalizacji wystarczy.

W modelach w których nie ma czasu na oderwanie wzroku, poprostu ma ostrzegać o nieprawidłowości np. niski poziom paliwa, przegrzany silnik itp. wtedy niezastanawiam się tylko ląduje, tak samo jak w przypadku rozładowanego nadajnika. Można ustalić dwa stany ostrzeżenie i alarm, więcej wydaje mi się że może być trudne do zinterpretowania.

Zastrzegam że jest to moja opinia i raczej niewygórowane potrzeby, a każdy ma napewno swoje pomysły i zastosowania. (z wygórowanych to czarna skrzynka - rejestrator )

 

W sumie jeśli chodzi o zmianę platformy to już zależy jak poważne by musiały być? o ile sprowadzało by się to do podmianki atmega to sądze że warto, sama instalcja ISP i CF wymaga już zaangażowania i "interwencji" w sprzęt.

[rafit]

Dodałem obsługę watchdoga

 

reset wykonywany jest w 2 momentach:

- po załadowaniu modelu

- po wybraniu "Nowy model (pusty)"

 

Watchdog jest ustawiony na 250 ms - reset w każdym przebiegu pętli głównej i przy zapisie EEPROM.

Wyłączany podczas operacji na karcie SD (trwają za długo).

[Arek12127]

Soft 0.78:

 

Nowy model => reset OK

 

Odczyt modelu z SD => brak resetu, trzeba wyłączyć i ponownie włączyć aparaturkę.

 

pozdrawiam

Arek12127

 

EDIT:

 

Czy umieszczenie resetu przed instrukcjami:

fatFclose();

sdClose();

nie spowoduje jakichś błędów na karcie SD?

[rafit]

Błąd tak głupi, że aż żal . Podczas sprzątania kodu skasowałem jedną linę za dużo... Nawet już nie chcę wprowadzać nowego numeru wersji.

 

Reset przed zamknięciem systemu plików i karty jest ok - ale tylko przy odczycie z karty. Nie ma tam żadnych modyfikacji ani zapisów. Czysty kod powinien mieć te instrukcje, ale taka zmiana to zawsze kilka bajtów do przodu. Ze względu na bardzo ograniczone miejsce w kodzie jest trochę takich "skrótów"

[Arek12127]

soft: 0.78 popr.:

 

Reset po wczytaniu modelu z SD jest trochę przydługi, ale da się wytrzymać.

Rozumiem, że zmiana czasu reakcji watchdoga na najkrótszy zabierze dodatkową pamięć i dlatego jest jak jest.

Zauważyłem jedną rzecz: przy szybkim wciskaniu trymera (zwłaszcza kierunku) , następuje reset atmegi. Przy przytrzymaniu trymera nic złego się nie dzieje.

 

 

Mój nadajnik przeszedł operację wymiany mózgownicy z 64 na 128.

Pacjent przeżył i ma się dobrze .

Fusebity ustawiłem jak dla 64-ki i wszystko gra.

[qnii]

a jak to się robi i ile to kosztuje -wymiana procka

[Gites]

1. Kupujesz nowy mikrokontroler... np. tu: http://sklep.avt.pl/...ex.php?id=32006

2. Wylutowujesz obecny - technologie są różne, np. szybkie podgrzanie nagrzewnicą pistoletową i podważenie pęsetą lub śrubokrętem. Inny sposób to podgrzewanie lutownicą pinu po pinie i delikatne podważanie pojedynczo zwykłą igłą do szycia (niestety jest to sposób który w większości przypadków prowadzi do uszkodzenia pinów starego mikrokontrolera i nadaje się on wtedy tylko na szrot - no ale w końcu po to go wylutowujemy)

3. Zakładając, że nie wyrwałeś padów przy poprzedniej operacji, delikatnie je pocynowujesz (dziwne słowo ale nie mam lepszego), następnie kładziesz na nie nowy mikrokontroler bardzo dokładnie go pozycjonując (ATMega64 i 128 mają taką samą "pinologię")

4. Wlutowujesz nowy mikrokontroler - technologie są różne, np. podgrzewając nagrzewnicą pistoletową i delikatnie przyciskając obudowę mikrokontrolera żeby "osiadł" lub lutujesz pin po pinie, poprzez nagrzewanie go cienkim grotem lutownicy od góry i delikatnie przyciskając

5. Wgrywasz firmware (to dla ATMega64 jest ok)

6. Ustawiasz bezpieczniki i lock-bity gdyż nowy mikrokontroler jest w stanie fabrycznym. Poprawna, działająca kombinacja to:

 

LOW: 0x0E

HIGH: 0x89

EXTENDED: 0xFF

LOCK: 0xFF

 

Jeśli nie ma się dwóch lewych rąk i wczesnego parkinsona to nie jest to aż tak skomplikowane jakby się wydawało. Niezbędne sprzętowe minimum to lutownica z bardzo cienkim grotem.

 

Dodano 2012-05-25

Po ostatnich bojach z wymianą na ATMega128, postanowiłem dla jasności dodać jeszcze dwa punkty (5 i 6)