Qt czy Eclipse dla linux embedded

0

Witam

Potrzebuje do projektu użyć środowiska w które byłoby najlepsze dla programowania linux embedded, (na razie bez wyświetlacza). Zebrałem już parę informacji ale gdzieś brakuje mi pewnych klocków, aby stworzyć oczywisty obraz i na coś się zdecydować.
Póki co w Eclipse udało się uruchomić kompilacje krzyżową i wysłać na urządzenie program, który zadziałał, więc sukces ! Mam zdalne debugowanie i uruchamiane. Przeciwnie do qt bo nawet nie dodarłem jeszcze do tego poziomu w ogóle, ponieważ mam pewne problemy z połączeniem się z urządzeniem i z ogólną konfiguracją qt do tego celu. Trochę nie rozumiem tego dlaczego muszę w qt używać kros kompilatora Angstroma. Dlaczego np narzędzie crosstool-ng nie posiada pliku qmake ? Do końca nie wyczytałem, czy do tego typu prac potrzebne jest zwykłe Qt, czy Qt-SDK, a może Qt-Embedded które haczy o wersje komercyjną ? W Qt na pewno podobają mi się biblioteki są uproszczone, łatwo się z nich korzysta, klasy kontenerów są niezłe, a mechanizm sygnałów i slotów ogólnie pomaga no i jest dobry support, dodatkowo miły interface dla oczu (jak dla mnie). Eclipse znów zmusza to standardowych bibliotek, przez co mamy więcej kodu, ale i większa kontrola, ma masę pluginów i możliwości, ale przez to znów nie jest zoptymalizowane i "ciężkie"
Sam nie wiem, proszę was o jakieś rady. To moje pytania z przemyśleniami, mam nadzieję, że ten temat mi pomoże się zdecydować.

ps Programowanie z hosta z linuxem

0

Ale odróżniaj Qt jako IDE (Qt Creator) od Qt jako biblioteki. Można używać Qt pod Eclipse, a można nie używać Qt pod Qt Creatorem.

0

Ok rozumiem, moją nie ścisłość. Czytałem o tym, że pod Eclips można użyć bibliotek Qt. No więc co radzisz użyć dla linux embedded ? Lepiej będzie pisać w Eclips używając bibliotek qt. Czy korzystać całkowicie z Eclipse, czy qt , a może coś zupełnie innego jakie jest wasze zdanie ? Ktoś ma doświadczenie i potrafi coś doradzić ?

0

Chyba nie zrozumiałeś bo to

Lepiej będzie pisać w Eclips używając bibliotek qt. Czy korzystać całkowicie z Eclipse, czy qt
nie bardzo ma sens.

Jeżeli chcesz używać Qt to chyba najlepszym wyborem będzie Qt Creator

0

Przede wszystkim chce, abyście uzasadnili czemu Qt-creator, a nie Eclipse....

0

Raczej Qt-creator jako IDE bo:

  1. Ma zintegrowane narzędzia budujące (qmake, kompilator/linker/cross-kompilator, kompilatory zasobów.. ).
  2. Ma zintegrowane narzędzia do tworzenia GUI w trybie ,,makieta XML" i kompilacja do obiektu
  3. Łatwo zrobisz resources (spakowane zestawy plików, ikonek, multimediów)
  4. Łatwe wywołanie linguist'a (pliki z tłumaczeniami językowymi)
  5. Łatwy dostęp do projektów przykładowych i dokumentacji.
  6. Integracja z narzędziami wersjonowania oraz uruchamiania kodu (np. valgrind)...
    7... a sprawdź sam co jeszcze :-)

Podsumowując, łatwiej zacząć.

Eclipse także jest ok ale trzeba go skonfigurować, doinstalować wtyczki, wiedzieć jak i gdzie każde z narzędzi wywołać itp. Czyli jest trochę zabawy. Jeśli warto, to już na dalszym etapie jak elementy środowiska Qt będą opanowane.

0
  1. Ma zintegrowane narzędzia budujące (qmake, kompilator/linker/cross-kompilator, kompilatory zasobów.. ).

Coś nie bardzo chyba... bo muszę pobrać paczkę z kros kompilatorem z distro ANGSTROM (nie wiem co ma Angstrom do qt... ale ok) wtedy wskazać na ten kompilator i na qmake z rozpakowanej paczki. Masz może jakieś namiary na tutorial jak skonfigurować qt do tego celu ? Bo już raz się męczyłem z tym i coś nie poszło.

0

No to może trochę precyzyjniej.

Pracujesz na jakiej platformie (system ew. dystrybucja), czyli gdzie będzie IDE?
Pod jaką platformę docelową chcesz budować aplikację w Qt?
I w jakiej wersji Qt ma to być aplikacja?
No i czy to ma być aplikacja do istniejącego systemu (już coś jest na platformie.. jakiś OS) czy Qt ma być tam natywnie?

Ja pisałem o Qt 5.4, z hostem pod GNU/Linux, Fedora 21 x64 i platformie docelowej Android bo to robiłem.

Tu masz konfiguracje oficjalne: http://doc.qt.io/QtForDeviceCreation/qtee-supported-platforms.html
Tu masz info o emb. linux http://doc.qt.io/qt-5/embedded-linux.html
Tu masz info o natywnej instalacji Qt http://doc.qt.io/QtForDeviceCreation/index.html

Jak nie będę tego wiedział, będzie trudno mi pomóc.

0
Mokrowski napisał(a):

No to może trochę precyzyjniej.

Pracujesz na jakiej platformie (system ew. dystrybucja), czyli gdzie będzie IDE?
Pod jaką platformę docelową chcesz budować aplikację w Qt?
I w jakiej wersji Qt ma to być aplikacja?
No i czy to ma być aplikacja do istniejącego systemu (już coś jest na platformie.. jakiś OS) czy Qt ma być tam natywnie?

Ja pisałem o Qt 5.4, z hostem pod GNU/Linux, Fedora 21 x64 i platformie docelowej Android bo to robiłem.

Tu masz konfiguracje oficjalne: http://doc.qt.io/QtForDeviceCreation/qtee-supported-platforms.html
Tu masz info o emb. linux http://doc.qt.io/qt-5/embedded-linux.html
Tu masz info o natywnej instalacji Qt http://doc.qt.io/QtForDeviceCreation/index.html

Jak nie będę tego wiedział, będzie trudno mi pomóc.

Host Debian 7.xxx versja Qt Qt Creator 3.3.2 (opensource) Bazujący na Qt 5.4.1 (GCC 4.6.1, 64 bitowy)
Target TI Sitara AM35xx ARM 1Gh i 512MB RAM
Platforma ? po prostu linux embedded z dystrybucją Angstrom, o ile coś mi się nie zmieni i zrezygnuje z dystrybucji, ale raczej ją zostawię. Ja będę pisał programy daemony obsługujące takie interace jak UART, SPI, I2C urządzenie, z kolei one posłużą aplikacji natywnej (WEB) która będzie głównym interacje dla użytkownika logującego się poprzez przeglądarkę do urządzenia.

0

Apropoo konfiguracji i debug zdalnego nie można tego zrobić takim prostym sposobem

https://www.olimex.com/forum/index.php?topic=3826.0

Dziękuje za linki, ale jest w nich strasznie dużo informacji i nie wiem czy to wszystko jest mi potrzebne :) Ja po prostu potrzebuje skrosować aplikacje i przesłać ją na target , a jakby mi się jeszcze udało jakoś zdalnie podejrzeć poprzez qDebug(), czyli w Hoscie bym widział co się dzieje jak ona działa tnz co wysyła po UART, I2C to by było mistrzostwo świata.

ps przepraszam za dubla, ale nie mogę edytować

0

Nie znam Twojej platformy i nie jest w dodatku na liście oficjalnych. Z tego co wiem Ångström może spokojnie wystawić ssh i zrobisz przez niego deploy (http://doc.qt.io/qtcreator/creator-deployment-embedded-linux.html#deploying-on-embedded-linux). Sesję debug także otworzysz przez tryb remote debug (http://doc.qt.io/qtcreator/creator-debugger-operating-modes.html).
Co do tutoriala to myślę że "ogarniesz temat" jak zobaczysz sobie to: http://www.qtday.it/2014/developing-embedded-linux-applications-qt/
Trudno podać jakiś generyczny tutorial bo każda z platform jest inna :-/
Dość że czeka Cię walka :-)

0

Taaa angstrom ma ssh, ftp, http i jeszcze wiele innych mistycznych rzeczy które dopiero odkrywam i właśnie doszedłem już do etapu w którym w qt pisało Deploy 2 with 3 steps i prawie już otwarłem szampana, ale niestety na tym się zatrzymało.... :( Później kolega mi powiedział, że coś grzebał przy ustawieniach serwera ftp więc może to było to. Będę w każdym razie walczył z tym. Proszę Cie, abyś jeszcze coś napisał odnośnie Qt-Embedded. Rozumiem, że do tego trzeba mieć już komercyjną wersję ? Z tego co widziałem dostarcza ona banalny sposób do tworzenia interface na TFT (przyciski , suwaki, polaedycji itp). Zakładam zatem że przy pomocy Qt-Creatora nie jest możliwe tworzenie tego typu rzeczy, do tego jest potrzebne xml dostarczone z Qt-Embedded ?

1
  1. W dużym uproszczeniu (bo w szczegóły nie warto wchodzić jak masz w doc.), wersja Community Edition nie zawiera części kontrolek dostępnych w wersji komercyjnej ale tu masz zatrzęsienie tak aplikacji jak i kontrolek: http://qt-apps.org/?xcontentmode=4298 wolnych
  2. Wersja GPL wymaga budowania na platformy embedded ze źródeł bo obrazów dla urządzeń nie ma. To zawsze poświęcony czas.
  3. Spokojnie jak sobie zbudujesz bibliotekę to możesz obsługiwać kontrolki na TFT. Problem leży tylko w dobrej obsłudze tegoż TFT a ja twojego sprzętu nie znam. Powiem tak, szukaj w TI.
    Jak nie znasz Qt, to warto tego Pana sobie posłuchać... robi stosunkowo niewiele błędów (np. przy wielowątkowości pojechał tylko w krzaki aż "zęby bolały" ale ogólnie jest ok) Tylko to nie jest embedded tylko aplikacje głównego nurtu.

Myślę że źródeł dostałeś tyle że możesz przez tydzień czytać i oglądać ;-)

1

vim.

0
Mokrowski napisał(a):
  1. W dużym uproszczeniu (bo w szczegóły nie warto wchodzić jak masz w doc.), wersja Community Edition nie zawiera części kontrolek dostępnych w wersji komercyjnej ale tu masz zatrzęsienie tak aplikacji jak i kontrolek: http://qt-apps.org/?xcontentmode=4298 wolnych
  2. Wersja GPL wymaga budowania na platformy embedded ze źródeł bo obrazów dla urządzeń nie ma. To zawsze poświęcony czas.
  3. Spokojnie jak sobie zbudujesz bibliotekę to możesz obsługiwać kontrolki na TFT. Problem leży tylko w dobrej obsłudze tegoż TFT a ja twojego sprzętu nie znam. Powiem tak, szukaj w TI.
    Jak nie znasz Qt, to warto tego Pana sobie posłuchać... robi stosunkowo niewiele błędów (np. przy wielowątkowości pojechał tylko w krzaki aż "zęby bolały" ale ogólnie jest ok) Tylko to nie jest embedded tylko aplikacje głównego nurtu.

Myślę że źródeł dostałeś tyle że możesz przez tydzień czytać i oglądać ;-)

Qt znam dosyć dobrze tak samo jak i tego Pana. Qt znam pod względem aplikacji GUI na PC. Co do tego gościa to wiele razy już go słucham i wiele razy już mi pomógł bądź podsunął rozwiązania :)

Mógłbyś rozwinąć ten poniższy pkt bo nie rozumiem ? Trzeba na platformie (target) umieścić pewnie biblioteki czy jak ? Zbudować coś na targe-cie, żeby aplikacja pod qt działała ?

  1. Wersja GPL wymaga budowania na platformy embedded ze źródeł bo obrazów dla urządzeń nie ma. To zawsze poświęcony czas.

ps Bardzo się cieszę, że znalazły się osoby które znają się na temacie. Dziękuje za porady.

Co do vim to chyba podziękuje....

1

Na platformie docelowej może nie być zbudowanego zestawu bibliotek qt. Należy wtedy skompilować te biblioteki ze źródeł. Jeśli będziesz to robił na docelowej platformie to... możesz budować to 2 dni albo dłużej :-/ (nie żartuję). A po 1 dniu otrzymać informację że coś jest "nie halo" :-/ Nie radzę, chyba że z ciekawości (na Raspberry Pi budowało się 3 dni). Lepiej zrobić to poprzez kompilację krzyżową na maszynie silniejszej, z użyciem toolchaina platformy docelowej (w Twoim przypadku kompilator do do Arngstrom'a). W filmiku który Ci podsunąłem, masz właśnie to podejście. Ja biblioteki buduję w klastrze z użyciem dictcc i ccache. Po 1h. mam od źródeł do binarki :-)

No i jeszcze ważna informacja. Jeśli jednak chcesz zbudować aplikację ze zintegrowanymi bibliotekami (kompilacja z bibliotekami statycznie linkowanymi), łamiesz licencję Qt. Nie wolno Ci wtedy takiej aplikacji dystrybuować. Ale to już raczej ważne jak będziesz chciał sprzedawać rozwiązanie.

0

Yhmmmm... Chyba kumam. Tutaj chodzi o skrosowanie pod arm takich bibliotek jak np QtCore , a pod linux to będzie libQt5Core.so.5.4.1 w zależności co użyjemy w projekcie i te biblioteki należy przerzucić do docelowego systemu na target. Na normalnych PC, aby działał program na "cudzym" PC trzeba było do *.exe , albo do binarki poodrzucać to o co płakał system tutaj analogicznie :)
Powiedz mi taką rzecz. Piszesz o użyciu kompilatora a Angstroma, ale dlaczego nie można użyć kompilatora typu
http://crosstool-ng.org/
Przecież tutaj chodzi o architektura a tą jest arm, więc co za różnica jakim kompilatorem przekrosuje to, tak samo na stronie TI kompilator do krosowania jest od Linaro ? Skąd ta różnorodność i po co ? Tego jeszcze nie ogarniam, bo widziałem, że w qt właśnie powinno się wskazać na kompilator z angstrom a nie "typowy" np arm-unknown-linux-gnueabi-g++,gcc

Ps człowieku , ile Ty mi czasu zaoszczędziłeś swoimi odpowiedziami, nawet nie masz pojęcia , dzięki Tobie klaruje mi się lepiej obraz całego mechanizmu tworzenia aplikacji na arm. Naprawdę serdecznie dziękuje za pomoc :)

0

ARM licencjonuje wyłącznie arch. rdzenia procesorów. Ma ich wiele rodzai. Np. rodzina mikrokontrolerów to M, procesory aplikacyjne A a do zastosowań czasu rzeczywistego R. W każdej z nich są jeszcze podrodziny np. Coretex-M0+ (bardzo małe i bardzo tanie mikrokontrolery), ... M3, Coretex-M4F (nieco droższe z koprocesorem zmiennoprzcinkowym - pojedyncza precyzja), A7, A9 aplikacyjne.
Do tego rdzenia, każdy z producentów (np. Texas Instruments, Cypress, Freescale, STM) dodaje swoje własne peryferia. Czyli każdy system może mieć nieco inne elementy (jeden ma zegar czasu rzeczywistego, inny nie, jeszcze inny może być uśpiony przy poborze prądu na poziomie ųA a następny ma akcelerację dla przetwarzania sygnału). Stąd kompilator i toolchain dobierasz taki, jaki zaleca producent.
Ja to uprościłem ale pisać elaboratów nie ma co.... Drugim powodem jest określony zestaw bibliotek w systemie (w tym przypadku GNU/Linux).
Stosuj toolchain zalecany. Bo z generycznym będziesz walczył i tracił czas. Czy jednak można? No można ale ... po co? :-/

0

Teraz już rozumiem, tą różnorodność. Myślę, że póki co w temacie wszystko dla mnie zostało wyjaśnione. Przede mną długa walka, ale jakże exytująca ? :) Dziękuję jeszcze raz za wszystkie informacje, są niesłychanie przydatne i pozwalają mi szybko określić całokształt tego czym się zajmuje. Myślę, że ten temat jest wyczerpany.
Pozdrawiam :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1