Linux_embedded_cz1.pdf

(296 KB) Pobierz

Wprowadzenie do Linux’a embedded

KURS

Wprowadzenie

do Linux’a embedded

Tabela 1. Minimalne wymagania syste-

mowe Linuxa z jądrem 2.6.x

Procesor: 32 – bitowy (ARM, MIPS, PPC)

Taktowanie procesora: 60MHz

Pamięć RAM: 4MB

Pamięć masowa (FLASH/Karta SD): 2MB

Współczesne oprogramowanie urządzeń powszechnego użytku staje

się coraz bardziej skomplikowane. Nowoczesne urządzenia mają

gra ﬁ czny interfejs użytkownika, najczęściej dotykowy, coraz bardziej

skomplikowane interfejsy komunikacyjne, takie jak WiFi, USB czy

Ethernet. Dostępne funkcje oprogramowania stwarzają nam takie

możliwości, o których kilka lat temu można było tylko marzyć.

Urządzenia stają się coraz bardziej przyjazne dla użytkownika

i coraz bardziej kolorowe. Kto by przypuszczał że kupując

współczesny telefon np. z systemem Android, kupujemy urządzenie

o wydajności komputera biurkowego sprzed kilkunastu lat, który

możemy zmieścić w kieszeni? Niestety coraz większe skomplikowanie

oprogramowania stawia coraz to nowe wyzwania programistom

i konstruktorom, i dlatego Ci coraz chętniej sięgają po systemy

operacyjne. Jednym z nich jest Linux embedded.

Tabela 2. Zalecane wymagania syste-

mowe Linuxa z jądrem 2.6.x

Procesor: 32 – bitowy (ARM, MIPS, PPC)

Taktowanie procesora: 200MHz

Pamięć RAM: 32MB

Pamięć masowa (FLASH/Karta SD): 32MB

dzania pamięcią MMU, oraz dużą pamięcią

RAM. Z uwagi na znaczny spadek cen, kom-

ponenty niezbędne do budowy prostego

systemu mikroprocesorowego dla systemu

Linux możemy nabyć w cenie dużego mi-

krokontrolera jednoukładowego.

O ile niegdyś w ramach małej ﬁ rmy na-

pisanie od postaw skomplikowanego opro-

gramowania było całkiem realne, o tyle

dziś już coraz trudniej temu podołać. Ko-

nieczność obsługi kolorowych wyświetla-

czy LCD, paneli dotykowych i skompliko-

wanych interfejsów powoduje, że obsługa

tych wszystkich peryferiów wykonywana

na „piechotę” poprzez dostęp do rejestrów,

bez żadnych dodatkowych bibliotek, jest

w zasadzie nie do wykonania w sensownym

czasie. W przypadku, gdy projekt jest sto-

sunkowo prosty, możemy skorzystać z do-

datkowych bibliotek coraz częściej dostar-

czanych przez producentów mikrokontro-

lerów. W przypadku większych projektów

takie podejście również okazuje się nie-

wystarczające. Brak jednolitego interfejsu

w świecie mikrokontrolerów powoduje, że

większość standardowego oprogramowania

(na przykład serwer www z szyfrowaniem

SSL) będziemy musieli utworzyć samo-

dzielnie. Również brak ochrony pamięci

pomiędzy zadaniami/procesami powoduje,

że nawet mały błąd w kodzie powoduje za-

wieszenie się całego urządzenia, a o błędy

w dużym i skomplikowanym programie nie

jest trudno.

Rozwiązaniem wyżej wspomnianych

problemów jest użycie systemu operacyj-

nego znanego z większych komputerów

biurkowych. Dzięki temu zyskujemy me-

chanizm ochrony pamięci pomiędzy proce-

sami, gdzie błędnie działająca aplikacja nie

może zawiesić całego systemu. Dostajemy

również dostęp do wielu standardowych

bibliotek i programów, przez co możemy za-

oszczędzić wiele czasu na tworzenie czegoś,

co zostało wymyślone kiedyś. Obecnie naj-

lepszym systemem operacyjnym przezna-

czonym do zastosowania w urządzeniach

wbudowanych jest system Linux, z uwagi

na jego skalowalność, otwarty kod źródło-

wy, brak konieczności zakupu kosztownych

licencji oraz dostępność na w zasadzie każ-

dą platformę sprzętową. Linux potraﬁ dzia-

łać na bardzo różnych mikrokomputerach,

począwszy od małych systemów mikropro-

cesorowych, poprzez PC, do komputerów

typu mainframe . Dzięki temu zdobywa on

coraz większą popularność w urządzeniach

wbudowanych i jest już używany w 25% te-

lefonów komórkowych (Android).

Niestety, zastosowanie Linux’a wymaga

użycia dużego procesora z jednostką zarzą-

Minimalny system

mikroprocesorowy potrzebny

do uruchomienia Linuksa.

Wymagania systemowe

W tabeli 1 umieszczono minimalne wy-

magania systemowe które powinien speł-

niać system mikroprocesorowy, niezbędne

do uruchomienia systemu Linux z jądrem

w wersji 2.6.x, dla systemów wbudowanych.

Są wymagania minimalne, w przypadku

których ciężko mówić o komfortowej pracy.

Aby zapewnić w miarę komfortową pracę

należy zbudować system mikroprocesoro-

wy o parametrach co najmniej takich, jak

wymienione w tabeli 2 .

Rysunek 1. Schemat blokowy przykładowego, minimalnego systemu mikroprocesoro-

wego dla Linux działającego na AT91RM9200

107

ELEKTRONIKA PRAKTYCZNA 4/2011

883836421.308.png

883836421.319.png

883836421.330.png

883836421.341.png

883836421.001.png

883836421.012.png

883836421.023.png

883836421.034.png

883836421.045.png

883836421.056.png

883836421.067.png

883836421.078.png

883836421.089.png

883836421.100.png

883836421.111.png

883836421.122.png

883836421.133.png

883836421.144.png

883836421.155.png

883836421.166.png

883836421.177.png

883836421.188.png

883836421.199.png

883836421.210.png

883836421.221.png

883836421.232.png

883836421.243.png

883836421.253.png

883836421.264.png

883836421.275.png

883836421.284.png

883836421.285.png

883836421.286.png

883836421.287.png

883836421.288.png

883836421.289.png

883836421.290.png

883836421.291.png

883836421.292.png

883836421.293.png

883836421.294.png

883836421.295.png

883836421.296.png

883836421.297.png

883836421.298.png

883836421.299.png

883836421.300.png

883836421.301.png

883836421.302.png

883836421.303.png

883836421.304.png

883836421.305.png

883836421.306.png

883836421.307.png

883836421.309.png

883836421.310.png

883836421.311.png

883836421.312.png

883836421.313.png

883836421.314.png

883836421.315.png

883836421.316.png

883836421.317.png

883836421.318.png

883836421.320.png

883836421.321.png

883836421.322.png

883836421.323.png

883836421.324.png

883836421.325.png

883836421.326.png

883836421.327.png

883836421.328.png

883836421.329.png

883836421.331.png

883836421.332.png

883836421.333.png

883836421.334.png

883836421.335.png

883836421.336.png

883836421.337.png

883836421.338.png

883836421.339.png

883836421.340.png

883836421.342.png

883836421.343.png

883836421.344.png

883836421.345.png

883836421.346.png

883836421.347.png

883836421.348.png

883836421.349.png

883836421.350.png

883836421.351.png

883836421.002.png

883836421.003.png

883836421.004.png

883836421.005.png

883836421.006.png

883836421.007.png

883836421.008.png

883836421.009.png

883836421.010.png

883836421.011.png

883836421.013.png

883836421.014.png

883836421.015.png

883836421.016.png

883836421.017.png

883836421.018.png

883836421.019.png

883836421.020.png

KURS

Istnieją również wersje linuksa, mogące

pracować bez MMU np. na procesorach

ARM7TDMI, czy CORTEX-M3, jednak są

one dużo mniej wydajne ponieważ MMU

jest emulowane, oraz nie zapewniają

odpowiedniego poziomu bezpieczeństwa.

Więc nie możemy go traktować jako

pełnoprawną wersję systemu Linux.

szczególne zadania kodowane są za pomocą

maszyn stanów w sposób jawny lub z wyko-

rzystaniem małych systemów RTOS, takich

jak FreeRTOS, czy ISIX, które zapewniają

nam wykonywanie zadań, bez konieczności

tworzenia podatnych na popełnienie błędu

maszyn stanu. Na rysunku 3 przedstawio-

no model zależności pomiędzy sprzętem

a przykładową aplikacją wielozadaniową

dla mikrokontrolera jednoukładowego.

Aplikacja ma trzy zadania realizujące

różne funkcje. System RTOS jest odpowie-

dzialny za przełączanie zadań, synchroni-

zację międzyzadaniową, która jest realizo-

wana za pomocą semaforów i kolejek. Na-

tomiast obsługa sprzętu realizowana jest za

pomocą dodatkowej biblioteki dostarczonej

przez producenta mikrokontrolera. Aplika-

cje, RTOS oraz biblioteki obsługi sprzętu

działają w ramach jednej wspólnej prze-

strzeni adresowej, która jest określana pod-

czas etapu linkowania. Każdy element apli-

kacji, czyli poszczególne zadania, RTOS,

biblioteki obsługi sprzętu, mają dostęp do

całej przestrzeni adresowej oraz systemu

przerwań. W takim modelu jedno błędnie

działające zadanie, które np. nadpisało pa-

mięć w drugim zadaniu, jest w stanie spo-

wodować zawieszenie działania całego pro-

gramu. Jedynym ratunkiem jest wówczas

zadziałanie sprzętowego układu watchdog.

O ile w prostych programach możliwość

wyszukania tego typu błędów jest w miarę

łatwa, to wykrycie ich w przypadku rozbu-

dowanych aplikacji jest dość problematycz-

ne. Do niewątpliwych zalet modelu progra-

mowego ze wspólną przestrzenią adresową

Rysunek 2. Pamięć RAM zamontowana mikrokontrolerze (źródło: www.wikipedia.org ).

Kluczowym elementem do prawidło-

wego działania systemu, jest dostępność

odpowiedniej ilości pamięci RAM, która

musi być znacznie większa, niż w przy-

padku aplikacji dla mikrokontrolerów jed-

noukładowych. Podobnie wygląda sprawa

z pamięcią, w której jest przechowywany

ﬁ rmware urządzenia. Samo jądro linuk-

sa z włączoną obsługą sieci zajmuje około

1 MB. Dużo mniej krytycznym aspektem

jest częstotliwość pracy procesora, i nawet

przy taktowaniu rzędu 60 MHz, system

będzie pracował w miarę wydajnie. Przy

wyborze odpowiedniego procesora kluczo-

wym znaczeniem jest jego dostępność oraz

powszechność. Im bardziej układ jest popu-

larny i używany przez większą liczbę osób

, tym lepiej dopracowany i stabilny jest

kod jądra przeznaczonego dla niego Linu-

x’a. Również kluczowe znaczenie ma tutaj

cena układu, a wiadomo – im układ bardziej

powszechny, tym jego produkcja jest tań-

sza. Ponieważ obecnie na rynku systemów

wbudowanych królują mikrokontrolery

z rdzeniem ARM, w dalszej części tekstu

będziemy skupiać się wyłącznie na tej ar-

chitekturze. Na rysunku 1 przedstawiono

przykładowy, minimalny system mikropro-

cesorowy z AT91RM9200, na którym może-

my w miarę komfortowo uruchomić system

linux:

Sercem układu jest dość leciwy mi-

krokontroler AT91RM9200, z rdzeniem

ARM920T do którego dołączono kluczowe

elementy, czyli pamięć SDRAM o wielkości

32MB. Pamięć masową dla systemu stanowi

pamięć Dataﬂ ash 128KB, w której przecho-

wywany jest program ładujący (bootloader),

oraz karta SD na której przechowywany jest

właściwy system linux. Zamiast pamięci

Dataﬂ ash i karty SDRAM w nowszych ukła-

dach np. 9260, SAM-G20 możemy użyć

pojedynczej pamięci typu NAND-FLASH.

Pozostałe elementy stanowią interfejsy ko-

munikacyjne i są w opcjonalne. Jak więc

widzimy, w stosunku do klasycznego roz-

wiązania układowego jedyną różnicą jest

konieczność dołączenia zewnętrznych

pamięci do układu. Koszt procesora, oraz

dodatkowych pamięci (SDRAM jest bardzo

tani) , jest porównywalny do większych mi-

krokontrolerów jedno-układowych a możli-

wości są nieporównanie większe. Niestety

problemem jest tutaj konieczność wyprowa-

dzenia całej magistrali , co znacząco kom-

plikuje konstrukcję. Jednak nadzieją są tu-

taj rozwiązania typu „Package on Package”,

umożliwiające umieszczenie pamięci nad

procesorem, i złożenie z nich jakby jedne-

go układu, np. rozwiązanie OMAP-DM510,

zawierającą pamięć DDR umieszczoną na

procesorze ( rysunek 2 ).

Ochrona pamięci systemowej

i co z tego wynika, czyli różnice

pomiędzy pisaniem aplikacji

dla mikrokontrolera a aplikacją

przeznaczoną dla Linux’a

Oprogramowanie dla mikrokontrolerów

jednoukładowych

jest najczęściej pisa-

ne na dwa sposoby:

bez systemu opera-

cyjnego, gdzie po-

Rysunek 3. Model zależności pomiędzy sprzętem a przykładową

aplikacją wielozadaniową dla mikrokontrolera jednoukładowego

Rysunek 4. Model programowy dla projektów realizowanych

z użyciem systemu Linux

108

ELEKTRONIKA PRAKTYCZNA 4/2011

883836421.021.png

883836421.022.png

883836421.024.png

883836421.025.png

883836421.026.png

883836421.027.png

883836421.028.png

883836421.029.png

883836421.030.png

883836421.031.png

883836421.032.png

883836421.033.png

883836421.035.png

883836421.036.png

883836421.037.png

883836421.038.png

883836421.039.png

883836421.040.png

883836421.041.png

883836421.042.png

883836421.043.png

883836421.044.png

883836421.046.png

883836421.047.png

883836421.048.png

883836421.049.png

883836421.050.png

883836421.051.png

883836421.052.png

883836421.053.png

883836421.054.png

883836421.055.png

883836421.057.png

883836421.058.png

883836421.059.png

883836421.060.png

883836421.061.png

883836421.062.png

883836421.063.png

883836421.064.png

883836421.065.png

883836421.066.png

883836421.068.png

883836421.069.png

883836421.070.png

883836421.071.png

883836421.072.png

883836421.073.png

883836421.074.png

883836421.075.png

883836421.076.png

883836421.077.png

883836421.079.png

883836421.080.png

883836421.081.png

883836421.082.png

883836421.083.png

883836421.084.png

883836421.085.png

883836421.086.png

883836421.087.png

883836421.088.png

883836421.090.png

883836421.091.png

883836421.092.png

883836421.093.png

883836421.094.png

883836421.095.png

883836421.096.png

883836421.097.png

883836421.098.png

883836421.099.png

883836421.101.png

883836421.102.png

883836421.103.png

883836421.104.png

883836421.105.png

883836421.106.png

883836421.107.png

883836421.108.png

883836421.109.png

883836421.110.png

883836421.112.png

883836421.113.png

883836421.114.png

883836421.115.png

883836421.116.png

883836421.117.png

883836421.118.png

883836421.119.png

883836421.120.png

883836421.121.png

883836421.123.png

883836421.124.png

883836421.125.png

883836421.126.png

883836421.127.png

883836421.128.png

883836421.129.png

883836421.130.png

883836421.131.png

883836421.132.png

883836421.134.png

883836421.135.png

883836421.136.png

883836421.137.png

883836421.138.png

883836421.139.png

883836421.140.png

883836421.141.png

883836421.142.png

883836421.143.png

883836421.145.png

883836421.146.png

883836421.147.png

883836421.148.png

883836421.149.png

883836421.150.png

883836421.151.png

883836421.152.png

883836421.153.png

883836421.154.png

883836421.156.png

883836421.157.png

883836421.158.png

883836421.159.png

883836421.160.png

883836421.161.png

883836421.162.png

883836421.163.png

883836421.164.png

883836421.165.png

883836421.167.png

883836421.168.png

883836421.169.png

883836421.170.png

883836421.171.png

883836421.172.png

883836421.173.png

883836421.174.png

883836421.175.png

883836421.176.png

883836421.178.png

883836421.179.png

883836421.180.png

883836421.181.png

883836421.182.png

883836421.183.png

883836421.184.png

883836421.185.png

883836421.186.png

883836421.187.png

883836421.189.png

883836421.190.png

883836421.191.png

883836421.192.png

883836421.193.png

883836421.194.png

883836421.195.png

883836421.196.png

883836421.197.png

883836421.198.png

883836421.200.png

883836421.201.png

883836421.202.png

883836421.203.png

883836421.204.png

883836421.205.png

883836421.206.png

883836421.207.png

883836421.208.png

883836421.209.png

883836421.211.png

883836421.212.png

883836421.213.png

883836421.214.png

883836421.215.png

883836421.216.png

883836421.217.png

883836421.218.png

883836421.219.png

883836421.220.png

883836421.222.png

883836421.223.png

883836421.224.png

883836421.225.png

883836421.226.png

883836421.227.png

883836421.228.png

883836421.229.png

883836421.230.png

883836421.231.png

883836421.233.png

883836421.234.png

883836421.235.png

883836421.236.png

883836421.237.png

883836421.238.png

883836421.239.png

883836421.240.png

883836421.241.png

883836421.242.png

883836421.244.png

883836421.245.png

883836421.246.png

883836421.247.png

883836421.248.png

883836421.249.png

Wprowadzenie do Linux’a embedded

możemy zaliczyć prostotę dostępu do za-

sobów. W zależności od potrzeb, z każde-

go miejsca aplikacji możemy bezpośrednio

obsługiwać sprzęt poprzez bezpośredni do-

stęp do rejestrów układów peryferyjnych,

z poziomu zadania, biblioteki, czy samego

RTOS-a. Również przekazywanie danych

pomiędzy zdaniami jest łatwe, ponieważ

każde zadanie ma dostęp do tego samego

obszaru pamięci, który może być zapisy-

wany lub odczytywany. Podobnie wygląda

sprawa z systemem przerwań, choć najczę-

ściej jest ona realizowana przez oddzielny

zestaw funkcji OS-a.

Na rysunku 4 zaprezentowano model

programowy dla projektów realizowanych

z wykorzystaniem systemu Linux. Dla syste-

mu Linux działającego na procesorze z jed-

nostką MMU, jest realizowana wzajemna

ochrona zasobów jądra i przydzielonych po-

szczególnym procesom (zadaniom). Każdy

proces ma niezależną, wirtualną przestrzeń

adresową, co zapewnia wzajemną ochronę

aplikacji oraz samego jądra systemu przed

błędnym działaniem innych procesów, jak

również umożliwia optymalne wykorzysta-

nie pamięci poprzez mapowanie adresów

wirtualnych na adresy ﬁ zyczne za pomocą

mechanizmu stronicowania. Każde odwoła-

nie do nieprawidłowego adresu wirtualne-

go powoduje zatrzymanie procesu poprzez

sygnał SEGFAULT informujący o błędnym

odwołaniu do pamięci. Z poziomu aplikacji

nie ma możliwości bezpośredniego odwoły-

wania się do sprzętu, a komunikacja z nim

musi odbywać się za pomocą wywołań sys-

temowych jądra, które przekazują żądania

obsługi sprzętu do sterowników urządzeń.

Wywołanie systemowe (w przypadku ar-

chitektury ARM instrukcja SWI) powoduje

przejście aplikacji z trybu użytkownika do

trybu jądra i wykonanie określonych czyn-

ności przez jądro na rzecz procesu (mówimy

wówczas że mamy do czynienia z wykony-

waniem kodu jądra w kontekście procesu).

Natomiast samo jądro wraz ze wszystkimi

sterownikami urządzeń działa w ramach

wspólnej pojedynczej przestrzeni adreso-

wej. Odizolowanie aplikacji od urządzeń

zapewnia również dostęp do danego urzą-

dzenia przez wiele procesów oraz chroni

przed błędnym działaniem poszczególnych

aplikacji.

Dostęp do urządzeń z procesu użyt-

kownika jest realizowany poprzez otwarcie

pliku urządzenia a następnie pisanie i czy-

tanie za pomocą standardowych wywołań

systemowych read , write , select itp. Wywo-

łania systemowe w aplikacji realizowane są

za pośrednictwem standardowej biblioteki

libc (b iblioteka języka C ), z której wywo-

ływane są funkcje realizujące wywołania

systemowe jądra. Przygotowanie projektu

z wykorzystaniem systemu Linux intensyw-

nie wykorzystującego zewnętrzne układy

peryferyjne, jest bardziej skomplikowane,

niż przy pisaniu aplikacji dla mikrokontro-

lera jednoukładowego, ponieważ będziemy

musieli napisać (lub wykorzystać gotowe)

sterowniki dla urządzeń oraz osobno napi-

sać aplikację, która będzie komunikowała

się ze sterownikami. Przy pisaniu sterowni-

ków musimy zachować szczególną ostroż-

ność, tak jak w przypadku pisania na mikro-

kontrolery bez MMU, ponieważ sterownik

zawsze ma dostęp do wszystkich zasobów,

więc głównie od jakości sterowników zale-

żeć będzie stabilność systemu.

Lepszym rozwiązaniem będzie wyko-

rzystanie standardowego mikrokontrolera

jednoukładowego, oraz ewentualnie syste-

mu RTOS takiego jak ISIX gdy:

– Wykonujemy aplikację, która reali-

zuje prosty algorytm niepotrzebujący

dużych zasobów, skomplikowanych

obliczeń ani dodatkowych bibliotek

zewnętrznych i niewymagający duże-

go nakładu pracy na napisanie samej

aplikacji. W Linux’ie napisanie samego

sterownika urządzenia może się okazać

zadaniem dużo bardziej skomplikowa-

nym, niż dodatkowy nakład potrzebny

na napisanie aplikacji samodzielnie.

– Wykonujemy urządzenie produkowane

masowo o niezbyt skomplikowanym

działaniu, gdzie koszt dodatkowej pra-

cy programistycznej jest niewspółmier-

nie mały do kosztów całego projektu

i konieczności minimalizacji kosztów

jednostkowych urządzenia. Takim przy-

kładem może być np. sterownik z in-

terfejsem ETHERNET, gdzie napisanie

aplikacji pod Linux’em jest bardzo pro-

ste, natomiast w przypadku mikrokon-

trolera jednoukładowego jest bardziej

skomplikowane, ale wykonalne w sen-

sownym czasie np. z użyciem bibliotek

udostępnianych przez producentów.

Jak więc widzimy użycie systemu mi-

kroprocesorowego z systemem Linux nie

jest lekarstwem na wszystko. W przypadku

prostych układów sterujących typu załącz/

wyłącz/steruj, lepszym rozwiązaniem bę-

dzie wykorzystanie klasycznego rozwiąza-

nia opartego o mikrokontroler jednoukła-

dowy.

Kiedy będziemy potrzebować

Linux’a?

Spróbujmy odpowiedzieć na pytanie,

w jakich przypadkach będziemy potrzebo-

wać systemu mikroprocesorowego z syste-

mem Linux, a kiedy szybsze i tańsze będzie

zastosowanie standardowego rozwiązania

opartego o zwykły mikrokontroler jedno-

układowy i mini system operacyjny np.

ISIX.

Systemu mikroprocesorowego z Linu-

kx’em będziemy potrzebować, gdy:

– Istnieje konieczność używania skom-

plikowanych interfejsów komunika-

cyjnych WiFi, Bluetooth, Ethernet itp.

(Linux ma wbudowane sterowniki dla

większości typowych urządzeń siecio-

wych oraz stosy WiFi, TCP/IP, BT, USB

HOST itp.).

– Potrzebujemy skomplikowanego inter-

fejsu użytkownika z dużym, kolorowym

wyświetlaczem TFT oraz panelem do-

tykowym. Korzystając z zewnętrznych

bibliotek graﬁ cznych, serwera X oraz Qt

czy GTK, możemy projektować bardzo

skomplikowane interfejsy graﬁ czne nie-

wielkim nakładem środków.

– Potrzebujemy aplikacji multimedial-

nej wyświetlającej ﬁ lmy, odtwarzającej

pliki MP3 itp. Możemy wykorzystać

bardzo bogate biblioteki kodeków, np.

ffmpeg itp.

– Jest wymagana komunikacja z wykorzy-

staniem szyfrowania danych SSL.

– Potrzebujemy wykonać urządzenie z in-

terfejsem sterowanym przez przeglądar-

kę WWW z bezpiecznym protokołem

HTTPS oraz dużą liczbą dynamicznie

generowanych stron. Możemy zainsta-

lować standardowy serwer www+PHP

i pisać aplikację, tak jak w przypadku

pracy z dużym komputerem PC.

– Potrzebujemy wykonać bardziej skom-

plikowane zadanie, a znaleźliśmy bi-

blioteki OpenSource pozwalające w ła-

twy sposób osiągnąć zamierzony efekt.

– Potrzebujemy urządzenia sterującego

niezależnymi procesami, z gwarancją

prawidłowego działania nawet w przy-

padku uszkodzenia jednego z proce-

sów.

Krótki kurs pisania aplikacji dla

Linux’a.

W literaturze, Internecie oraz na wy-

kładach prowadzonych na wyższych uczel-

niach, możemy znaleźć wiele informacji na

temat programowania w systemie Linux.

Kursy te najczęściej są poświęcone ogólnym

zagadnieniom dotyczącym programowania

systemowego, najczęściej z wykorzysta-

niem komputerów PC. Niestety, brakuje lite-

ratury poświęconej Linux’owi w zastosowa-

niach embedded. W tym kursie postaram się

wypełnić tę lukę pokazując, w jaki sposób

do przykładowej płytki z Linux’em dołączyć

standardowe układy typu wyświetlacz LCD

czy klawiatura oraz w jaki sposób odwołać

się do nich za pomocą aplikacji systemu

operacyjnego. Jako platformę testową wy-

brano zestaw ewaluacyjny BF210 ( http://

www.boff.pl/?shop=1&p_id=5 ) zawierający

mikrokontroler AT91RM9200, dla którego

będą prezentowane gotowe obrazy karty SD

pozwalające bez dodatkowych czynności

uruchomić prezentowane przykłady.

Lucjan Bryndza, EP

lucjan.bryndza@boff.pl

109

ELEKTRONIKA PRAKTYCZNA 4/2011

883836421.250.png

883836421.251.png

883836421.252.png

883836421.254.png

883836421.255.png

883836421.256.png

883836421.257.png

883836421.258.png

883836421.259.png

883836421.260.png

883836421.261.png

883836421.262.png

883836421.263.png

883836421.265.png

883836421.266.png

883836421.267.png

883836421.268.png

883836421.269.png

883836421.270.png

883836421.271.png

883836421.272.png

883836421.273.png

883836421.274.png

883836421.276.png

883836421.277.png

883836421.278.png

883836421.279.png

883836421.280.png

883836421.281.png

883836421.282.png

883836421.283.png

Plik z chomika:

Inne pliki z tego folderu:

Wentylatory.pdf (1666 KB)
Star Wars. Katalizator. Wprowad - James Luceno.pdf (1665 KB)
Gordon R. Dickson - Smoczy rycerz T2.pdf (1663 KB)
LOKOMOTYWA TOWAROWA EMD JT42CWRM(Class66).pdf (1662 KB)
Greer Luanshya - Kto sieje wiatr 02 - Po burzy spokój.pdf (1660 KB)

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin