Witam!

Podczas czytania i analizowania całego projektu tego lcd, pojawił mi sie problem filozoficzny. Mianowicie chodzi o to, że tworzymy funckje, która buduje object, mianowicie: creat_obj(), która zwraca nam indeks w tablicy struktur, gdzie został zapisany ten nowy obiekt. I jak mam to wykorzytsac w programie skoro mam indeks w tablicy struktur, gdzie siedzi dana warstwa. Analizowałem main i tam jest tylko tworzenie obiektów, bez sprawdzania co one zwracają.

Kolejny probelm jest w funckji:
create_obj(&trasnparent_layer,*,*, "coś");

i czemu odowłanie do niej jest przez kropkę:
actwive_buf = transparent_layer.buf.
Skoro jest to wskaznik na strukturę. zgodnie z funckja create_obj(TWIN *bf, "coś:)l

W sumie dzieki za jakies odpowiedzi, to mi rozjasni w sumie jakąs część projektu.

_________________
sig off ;(

No a jakbyś chciał dynamicznie w programie tworzyć obiekty i je później np zwalniać? zobacz sobie tam masz taką funkcję:



to właśnie dzięki niej - podając jako argument ten index tablicy można zwolnić taki obiekt

------------------------ [ Dodano po: 9 minutach ]

O! a na pozostałe pytania Anty dobrze podpowiedział

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Co do pierwszej części w sumie jest już jakis przykład zastosowania.
Bo do tej pory myslałem, że jak wypełnie strukture to ja po prostu mam i tyle, a tutaj, że NULL. Może to jest kluczowe burrel[i] = bf;. Pewnie chodzi o to, że nadpisze ją wywołując kilka razy a dajac takie przypisanie już będe miał w tablicy struktur all co zostało zapisane w strukturze *bf.

A co do tej drugiej części to w main jest o:
TWIN transparent_layer.
czyli odwolanie poprzez "."-kropke. A w funckji mam wskaznik jako adres, więc przekazuje adres tego elementu jako obiekty struktury TWIN.
Niemalże każdy kod z ksiązki to inne podejście do C. W sumie fajne to jest, bo jak człowiek to uświadomi to wykorzystuje i jest happy, że działa.

_________________
sig off ;(

no ale o czym ty teraz mówisz ? a co tu struktury nie masz ? toż używam jej tutaj do trzymania że tak powiem uchwytów (wskaźników) do różnych warstw, które są tworzone dynamicznie - nawet na stosie ... - więc jak kończę z jakąś warstwą to wyrzucam jej wskaźnik ze struktury wpisując NULL ale co wg ciebie struktura znika ? toż tylko w jej elemencie (tablicy) pojawia się NULL -

------------------------ [ Dodano po: 6 minutach ]



no ale coś ty ? przecież akurat tą warstwę zdefiniowałem jako typową zmienną globalną

TWIN transparent_layer;

no zobacz sobie nad main - i do niej chyba nie dziwne że przez kropkę się odwołuję do pól



no druga książka to już nie jest dla początkujących i jej celem jest pokazanie w praktyce przeróżnych technik podejścia do programowania.... Więc nie są to różne podejścia do C ... tylko różne sposoby wykorzystywania mechanizmów jakie daje ten język ... bardzo wielu osobom właśnie chodziło o takie przykłady - bo to pozwala podejrzeć, że czasem to co robiliśmy przez pół życia jednym sposobem i wydawało się że nie ma innej drogi - to podglądając czyjeś kody - można odkryć - że jednak da radę zrobić coś inaczej a czasem nawet dużo prościej .... ja sam tak lubię się uczyć - dlatego dużo analizuję kodów z netu szukając często takich, których na początku ni w ząb nie rozumiem ... za to jak już zrozumiem to czasem się znowu DUUUUŻO nauczę ... i tak ciągle

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Hej.
Przy okazji tematu mam pytania. Od razu na początku nadmienię, że niestety mam jakiś problem z proxy w pracy i nie mogę kodu umieścić w syntaxie, nie działa mi edytor tekstu, nic. Forum nie ma żadnej grafiki, nie dział JS, css itp .

Ale do rzeczy, pytanie odnośnie linijki:



Widać, że każdy z obiektów w tablicy barrel, obsługiwany jest jeden po drugim (while). Czyli co 10ms, w jednym obiegu pętli głównej programu, rozpracowywane są wszystkie obiekty z kolejki barrel. Gdy jakis obiekt zostaje dodany, to obsługiwane jest więcej obiektów. Co tutaj się dzieje, jest dla mnie jasne i w pełni to rozumiem.

Jaki zysk, bądź stratę mielibyśmy, gdyby barrel potraktować jako bufor kołowy (oczywiście o odpowiedniej przeliczonej wielkości), wrzucać do niego obiekty i obsługiwać 1 obiekt na 1 obieg pętli głównej programu, ale nie co 10ms, tylko w trybie idle, aż do opróżnienia sie kolejki? Kolejka uzupełniana byłaby poprzez dodanie do niej naszych obiektów nie tylko co 10ms, ale również w trybie asynchronicznym. Gdy kolejka jest pusta - nic się nie wykonuje. Gdy ma 10 obiektów, obsłuży 10 w 10 obiegach pętli głównej, ale w trybie idle. Czy takie podejście jest wogule racjonalne? Czy może lepsze jest podejście mirkowe przedstawione w funkcji BARREL_EVENT? Czy to wszystko zalezy od konkretnego problemu?

Zdaję sobie sprawę z tego, że przedstawione przezemnie podejście może zająć więcej zasobów. Ale może zyskiem jest tutaj łatwa obsługa priorytetów i lepsza skalowalnośc takiej obsługi warstw?

Niestety wybiórczo czytałem zielonkę, może gdzieś ten problem jest opisany (tylko bardzo proszę nie krzyczeć!)? Bo mi to chodzi po głowie, a nie wiem co mam z tym zrobić, więc postanowiłem się podzielić przy okazji tematu.

rolba --> a któż miałby krzyczeć i za co ?

jaki zysk i jaka strata ? w odpowiedzi na twoje pytanie - hmm twoją koncepcję - już odpowiadam.

PRZEDE WSZYSTKIM i to napisałem dużymi literami, a powtarzam to wszędzie gdzie się da, chciałbym aby było jasne - że ja nigdy nie prezentuję przykładów w swoich książkach, które są jedynie najlepsze i jedynie słuszne w nich podejście - jak to robią niektórzy na niektórych blogach ....

Moim zdaniem i będę to powtarzał z uporem maniaka sposobów na rozwiązanie jakiegoś zagadnienia programistycznego może być tyle ilu programistów jest na świecie.....

a SZCZEGÓLNIE w takich już bardziej skomplikowanych zagadnieniach. Więc ja nawet nie chciałbym się odnosić, ba! nawet nie mam jak - bo ogólnie jakoś widzę twoją koncepcję ale wiesz - ja mam tak - że jak sam czegoś nie wrzucę do procka i nie sprawdzę to nie jestem w stanie nawet tak teoretycznie ocenić. Zatem przechodząc do sedna - nawet gdyby twoja metoda miałaby użyć ciut więcej zasobów to co z tego ? jeśli z powodzeniem zrealizujesz w oparciu o nią swoje zadania ?

Moim celem jest pokazanie innym, nauka poprzez prezentację takich kodów - jak można różnie podchodzić do wielu spraw. Ale tak ostatecznie to powiem ci - że najbardziej to zgadzam się z tym co napisałeś że wszystko tak na prawdę zależy od projektu, bieżących potrzeb, dostępnej pamięci, szybkości wykonywania się itp itp itd

zwróć tylko uwagę, że tu 10ms jest nawet zbyt szybkim czasem - spokojnie wystarczyłoby 20 ms jak nie 30 albo i 50ms ... bo chodzi o wyświetlanie tak na prawdę na LCD - a że przy okazji wplotłem w to niejako inne procesy .... to już inna sprawa

ja bym coś koło twojego podejścia bardziej widział gdybym np (ja oczywiście) działał nie na LCD w tym przypadku tylko organizował np taką sobie pseudo-wielowątkowość, gdzie nawet zależałoby mi na jakiejś większej rozdzielczości czasowej nawet 5ms albo i szybciej ... ponieważ pomysł z kolejką i dodawaniem tylko istotnych w danym momencie procesów jest bardzo fajny ... a wpłynęłoby to znacząco z kolei tak myślę i gdybam, na jeszcze mniejsze blokowanie czasowe całości

nie mówiąc już o priorytetach właśnie ...

reasumując - że ja wymyśliłem sobie prosty system warstw dla wyświetlania na LCD i do tego nadaje się to super wg mnie, ale w książce chciałem pokazać że taki mechanizm - jak człowiek chce to jeszcze można zaprzęgnąć do czegoś innego - ba! wręcz do jakiegoś prostego obsługiwania procesów .....

i taka była droga tego projektu - to troszkę tak jak np z dobrą kamerą która nigdy nie będzie dobrym aparatem fotograficznym pomimo że producent kusi taką opcją i podobnie jak najlepszy aparat nigdy nie będzie dobrą kamerą (choć przy dobrych lustrzankach to już taka granica się zaciera co nieco )

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Hej.
Dzięki Mirek za odpowiedź. Chciałbym Ciebie prosić o wrzucenie lekkiego luzu . Zdaję sobie sprawę z tego, że twoje rozwiązania są propozycją załatwienia pewnych problemów. Dla mnie stanowią jednocześnie inspirację do tego, aby wymyślić swój sposób na rozwiązanie jakiegoś problemu z wieloma różnymi zadaniami w systemie. Ale dobra, tak się składa, że w pracy mam pod swoją ręką kod napisany przez kogoś wiele lat temu. Działa na zasadzie zliczania impulsów w interwale 5ms i wywoływania odpowiednich zadań w odpowiednim czasie. Użyty jest sposób z "%" również wspomniany przez Ciebie w tym samym temacie o wielowątkowości LCD. W związku z tym spróbuję "uszeregować" zadania (a jest ich kilkadziesiąt) i zobaczyć, co z tego będzie i czy będzie to działać we wspomniany prze zemnie sposób.

Jest jeszcze kwestia zagłodzenia wątku o najniższym priorytecie. Tutaj zastanawiam się, czy by nie użyć jakiegoś licznika życia wątku i w przypadku zbyt długiego przesiadywania w kolejce, nie zwiększać sztucznie priorytetu, by go w końcu wykonać. Kolejna sprawa to sortowanie wątków po priorytetach (jaki algorytm???? jest ich masa, każdy inny, jeden lepszy dla takich inny dla siakich przypadków). Czy sortowanie ma się odbywać po zakończeniu wkładania wątków do kolejki, czy za każdym razem, gdy wątek wchodzi do kolejki? No i co w przypadku asynchronicznych wątków? A gdzie tryby oszczędności energii? Wydaje mi się, że jak robota zostanie rozdana, można kazać prockowi iść spać i budzić się np co 10 ms (jako timer systemowy i rozdać robotę). A każde z zadań może mieć osobną maszynę stanów... i wykonywać część roboty... Tyle dylematów...

Kończę, bo coś mam niestabilne napięcie w sieci i mi światło przygasa.

Pozdro.

no ale o co chodzi ? a co się stało ? coś źle napisałem ? .... eeeeh ludzie no ja piszę najspokojniej w świecie i z życzliwością się odnoszę - a ty mówisz żebym luz wrzucił jakbym coś gdzieś komuś czy tobie przygadał .... .... nie rozumiem, nie rozumiem

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Musisz się przyzwyczajać. Z tego co widzę ludzie odbierają Twoje słowa jako pewnego rodzaju atak.

Nie wiem czym to jest spowodowane, może zbyt długo przebywali na Elektrodzie gdzie to jest normalne?

_________________
http://www.jaglarz.info

Hej.
Mirek, nie zroum mnie źle, ale chciałbym bardzo Ciebie prosić, abyś nie tłumaczył się za każdym razem, gdy dyskusji jest poddawany Twój kod i propozycje zmian do niego. Wiem (!), że nie narzucasz rozwiązań i że są one propozycją rozwiązania pewnych zagadnień. Nie ma potrzeby pisania wkółko tego samego elaboratu w tej kwestii, jest to dla nas wszystkich jasne. Proszę i przepraszam, jeżeli zabrzmiało to inaczej.

Prostując moje zawiłości, twoje rozwiązania inspirują mnie do tworzenia własnych, z tąd moje pytanie. Ty masz więcej doświadczenia odemnie, widze, że umiesz z marszu ocenić niektóre sprawy. Więc z doświadczonymi ludźmi chciałbym tę dyskusje prowadzić. Oprzeć się na doświadczeniu innych, by budować własne. Tak to Mirek potraktuj.

Zacząłem kodowanie i przeróbkę Twojego projektu oraz adaptację istniejącego kodu w pracy do mojej koncepcji. Będę informował na bierząco. Małymi kroczkami do przodu.

Pozdro.

to ja może doprecyzuję (ale uprzedzam że wcale się nie gniewam na ciebie) ...

1. te osoby, które mnie znają wiedzą że jestem gadułą - i nic na to nie poradzę ani niestety nie posłucham takiej prośby - bo ja tak mam i już - muszę się z tym nauczyć żyć ... a nie wiem czy aż tak to innym przeszkadza. Jeśli tobie tak - no to też przykro mi ... musisz jakoś odfiltrowywać sobie moje "elaboraty" jak to nazwałeś

2. piszesz że jest to dla "nas wszystkich" jasne - to ja zapytam dla jakich nas ? Sugerujesz że wypowiadasz się w imieniu rzeczywiście wszystkich osób ? Bardzo uprzejmie przepraszam ale wątpię. Ja może czasem dużo mówię ale za to albo dzięki temu wiele osób mnie zrozumie. Uwierz mi proszę - że są osoby którym to przeszkadza tak jak tobie (w to łatwo pewnie ci uwierzyć) ale też są osoby którym to nie przeszkadza a nawet się cieszą że znajdują wyjaśnienia.



No ale ja DOKŁADNIE tak zrozumiałem twój przekaz i postarałem się odpowiedzieć jak umiałem i odpowiedziałem (a że być może nie przy okazji tylko tobie ale i innym którzy tu zajrzą to sorki) ... Dlatego może zakończmy dyskusję (niepotrzebną w ogóle i nie uczmy się nawzajem jak należy się wypowiadać na forum, jakie elaboraty pisać a jakie nie - bo to troszkę nieteges).



Nie przesadzaj ja nie byłbym tego taki pewien na twoim miejscu ... ja po prostu staram się i wciąż się uczę - a że akurat poruszyłeś bardzo ciekawe również dla mnie zagadnienia to dlatego włączyłem się do dyskusji bo wydała mi się interesująca i ciekawie opisane przez ciebie zagadnienia



Tak traktuję i sam się cieszę że mogę z tyloma fajnymi ludźmi na tym forum kulturalnie wymieniać doświadczenia bo to mi też dużo daje.



I o to chodzi - mogą wyjść z tego bardzo fajne rzeczy

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Hej.
Mirek, dzięki za dobrą krytykę. Lecimy dalej.

Coś już działa. Po krótce, bo za dużo nie mogę powiedzieć (tajemnica służbowa). System jest mocno obciążony komunikacją RS-485 (w pętli głównej, ze względu wymogi czasowe i ilość danych) + obsługa dodatków w sposób synchroniczny (timery programowe): LCD (bardzo zaawansowana obsługa), bardzo duże menu, które jest kompilowane osobnym programem, dołączane do hexa firmware (menu i teksty siedzą w osobnej pamięci), plus klawiatura, buzzer, sterownik pamięci flash. I te rzeczy scheduler wykonuje synchronicznie po kolei. Jest ich bardzo dużo, są odpalane w różnych odstępach czasu (np co 50ms w zerowej, pierwszej, drugiej... dziesiątce), co 10 ms, co 100ms itp. Każdy z tych tasków przypomina wyglądem superdebounce, ale maszyna stanów w środku każdego z nich jest bardziej rozbudowana.

Na początek wziąłem pętlę główną (bo najłatwiej i najmniej tasków). Było tak:






Zmieniłem na takie cuś:



Odpalam urządzenie i działa dobrze, nic się nie dławi, nie zawiesza. Teraz czas na dalsze modyfikacje i nowe funkcje:

add_task(task), run_task() oraz implementacja w odpowiednim miejscu tych funkcji. Czyli:




I to też działa, urządzenie ma pełną funkcjonalność, nie zawiesza się. Teraz tylko gdyby ktoś fahowym okiem sprawdził, czy nie ma blędu, czy to może na pierwszy rzut oka tak trybić. A ja jutro sprawdzę, jak to wydajnościowo wypada.

Jeszcze tak dodatkowo moje małe reflekcje. Wydaje mi się, że jest w tym mały potencjał do dużych, wielozadaniowych programów na procka. Gdyby dodać do strukturki jeszcze 3 pola:


To można by mieć:
*elegancką obsługę priorytetów, w osobnej funkcji dodać sortowanie, a taski o tym samym priorytecie traktować jako FIFO
*eleganckie _delay_ms(x) dla danego wątku poprzez wysłanie go do odpowiedniej kolejki (do spania). Oczywiście wymaga to oprogramowania tej rzeczy w maszynie stanów danego wątku.
*zabezpieczenie przed zagłodzeniem wątków, które mają najniższy priorytet. Chodzi o to, by wymusić taki mechanizm zwiększenia priorytetu, by wątek się w końcu wykonał, jeżeli ma niski priorytet.
*myślę, że gdy głowa zrówna się z ogonem, to w pętli głównej ścielimy prockowi łózko i idzie spać. Budzi się wraz z system tick.

Jak to widzicie? Na żywym organizmie działa. Sprzęt się nie wiesza . Ale proszę o weryfikację. Pamięci mam dość - uprzedzając pytania.

I jeszcze. Jak sprawdzić system wydajnościowo? Liczyć jakiś czas? Kurka, nie wiem... (???)

rolba ---> ale żeś zamieszał oczywiście w pozytywnym tego słowa znaczeniu ... fajnie tzn...

na prawdę ciężko coś takiego sprawdzić ot tak ... na churra - ale starałem się przeanalizować - bo, przyznam że masz tu fajny tok myślenia ... i fajny pomysł hyhyhy z tym buforem cyklicznym jak z UART'a haahaha ale idea jest przednia

tak wydaje mi się że to ma potencjał i fajnie że opisujesz to na forum bo może to być dobrym przykładem dla innych

hmm też bym się zastanawiał jak testować wydajność i obciążenie ale ...

1. i tak tego typu ala "systemik" wdraża się praktycznie indywidualnie pod dany projekt i go tuninguje - chociaż z tego opisu widać że wręcz dałoby się wyprowadzić jakieś ogólne mechanizmy w jakąś nawet taką pseudo bibliotekę i spokojnie używać w różnych swoich projektach

2. to co pisałeś - nie ma sensu mówić tu o ilości pamięci RAM - bo wiadomo, że już taki ciut bardziej rozbudowany systemik wielozadaniowy no ciężko byłoby robić na procku mającym 64bajty RAMU

3. co do samej wydajności - tak z grubsza porównując do tego co robiłem w warstwach, to może nie wyjdzie to jakoś szczególnie szybciej bo i tu i tam są IF'y które ew nie wykonują procesów, gdy nie mają one nic do roboty - nie mniej jednak jak mówiłem - nie tworzyłem go z taką myślą jaka ci przyświeca i dlatego zdecydowanie uważam - że twoja idea do celu obsługi procesów jest bardzo fajna - przynajmniej tak na luzie teoretycznie to rozpatrując - bo wiadomo że gdyby siedzieć i kodować to pewnie jakieś uwagi by może się nasunęły - ale wszystko jest do rozwiązania

ostatecznie - chyba ciężko sprawdzać tu system wydajnościowo - bo coś takiego byłoby możliwe chyba - gdyby to właśnie tworzyć jako uniwersalny system - a jeśli to jest i tak do indywidualnego wdrażania w każdy projekt - to ta wydajność będzie mocno zależała od projektu ...

i wydaje mi się, kończąc, że to dodawanie i usuwanie tasków - nie tylko mocno wspomoże wydajność ale jeszcze wydaje się być bardzo przejrzyste i miłe w realizacji

PS... wdziałem i czytałem, analizowałem wiele kodów na realizację takich systemów wielozadaniowości dla 8-bitowców. Wiadomo jest tego sporo .... ciężko nawet je wszystkie porównywać bo jak mówię - porównywać to można np jakieś już gotowe RT-OSy ... ale dla mnie liczy się przejrzystość implementacji i wydaje mi się, że taki pomysł mieści się w takich fajnych granicach.

Jak potestujesz do końca to daj znać sam jestem ciekaw opinii z prania

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Hej.
Kilka kodów, przed prezentacją wyników.

Dla pokazania, co mam na mysli, napisałem taki oto pseudo kod:


Myślę, że jest to wszystkim dobrze znane. Przykład bazuje na moim prywatnym projekcie w domu i na Mirekowym opisie wielozadaniowego projektu LCD w zielonce.

Zamieniam na kolejkowanie:


Wynikami podzielę się wieczorem, są bardzo ciekawe:). do_tasks(); traktujmy jako pętlę główną.

Cześć!
Trochę trwało, ale udało mi się w końcu siąść przy komputerze. Jedziemy dalej. Wkleję parę wykresów, na dobry początek.




Teraz kilka danych statystycznych:

I grupa.

• ilość zbadanych okresów pomiędzy przerwaniami: 11797 - ok 1 minuty działania systemu
• średnia/odchylenie standardowe "0 tasks" - 51/14 (obrotów pętli głównej pomiędzy przerwaniami timera, co 5ms)
• średnia/odchylenie standardowe "40 tasks" - 42/12 (obrotów pętli głównej pomiędzy przerwaniami timera, co 5ms)

II grupa.

• ilość zbadanych okresów pomiędzy przerwaniami: 92800 - ok 8 minut działania systemu
• średnia/odchylenie standardowe "0 tasks" - 81/13 (obrotów pętli głównej pomiędzy przerwaniami timera, co 5ms)
• średnia/odchylenie standardowe "40 tasks" - 68/11 (obrotów pętli głównej pomiędzy przerwaniami timera, co 5ms)

A teraz słówko wyjaśnienia, o co chodzi i mały komentarz do kodu. Postaram się pisać zrozumiale, ale nie wiem, czy mi wyjdzie.

• "0 tasks" - parametry statystyczne opisujące sytuację, która jest przedstawiona w moim poprzednim poście, w pierwszym listingu. W kodzie nie używam żadnego mechanizmu kolejkowania zadań, jest to klasyczny synchroniczny sheduler, znany z zielonki i niebieskiej.
• "40 tasks" - parametry statystyczne opisujące sytuację, która jest przedstawiona w moim poprzednim poście, w drugim listingu. W kodzie widać, że co jakiś czas ładuję do kolejki zadania przy pomocy funkcji add_task(taskn);, a w pętli głównej opróżniam tę kolejkę wykonując jedno zadanie na jeden obieg pętli głównej run_task();.
• "taskn()" - Jakieś tam zadanie, które zbudowane jest na podstawie maszyny maszyny stanów. Na każdy moment, kiedy zadaniu przydzielony jest czas procesora, wykonuje się jeden ze stanów, maszyny stanów. Jest to mechanizm bardzo podobny do przełączania wątków po ticku timera systemowego (np. po 10ms) w RTOS'ach, jednak zdecydowanie szybszy, bo nie bawimy się w zapamiętanie licznika programu i dbanie o zapamiętywanie i przywracanie zawartość stosu oraz rejestrów procesora.

Wykresy są histogramami. W osi x widzimy ile było obrotów pętli głównej pomiędzy tickiem timera systemowego, co 5ms. W osi Y widzimy, jak często dana ilość obrotów pętli głównej wystąpiła w czasie okresu pomiarowego. Oś y celowo została wyskalowana w % dla lepszej wizualizacji. Interpretacja wykresu jest następująca. Załóżmy, że wykres 1 został zrobiony na podstawie zliczonych obiegów pętli głównej pomiędzy 1000 przerwaniami. Z kapelusza np. liczba 42 w osi x oznacza, że pętla przekręciła się 42 razy w ciągu tych 5ms. Załóżmy, że 42 ma w osi Y 10%. 10% z 1000 = 100, czyli 100 razy w okresie pomiarów (pomiędzy tymi 1000 przerwań) w czysto losowym czasie, pętla główna obracała się 42 razy. Można powiedzieć, że dosyć często. Wniosek jest jeden. Im mniejsza liczba w osi x tym pętla główna jest bardziej obciążona. Im więcej % w osi y tym dana grupa wystąpiła częściej podczas pomiarów .

Interpretacja wyników. Widać, że dodając jedno dodatkowe zadanie do pętli głównej, pętla zwalnia. Wykres pokazuje to równie dobrze, jak średnia zarówno dla małej jak i dużej grupy badanych odstępów pomiędzy przerwaniami. Można się tego spodziewać, zwłaszcza, że różnice pomiędzy średnimi oscylują w okolicy kilkunastu procent (mała grupa - 19% i duża grupa - 16%), co jest poprawnym wynikiem, bo po opróżnieniu kolejki, pętla mieli dalej 3 zadania, a ilość zadań do zmielenia zarówno dla pierwszego jak i drugiego listingu jest taka sama i zależy tylko od pewnych wielokrotności czasowych. Z różnicy % pomiędzy średnimi dla małej grupy widać, że start systemu bardziej obciąża pętlę główną. Ale to już taka ciekawostka bardziej.

Błędnym wnioskiem jest twierdzenie, że zwolnił nam cały system. Zwolniła nam jedynie pętla główna, której co 5ms wpada coś do zrobienia i która na jeden obrót ma czasami o jedno zadanie więcej do zrobienia. Tylko że w przypadku pierwszego listingu, blokujemy procesor na dłuższy czas, bo musimy wykonać wszystkie zadania ze shedulera, co 5ms, w zależności od tego, co tam nam timer akurat naliczył. No i blokujemy zadania 1, 2 i 3. A w przepadku drugiego sposobu w bardzo szybki sposób ustalamy kolejkę zadań przy pomocy shedulera, którą to w obiegu pętli głównej opróżniamy, nie blokując aż tak mocno ważnych zadań o numerach 1, 2 i 3.

Nie rozumiem natomiast jednej rzeczy. Czemu odchylenie standardowe się zmniejszyło, po tym, jak wdrożyłem kolekowanie. Czy to oznacza, że dynamika operowania drugiego kodu jest większa? Tzn., czy mogę to interpretować w taki sposób, że histogram jest bardziej zawężony? Czy trzeba by coś więcej policzyć, by to stwierdzić?

Może ktoś z was ma pomysł, jakie ciekawe parametry statystyczne jeszcze policzyć? bo fajnie by było coś jeszcze dorzucić .

Na tym etapie widzę, że powyższe pomiary i dane są niekompletne. Koniecznie muszę uzupełnić je o to, ile średnio dodatkowych zadań wykonywanych jest pomiędzy przerwaniami. Całe szczęście mam dobry debuger. Chcę też pomierzyć czas obijania się procka (czyli gdy obsługuje tylko te 3 krytyczne czasowo taski). Tutaj muszę uwolnić jeden z timerów, bo wszystkie są zajęte. Sam jestem strasznie ciekawy dalszych wniosków a przy okazji dzielę się nimi na forum.

No i na koniec taka moja prywatna refleksja. JA Mirkowi zarzuciłem lanie wody, a teraz role się odwróciły... Już nie dziwię, że chcesz by ludzie Ciebie dobrze rozumieli, powtarzając niektóre kwestie i kwieciście opisując prozą niektóre zagadnienia . W moim wypadku zanosi się na więcej, bo jak dokonam pozostałych badań to będzie jeszcze ciekawiej. Widać, jak się nie wjedzie czasami w czyjeś buty to się nie doceni pracy osoby, którą się krytykowało. Teraz Mirek to doceniam.


Pozdrawiam czytających i mam nadzieję, że nie zanudziłem.

WOW! ale teraz dowaliłeś "z grubej rury" tzn w pozytywnym tego słowa znaczeniu ... jak ty to ogarniasz i zbierasz dane do wykresów ? chyba że twój program/projekt jest na tyle specyficzny, że w jakiś zewnętrzny sposób możesz tak mierzyć te taski albo hmm jakich narzędzi używasz ? aż zapytam .... generalnie bardzo fajna analiza - aż szczęka opada do podłogi

tzn piszesz że masz dobry debuger - czyli ?

generalnie podchodzisz do zagadnienia można by rzec iście naukowo próbując dokonać ocen statystycznych tworzonych mechanizmów w wielu badaniach - tak jakby miały to być wręcz podwaliny pod nowy system RTOS ...

nie wiedziałem, że aż tak daleko się rozpędzisz - ja już powoli wymiękam w rozważaniach - chociaż przyznam - że to NIESAMOWICIE interesujące ... czuję, że jest to ci potrzebne mocno do projektu, który akurat realizujesz ... nie mniej jednak uważam że fajnie zobaczyć jak się coś takiego robi ...

Mnie się już na tym etapie ciężko odnieść w konkretny sposób do pytań bo musiałbym mieć czas i możliwości aby do tego w podobny sposób zasiąść i się pobawić .... Przez ciebie pewnie kiedyś się za to zabiorę (mam kolejny cel) .... bo to na prawdę wręcz arcy-ciekawe zagadnienie (przynajmniej jak dla mnie) ....

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Z wykresem poszło dosyć łatwo. W najprostszy sposób dodałem sobie licznik, w pętli głównej go inkrenetowałem, a jak wystąpiło przerwanie, to licznik wyrzucałem na terminal, każdą wartość na osobną linijkę, a potem go zerowałem i dalej od początku. Terminal logował do pliku tekstowego. Potem plik tekstowy z ponad 90000 linii ładowałem do excela i przy pomocy funkcji countif(zakres, liczba) policzyłem sobie histogram dla konkretnych wartości w osi x. W dalszej kolejności narysowałem sobie wykresik , jak pani na informatyce uczyła w gimnazjum paręnaście wiosen temu. Taka w sumie najprostsza metoda, a już daje pewien obraz. W ten sam sposób postąpię dalej z innymi pomiarami.

Co do debugera. Ktoś kiedyś zaimplementował w tym systemie coś a'la printf'a drukującego na terminal. Nie wgłębiałem się w jego budowę, wiem tylko tyle, że jak zrobię debug_print("%d/n", licznik); to mi drukuje w terminalu wartość licznika w eleganckim dziesiętnym formacie. No i nie tylko %d, ale też różne inne formaty: hex, binary, string itp. Nie wiem dokładnie co siedzi w tej funkcji. Ale jest na tyle dobre, że nie muszę bawić się jtagiem , lub pisać własnych.

Co do "celu". Przede wszystkim lubię optymalizować więc poniekąd jest to mi potrzebne w pracy. Ale z drugiej strony robię to też dla tego, że mam przestój w obowiązkach i chcę się czegoś nowego nauczyć. Podwaliny pod RTOS? Nieee , to już gruba sprawa, pilnowanie stosu dla każdego z wątków, zabawa z licznikiem programu, rejestry, semafory... Może za 5 lat i pewnie ze wsparciem ludzi z forum. Obecnie mam inny cel. Chcę mieć narzędzia, które będą dla mnie wygodne i których użycie będzie opłacało się bardziej niż RTOS, niezależnie od stopnia skomplikowania projektu. Lubię wiedzieć czy to, co robię jest warte zachodu, z tąd te statystyki. Bez tych informacji będzie bardzo ciężko odnieść się krytycznie do tego rozwiązania.

Dla tego też kolejnym etapem na pewno będzie zebranie czasowych zależności, jeszcze większej ilości próbek i próba wyjścia z analizą z dziedziny czasu w dziedzinę częstotliwości. Może tam będzie odpowiedź na niektóre pytania. Zobaczymy. Miłej nocy.

Nie żebym miał coś przeciwko RTOS'om ... ale właśnie takie projekty hmmm takie podejście pokazuje dobitnie, że często wiele osób sięgając po RTOS'a dokonuje swoistego przerostu formy nad treścią .... podczas gdy takimi hmm w sumie prostymi metodami można wiele spraw załatwić .... pewnie że tutaj określenie "proste metody" może nie pasuje do kogoś kto dopiero zaczyna przygodę bo jak to czyta to mu jeden diabeł czy to jakiś RTOS czy co to za taski tutaj latają .... ale myślę - że dotarcie ze stopnia początkującego do takiego etapu to na prawdę nie jest trudna droga ... byle by zaskoczyć te podstawy

------------------------ [ Dodano po: 1 minucie ]



Na prawdę bardzo ciekawe i godne pochwały podejście na dodatek rzeczywiście przy tak skromnych ale jak skutecznych narzędziach

jak coś jeszcze będziesz miał po analizach to ja na pewno z chęcią poczytam

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Witam!
Próbuję uruchomić projekt wielozadaniowy z GB bez żadnych zmian (L19_HD44780_LCD). Rozumiem działanie mechanizmu warstw po lekturze stosownego rozdziału w GB. Kompilacja przebiega prawidłowo, ale na LCD wyświetla się tylko data (12-02-25) w prawym dolnym rogu. Pozostałe warstwy "reprezentowane" są przez białe kwadraty (7 sztuk) przesuwające się równomiernie z prawej strony ekranu na lewą i z powrotem. Co sprawdzić aby uzyskać poprawne wyświetlanie warstw? ATB Rev. 1.03. ATmega32. Bardzo proszę o pomoc.
Pozdrawiam

P.S. W pliku nagłówkowym LCD jest 4x16, a mój LCD jest 2x16 Zmieniłem wyświetlacz na 4x20 i stosownie zaktualizowałem wpis w pliku nagłówkowym LCD. Nadal wyświetla się poprawnie tylko warstwa 1 (godzina i data) w górnym prawym rogu LCD. Na jej tle przesuwają się pełne prostkąty.