Qt och Debian eller Raspbian

Permalänk
Medlem

Qt och Debian eller Raspbian

Det finns "folk" som säger att utveckla mjukvara för Raspberry i Qt och köra i en ren Debian är bättre än att utveckla on-board i Raspbian.

Skulle vara kul och ta del av era åsikter i detta. Jag själv kör Raspbian och programmerar och kompilerar med gcc. Mest för tidsbrist och det går fort o få nåt gjort. Innan Qt/Debian används måste viss kunskap hämtas in och jag vill veta om det är värt det.
Fördelar? Nackdelar? Risker och möjligheter?

Applikationer? Läsa sensorer. Touchskärm. Styra och blinka. Webserver. Olika projekt och med olika hårdvara och komplexitet. Zero alt. standard-Rpi...

Permalänk

@Sweedland:
Så länge du skriver POSIX-kompatibel kod bör det väl bara vara att ta med sig koden och kompilera om den på den andra plattformen? Nu börjar ju Raspberries bli ganska snabba, men jag gissar att du har lite mer kräm i din vardagsburk, så det lär ju vara bekvämare att göra på det viset än att skriva allt i/för Raspbian. Enda stora fördelen med att utveckla direkt på en Raspberry är väl att du omedelbart får en känsla för hur kvickt programmet känns på målplattformen.

Permalänk
Medlem

Har kört Qt på ett par olika moduler och SBC men de har kört buildroot. Under utvecklingstiden korskompilerades det mestadels men innan faktiskt släpp i fält kompilerades det direkt på målenheten av olika skäl. Som mycket annat är det ofta summan av alla faktorer som avgör vad som är bäst för situationen. Funkar det fint för dig att kompilera på målenheten direkt så kör på det.

Permalänk
Medlem
Skrivet av Det Otroliga Åbäket:

@Sweedland:
Så länge du skriver POSIX-kompatibel kod bör det väl bara vara att ta med sig koden och kompilera om den på den andra plattformen? Nu börjar ju Raspberries bli ganska snabba, men jag gissar att du har lite mer kräm i din vardagsburk, så det lär ju vara bekvämare att göra på det viset än att skriva allt i/för Raspbian. Enda stora fördelen med att utveckla direkt på en Raspberry är väl att du omedelbart får en känsla för hur kvickt programmet känns på målplattformen.

Skrivet av Opatagio:

Har kört Qt på ett par olika moduler och SBC men de har kört buildroot. Under utvecklingstiden korskompilerades det mestadels men innan faktiskt släpp i fält kompilerades det direkt på målenheten av olika skäl. Som mycket annat är det ofta summan av alla faktorer som avgör vad som är bäst för situationen. Funkar det fint för dig att kompilera på målenheten direkt så kör på det.

Nu har jag inte arbetat i Qt och sett de direkta fördelarna. Det jag fruktar lite är att det blir blir två platser det finns intelligens på och med föränderlig intelligens så finns det versioner av dem också. Dels den dator man har Qt på och dess kompilator och version. Sen målsystemets konfigurationsfiler och inställningar samt ev. script. Det känns, utan att exakt veta, som att man får versionhantera både Qt:s miljö och även målsystemets konfigs och program.
Nu, när jag jobbar direkt i målsystemet med ansluten monitor och tangentbord/mus så kör jag en rsync till en minnessticka och på så sätt får jag en revision.

Permalänk
Medlem

@Sweedland: Sätter man målsystemet och toolchain korrekt för korskompilering ser jag inte varför det skulle behöva versionhanteras i flera olika system då programmet kompileras på arbetsstationen men sedan körs direkt på målsystemet. Poängen är att du ska programmera något som fungerar på målsystemet och inte nödvändigtvis på den platform du använder för att skriva koden.

Det är framförallt när det börjar röra sig om stora komplexa program som jag skulle undvika att använda en IDE på Raspberry av lite olika anledningar. Som den koden jag sitter och petar i nu ligger runt 380000 rader på ca 65+ filer och tar ca 38s att kompilera på en arbetsstation med Xeon. Skulle troligtvis ta över 3-4 minuter att kompilera på en Raspberry vilket är lite tråkigt.

Permalänk
Medlem
Skrivet av Opatagio:

@Sweedland: Sätter man målsystemet och toolchain korrekt för korskompilering ser jag inte varför det skulle behöva versionhanteras i flera olika system då programmet kompileras på arbetsstationen men sedan körs direkt på målsystemet. Poängen är att du ska programmera något som fungerar på målsystemet och inte nödvändigtvis på den platform du använder för att skriva koden.

Det är framförallt när det börjar röra sig om stora komplexa program som jag skulle undvika att använda en IDE på Raspberry av lite olika anledningar. Som den koden jag sitter och petar i nu ligger runt 380000 rader på ca 65+ filer och tar ca 38s att kompilera på en arbetsstation med Xeon. Skulle troligtvis ta över 3-4 minuter att kompilera på en Raspberry vilket är lite tråkigt.

Tack för dina reflektioner.

Informationen om toolchain och andra ingående detaljer blir ju lagrat i den dator som innehåller Qt. Så om man ska sätta ihop systemet igen efter 1 år så ska ju det vara lika som sista gången. Både utv.miljön och målets konfigurering. Orsaken till min fundering är att vi stöter på ibland liknande problem här när vi ska jobba med Atmel-processorer och man undrar vilken IAR-kompilator-version man hade sist och hur allt var konfigurerat.

Att ställa iordning systemet i en Raspberry inför leverans försöker jag nu göra så det är ett script som ställer in typ crontab, ID, nätverk och BlueTooth samt en del andra grejer. Det scriptet kan versionshanteras. Dock är inte scriptet 100% täckande så jag måste ialla fall göra en rsync på mer eller mindre hela RPI:n. Det är för att vara säker på att få med allt.

Jag tror aldrig vi kommer att hamna i så stora projekt så vi hamnar i den stora mängd kod du nämner. En tiondel av det du hanterar kommer vi kanske i kontakt med. Mitt största är ett på 40k rader men det är iofs tiil en Atmega.

Så jag ifrågasätter användandet av Qt som en inhouse-standard i alla lägen. Är det verkligen nödvändigt och är det en bra väg att gå? Det är visserligen mycket bra med företagsstandard bara man har gjort en bra research. Kanske man inte ska utesluta nåt utan välja det som passar för projektet? Det är väl min ståndpunkt.

Permalänk
Medlem

@Sweedland: Problemet du tar upp handlar mer om att kompilator/sdk blir uppdaterad över tid och äldre kod inte funkar att kompilera längre. Det problemet har man överallt, C# som i C på någon liten obskyr PIC10. Såvida man inte tar en fullständig backup med alla verktyg, Windows/Linux, fysisk dator osv så kommer det problemet alltid att kvarstå. Det är väl där @Det Otroliga Åbäket tips kommer väl till pass, skriv POSIX eller åtminstone ANSI/ISO kod. Då behöver man justera minimalt i koden för den nya sdk (vanligtvis GPIO/UART/Timers etc).
Klassikern är väl när Microchip gick från MPLAB 8 till MPLAB X. En sörja utan dess like. Likaså när Renesas gick från HEW till E2.

Här på företaget kör vi båda delarna (inte allt mot Raspberry utan även mot moduler med MIL-STD krav). Vissa script och program osv blir väldigt specifika till den hårdvara du arbetar mot och då jobbar man ofta direkt på den hårdvaran.

Dit jag vill komma är att det är viktigt att välja sin utvecklingsmiljö utifrån krav, behov och vad man är bekväm med helt enkelt. Är det att köra MS Visual Studio och korskompilera så gör man det, är det Qt så kör man på det istället. Fungerar det bra eller rent av krav att jobba direkt på hårdvaran så gör man det.
Att säga "det här verktyget måste du jobba i" och som standard på ett företag funkar nog jättebra när till allt utom utveckling till MCU:er. Det är i princip olika miljöer från varje tillverkare. En del har bra samarbete med företag som IAR och Keil, andra har det inte. Vissa fungerar bra med platform.io, andra inte, har sett ett par sådana "standardiseringsplatformar" komma och gå i mina dagar.

Slutsats, jag håller med dig. Det går inte att säga att Qt eller något annat ska vara standard. För det finns ingen standard när det kommer miljöer från de olika tillverkarna. Håller man sig till POSIX så minskar arbetet när bakåtkompabilitet bryts i utvecklingsmiljön.

Permalänk
Medlem
Skrivet av Opatagio:

@Sweedland: Problemet du tar upp handlar mer om att kompilator/sdk blir uppdaterad över tid och äldre kod inte funkar att kompilera längre. Det problemet har man överallt, C# som i C på någon liten obskyr PIC10. Såvida man inte tar en fullständig backup med alla verktyg, Windows/Linux, fysisk dator osv så kommer det problemet alltid att kvarstå. Det är väl där @Det Otroliga Åbäket tips kommer väl till pass, skriv POSIX eller åtminstone ANSI/ISO kod. Då behöver man justera minimalt i koden för den nya sdk (vanligtvis GPIO/UART/Timers etc).
.....

Slutsats, jag håller med dig. Det går inte att säga att Qt eller något annat ska vara standard. För det finns ingen standard när det kommer miljöer från de olika tillverkarna. Håller man sig till POSIX så minskar arbetet när bakåtkompabilitet bryts i utvecklingsmiljön.

Har tagit upp detta mer med kollegan/kollegorna och vi kommer att hålla alla vägar öppna. Utv.miljö väljs efter mål. Dit ville jag. Jag ska ialla fall sätta mig in i Qt och all dess moduler. Behöver jag verkligen alla moduler för att bara kompilera gcc? Jag vet att vi behöver snygga grafiska element senare men...

Permalänk
Medlem

@Sweedland: Jag skulle säga att om ni gör ett program idag som i framtiden kommer behöva ett grafiskt skal kanske man kan titta på att göra något form av "dll". Om det sedan anropas från ett console-program eller via grafiskt interface spelar då mindre roll. Men har man inte pysslat med (shared?) libraries tidigare får man se till tiden det tar att sätta sig in detta om det är rimlig väg att gå.