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
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
Materiały