Konrad Rybacki, konrad.rybacki@wp.pl

Embedded Prolog Runtime (EPR) – Running Prolog on Embedded Platforms, programming Prolog-C Interfaces, evaluation, refinment, testing, improvement; C and Prolog Programming is required

• klasy problemow: wymagania sprzetowe, sychnr prologu z otoczeniem, prolog a rt
• runtime? linux/prolog

• Wybór kompilatora prologa (SWI, GNU), analiza jakości działania obu kompilatorów - pod względem zużycia zasobów systemu, stabilności oraz możliwych mechanizmów komunikacji z innymi składnikami systemu.
• Sposób integracji z systemem - np. jako moduł jądra - wysoka wydajność i uproszczona komunikacja między składnikami systemu, duża podatność na awarie, niska portowalność na inne architektury; w przestrzeni użytkownika - większa stabilność kosztem potencjalnie bardziej złożonej komunikacji i mniejszej wydajności, konieczność opracowania rozbudowanej warstwy komunikacyjnej umożliwiającej integrację z systemem
• Analiza alternatywnych środowisk uruchomieniowych - porównanie dostępnych platform bazujących na systemie GNU/Linux z innymi dostępnymi, jak np. NetBSD; należy zwrócić uwagę na wymagania sprzętowe, trudności związane z konfiguracją systemu oraz odtwarzaniem tej konfiguracji w nowych warunkach a także jakość dokumentacji i perspektywy rozwoju danej implementacji. Licencje i dostępność.
• Rozważenie wykorzystania istniejącego już oprogramowania (D-Bus, PolicyKit, HAL) do realizacji zadań związanych z dostępem do sterowników oraz zarządzaniem zdarzeniami. Ewentualnie wykorzystanie pewnych wzorców dostępnych w wymienionych implementacjach.
• Na podstawie powyższych punktów, określenie minimalnych wymagań sprzętowych umożliwiających działanie w czasie rzeczywistym.

• wymagania prologu → SWI/Yap praca na czymś innym niż ix86? ARM?
• minimalne środowisko gnu/linux, ew. netbsd? → spec
• emulacja arm, test dystrybucji linux/netbsd arm-owej na QEmu
• uwaga! pytanie co daje cxprolog i jaki ma footprint, porównując do powyższych?

• opis krosskomp
• inst linux/bsd arm na wirtualizatorze
• testy wydajności prologu http://www.ncc.up.pt/~vsc/Yap/documentation.html#SEC83
• może warto brać pod uwagę jako platformy
  • OpenMoko.org OpenMoko.com
  • Maemo

• spis środowisk + ew. ewalucja: OpenMoko, Android → argumenty
• ew. zasadzki w kompilacji prologu na w.w

• próby z swi?
• bezp. uzycie debiana arm, ew. armel?
• http://en.wikipedia.org/wiki/Maemo
• http://www.toradex.com/e/colibri_evalboard.php

• propozycja generyczna platformy arm, w kier maemo?
• minimalne wymagania sprzętowe?
• emulator?
• http://www.scratchbox.org/

• sprawozdanie: wnioski, obserwacje, różnice pomiędzy platformami ARM na przykładzie 2-3, ew. problemy z przenaszalnością, etc., przyszłe kierunki prac co do mgr.,wymagania swi/yap? co do pamięci

• Próba utworzenia wirtualnego środowiska uruchomieniowego emulującego system oparty o procesor z rodziny ARM.

Wykorzystano: Pakiet QEMU, wersja 0.9.1_2, system uruchomieniowy (host) FreeBSD 7.0, procesor klasy i686. Uruchomienie dystrybucji ARM systemu NetBSD nie powiodło się. Emulator albo zupełnie odmawia współpracy, nie rozpoznając właściwie obrazu jądra, albo sygnalizuje błędy w uruchamianym kodzie. Należy dokładnie sprawdzić wsparcie dla architektury opartej o ARM w tym systemie w konfrontacji z możliwościami QEMU. Niestety, brak jest dokumentacji opisującej bezpośrednio przykłady uruchomienia NetBSD na tym symulatorze.

Próba uruchomienia systemu Linux na wspomnianym emulatorze, zgodnie z opisem http://www.aurel32.net/info/debian_arm_qemu.php zakończyła się połowicznym sukcesem. System wprawdzie uruchamia się, ale przy próbie zapisu na dysk dochodzi do błędu segmentacji. Najprawdopodobniej jest to spowodowane jakimiś zależnościami FreeBSD - QEMU. Niestety, nie miałem możliwości przetestowania QEMU na innym systemie - do zrobienia w najbliższym czasie.

• Analiza wymagań implementacji Prologa:

W związku z wymienionymi wcześniej problemami, trudno podejmować próby oceny wymagań dostępnych środowisk. SWI Prolog posiada wygodną w użyciu bibliotekę, pozwalającą w pewnym stopniu analizować zużycie zasobów http://gollem.science.uva.nl/SWI-Prolog/Manual/profile.html. Niestety, nie udało mi się znaleźć odpowiednika dla YAP, bez czego właściwie trudno o wykonanie sensownych porównań. Do wykorzystania zestaw testów sprawdzających wydajność Prologa: http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/prolog/code/bench/0.html. Interesująca może być również strona: http://www.david-reitter.com/compling/prolog/compare.html.

• Próba cross-kompilacji Prologa na architekturę ARM:

W ramach próby wykorzystałem toolchain arm-elf-linux. Niestety, kompilator sygnalizuje błędy w kodzie (zarówno w przypadku YAP jak i SWI) - może być to spowodowane niezgodnością wersji. Należy przetestować inne dostępne wersje oraz, po rozwiązaniu problemów zasygnalizowanych powyżej (QEMU), sprawdzić, czy możliwa będzie kompilacja w natywnym środowisku.

Kompilacja CxProlog nie powiodła się zarówno przy środowisku docelowym arm-linux jak i FreeBSD. Brak skryptów umożliwiających konfigurację budowy tego oprogramowania prawdopodobnie poważnie utrudni możliwość jego uruchomienia w systemie innym niż GNU/Linux.

Kross-kompilacja:

• Przygotowanie środowiska. Należy pobrać archiwa zawierające pakiety binutils, newlib oraz gcc i umieścić w odpowiednio dobranej strukturze katalogów.

1. cd [binutils-build]
2. [binutils-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
3. make all install
4. export PATH=„$PATH:[toolchain-prefix]/bin”
5. cd [gcc-build]
6. [gcc-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib –enable-languages=„c,c++” –with-newlib –with-headers=[newlib-source]/newlib/libc/include
7. make all-gcc install-gcc
8. cd [newlib-build]
9. [newlib-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
10. make all install
11. cd [gcc-build]
12. make all install
13. cd [gdb-build]
14. [gdb-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
15. make all install

• Jeżeli ma się odbyć pełny proces kompilacji, to należy również wyposażyć się w pliki nagłówkowe oraz wymagane biblioteki z przyszłego środowiska uruchomieniowego.
• Kompilacja oprogramowania odbywa się zgodnie z np. następującymi regułami:

1. rozpakowanie archiwum, wejście do katalogu, w którym odbywa się kompilacja
2. [sciezka_do_zrodel]/configure –target=arm-elf –host=i386-unknown-freebsd CC=[toolchain-prefix]/bin/arm-elf-gcc CPP=[toolchain-prefix]/bin/arm-elf-cpp RANLIB=[toolchain-prefix]/bin/arm-elf-ranlib CPPFLAGS=„-I[sciezka_do_naglowkow]” LDFLAGS=„-L[sciezka_do_bibliotek] –prefix=[prefiks]
3. użycie CPPFLAGS i LDFLAGS jest w pewnych warunkach opcjonalne

• YAP przechodzi taki proces pomyślnie do momentu linkowania. Niestety, ze względu na ciągłe trudności ze znalezieniem właściwego środowiska, brak odpowiednich bibliotek umożliwiających końcowe zbudowanie pakietu.
• W przypadku SWI problemem jest brak odpowiednich plików nagłówkowych - należy to rozwiązać tak samo jak problem powyższy.

• Udało się znaleźć ciekawe wydanie systemu linuks uruchamialne na wirtualizatorze qemu:

http://free-electrons.com/community/demos/qemu-arm-directfb Samo wydanie nie odpowiada dokładnie oczekiwaniom ale zawiera zestaw skryptów oraz opis pozwalający na budowę własnej dystrybucji - co wobec problemów ze znalezieniem jakiejkolwiej innej, działającej, może być dobrym rozwiązaniem.

• Platforma Neo1973 wymagana do uruchomienia dystrybucji OpenMoko nie jest oficjalnie wspierana przez Qemu. Wsparcie dla tej architektury jest aktualnie przedmiotem aktywnego rozwoju - instnieje możliwość wyposażenia Qemu w taką funkcjonalność, ale nie jest to rozwiązanie w pełni stabilne i przewidywalne.

Platformy warte rozważenia w dalszej części projektu, to: Android, OpenMoko (Neo1973) oraz płyta ewaluacyjna Versatile PB.

• Stabilny rozwój architektury.
• Dobry zestaw narzędzi pozwalających na tworzenie oprogramowania.
• Dobrej jakości dokumentacja.

• Ograniczenia licencyjne (Google zastrzega sobie pewne zasadnicze prawa co do projektu)
• Częściowo zamknięty kod
• Ograniczenie dostępności pewnych funkcji hardware'u dla oprogramowania.
• Duży koszt ew. urządzenia.

• Całkowita otwartość kodu.
• Jasna koncepcja rozwoju.
• Dostępność wirtualizatora (w najbliższej przyszłości, p. wyżej)

• Aktualnie brak dobrego środowiska do emulacji platformy.
• Duży koszt ew. urządzenia.

http://www.arm.com/products/DevTools/VPB926EJ-S.html

• Jest to architektura o względnie uniwersalnym charakterze.
• Obecna od dłuższego czasu na rynku - dobra dostępność oprogramowania.
• Możliwość rozbudowy o dodatkowe komponenty.

• Przeciętnej jakości dokumentacja.

• Całkowicie otwarty kod.
• Dobrej jakości SDK.
• Pełen zestaw mogących się przydać bibliotek i oprogramowania: D-Bus, Hal, X Windows, itp.
• Z przyczyn finansowych brak możliwości przetestowania poza środowiskiem emulowanym.

• Każda z tych platform jest związana z konkretnym rozwiązaniem sprzętowym - trudność migracji, brak możliwości uruchomienia poza środowiskiem emulowanym. Przeciwnie, środowisko oparte o własnoręcznie dostosowany system prawdopodobnie byłoby łatwiej dostosować do nowego rozwiązania sprzętowego.
• Ograniczona dostępność oprogramowania w binarnych pakietach w porównaniu np. do standardowej dystrybucji Debiana.
• Konieczność stosowania określonych rozwiązań, częściowa zamkniętość/ograniczenia w użyciu kodu/narzędzi.

Brak wsparcia ze strony dostępnych wirtualizatorów.

Wsparcie dla środowiska Linuksa: http://www.vollmann.ch/en/colibri/info.html, http://wiki.toradex.com/index.php?title=Linux. Niestety są to rozwiązania komercyjne.

http://rybacki.rootnode.net/debian.pdf

http://wiki.debian.org/Embedded_Debian

http://www.emdebian.org/

http://wiki.debian.org/EmdebianQuickStart

http://wiki.debian.org/EmdebianGuide

Jako platformy uruchomieniowej wydałoby się zasadne użycie systemu GNU/Linux wyposażonego w pakiety: D-Bus, PolicyKit oraz Hal. Pakiety te umożliwiają realizację zagadnień takich jak: komunikacja międzyprocesowa, zarządzanie uprawnieniami oraz interakcja z warstwą sprzętową. Dzięki wysokiemu poziomowi abstrakcji oraz łatwej konfigurowalności mogłby by stanowić wystarczające środowisko - teoretycznie, możliwe do przeniesienia na inne platformy.

Środowisko to pozwala na imitację częściowo natywnej kompilacji oprogramowania oraz kompilację skrośną. Wykorzystywany jest emulator QEMU dla architektury ARMEL.

SDK maemo pozwala na stworzenie środowiska uruchomieniowego na bazie architektury x86 opartej o system GNU/Linux. Nie jest to emulacja, lecz kompilacja i użycie natywnego dla tej architektury kodu ale z użyciem elemetów dostępnych tylko dla maemo:

http://maemo.org/development/documentation/tutorials/maemo_4-0_tutorial.html#development

Takie rozwiązanie znacznie zwiększa wygodę testowania i obsługi aplikacji, jednocześnie nie ograniczając możliwości uruchomienia w środowisku emulatora (QEMU).

Ostatecznie, do dalszych prac, zostały uwzględnione trzy różne rozwiązania sprzętowe oparte o procesor architektury arm/armel. Dwa z nich to klasyczne urządzenia typu smartphone/pda, natomiast w przypadku trzecim jest to płyta ewaluacyjna o szerokim zakresie zastosowań. Właściwości tych urządzeń zostaną rozpatrzone w poniższych punktach:

Jest to telefon pracujący w standardzie GSM , wyposażony w zestaw funkcji pozwalających zaliczyć go do klasy urządzeń smartphone. W finalnej wersji (aktualnie jest to sprzęt będący obiektem ciągłego rozwoju) mają się znaleźć:

• Procesor: Samsung S3C2442 B54 SoC @ 400Mhz
• Interfejs WiFi: Atheros 802.11 b/g
• Akcelerator graficzny: SMedia Glamo3362
• Dwa czujniki przyspieszeń (3D)
• 256MB pamięci Flash
• 128MB pamięci SDRAM
• 2MB pamięci Flash NOR
• Bateria 1200mAh
• Podświetlanie LED
• Odbiornik GPS u-blox/Atmel ATR0635
• Interfejs Bluetooth
• Host USB z zasilaniem
• Czytnik kart microSD
• Interfejs JTAG

Oprogramowanie na tę architekturę powstaje w środowisku OpenMoko, które zostanie opisane w dalszych akapitach.

Platforma ta może być emulowana przez wirtualizator QEMU, jednak wsparcie dla niej jest ciągle w fazie rozwoju (konieczności modyfikacji źródeł QEMU na podstawie odpowiedniego repozytorium).

Jest to seria urządzeń o funkcjonalności zbliżonej do klasycznych rozwiązań typu PDA (wbrew błędnie powielanym opiniom, urządzenia te nie posiadają funkcji telefonu). Najnowszym modelem z tej serii jest N810:

• Procesor: 400 MHz TI OMAP 2420
• 2GB pamięci Flash
• 128MB pamięci SDRAM
• Klawiatura, ekran dotykowy
• Wyświetlacz 800×400 pikseli, 16 bitowa głębia kolorów
• Intefejs IEEE 802.11 b/g
• Bateria 1500mAh
• Czytnik kart miniSD
• Interfejs Bluetooth
• Interfejs USB
• Odbiornik GPS
• Kamera
• Czujnik światła

Platforma rozwojowa - maemo.

Architektura ta jest wspierana (częściowo) przez wirtualizator QEMU.

Platforma ta, spośród wybranych, zawiera najszerszy zestaw komponentów - jest to rozwiązanie przeznaczone do w pełni profesjonalnych zastosowań. Istnieje wiele odmian tego urządzenia; jako przykład może zostać przedstawiona płyta:

• Procesor ARM926EJ-S
• Akcelerator Java Jazelle®, dodatki DSP
• Koprocesor MOVE™, sprzętowy akcelerator kompresji MPEG
• Koprocesor zmiennoprzecinkowy
• Kontroler DMA, kontroler przerwań
• Interfejs JTAG
• 64MB pamięci Flash
• 128MB 32 bitowej pamięci SDRAM
• 2MB pamięci SRAM
• Interfejs ethernet
• LCD i ekran dotykowy
• Wyjście VGA
• 4 porty szeregowe
• 1 synchroniczny port szeregowy
• 32 zewnętrznych wyprowadzeń i/o
• 1 interfejs USB, 2 hosty USB
• 2 czytniki SmartCard
• Interfejs klawiatury i myszy
• Wyjście/wejście audio stereo
• Wyświetlacz alfanumeryczny 2×16 LCD
• Kontroler PCI

Jest to projekt w stu procentach społecznościowy, a zatem i otwarty/niezależny (GPL). Dystrybucja ta powstaje w oparciu o platformę http://oe.linuxtogo.org/.

Struktura zawartego oprogramowania została przedstawiona na poniższym schemacie:

• Za komunikację międzyprocesową odpowiedzialny jest demon D-Bus.
• Obsługa zdarzeń systemowych (np. zmiana stanu baterii, itp.) jest zapewniona przez demona neod; jest to rozwiązanie dość nietypowe i wyłamujące się z konwencji (w środowiskach opartych o system Linux tę rolę pełni najczęściej HAL), dodatkowo, prawdopodobnie jest to rozwiązanie tymczasowe: http://svnweb.openmoko.org/trunk/src/target/OM-2007.2/daemons/neod/README?view=auto

:pl:miw:gjn-mixdes2006-final.pdf

http://www.toradex.com/e/colibri_evalboard.php