Hallo, wir müssen bei einer Neuentwicklung für einen Kunden auf Embedded Linux umsteigen. Es soll ein Gerät mit Touch-Display, Internetfähig entwickelt werden. Nachfolgend einige der genannten Stichworte Embedded Software: Treiber, Embedded Betriebssystem (Linux, Segger), Firmware, CAN, SPI, Sound Frameworks: Embedded Linux, Device Drivers, Microcontroller, C, C++ o Applikation am Embedded System: GUI, Abläufe, Filesystem Handling (Config-Dateien), Threading, TCP/IP Umgang mit Entwicklungsumgebungen, Debuggern und Programmiererfahrung in C liegt vor, allerdings überhaupt keine Erfahrung mit Linux. Daher fällt es mir schwer, den Zeitaufwand zur Einarbeitung abzuschätzen. Vielleicht kann jemand aus eigener Erfahrung in etwa eine realistische Zeiteinschätzung nennen. Vielleicht gibt es auch empfehlenswerte Quellen oder Schulungen ? Bei der Vielfalt der Infos im Internet verliert man etwas den Überblick, was wirklich zum effektiven Einarbeiten taugt. In München z.B. gibt es einige Schulungszentren, wobei die Lehrgänge allgemein relativ teuer sind und schwer abschätzbar ist, was diese wirklich bringen.
Zur Applikation: Da habt Ihr zwei Alternativen - entweder Android nehmen oder QT. Android ist nochmal eine weitere Schicht auf dem Linux drauf und vielleicht noch etwas komplexer. QT deckt Euch schon mal eine ganze Menge ab, von der GUI über Netzwerk, Touch Einbindung, etc pp. Wenn Ihr alles nutzen wollt, braucht Ihr eine Hardware mit OpenGL eingebaut. Darauf müsst Ihr achten! QT ist ansonst das gleiche QT wie auf dem Desktop. Kernel-Anpassungen und so würde ich rausgeben oder zukaufen. Ein halbes Jahr ist denke ich für dieses Thema nicht untertrieben. fchk
Ohne jegliche Erfahrung ist das wirklich ein ganzer Brocken. Ich kann mal ein paar weitere Themen auflisten, die ggf. beim Googlen hilfreich sind: > Treiber, Embedded Betriebssystem (Linux, Segger), > Firmware, CAN, SPI, Sound Für Treiberentwicklung sollte man sich "The Linux Kernel Module Programming Guide" ansehen ( http://www.tldp.org/LDP/lkmpg/2.6/lkmpg.pdf ) und es gab auch eigentlich immer ein Buch über die Linux Kernel entwicklung von Addison Wesley. Zum Ansteuerung von manchen Dingen unter Linux ist "ioctl()" ein guter Kandidat wo man loslegen kann zu suchen. Details zu SPI u.A. in der Kernel-Dokumentation zu finden: https://www.kernel.org/doc/Documentation/spi/spi-summary > Frameworks: Embedded Linux, Device Drivers, Microcontroller, C, C++ Für Zeitkritisches wird üblicherweise RTLinux verwendet. > GUI, Abläufe, Filesystem Handling (Config-Dateien), Threading, TCP/IP Wenn man C++ nicht zu sehr scheut, sollte man sich hier ggf. mal Qt ansehen. Das ist eine seit den 90ern entwickelte frei verfügbare GUI Bibliothek welche auch sehr viel Kram für alltägliche Aufgaben mit bringt (Filesystem Handling, Threading, TCP/IP, HTTP, PDF erzeugung, uvm.). Dafür gibts sowohl komerzielle als auch freie Lizenzmodelle. Ansonsten sollte man sich bei C++ evtl. mal boost ansehen und POCO. Dringend rate ich dazu auch einmal ein paar Administrations HOWTOs zu ergooglen und ggf. ein paar Bücher dazu. Zeitaufwand für die Einarbeitung hängt ganz von den Zielen ab und wie Marktreif das Produkt werden soll. Man sollte definitiv wissen wie man Linux richtig aufsetzt und konfiguriert, damit es im embedded Betrieb nicht zu Problemen kommt. Hier gibts aber auch schon Distributionen die einen da weiterhelfen und schon für Embedded ausgelegt sind. Insgesamt ist es aber alles eher in den Griff zu bekommen als bei Microsoft Windows. Linux is da oft wesentlich transparenter.
Wem die Lehrgänge zu teuer sind, wird bei den Qt Lizenzkosten auch nicht glücklich.
Dumdi D. schrieb: > Wem die Lehrgänge zu teuer sind, wird bei den Qt Lizenzkosten auch nicht > glücklich. Qt ist umsonst wenn man nicht statisch linkt soweit ich mich entsinne. Korrektur, du hast recht: > 2.19. Do I need to have a distribution > agreement to develop an embedded device with Qt? > Yes. A distribution agreement explaining the terms for distributing > the Qt libraries is included in your Qt license agreement. > When you create an embedded device you typically > have ‘joint hardware and software distribution’, > which is subject to a distribution fee, > please contact us for more information. https://www.qt.io/faq/#_Toc_2_19
:
Bearbeitet durch User
Moin, ich unterschreibe die vorgehende Aussage auch mal mit. Von den diversen Schulungen halte ich generell nicht so viel, mit dem dort meist vermittelten gefährlichen Halbwissen kommt man dann oft konkret nicht weiter. Besser die Experten für einen Workshop einkaufen und Knowhow-Transfer und Arbeitspaket für z.B. Kerneltreiber in Einem erschlagen. Ansonsten gibt es immer mehr Firmen, die zu ihrer More-Modul Hardware fertige board supply-Packages anbieten, inkl. Build-systeme, wie Buildroot, OpenEmbedded, usw. - da muss man sich dann das Paket seines Geschmacks halt etwas suchen. Für einen ersten Prototypen führt der Ansatz mit einem Coremodul recht schnell zum Erfolg. Für dein skizziertes System hätte ich jetzt z.B. als erstes mal bei Phytec, FS, oder ACME reingeschaut. Man kann auch immer mal FAEs mit konkrekten Fragen quälen :-)
Richard B. schrieb: > Vielleicht kann jemand aus eigener Erfahrung in etwa eine realistische > Zeiteinschätzung nennen. Nicht mit den paar sehr generischen Stichworten. Wichtig zu wissen ist: Welche Plattform verwendet ihr: Ist das eine modulbasierte Lösung von einem etablierten Hersteller, der selber schon ein Linux für seine Module bereitstellt? Oder ist das eine Eigenentwicklung mit einem pfuschneuen Prozessor, dessen Hersteller sich nicht für Linux interessiert und für den man erstmal grundlegende Portierungsarbeiten machen müsste... Das ist ein riesiges Spektrum, was den potentiellen Arbeitsaufwand angeht. Wenn die Hardware noch nicht festgeklopft ist, hat man gute Chancen, durch clevere Komponentenauswahl viel Entwicklungszeit einzusparen. > Vielleicht gibt es auch empfehlenswerte Quellen oder Schulungen ? > > Bei der Vielfalt der Infos im Internet verliert man etwas den Überblick, > was wirklich zum effektiven Einarbeiten taugt. > > In München z.B. gibt es einige Schulungszentren, wobei die Lehrgänge > allgemein relativ teuer sind und schwer abschätzbar ist, was diese > wirklich bringen. Wollt ihr schnell zum Ziel kommen? Oder in-house know-how aufbauen? In ersterem Fall sucht euch einen Dienstleister. Neben der Anpassung des Linux-Kernels an eure Hardware-Plattform gibt es dann natürlich noch die Applikationsentwicklung. Da gibt es neben Android und QT durchaus noch weitere Optionen, das sollte aber abhängig von Euren Rahmenbedingungen evaluiert werden. Viele Grüße, Simon
Hallo, ich hätte ein paar Fragen: - was soll das ganze System machen (ständig mit dem Netzwerk verbunden sein, Usereingaben per Netzwerk übertragen, ausgewählte Infos aus dem Netzwerk anzeigen) - nur kurze Beschreibung - wie sieht es denn preistechnisch bei der Hardware aus? Wie viel sollte ausgegeben werden? Wo ist das Limit? - werden mehrere solcher Systeme benötigt oder nur 1 für einen Kunden? - Kommt ein Raspberry Pi oder ähnliche HW gar nicht in Frage? Dafür gibt es auch verschiedene OS, unter anderem Embedded OS. Was würde dagegen sprechen? Ich habe zwar keine Erfahrung in Schätzungen wie lange das Anlernen dauern würde (da ist jeder individuell), aber ich würde für die GUI GTK+ bzw. Gtkmm 3.0 mit Verbindung von C++ empfehlen. Das habe ich mir selbst innerhalb von kürzester Zeit beigebracht und konnte nach wenigen Tagen grafik- bzw. Gui-technisch schon ne ganze Menge (Buttons, formatierte Labels, Eventhandling, Kurven und weitere 2D-Objekte zeichnen + Positionen verändern). Das ganze dann innerhalb von Netbeans zu entwickeln ist ziemlich angenehm. Der Vorteil eines Raspberrys ist dann auch noch dass man alles individuell einstellen kann: z.B. nach dem Booten das Programm direkt starten (im Vollbildmodus) und dann läuft das Ding einwandfrei. Mit der Steuerung der GPIO's kann man dann direkt im Betrieb die Signale verarbeiten, wie man möchte (falls gewünscht). Ausgabe kann dann auf ein Touchscreen erfolgen (es gibt viele verschiedene Modelle mit verschiedenen Größen). Mit einer Zeile in der config.txt Datei kann man die Ausrichtung bestimmen.
Strubi schrieb: > Ansonsten gibt es immer mehr Firmen, die zu ihrer More-Modul Hardware > fertige board supply-Packages anbieten, inkl. Build-systeme, wie > Buildroot, OpenEmbedded, usw. - da muss man sich dann das Paket seines > Geschmacks halt etwas suchen. Die Firma bei der ich arbeite hat sich vor einigen Jahren auch so ein Embedded-System von einer Firma machen lassen. Gleich zusammen mit Frontpanel mit Folientastatur, Matrix-Display und RFID-Kartenleser. Hinten drin lief ein Linux das von einer CF-Karte dann shell-Scripte ausgeführt hat. Wir haben die Hardware dann zusammen mit einem Entwicklerpaket (Linux, Buildroot Entwicklungsumgebung für Windows, C-Bibliothek zum Ansteuern des Displays und der Tastatur usw.). Leider is das ganze jetzt schon einige Jahre her und die Firma kann die Dinger nicht mehr (kompatibel) Produzieren, obwohl die noch produktiv beim Kunden im Einsatz sind. (Haben aber zum Glück noch einige im Lager).
> Umgang mit Entwicklungsumgebungen, Debuggern und Programmiererfahrung in > C liegt vor, allerdings überhaupt keine Erfahrung mit Linux. Dann solltest ihr das lassen. Ihr braucht mindestens einen Typen der Linux auf Gurulevel drauf hat und mehrere andere bei denen ihr akzeptiert das sie fuer einige Monate nur 50% der sonstigen Leistung zeigen weil sie halt noch lernen muessen. Falls dir die Antwort nicht gefaellt, ueberleg dir mal wie es umgekehrt waere: Ihr seid eine Firma wo jeder krass viel Ahnung von Linux hat aber noch nie von Windows gehoert habt und dann willst du eine Windowsanwendung programmieren. Dann hast du eine ungefaehre Vorstellung was da auf einem zukommt. Natuerlich lernt man dann als erfahrener Entwickler schneller als ein Doedel frisch von der Uni, aber es muss auch jemand da sein der Wissen vermittelt und gleich zu anfang eine sinnvolle Richtung vorgeben kann. Olaf
Olaf schrieb: > Ihr braucht mindestens einen Typen der > Linux auf Gurulevel drauf hat und mehrere andere bei denen ihr > akzeptiert das sie fuer einige Monate nur 50% der sonstigen Leistung > zeigen weil sie halt noch lernen muessen. So hart wollte ichs nicht ausdrücken. Aber das wäre natürlich das beste. Ein neues System vollständig in den Griff zu bekommen ist nicht durch ein paar Schulungen eben mal zu lernen. Da braucht man leider, wie bei Windows auch, echte aus Fehlern angeeignete Erfahrung. Üblicherweise holt man sich sowas auf dem Arbeitsmarkt. Senior Entwickler für Embedded Linux mit min. 5 Jahre Berufserfahrung und einer schönen Liste an Projekten aufm Lebenslauf. Schulungen sind auch nicht billig. Dabei spreche ich nichtmal von den Schulungsgebüren selbst, sondern davon dass die Entwickler die dort sitzen nicht an Projekten sitzen können. Bei 5 Entwicklern, und 1000€/Tag/Entwickler kommt man bei einer zweiwöchigen Schulung schnell auf 50k€ und mehr. Und danach haben sie erstmal nur grobes Fachwissen, aber keine echte Erfahrung. Da kann man sich gut überlegen ob es nicht lohnt jemanden für 80-100k€/Jahr einzustellen.
> So hart wollte ichs nicht ausdrücken.
Die Alternative sind dann Ergebnisse wie manche DVB-T Empfaenger oder
Router wo man einmal die Woche die Resettaste druecken muss,
verdreifachte Projektlaufzeiten, wochentliche Firmwareupdates und
regelmaessige Erwaehnung in der C't in der 'mal wieder gehackt' Rubrig.
:-)
Olaf
Richard B. schrieb: > wir müssen bei einer Neuentwicklung für einen Kunden auf Embedded Linux > umsteigen. Es soll ein Gerät mit Touch-Display, Internetfähig entwickelt > werden. > > Nachfolgend einige der genannten Stichworte > Embedded Software: > Treiber, Embedded Betriebssystem (Linux, Segger), Firmware, CAN, SPI, > Sound > Frameworks: Embedded Linux, Device Drivers, Microcontroller, C, C++ > o Applikation am Embedded System: > GUI, Abläufe, Filesystem Handling (Config-Dateien), Threading, TCP/IP Deine Informationen sind ziemlich dünn, insbesondere hinsichtlich der in Eurem Hause vorhandenen Vorkenntnisse im Betriebssystem- und da besonders im UNIX-Umfeld. Daher kann eine Antwort auf Deine Fragen natürlich auch nur oberflächlich und allgemein bleiben. Was Linux selbst angeht, kann ich folgendes Buch [1] sowie die Webseiten [2,3] empfehlen. Die Webseiten sind zwar für die Debian-Distribution gedacht, passen aber auch für Systeme die auf Debian basieren, wie die Ubuntu-Familie, Linux Mint, Raspbian, und verschiedene andere. In Bezug auf die Treiberentwicklung ist das Buch [4] heute das Standardwerk. [1] https://kofler.info/buecher/linux/ [2] http://debiananwenderhandbuch.de/ [3] https://debian-handbook.info/browse/de-DE/stable/ [4] https://www.dpunkt.de/buecher/12176/Linux-Treiber%20entwickeln.html
Robin R. schrieb: .. > > Leider is das ganze jetzt schon einige Jahre her und die Firma kann die > Dinger nicht mehr (kompatibel) Produzieren, obwohl die noch > produktiv beim Kunden im Einsatz sind. (Haben aber zum Glück > noch einige im Lager). Das ist halt das grosse Problem, wenn es günstig sein soll, hat man meist auch die Garantie der Verfügbarkeit a la industriell nicht. Es gibt da auch sehr wenige Modulhersteller, die ernsthaft 10 Jahre garantieren können (und manche gehen trotz allem vorher pleite...), oder der Hersteller der CPU wird mal eben gekauft und der Fokus ändert sich. Unterm Strich ist das Geschäft sehr volatil geworden. Trau, schau wem... Diesbezüglich ist Linux ansich eine gute Entscheidung, da muss man wenigstens die SW nicht komplett neu schreiben. Die kostet definitiv mehr Aufwand als die HW. Unterm Strich sollte man sich schon im Klaren sein, dass Linux von der Wartung her nicht unbedingt günstiger ist als bare metal, weil es einfach zuviel kann. Das kann für ne Dreambox gewollt sein, für eine IoBS-Alarmanlage aber eher nicht.
com/sbc mit board support package nehmen (rpi cm3, opossom, beaglebone black mit buildroor, yocto, openembedded) Pass auf ob das ding sich autoupdaten soll.. Einiges geht dann schon auf einem relativ hohem level (tcp/ip, i2c, spi usw.) Vielleicht auch einfach python anschauen? die haben eine super threading lib. Hilft natürlich auch eine ähnliche linux Distro am Entwicklerrechner laufen zu haben. zur gui: qt (in c++ oder python), tkinter
Für Entwickler empfehle ich, sich Linux auf den heimischen PC/Laptop zu installieren, um den Umgang damit zu lernen. Dann aber auch bitte möglichst alles (außer Spielen) unter Linux machen. Debian deswegen, weil es am besten dokumentiert ist und zahlreiche andere Linux Distributionen davon abgeleitet sind. Wer Debian kennt, kommt mit anderen Linux Distributionen in der Regel gut zurecht. Und Programme, die für Debian compiliert wurden, laufen meistens ohne Änderung auch auf andere Distributionen.
Und wenn man sich dann auf einem PC mit linux vertraut gemacht hat, geht man zu einem Raspberry Pi, und schaut wie man damit zurecht kommt.
Der Tipp jemanden der weiß wie es geht zu bezahlen (am besten einstellen) ist Gold wert. Mit Linux bekommt man ein vollwertiges Großrechner-Betriebssystem, dass dank des Technischen Fortschritts mittlerweile überall läuft. Linux kann viel und der größte Fehler beim Einführen von Linux ist nicht zu nutzen was Linux kann, sondern entweder separat, drumherum oder sogar gegen das Betriebssystem zu arbeiten. Zum Beispiel habe ich schon ein paar mal gesehen, dass offiziell Linux verwendet wurde - aber nur als Loader um ein einziges fettes Alles-in-einem-Binary zu laden. Typisch für Leute die Freestanding-Environments gewohnt sind und die keinen Bock haben sich mit Linux zu befassen. In dem Binary wird dann versucht "irgendwie" Dinge pseudo-parallel laufen zu lassen, Memory zu verwalten und natürlich an allen Betriebssystem-Funktionen vorbei direkt auf Hardware zu schreiben. Sowas stürzt dann regelmäßig ab und der Ober-Hacker, der bestimmt hat dass man das so zu machen hat, hat einen Pseudo-Grund mehr rumzunörgeln das Linux nichts taugt. Leseempfehlung für das grundsätzliche Systemprogrammieren auf Unix (incl. Linux und unabhängig ob embedded oder nicht): https://www.amazon.de/Programming-Environment-Addison-Wesley-Professional-Computing/dp/0321637739 Leseempfehlung speziell für Netzwerk-Kommunikation unter Linux (das wird gerne von Anfängern so versaut, dass man im Strahl kotzen muss): https://www.amazon.de/Unix-Network-Programming-Sockets-Networking/dp/9332549745/ Wenn man schon nicht lernen will wie es wirklich funktioniert kann man aus den Büchern wenigstens die Rezepte abschreiben. Nicht so toll ist https://www.amazon.de/Linux-Device-Drivers-Jonathan-Corbet/dp/0596005903 (gibt es aber legal zum kostenlosen Runterladen https://lwn.net/Kernel/LDD3/). Einiges ist veraltet weil sich im Kernel schneller Dinge ändern als man "make" sagen kann. Sogar vor den Änderungen war das Buch nie vollständig, aber es ist immer noch besser als nichts.
Der Aufwand für die Einführung hängt maßgeblich von zwei Faktoren ab: 1. wie viel Linux könnt ihr 2. wie viel Linux wollt ihr Da ersteres schon mit "so gut wie keine Kenntnisse vorhanden" beantwortet wurde, stimme ich meinen Vorpostern uneingeschränkt zu und empfehle euch dringend jemanden einzustellen, der das entsprechende Know-How mitbringt. Wie viel er mitbringen muss hängt zweifellos von 2. ab. Natürlich besteht auch immer die Möglichkeit sich Know-How von externen Dienstleistern einzukaufen aber das kann unter Umständen sehr schnell sehr teuer werden und sorgt garantiert für Frust, wenn man an einer Kleinigkeit festhängt, die der Kollege am Schreibtisch gegenüber in zwei Minuten gelöst hätte und man stattdessen erst wieder den Externen anrufen muss und der unter Umständen gar nicht erreichbar ist, obwohl man ihn gerade am dringendsten bräuchte. Zu 2.: Wirklich sehr viele Sachen sind schon da und funktionieren "Out-of-the-Box", d.h. man muss nicht noch erst eigene Treiber entwickeln. Nehmt ihr Hardware, welche bereits vollumfänglich unterstützt wird, ist da der Entwicklungsaufwand nahezu Null. Stacks für CAN, TCP/IP, etc. sind alle vorhanden. Hier ist die Frage auf welcher Ebene ihr mit diesen Stacks arbeiten wollt. Braucht ihr einen Webserver ist der mit Python oder Go viel schneller am laufen als wenn ihr mit C und BSD-Sockets an die Sache heran geht. Da ist halt die Frage wie viel Zugriff ihr braucht. Noch wichtiger ist aber die Frage ob ihr eigene Treiber für die Hardware schreiben müsst und die Frage ob es ein RT-Kernel werden soll. Das Kriterium RT-Kernel schränkt sowohl die Hardware-Auswahl bei den Prozessoren etwas ein und bringt zum anderen evtl. den einen oder anderen Treiberbug zum Vorschein, der in einem konventionellen Kernel nicht so aufgetreten wäre. Nur mal so als Beispiel: Ihr könnt ein Beaglebone nehmen, einen fertiges Can-"Cape" draufsetzen (z.B. http://www.caranea.com/hardware/bbb-can-cape), einen 08/15 Touchscreen (z.B. https://www.sparkfun.com/products/12086) anschließen und unter der Voraussetzung, dass es bei den IOs keine Überschneidungen gibt (was ich nicht geprüft habe), habt ihr an einem Nachmittag euren Prototypen am laufen. Ein kleines Python-Programm was per Touchscreen-GUI verschiedene Pakete auf den CAN-Bus schickt (per SocketCAN), diese gleichzeitig in einer Log-Datei speichert und sich auch per TCP/IP steuern lässt, ist ebenfalls schnell gemacht. Damit wären alle eure Punkte (CAN, Internet, Filesystem, Touchscreen) abgedeckt, ohne den Kernel überhaupt angefasst zu haben. Für eine Person, die sich ein bisschen mit Python, CAN und BSD-Sockets auskennt, sowie der englischen Sprache mächtig ist, würde ich die Entwicklungszeit für ein solches "Proof-of-Concept" mal konservativ auf eine Woche schätzen (natürlich macht Python für ein "richtiges" Produkt nicht viel Sinn, es soll nur als Beispiel dienen). Wollt ihr aber unbedingt diesen oder jenen AD-Wandler, für den es noch keinen Treiber gibt und außerdem alles möglichst in Echtzeit und möglichst auf einem nVidia-Tegra und außerdem wollt ihr noch einen bestimmten Touchscreen-IC, wofür ihr ebenfalls noch einen Treiber schreiben müsst, dann sind fünf Mannjahre weg wie nichts bis ihr einen lauffähigen Prototypen habt. Ich vermute mal eure Anforderungen werden irgendwo zwischen diesen beiden Extrembeispielen liegen. Um überhaupt mal einen Einblick zu bekommen, wie man einen eigenen Kernel kompiliert und eigene Treiber schreibt kann ich das (leider mittlerweile schon etwas veraltete) Buch "Embedded Linux lernen mit dem Raspberry Pi" von Jürgen Quade empfehlen (https://www.amazon.de/dp/386490143X). Der Autor beschreibt kurz und knapp alle wichtigen Schritte und Grundlagen, angefangen von der Partitionierung über das Dateisystem bis hin zum Laden eines Kernels mittels U-Boot, der eigentlichen (Cross-)Kompilierung des Kernels, sowie dem schreiben eigener Treiber. Ein Blick ins Buch bei Amazon und Co. schadet sicher nicht und beim Verlag selber kann man das Buch auch als DRM-freies PDF bekommen. Von Herrn Quade gibt es auch noch weiterführende Literatur zum Thema Linux Kernel-Treiber, die ich jedoch selber noch nicht gelesen habe. Ein weiteres interessantes Buch, was ich persönlich ebenfalls nicht gelesen habe aber was einen guten Eindruck macht und etwas aktueller ist, ist "Embedded Linux mit Raspberry Pi und Co" (https://www.amazon.de/Embedded-Linux-Raspberry-mitp-Professional/dp/395845061X). Noch so als letzter Tip: Die Wahl des Prozessors ist mit entscheidend dafür wie viel Ärger ihr in Zukunft mit der Wartung/Aktualisierung eures Systems haben werdet. Hervorragende Unterstützung gibt es z.B. für Intel, TI AM335x oder i.mx6 von Freescale. Die letzteren beiden bringen auch eine CAN-Schnittstelle und IEEE 1588 mit und haben eine von den Herstellern garantierte Verfügbarkeit über mehrere Jahre. Dev-Boards und Module sind allgemein gut verfügbar und auch RT-Kernel werden für beide gepflegt. Von nVidia oder gar Allwinner, Rockchip und Co. würde ich unbedingt die Finger lassen.
Leute nehmt euch jedenfalls viel Zeit. Wenn die Hardware eine Eigenentwicklung ist dann muss der Linux Kernel dafür angepasst werden und Treiber geschrieben werden. Ihr müsst euch zuerst mal eine Entwicklungsumgebung schaffen, am besten ein NFS wo ihr den neu compilierten Kernel (Module) hin kopiert könnt. Zusätzlich braucht ihr einen PC zur Cross Compilierung von Kernel und und Applikations Software. Das Debugging ist die nächste Herausforderung, für Applikationen wird das mit dem GDB gehen, beim Kernel ?. Als nächstes kommt dann noch wie das Filesystem Layout aufgebaut wird, und das Update.Wenn alles mal steht ist die Entwicklung sicher super mit MMU und Segemntation Fault anstatt unbekannter Absürtze, jede Menge Ram und die SW kann gut struckturiert und in Prozesse oder Threads aufgeteilt werden, sogar Java kann verwendet werden. Wenn ich Segger lese dann kenne ich von dort nur die Emwin Grafiklib soll die eingestetzt werden? QT ist leistungsfähiger. Das RTOS von Segger wird bei einem Linux Betriebssystem ja nicht zu Einsatz kommen. Es besteht natürlich auch noch die Möglichkeit Android zu verwenden. Meiner Meinung nach wesentlich mehr Aufwand als eine Entwicklung mit FreeRTOS und LWIP aber dafür auch wesentlich leistungsfähiger auf lange Zeit gesehen.
Richard B. schrieb: > Es soll ein Gerät mit Touch-Display das ist ein sehr weites Feld und hier solltet Ihr die Anforderungen von Anfang an sauber festklopfen: Wird eine "einfache" Touch-GUI mit Anzeige von etwas Text, einfachen Datenanzeigeelementen (z.B. Tacho, Füllstand, Barchart,...) und ein paar angezeigten Knöpfen gewünscht? Oder muss das Ding von der Bedienung her das können, was man von aktuellen Smartphones gewohnt ist? Also Multitouch, Pinch-to-zoom, Scrollgesten,... Da liegen Welten an Hardwareanforderungen und Entwicklungsaufwand dazwischen. Auch die nötigen Frameworks sind unterschiedlich. Wenn der Chef den ersten Prototypen in der Hand hält und dann plötzlich Multitouch etc. fordert, fangt ihr wieder fast von vorne an. > Internetfähig Da solltet Ihr Euch auch Gedanken über längerfristiges Updatemanagement machen. Ein 5 Jahre altes Embedded-Gerät kannst Du z.B. heute nicht mehr vollständig verwenden, wenn es beim Emailversand oder Webseitenabruf keine Verschlüsselung mit >=TLSv1.0 bietet und Zertifikate mit SHA-256 versteht. Das ist heute aus Sicherheitsgründen Mindestvoraussetzung, damals haben sich die meisten Embedded-Entwickler das aber gespart weil es auch noch ohne ging. Für die PCs mit Windows > XP gibt es Updates, für viele Embedded-Geräte nicht. Die fliegen dann in die Tonne oder man muss sich mühsam nen Extra Gateway davorbauen um die noch betreiben zu können.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.