To jest stara wersja strony!
Opis
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
Spotkania
08.03.04
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.
080318
080408
080415
spis środowisk + ew. ewalucja: OpenMoko, Android → argumenty
ew. zasadzki w kompilacji prologu na w.w
080422
Projekt
Sprawozdanie
08.03.18
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.
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.
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.
08.04.08
Kross-kompilacja:
cd [binutils-build]
[binutils-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
make all install
export PATH=„$PATH:[toolchain-prefix]/bin”
cd [gcc-build]
[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
make all-gcc install-gcc
cd [newlib-build]
[newlib-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
make all install
cd [gcc-build]
make all install
cd [gdb-build]
[gdb-source]/configure –target=arm-elf –prefix=[toolchain-prefix] –enable-interwork –enable-multilib
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:
rozpakowanie archiwum, wejście do katalogu, w którym odbywa się kompilacja
[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]
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.
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.
08.04.15
Platformy warte rozważenia w dalszej części projektu, to: Android, OpenMoko (Neo1973) oraz płyta ewaluacyjna Versatile PB.
Android
Zalety
Stabilny rozwój architektury.
Dobry zestaw narzędzi pozwalających na tworzenie oprogramowania.
Dobrej jakości dokumentacja.
Wady
OpenMoko
Zalety
Wady
Versatile PB
Zalety
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.
Wady
08.04.22
Materiały