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.

OS w mikrokontrolerach, wady i zalety?

marenc 01 Kwi 2007 22:37 2213 12
  • #1 01 Kwi 2007 22:37
    marenc
    Poziom 24  

    Witam, chciałbym uzyskać informację odnośnie tego jakie są zalety i wady stosowania systemów operacyjnych. Kiedy je stosować, a kiedy nie.

    Mam na myśli AVR, ale mogą być dowolne mikro.

    0 12
  • #2 01 Kwi 2007 23:49
    adamusx
    Poziom 27  

    Moje zdanie jest takie, ze OS na AVRy to troche przerost formy nad treścią. Na ARMy to już nabiera jakiegoś sensu, chociaz w wiekszosci wypadków mozna sie obejsc bez niego.

    0
  • #3 02 Kwi 2007 06:37
    gol
    Poziom 13  

    Kiedy potrzebujesz wielo-wątkowości lub obsługi stosu TCP/IP

    0
  • #4 02 Kwi 2007 15:31
    marenc
    Poziom 24  

    No, ale równie dobrze można to napisać, że stosując OS'a. Jaki więc ma sens korzystanie z nich?

    adamusx - chodzi mi tylko o ogólny zarys korzystania z nich, bo jestem przeciwny marnotrawieniu pamięci Flash(Długo się przekonywałem do języka C i gdyby nie prędkość tworzenia to został bym przy ASM).

    0
  • #5 02 Kwi 2007 16:37
    szelus
    Specjalista - Mikrokontrolery

    mariuszlorenc napisał:
    (Długo się przekonywałem do języka C i gdyby nie prędkość tworzenia to został bym przy ASM).


    Wiesz, to jest taki sam argument. Chcesz coś zrobić szybciej - bierzesz gotowca (tu OS, standardowe biblioteki itd.).
    Chcesz zrobić optymalnie i wycisnąć wszystko co się da, do ostaniego bajtu Flash-a - piszesz na piechotę w asm i poświęcasz na to pisanie (i uruchamianie!!!) następne 10 lat :wink:

    0
  • #6 02 Kwi 2007 16:53
    starob
    Poziom 25  

    Spróbuje Ci to wytłumaczyć na przykładzie.
    Jesteś producentem jakiegoś urządzenia (sterownika) do uniwersalnych zastosowań.
    Wyposzażonego w klawiature, wyświetlacz, złącze komunikacji, porty I/O ect...
    W momencie produkcji jego funkcjonalność jest nieokreślona i wcale Cię ona nie obchodzi. Dopiero użytkownik decyduje o sposobie działania.
    Chcąc odnieść sukces komercyjny powinneś "wbudować" podstawowe funkcje obsługi urządzeń I/O, wspomagających programowanie (wgrywanie w prosty sposób programu funkcjonalnego) - taki OS.
    Dzięki OS użytkownik wcale nie musi znać się na tym co siedzi w środku.

    Chciałbyś kupić PC bez biosu?

    Drugi przypadek to jesteś programistą.
    Po co pisać za każdym razem wszystko od początku.
    Patrz wyżej kol.gol
    Dla rozwiązań unikatowych raczej nie celowe.

    0
  • #7 02 Kwi 2007 16:57
    marenc
    Poziom 24  

    Czyli OS to nic innego jak zbiór funkcji i procedur do obsługi danego urządzenia?

    Czyli na dobrą sprawę można się nauczyć obsługiwać OS dla uC zamiast rozpatrywać jego działanie? Ale bezsens :P Myślałem, że to daje większe możliwości.

    0
  • #8 02 Kwi 2007 17:09
    starob
    Poziom 25  

    mariuszlorenc napisał:
    Ale bezsens :P Myślałem, że to daje większe możliwości.

    Tak? Dam ci od oprogramowania prosty sterowniczek PLC LOGO, banalny do oprogramowania nawet z klawiaturki kilkoprzyciskowej, ale bez OS. Ciekawe czy nadal będziesz taki szczęśliwy?

    0
  • #9 02 Kwi 2007 17:10
    szelus
    Specjalista - Mikrokontrolery

    mariuszlorenc napisał:
    Czyli OS to nic innego jak zbiór funkcji i procedur do obsługi danego urządzenia?


    Każdy OS jest tylko i aż zbiorem funkcji, procedur i ewentualnie wątków/procesów plus jakichś tam danych konfiguracyjnych.
    Tylko zwróć uwagę, że ta lista wyczerpuje w zasadzie całą funkcjonalność jakiegokolwiek programu :)


    Cytat:
    Czyli na dobrą sprawę można się nauczyć obsługiwać OS dla uC zamiast rozpatrywać jego działanie? Ale bezsens :P Myślałem, że to daje większe możliwości.


    Rozumienie jak działa dany OS (czy biblioteka, czy jakiekolwiek inne narzędzie) niewątpliwie ułatwia wykorzystanie go w sposób najbardziej efektywny.

    0
  • #10 02 Kwi 2007 17:15
    _Matik_
    Poziom 19  

    Dokladnie, jak sie dobrze uprzesz to uzywajac systemu operacyjnego mozesz poczuc sie jak sredniej klasy programista PC. Na zasadzie: nie wiem jak to dziala, nie wiem dlaczego to tak dziala, ale wiem jakie parametry musze podac do okreslonej funkcji zeby wyplula okreslony wynik.
    W ten sposob mozna latwo zboczyc z wlasciwej drogi :D.
    Ale jezeli programista zna assembler danego procesora, potem napisze kilka programow w C i wie jak one sa tlumaczone na assembler, nastepnie zacznie przegladac zrodla systemu operacyjnego i wie dlaczego sa one tak napisane a nie inaczej, to staje sie swiadomym programista OS i uzyskuje potezne narzedzie do szybkiego tworzenia aplikacji. :>.

    Ja troche pisze pod FreeRTOSem na ARMie i osiagnalem wyniki ktorych nie da sie uzyskac w sensownym czasie bez OS. Niestety jednak nadal bardzo czesto zdarzaja sie sytuacje ze pisze cos co potem nie dziala tak jak planowalem albo co gorsza, cos co dziala przez kilka godzin a potem wyklada system na lopatki... i znajdz tu teraz blad jak masz kilkadziesiat kilo kodu (a blad niezawsze wynika bezposrednio z nieprawidlowego uzycia danej instrukcji tylko np. z tego ze "ktostam kiedys nie uwzglednil czegostam w stosie TCP i cos sie gdzies przepelnia przy jakichs konkretnych warunkach otoczenia - czytaj raz na tydzien").

    0
  • #11 02 Kwi 2007 22:45
    JacekCz
    Poziom 36  

    mariuszlorenc napisał:
    Czyli OS to nic innego jak zbiór funkcji i procedur do obsługi danego urządzenia?

    Czyli na dobrą sprawę można się nauczyć obsługiwać OS dla uC zamiast rozpatrywać jego działanie? Ale bezsens :P Myślałem, że to daje większe możliwości.


    OS ujawnia swoje możliwości gdy zastonowimy się nad tym, co NIE jest OS-em.
    a) Z jednej strony są to moduły z okolic OS-a (opcjonalne drivery itd)
    b) Z drugiej aplikacje (zwłaszcza ładowalne na życzenie, lub chronione nawzajem przed sobą)
    c) Po trzecie jakakolwiek okoliczność co do pracy zespołowej programistów, udostępniania lub korzystania z wyników czyjejś pracy (np. tu się rzekło stosu TCP/IP), upgradowania itd.

    Jeśli życie stawia cię przed okolicznościami to są okoliczności do użycia OS-a.

    Ktos kto uważa, że ZAWSZE napisze sam sobie lepiej itd. na zasadzie jednego dupnego monolitycznego programu, to powienien zająć się wynajdywaniem koła (może zrobi okrąglejsze niż te które są). Na serio: po paru latach sam dochodzisz to tego, żeby nałożyć swojej pracy jakieś więzy, ograniczenia (interfejsy, warstwy). Sam sobie wyznaczysz zarys SO.

    Pośrednio głos pokory tu zabrzmiał, że "napisałem, zwykle prawie mi działa".

    Ponieważ wiele zastosowań uK nie pociąga za sobą a),b) ani c), a koszty (wydajnościowe) OS jakieś są, OS dość rzadko występuje, choć w zabawkach o złożoności MP3 playera juz występuje zarys SO.

    Bunt przeciwko (jak tutaj) OS-wi, czy bibliotekom standardowym itp bzdurom mnie nie dziwi, bo jest typowy. Z wiekiem i doświadczeniem przechodzi.

    Dodano po 7 [minuty]:

    _Matik_ napisał:

    Ale jezeli programista zna assembler danego procesora, potem napisze kilka programow w C i wie jak one sa tlumaczone na assembler, nastepnie zacznie przegladac zrodla systemu operacyjnego i wie dlaczego sa one tak napisane a nie inaczej, to staje sie swiadomym programista OS i uzyskuje potezne narzedzie do szybkiego tworzenia aplikacji. :>.


    Podałeś przykład warstwy IO, modułu, ale do definicji SO brakuje zestandaryzowania (sformalizowania) - cokolwiek by to znaczyło w konkretnej sytuacji. Jeśli zastąpiłeś (zmieniłeś) fragmenty lub całość SO, już to w zasadzie dowodzi, że nie był to rasowy SO.

    Dodano po 4 [minuty]:

    _Matik_ napisał:
    a blad niezawsze wynika bezposrednio z nieprawidlowego uzycia danej instrukcji tylko np. z tego ze "ktostam kiedys nie uwzglednil czegostam w stosie TCP i cos sie gdzies przepelnia przy jakichs konkretnych warunkach otoczenia - czytaj raz na tydzien").


    W moim, już niekrótkim życiu programisty o wiele częściej stanął mi przed oczami własny błąd niż błąd systemu operacyjnego (w proporcji tak z 1000:1). Natomiast (nie weź tego zbyt osobiście, zakładam że masz spore wyniki) dowodzenie "na dzień dobry" błędów w SO (bibliotece itd) jest dla mnie testem na żółtodzioba (to taki sekret zawodowy)

    0
  • #12 03 Kwi 2007 02:14
    _Matik_
    Poziom 19  

    Cytat:

    Podałeś przykład warstwy IO, modułu, ale do definicji SO brakuje zestandaryzowania (sformalizowania) - cokolwiek by to znaczyło w konkretnej sytuacji. Jeśli zastąpiłeś (zmieniłeś) fragmenty lub całość SO, już to w zasadzie dowodzi, że nie był to rasowy SO.


    Nie mowilem o zastepowaniu lecz o poznaniu zasady dzialania (w tym przypadku zasad szeregowania watkow, wywlaszczania, zmiany kontekstu itp. - przyklady z doswiadczen z FreeRTOSem - nie mowie ze pozjadalem wszystkie rozumy tylko wymieniam rzeczy ktore chcialbym poznac w tym systemie dokladniej).
    Jezeli chodzi o definicje SO to mnie uczyli "interfejs posredniczacy pomiedzy uzytkownikiem komputera a sprzetem" ;>. Inni nazywaja systemem operacyjnym sam algorytm szeregowania watkow. Definicji jest wiele, wszystko zalezy od punktu siedzenia.

    Cytat:

    W moim, już niekrótkim życiu programisty o wiele częściej stanął mi przed oczami własny błąd niż błąd systemu operacyjnego (w proporcji tak z 1000:1). Natomiast (nie weź tego zbyt osobiście, zakładam że masz spore wyniki) dowodzenie "na dzień dobry" błędów w SO (bibliotece itd) jest dla mnie testem na żółtodzioba (to taki sekret zawodowy)


    Fakt, nikt nie lubi jak ktos biega i mowi mu ze cos nie dziala bo jest do dupy. :>
    Ale nie oszukujmy sie, swiat OpenSource jest nafaszerowany bugami. W koncu dostajemy nie gotowy produkt a cos co jest zazwyczaj w trakcie rozwoju.
    Zreszta apropo stosu TCPIP, 1/3 tanich routerow na rynku zawiesza sie po wlaczeniu Emule przez uzytkownikow sieci, rejestratory cyfrowe po kilka tysiecy zloty (fakt, z dalekiego wschodu) maja takie bledy w TCP (i nie tylko) ze nie da sie ich uzywac dopoki producent nie wypusci softu w wersji tysionc pincet (przyklady z pracy).

    Jeszcze malutki przykladzik nie na temat - kto probowal wykorzystywac zaawansowane mozliwosci peryferiow procesora LPC2101/2/3 ten wie ze i w krzemie tez wystepuja bledy. Prosze np. sprobowac bez zadnego obchodzenia napisac obsluge CC1000 (sprzetowy SPI slave) lub zliczanie impulsow z enkodera na timer1 przy pomocy wejsc capture. Albo podlaczyc ethernet PHY do at91sam7x256 przez RMII (stare partie scalakow).

    0
  • #13 13 Sty 2008 10:59
    Booby
    Poziom 14  

    Czy FreeRTOS to dobry wybór? Czy działa stabilnie? Czy są jakieś problemy z jego kompilacją, używaniem we własnych projektach?
    Proszę o uwagi. Używam AT91SAM7A3, GCC+Eclipse.

    0