Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Obsługa wątków na pic18 z kompilatorem sdcc (PIC18XXXX threads)

trol.six 09 Mar 2019 21:21 1692 9
  • Obsługa wątków na pic18 z kompilatorem sdcc (PIC18XXXX threads)

    Chociaż na zdjęciu widać mini płytkę z PIC18F1220, to posłuży ona jedynie do praktycznego zaprezentowania obsługi wątków które zaimplementowałem.

    Obecne możliwości kodu który chce zaprezentować, to działanie równoległe 2 lub trzech wątków, w tym głównej funkcji main która jest pierwszym wątkiem. Całość wymaga kompilatora sdcc (3.6.0) oraz pakietu gputils. Cykl wątków przełączany jest z częstotliwością timera0.

    Niestety nie wiem czy ta obsługa wątków będzie działać na innych mikrokontrolerach, ponieważ nie mam na czym testować ;) Generalnie powinna, jesli tylko timer0 jest do dyspozycji. Sprawdzałem kompilacje i działanie na symulatorze dla PIC18f2420, ale to 100% pewności nie ma czy jakieś błędy czy niedopatrzenia tam się nie przemyciły.

    Na chwile obecną nie ma możliwości dynamicznych zmian wątków w trakcie programu po ich utworzeniu, wątki należy utworzyć najlepiej przed włączeniem przerwań. I ich ilość maksymalna jest konfigurowana na stałe.

    Całość powstała w 90% na bazie obserwacji (reverse enginering), ponieważ łatwiej mi to zrozumieć niż dokumentacje (której nie wiadomo gdzie szukać i co w niej szukać), więc być może są błędy. Krytyka i uwagi w tym temacie mile widziane. :)

    Całość udostępniam jako szkielet programu w którym jest już wywołanie funkcji main oraz funkcje przerwaniowe. Na chwile obecną nie wiem czy da się to zrobić na zasadzie udostępniania np biblioteki.


    Co w przyszłości:
    Jest to pierwsza wersja o dość ograniczonych możliwościach. Nie wiem czy będą następne wersje ponieważ zależy to od wielu czynników, czas, czy w ogóle ktoś będzie zainteresowany itp. itd. Sam chętnie rozwinąłbym to w formie bardziej zaawansowanej. Ponieważ jest sporo konfiguracji i może ona być trudna i podatna na błędy, mam też w planach napisanie programu który tą konfigurację ułatwi.


    Kod można pobrać z gitlaba:
    https://gitlab.com/trolsix/pic18thread

    szkielet w katalogu:
    0.1.0
    przykład z PIC18F1220 w katalogu
    0.1.0_example

    Pierwszą wersje udostępniam na licencji MIT, w sumie nie wiem która byłaby sensowniejsza do tego typu rzeczy.

    Na elektrode wrzucam schemat i pcb płytki z PIC18f1220






    Obsługa wątków na pic18 z kompilatorem sdcc (PIC18XXXX threads) Obsługa wątków na pic18 z kompilatorem sdcc (PIC18XXXX threads)

    Filmik z działania płytki na terminalu:




    To tak w skrócie. :) Teraz jeśli ktoś jest bardziej zainteresowany będzie opis jak tego użyć.


    1. pliki:

    upsimple.c - główny z funkcją main
    threadpic16conf.h - konfguracja
    thp.S - konfiguracja dla asemblera
    irq_high.c - obsługa przerwania o wyższym priorytecie
    threadpic16.c - przerwanie o niższym priorytecie wraz z obsługą wątków
    nothing.c - jakieś dodatki typu czyszczenie watchdoga
    Bconf.h - konfiguracja dla mikrokontrolera
    Bheadb.h - taki sobie plik nagłówkowy jeśli potrzebujemy konfigu dla rejestrów, lub korzystamy z atrybutu __wparam z pomocą makra _MYMODFUN_. Tak naprawde ten atrybut i to działanie ma sens jeśli piszemy program który będziemy kompilowali innym kompilatorem i kiedy z tego atrybutu korzystamy. W przypadku jeśli nasz program będzie kompilowany tylko za pomocą sdcc nie ma potrzeby.
    makefile - polecenia dla make

    W pliku makefile należy ustawić ścieżke do sdcc oraz gputils oraz typ uK.

    Własne pliki projektówe *.c można dodawać w katalogu projektu, makefile powinien automatycznie skompilować wszystkie. Nie należy dodawać plików o rozszerzeniu *.asm ponieważ są czyszczone, jeśli już to plik asemblera o rozszerzeniu *.S



    2. Uwaga na zużycie pamięci

    Mikrokontrolery z serii PIC18 są całkiem ciekawe jeśli pisze się w asemblerze, troche gorzej jest z kompilowaniem kodu w C. Z tego z resztą powodu kompilator XC8 przynajmniej w darmowej wersji nie kompiluje kodu reentrant. Kompilator sdcc może taki kod wygenerować, jednak często wzrasta zużycie pamięci i bez potrzeby lepiej tego jednak nie używać.

    Z powodu pamięci jest opcja w pliku threadpic16conf.h

    Kod: text
    Zaloguj się, aby zobaczyć kod


    która jeśli damy 0, oszczędzi nam 4 bajty na wątek. A zapisuje rejestry do obsługi pamięci flash. Jeśli nie wiemy co robimy lepiej zostawić 1.

    Na chwile obecną kod jest napisany dla modelu small, nie wiem czy sdcc wspiera już large.



    3. konfig ilości wątków w pliku threadpic16conf.h

    Kod: text
    Zaloguj się, aby zobaczyć kod


    na chwile obecną 2 lub 3



    4. Konfig ram

    Obsługa wątków na pic18 z kompilatorem sdcc (PIC18XXXX threads)

    PIC18 mają pamięć dostępną na kilka sposobów, przez bank, przez wskaźnik lub przez bit access, z tego powodu pierwsze 128 bajtów kompilator rezerwuje na zmienne do użycia. Maksymalną ilość używanych zmiennych należy przy zmianie wątków zapamiętać. Ile tych rejestrów potrzeba, można odczytać z plików asm wygenerowanych przez kompilator. Liczba ta w zależności od kodu wacha się od 16-64 bajtów (max 128). Jeśli nie wiemy ile, trzeba odłożyc maks. Z tym że obecne możliwości to dla dwóch wątków około (zależy od konfiguracji) 256/2-12 czyli 116 a dla trzech 256/3-12 czyli 73. Bo na chwile obecną tyle maks może mieć tabela.

    Ilość rejestrów do zapamiętania przy zmianie kontekstu konfigurujemy w linii:

    Kod: text
    Zaloguj się, aby zobaczyć kod




    5. Kwestia stosu skoku adresu

    Obsługa wątków na pic18 z kompilatorem sdcc (PIC18XXXX threads)

    PIC18 posiadają stos sprzętowy w wielkości 31 :) W tej obsłudze nie robiłem odkładania ich do pamięci, co powoduje ograniczoną liczbę skoków do 15 dla dwóch wątków i 10 dla trzech. Może to być dość duże ograniczenie ponieważ w tych 10 adresach musi się zmieścić wykonywany program plus skok do przerwania plus skok do przerwania o wyższym priorytecie :)

    W przyszłej wersji można to zrobić aby mieć cały stos dla każdego wątku. Jednak wzrasta ilość pamięci. Dla trzech wątków mamy plus 279 bajtów gdybyśmy chcieli zapisać cały stos.



    6. Kwestia stosu danych

    Na potrzeby działania programu trzeba zarezerwować pamięć na stos. Każdy wątek powinien mieć własny.
    Cały stos ustawiany jest w konfigu w pliku threadpic16conf.h w linii:
    Kod: text
    Zaloguj się, aby zobaczyć kod


    Na chwile obecną zalecane jest zmieszczenie się w wyrównanym adresie do 256

    oraz dla każdego wątku górny adres:
    Kod: text
    Zaloguj się, aby zobaczyć kod




    7. Kwestia przerwań.

    W PIC18 można właczyć jeden lub dwa poziomy przerwań. Cała obsługa wątków jest zrealizowana na przerwaniu o niższym priorytecie ponieważ wiadomo że sprzęt przeważnie jest ważniejszy i nie może czekać. Stąd obsługe przerwań urządzeń ważniejszych należy robić w przerwaniu o wyższym priorytecie, natomiast jeśli czas zmiany obsługi wątków nie wpłynie na opóźnienie można je realizować również w przerwaniu gdzie jest obsługa wątków. Jest opcja do zmiany aby używać tylko jednego przerwania, ale nie ruszać, bo po zmianach w kodzie nie wiem czy zadziała.

    Z tym że uwaga, w przerwaniu o niższym priorytecie można dodawać tylko
    wywołania funkcji typu void, jest to spowodowane że cała funkcja jest typu "naked", a może dojść konieczność odkładania innych atrybutów które nie są uwzględnione.

    w programie powinno być tylko jedno włączenie przerwań za pomocą

    Kod: text
    Zaloguj się, aby zobaczyć kod


    Natomiast gdy zajdzie potrzeba wyłączenia jakiejś sekcji kodu (dla atomowości) oraz włączenia robimy to za pomocą

    Kod: text
    Zaloguj się, aby zobaczyć kod


    Z tym że w zasadzie dotyczy to przerwań wyłączanych z przerwania, ponieważ ustawienie ich z funkcji głównej main jest w zasadzie takie same. I takie działanie wyłączy nam wszystkie.

    Ponieważ nie zawsze jest to zalecane, ponieważ sprzęt przeważnie powinien być na najwyższym priorytecie i nie blokowany, można wyłączać tylko te o mniejszym priorytecie, oczywiście o ile nie jesteśmy w przerwaniu:

    Kod: text
    Zaloguj się, aby zobaczyć kod




    8. plik thp.S

    Ponieważ nie wiem jak to zgrabniej zrobić, należy ustawić w pliku thp.S ilość wątków

    Kod: text
    Zaloguj się, aby zobaczyć kod


    i odkomentować zakomentować adres stosu dla watku 2 (nr 1)

    Kod: text
    Zaloguj się, aby zobaczyć kod


    i ustawić liczbe rejestrów do zapisu z pliku threadpic16conf.h
    Kod: text
    Zaloguj się, aby zobaczyć kod




    9. cykle:

    Na chwile obecną prescaler timera0 jest ustawiony na 64, dla mikrokontrolera który wykonuje 2MHz cykli (zegar 8MHz) przełączanie odbywa się 122 razy na sekunde. Można tenże zegar skonfigurować inaczej w funkcji void initth ( void )



    10. uruchamianie wątków

    Kolejność uruchamiania zalecana:
    prototyp funkcji: uint8_t myfun1 ( void );
    konfiguracja i start obsługi: initth();
    uruchomienie naszej funkcji np: thret = startthvoid ( &myfun1 );
    włączenie przerwań: irq_on();



    11.

    Wątki na razie nie zwracją wartości, i mogą być zakańczane na dwa sposoby. Przez pętle while(1) która nic nie robi poza marnowaniem zasobów.
    Przez ustawienie przerwania i kolejną zmiane kontekstu dla następnego wątka (domyślnie).



    12. Uwagi odnośnie demonstracyjnej wersji dla PIC18F1220

    Ponieważ PIC18F1220 ma mało pamięci, uruchomienie wątków jest sensowne po zmianie w opcjach linkera odnośnie zarezerwowanej pamięci. Jak pisałem, pierwsze 128 bajtów ram są zarezerwowane dla rejestrów roboczych, co powoduje brak pamięci na reszte danych, wartość ta jest zmiejszona do 32 bajtów przez przydział większej ilości pamięci.

    Cytat:
    DATABANK NAME=gpr0 START=0x20 END=0xFF




    Cały program który w zasadzie wiele nie robi, pochłania 2 KB flash i niemal całą pamięć 256 bajtów. Z czego główne zużycie to:
    100 stos
    54 zrzut rejestrów
    32 na rejestry robocze
    16 bufor RS
    24 dwa bufory robocze na stringi

    razem wstępnie 226 :) plus inne zmienne.



    Macie jakieś dygresje, pytania, uwagi, śmiało możecie pisać. Jeśli tylko czas pozwoli to się do nich odniose, tudzież uwzględnie w następnej wersji.

    --------


    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
  • #2 10 Mar 2019 00:25
    Krzysztof Klimek
    Poziom 10  

    Nic z tego nie rozumiem, ale szacun za napisanie wielowątkowego systemu operacyjnego na takie małe coś. Zastanawiam się tylko, czy w praktyce znajdzie zastosowanie, bo jednak ilość pamięci jest znikoma.

  • #3 10 Mar 2019 01:18
    Stefan_2000
    Poziom 18  

    A czemu nie FreeRTOS?

  • #4 10 Mar 2019 09:18
    IS
    Poziom 16  

    FreeRTOS to by raczej na 256bajtach nie pochodził...

  • #5 10 Mar 2019 12:19
    lemgo
    Poziom 12  

    Komentarze po polsku, nazwy stałych po polsku (_ILETHR) - nie wróżę światowego rozgłosu, publikacji na obcych forach ani licznych recenzentów kodu

  • #6 10 Mar 2019 20:01
    trol.six
    Poziom 31  

    Krzysztof Klimek napisał:
    Nic z tego nie rozumiem

    Z tego powodu chce napisać konfigurator i może jakieś programy użytkowe, aby ktoś kto nic nie rozumie też miał możliwość użycia. Z resztą nawet dla mnie będzie to przydatne, bo ręczne ustawianie tego wszystkiego jest delikatnie mówiąc denerwujące ;) i czasochłonne.

    Krzysztof Klimek napisał:
    Zastanawiam się tylko, czy w praktyce znajdzie zastosowanie, bo jednak ilość pamięci jest znikoma.

    Myśle że gdyby ktoś coś takiego potrzebował to dawno już by zostało napisane. Ja to zrobiłem m.in. z ciekawości. Niestety zabawy z wątkami są pamięciożerne. Ale paradoksalnie, dodając pamięć zewnętrzną możemy zwiększyć możliwości PICa w tym zakresie, bo w końcu kontekst można zapisywać na niej. Sens praktyczny, prawdopodobnie żaden ;)

    Są pice co mają więcej niż te skromne 256 bajtów, niemniej jednak to malutkie jest.

    @IS: Gwoli ścisłości, ram jest 256 bajtów, ale pic18 mają sprzętowy stos który ma 93 bajty (3x31). Razem 349 ;) Z tym że w przykładowym projekcie jest wykorzystywanych coś w okolicach 7x3

    @lemgo: w sumie nie wiem czy na popularności mi zależy, ale racja, można ujednolicić te zapisy skoro się wrzuciło projekt dla szerszej publiki. Na razie wstępnie projekt jest że tak to ujmę lokalny.

    @Stefan_2000: w następnej wersji może dodam semafory (itp.) i usprawnie wykorzystanie zasobów. Takie coś w sumie już można sensownie wykorzystać. Jednak tak czy siak, trzeba mieć na uwadze że ilość pamięci jest mała, moc obliczeniowa też nie za potężna. Raczej nikt nie bierze małego uk do większych zadań w których sens wykorzystania RTOS'a ujawniłby swoje zalety ;) Ale zważywszy na pomysły jakie czasem spotyka się w internecie... ;)

  • #7 11 Mar 2019 08:53
    LChucki
    Poziom 28  

    Nie widzę sensu wynajdowania koła na nowo skoro jest RTOS, uRTOS, itp.

    IS napisał:
    FreeRTOS to by raczej na 256bajtach nie pochodził...

    Bierze się uC z większą RAM i po problemie. System wielowątkowy wymaga więcej RAM niż system bez wielowątkowości i to nie jest tajemnicą.

  • #8 13 Mar 2019 22:13
    trol.six
    Poziom 31  

    LChucki napisał:
    Nie widzę sensu wynajdowania koła na nowo skoro jest RTOS, uRTOS, itp.

    Projekt ma troche inny charakter niż te co wymieniłeś, ma być względnie mały i tylko na PIC18. Przynajmiej na chwile obecną.

    Wielkiego konfiguratora chyba nie będzie... bo jednak programista się musi orientować ile czego potrzebuje, ale:

    1. Napisałem już program który szacuje zużycie stosu przez funkcje, trzeba przyznać że naprawde jest pomocny w jego ustawieniu. Dokładnie wszystkiego nie policzy bo skoki do funkcji przez wskaźnik raczej są nie policzalne, jak i funkcji bibliotecznych, ale mając zestawienie jest to duże ułatwienie.

    2. Program szacuje też ilość rejestrów, na razie maks na plik, ale może będzie liczyć odrębnie dla funkcji.

    3. konfigurator może być sensowny dla większych piców. Będą domyślne wartości, a stos będzie ustawiany półautomatycznie ze skryptów linkera.

    Już udało mi się odpalić trzy wątki testowe na tym ;) Choć troszke uprościłem jedną funkcje.

    Jak nie będzie jakiś przeszkód wkrótce się pojawi.

    ----------

    Wstępnie zrzut z analizą rejestrów roboczych oraz skoków:
    Code:

    threadpic16.asm irq_high.asm nothing.asm upsimple.asm prginit.asm funbcd.asm
                     threadpic16.asm reg   1 max   2
                        irq_high.asm reg   2 max   2
                         nothing.asm reg   1 max   2
                        upsimple.asm reg   4 max   4
                         prginit.asm reg   1 max   4
                          funbcd.asm reg  15 max  16
    #define NUMBREGSAVE 16
    - - - - - - - - - - - - - - - - - -
              S_threadpic16__tch_int   0   0
               S_threadpic16__thstop   1   1
               S_threadpic16__irq_on   0   1
               S_threadpic16__initth   0   1
         S_threadpic16__tch_int_jump   9   9
          S_irq_high_ivec_0x1_tc_int   0   9
                  S_irq_high__tc_int   8   9
                   S_nothing__CLRWDT   0   9
                    S_upsimple__main  13  13
                S_upsimple__RSouttbl   3  13
                  S_upsimple__RSoutP   3  13
                  S_upsimple__myfun2  11  13
                  S_upsimple__myfun1   0  13
                 S_prginit__initport   0  13
                   S_funbcd__binbcd1  17  17
                      S___irq_on_asm   0  17
                     S___irq_off_asm   0  17
                 S___irq_restore_asm   0  17
                 S___startthvoid_asm   3  17

    .

  • #9 13 Mar 2019 22:22
    LChucki
    Poziom 28  

    trol.six napisał:
    LChucki napisał:
    Nie widzę sensu wynajdowania koła na nowo skoro jest RTOS, uRTOS, itp.

    Projekt ma troche inny charakter niż te co wymieniłeś, ma być względnie mały i tylko na PIC18. Przynajmiej na chwile obecną.

    Czy to nie jest sztuka dla sztuki? Przy obecnych cenach wypasionych uC, pchanie jakis własnych uRTOS w malutkie uC? To jak na siłę udowadnianie, ze Arduino UNO wyświetli JPEG z karty SD na LCD 1-bit 320x240 ze sterownikiem bez wspomagania sprzętowego. Da się? Da! To, ze obrazek będzie rysował się linia po linii przez 2,7sekundy nie jest już ważne.

    Z tą obsługą wielu ("aż" trzech) wątków na PIC18 pewnie będzie tak samo. Udowodnione zostanie, że można ale jakieś praktyczne zastosowania?

  • #10 20 Mar 2019 09:46
    trol.six
    Poziom 31  

    Nowa wersja 0.2.1

    - łatwiejsza konfiguracja
    - dodano numeracje wątków, teraz start: startthvoidn ( &myfun1, 1 )
    - wątki można zatrzymać: threadstop ( 1 )
    - wątki można wznawiać: threadrun ( 1 )
    - można uruchomić od nowa pod tym samym numerem: startthvoidn ( &myfun1, 1 )
    - można to zrobić niemal w dowolnym momencie, nie trzeba wyłączać przerwań
    - wątki zakończone oraz zatrzymane nie są w "rutingu" czyli oszczędzamy zasoby
    - ilość maksymalna to 5 włącznie z main
    - każdy wątek ma osobną konfiguracje, czyli oszczędzamy zasoby
    - opcja STACK_FOR_IRQ, przerwania IRQL przełącza na własny stos
    - dodano opcje speed_up - wielokrotności 1,2,4,8 ale uwaga na wyrównanie rejestrów
    - wstępnie napisałem program do ustalania ile czego
    - naprawione błędy z poprzedniej wersji

    link do kodu na gitlabie: picthread

    ------------------------------

    Wersja przykładowa dla pic18f1220, 5 wątków, jedynie co robią to inkrementuja zmienne. W pętli main konwersja i przykład z zatrzymaniem i wznowieniem nr 1. Zakończenie wszystkich i ponowne uruchomienie 2,3,4

    W linijce cycles ilość cykli zużytą przez przerwanie, przy zmianie dwóch różnych kontekstów.

    Jak ktoś lubi filmiki, to przyspieszony x4 razy.



    ------------------------------

    Co trzeba ustawić:

    plik: threadpic16conf.h
    - ilość wątków (2-5)
    - stos sprzętowy jest wstępnie skonfigurowany, ale jeśli trzeba, zmienić (THSTACKPOINTxx)
    - ilość rejestrów NUMBREGSAVExx, musi być wyrównana do SPEEDUPSAVE

    plik: threadpic16stckconf.h
    - wielkość stosu programowego
    - rozmiar tego stosu dla każdego wątku oraz IRQ

    inne opcje:
    - SPEEDUPSAVE - przyspieszenie ile na raz odkładanych jest rejestrów,
    wadą jest że ilość rejestrów musi być zaokrąglona do tej wartości, wielkiej oszczędności nie będzie ale jeśli będziemy zapisywać większą liczbe rejestrów może to mieć sens

    - STACK_FOR_IRQ - lepiej dać 1, powoduje że IRQ ma własny stos THSTACSIZIH
    dzięku czemu dodajemy jeden a nie dwa stosy z przerwania (max), wada kilka cykli z wyłączonymi przerwaniami high. Ale je i tak czasem trzeba wyłaczać.

    - _PRESCALER_T0 - dzielnik timera0 jak często będzie osbługa wątków (256*): 16,32,64,128,256

    ------------------------------

    Program pictc (pic thread configurator) służy do szacowania ilości rejestrów oraz stosu. Analizuje pliki *asm wygenerowane przez kompilator sdcc. Trzeba go dopracować, bo pewnych rzeczy nie uwzględnia (np analiza funkcji naked) itp. Ale w miare się już nadaje. Poza tym jak pisałem wszystkiego raczej nie przeanalizuje.

    Uruchamiamy:

    Cytat:
    pictc -s lista wszystkich plików pojektu.asm


    Informacje o znalezionych funkcjach:
    - nazwa asemblerowa
    - zużycie stosu
    - zużycie rejestrów
    - zużycie ramu (na plik)
    - zużycie sumaryczne (wszystkie pliki)
    - ustawiony stos (stos ustawia sie tylko w jednym pliku)

    Code:
              code_name              ramstack reg  ram sumram stackram
    
          S_irq_high_ivec_0x1_tc_int     0     0     0     0     0
                  S_irq_high__tc_int     8     2     0     0     0
                   S_nothing__CLRWDT     0     0     0     0     0
              S_threadpic16__tch_int     0     0    88    88   100
       S_threadpic16__startthvoidnum     2     0    88    88   100
               S_threadpic16__setset     0     0    88    88   100
          S_threadpic16__irq_restore     0     0    88    88   100
              S_threadpic16__irq_off     0     0    88    88   100
        S_threadpic16__thstop_endfun     1     0    88    88   100
               S_threadpic16__irq_on     0     0    88    88   100
            S_threadpic16__threadrun     3     3    88    88   100
           S_threadpic16__threadstop     3     3    88    88   100
               S_threadpic16__initth     0     0    88    88   100
         S_threadpic16__tch_int_jump     9     2    88    88   100
                    S_upsimple__main     7     0    48   136     0
                S_upsimple__RSouttbl     9     8    48   136     0
                  S_upsimple__RSoutP     3     3    48   136     0
                  S_upsimple__myfun4     0     0    48   136     0
                  S_upsimple__myfun3     4     4    48   136     0
                  S_upsimple__myfun2     0     0    48   136     0
                  S_upsimple__myfun1     0     0    48   136     0
                 S_prginit__initport     0     0     0   136     0
                   S_funbcd__binbcd1    17    15     0   136     0
                S___startthvoidn_asm     3     0     0   136     0
                 S___startthvoid_asm     0     0     0   136     0


    1. Ilość stosu jaką musimy ustawić dla wątku to suma zużycia przez wszystkie funkcje które się wywołują.
    Jeśli mamy opcje STACK_FOR_IRQ, to plus większa wartość z przerwań.
    Jeśli nie mamy opcji STACK_FOR_IRQ, to plus suma z przerwań IRQL i IRQH.

    2. Ilość rejestrów jaką musimy ustawić, to maksymalna wartość, czyli jeśli nasza funkcja main zużywa 7 a wywołuje funkcje binbcd1 15 to maks 15. Ale jeśli korzystamy ze SPEEDUPSAVE np 2 to musimy wpisać 16.

    Inne możliwości programu uruchomienie:
    Cytat:
    pictc/pictc -cs /sciezka/do/skryptu_linkera

    Przykładowy wynik:
    Cytat:
    pictc: stack start 16 siz 240 end 255 numbgpr 0


    daje informacje o największym ostatnim bloku pamieci, który można wykorzystać do ustawienia stosu.

    W planach program będzie szacował ile czego. Na razie tyle napisałem. Program napisany troche na szybcika ;) U mnie program rezyduje w podkatalogu projektu "pictc" i tak napisany jest makefile. Traba sobie skompilować przed użytkowaniem. Plik makefile jest dla gcc.

    LChucki napisał:
    Da się? Da!

    Ale ja nie wiem co się da, ani co dam rade zrealizować. Teraz w planach mam mutexy i semafory. Może dzięki temu zasoby będą lepiej wykorzystywane. Przynajmniej takie są plany.
    :)