Guten Tag zusammen! Ich bin gerade in der Planung für meine Diplomarbeit. Momentan muss ich abchecken was machbar ist und was nicht. Und was ggf. für eine Diplomarbeit an der FH überhaupt in Frage kommt. Vorab sollte vielleicht noch gesagt sein, dass meine Linuxkenntnisse nicht die besten sind! ;-) Zur Auswahl steht bei einem embedded Linux (warscheinlich auf Basis des AVR32 oder TMPA 910): a) Touchscreen Treiber Soll eine Art Maustreiber werden, so das ich die Events wie eine Maus verwalten kann. Alternative Vorschläge sind immer gern gesehen. ;-) Bei der Recherche im Internet habe ich lesen können, dass es zwar einen TS Treiber gibt aber so wie es scheint nicht richtig funktioniert. b) Ethernet - Wlan Diese beiden Komponenten, die möglichst günstig sein sollen. An das eLinux anbinden und nutzen --- Was ich allerdings zu erst entscheiden muss, wann lohnt sich ein Embedded Linux und wann ein uC Lösung. Bedenkt, dass ich nur 6 Monate Zeit habe! ;-) Wovon sicherlich mindestens 2-3 Monate an Einarbeitung und 1-2 Monate an Dokumentation wegfällt. Sprich am reiner Schreibzeit habe ich vielleicht 1-2 Monate. :) LG Max
Einarbeitung sollte max. 1-2 Monate sein. Also Datenblätter lesen, Toolchains zum Laufen bringen. Grundlegende Dinge (Blockschaltbilder, etc.) und natürlich genau zu spezifizieren, was man eigentlich erreichen will. Dann kann man in ca. 2-3 Tagen die ersten Kapitel verfassen. Bei embedded Linux und auch anderen Systemen ist das aufwändigste (in der Regel) das Einrichten der Toolchain und mal das erste "Hello World" laufen lassen und zu debuggen. Für (embedded) Linux Dinge hab ich mir mal ein paar Bücher organisiert, die einen ganz guten Eindruck machen (Kernel Treiber, Kernel Internals, etc). Die Entscheidung ob man ein uC System oder einen kleinen "PC" benutzt ist an mehrere Vorraussetzungen geknüpft: - Preis - Rechenleistung - Speicherverwaltung (MMU kann manchmal hilfreich sein) - Sicherheit (statt MMU geht auch ne MPU) - Benutzerinterface bzw. eigentlich Aufgabe - Wiederverwendbarkeit (für weitere Projekte an der Hochschule) - Flexibilität (wieviele Applikationen sind mit dem System möglich) - etc. Linux gibt es einmal für Systeme mit MMU ([embedded] Linux) und als Version für Systeme ohne MMU (uC Linux). Die MMU ist für die virtuelle Speicherverwaltung und für den Speicherschutz. Systeme mit MPU sind nur in der Lage eine "Schutzverletzung" zu erkennen. Virtuellen Speicher benötigt man nicht zwingend. Wenn Du NUR einen Treiber schreiben willst, dann würde ich Dir ein Borad empfehlen, dass einen Controller (mit oder ohne MMU) drauf hat, an den Du über IO-Ports, SPI, UART, etc. was anschließen kannst. Das Board sollte eine sehr gute Linuxunterstützung haben. Also nicht das "allerneueste" sein. In deinem späteren Berufsleben wirst Du dich noch oft genug mit "Kinderkrankheiten" diverser Hardware rumschlagen müssen. Bei einer Diplomarbeit kostet dich das zuviel Zeit und Nerven! Also lieber etwas sorgfältiger wählen. Eine besonderes Augenmerk solltest Du auf die Frage legen, wie man das System debuggen kann. Also kann man mit JTAG im Signle Step durch das Programm gehen oder braucht man schon einen gdb-server oder was aufwändigeres. Der GDB im Kommandozeilen-Modus ist sehr umständlich. Evtl. hilft Dir der DDD oder was ähnliches. Für Kernel Treiber gibt es auch ein paar Besonderheiten, die man beachten sollte. Wenn Du willst, kann ich Dir mal meine Literaturliste zukommen lassen. Die Bücher sollten dafür brauchbar sein.
Embedded Linux bietet den Vorteil, dass es schon ungemein viele Anwendungen im Netz existieren, die man ggf noch anpassen kann. Auch ist es wesendlich leichter, ein Programm in Perl zu schreiben und auch direkt auf der Kiste zu editieren. Das beschleunigt die Entwicklungszeit ungemein. Wenn es zeitkritisch ist, aber nicht auf Echtzeit ankommt, kann man schnell auf C/C++ wechseln, da man ein auf dem PC erstelltes Programm recht einfach und schnell auf das andere System umstellen kann. Wenn es auf Echtzeitfähigkeit ankommt, gibt es zwar Echtzeitsysteme für Linux, je nach Aufwand der Applikation würde ich dabei aber eher auf eine µC-Lösung gehen.
Danke euch! :) @Matthias Also scheint ein reinen Treiber zu schreiben also nicht ausreichende genug? Oder nicht so aufwendig. Also Demonstration wollte ich dann auch ein kleines QT Programm schreiben. Also Board wollte ich eventuell das NGW100 nehmen. Oder halt eines von Toshiba für den TMPA910. Allerdings beim Toshiba weiß ich nicht wie das mit der Toolchain aussieht. Es soll diesen Monat eine GNU Toolchain kommen. Jo bitte gib mir die Buchtitel. Das wäre sehr hilfreich. Kennst du vielleicht auch folgendes? http://www.amazon.de/Linux-Treiber-entwickeln-systematische-Einf%C3%BChrung-Ger%C3%A4tetreiber/dp/3898643921/ref=pd_sim_b_4 LG Max
@Max: Das Buch was Du angegeben hast habe ich mir vor über 2Jahren mal gekauft, und da war es schon nicht mehr so aktuell. Das einzig positive ist, daß es in Deutsch ist. Was mich auch stört an dem Buch, daß bei einigen Sachen nur kurz von neuerungen gesprochen , aber nicht wirklich darauf eingegangen wird (z.B. devfs und die Gerätenummern AFAIR). LDD3 ist zwar auch nicht so das Aktuellste, aber meiner Meinung nach wesentlich besser (man muss blos Englisch können :D ) Beide Bücher beziehen sich aber direkt auf den Kernel, Embeddedspezialitäten gibts da eigentlich nicht. Wichtig sind bei nem Embeddedboard und I/O, wann was Konfiguriert wird.Bei manchen IO soll es so sein, daß der Bootloader schon einige Sachen umkonfiguriert (vor allem bei mehrfachbelegung der I/O) die dann nicht ohne weiteres Rückgängig gemacht werden können. Und ob ein Treiber ausreichend ist für eine Dipl.Arbeit, hängt vom Treiber ab. Wenn Du es schaffst btrfs innerhalb deine Diplarbeit stabil für den Einsatz zu machen, sollte das schon reichen ;) so far, und viel Erfolg dabei
Hm... ok... Ein bissel Zeit habe ich ja noch. Gott sei Dank. Könnte natürlich auch den Touchscreen"treiber" dann mit dem GPIO Treiber von Atmel realisieren.
Hallo, kurz zu den verlinkten Buch; wenn Du keine Ahnung von Treibern im LinuxKernel 2.6(!) hast, dann hilft Dir das Buch gut weiter (so zumindest mir). Wenn es mehr ins detail gehen soll, dann helfen die Tutorials von "Greg Kroah-Hartman" (einfach mal google anwerfen).
Scouty schrieb: > Ich bin gerade in der Planung für meine Diplomarbeit. Was ist denn überhaupt das Thema der Diplomarbeit? > Vorab sollte vielleicht > noch gesagt sein, dass meine Linuxkenntnisse nicht die besten sind! ;-) Dann wäre mir persönlich das Schreiben von Linux-Treibern zu sportlich. > a) Touchscreen Treiber Hast Du denn schon einen Touchscreen ausgesucht und dessen Datenblatt gelesen? Wird ja auch noch entsprechende Interface-Hardware zu erstellen sein. > b) Ethernet - Wlan Dito, d.h. Hardware ausgesucht, Datenblatt gelesen, Anbindung überlegt? > Was ich allerdings zu erst entscheiden muss, wann lohnt sich ein > Embedded Linux und wann ein uC Lösung. Da wir nicht Deine Anforderungen kennen, ist das schwer zu sagen. Es gibt auch speziell Touchscreens für MCs, z.B.: http://www.lcd-module.de/produkte/ediptft.html Da kann man sehr schnell was zusammenprogrammieren und erste Erfolge haben. Aber ehe ne Anwendung dann richtig fertig ist, kanns auch dauern. Es gibt auch fertige Ethernet- oder Wlan-Module mit integrierten Treibern und SPI-Anbindung, z.B.: http://www.avisaro.com/tl/index.php/avisaro-wlan-modul-20.html Peter
Das Buch gibt es auch auf https://ezs.kr.hsnr.de//TreiberBuch/html// , allerdings nur in der ersten Auflage. Als veraltet würde ich es nicht bezeichnen. Für den Einstieg müsste es reichen... also auch die Online-Version.
@Peter Hardware ist noch nicht ausgesucht worden. Privat habe ich mir das Grasshoppers + TFT + Touch von embedded projects gekauft. Leider hatte ich noch keine Zeit etwas rumzuspielen. Muss noch eine Adapterplatine bauen mit dem Boost Converter etc. Themenmässig ist noch nichts in trockenen Tüchern. Es soll wahrschreinlich eine embedded Linux System werden mit Touchscreen und ich sage mal Netzwerkanbindung. Genaueres weiß ich leider nur noch nicht. Aber eines der beiden Sachen wird warscheinlich gemacht, Touch oder Wlan. Möchte halt wissen, ob das machbar ist in 6 Monaten eines der beiden oder sogar beides zu bearbeiten. Wobei beides für mich glaube ich was viel ist. Wlan mässig hab ich mir erstmal das rausgesucht. http://gumstix.com/store/catalog/product_info.php?cPath=31&products_id=191 Nur ist das eventuell zu teuer. Muss ja alles heut zu tage billig sein. Und billig ist leider nicht ganz einfach dann. Das Gumstix soll aber zu mindest schon mal "problemloser" an ein AVR32 System anbindbar sein, da es scheinbar Treiber dafür gibt. Also Alternative gäbe es dann noch den XG-182M von Zcomax (hab ich leider keinen Preis bisher) oder von wi2wi das W2sw0001. Letzteres ist mit 16 Euro (Wlan) bzw. 21 Euro (inkl. Wlan und Bluetooth) recht günstig. Es heißt das es Linuxtreiber geben soll. Aber na ja... Im schlimmsten Fall könnte ich doch auch per Uart Treiber von Atmel auf solche Module zugreifen. Nur stellt sich dann die Frage wie ich den optimal ins Linux anbinde. Denn soweit ich gelesen habe muss man die Module öfters triggern, damit sie am "Leben" bleiben...
Max schrieb: > ...Also Board wollte ich eventuell das > NGW100 nehmen. Oder halt eines von Toshiba für den TMPA910. Allerdings > beim Toshiba weiß ich nicht wie das mit der Toolchain aussieht. Es soll > diesen Monat eine GNU Toolchain kommen. Ich würde dir empfehlen auf ein Board zurück zu greifen, welches bereits einige Zeit auf dem Markt ist. Wenn die Toolchain jetzt noch nicht einmal auf dem Markt ist heißt das, dass du dich eventuell mit dessen Kinderkrankheiten herumschlagen musst und in Foren weniger Hilfe finden würdest. Zum NGW100 (oder auch Grasshopper) kann man sagen, dass es hier doch schon des öfteren verwendet wurde. Du solltest dir auch nicht zu viel vornehmen. Falls du mit Qt noch nichts oder wenig bisher getan hast, wäre dies wieder ein riesen Bereich der sich da auf tut.
> Privat habe ich mir das Grasshoppers + TFT + Touch von embedded > projects gekauft. Leider hatte ich noch keine Zeit etwas rumzuspielen. > Muss noch eine Adapterplatine bauen mit dem Boost Converter etc. schaust du hier: Beitrag "AVR32 Grasshopper: Wie Sound?" letzter Beitrag.
Also mal ein kurzer Kommentar zu den vorgeschlagenen Atmel AVR32 Board: ----------------------------------------------------------------------- Atmel wird die AP Serie (so zumindest die Aussage auf der letzten Messe) nicht weiter entwickeln. Und mit viel Pech langfristig einstampfen (meine Interpretation - zwischen den Zeilen, also nicht offiziell von Atmel!!!). Also würde ich keine Zeit mehr an diese Teile verschwenden. Atmel baut jetzt auch auf neue ARM Kerne. Für kleine Systeme Cortex-M3 und in Planung Cortex-A8 (wird dann glaub Nachfolger von ARM9). Für eine Diplomarbeit kann ich nur ein sehr gut unterstütztes Board empfehlen. Eine Recherche im Internet allein wird wahrscheinlich nicht unbedingt zum Ziel führen, da g**gle schon sehr viele Suchergebnisse liefert. Aber vielleicht hilft es auch mal in deiner Hochschule ein paar Leute zu interviewen. Evtl. hat schon jemand ein ARM Board organisiert, dass Du verwenden kannst. Was die Bücher betrifft: ------------------------ Ich persönlich hab, wenn ich mich recht erinnere, das Buch mal angeschaut, aber wegen dem Datum 2006 nicht gekauft. Dafür hab ich jetzt 3 Bücher mit neuerem Datum gefunden (Ich hab leider die Liste gerade nicht zur Hand). Eines mit einer guten Übersciht über die verschiedenen Geräteklassen und Treiberstrukturen (Also ein Überflug über die verschiedenen Mechanismen im Kernel), eines in dem die Kernel-Internen Dinge wie Filesystem etc. abgehandelt werden und eines, wie man ein Embedded Linux von der Pieke an baut. Zum Lesen der letzten beiden, bin ich leider mangels Zeit noch nicht gekommen. Aber ich werde die Liste mal hier reinschreiben, sobald ich die hab.
> Atmel wird die AP Serie (so zumindest die Aussage auf der letzten Messe) > nicht weiter entwickeln. Und mit viel Pech langfristig einstampfen > (meine Interpretation - zwischen den Zeilen, also nicht offiziell von > Atmel!!!). Also würde ich keine Zeit mehr an diese Teile verschwenden. Das verbreitest du jetzt schon geraume Zeit hier. Aber weder auf der Atmel-Seite noch auf AVR-freaks kann man bis heute etwas davon lesen. (Außer deinen Kommentar auf AVR-freaks). Dagegen sieht man, dass immer mehr Firmen dafür Entwicklungsboards anbieten. Kann es sein, dass du auf der Messe mit jemanden aus der Cortex-Truppe gesprochen hast der seinen Job sichern wollte?
gibt es vielleicht so einen Treibertemplate was man sich mal anschauen kann? Um einfach mal einen Eindruck zu bekommen, wie das so ist! ;-)
> gibt es vielleicht so einen Treibertemplate was man sich mal anschauen > kann? Um einfach mal einen Eindruck zu bekommen, wie das so ist! ;-) Einen ganzen Asch voll findest du im Kernel-Source... ;-) Ansich gibt es im Linux-Kernel-Tree sogenannte Skeletons (oder so ähnlich), ich glaube das ist etwas in der Richtung. Das obige Buch hatte mir damals gereicht. In einem der Linux-Zeitschriften gab es eine Serie über Treiber usw., die stammte aber auch von dem Autor des obigen Buchs, dürfte also nichts neues sein. Der verdient an dem Buch dreimal, als Buch, als Artikel-Serie und als sein Vorlesungsskript. ;-) Wobei ich ihm das gönne, zumindest fand ich das Buch gut. Ist aber auch Geschmackssache... google mal nach denen, vielleicht hilft das ein wenig drivers/net/pci-skeleton.c drivers/net/isa-skeleton.c drivers/video/skeletonfb.c drivers/pci/hotplug/pcihp_skeleton.c drivers/usb/usb-skeleton.c
>Das verbreitest du jetzt schon geraume Zeit hier. >Aber weder auf der Atmel-Seite noch auf AVR-freaks kann man bis heute >etwas davon lesen. (Außer deinen Kommentar auf AVR-freaks). >Dagegen sieht man, dass immer mehr Firmen dafür Entwicklungsboards >anbieten. Jeder kann sich von mir aus seine eigene Meinung dazu bilden. Bisher ist keine Akündigung der 2 AP Varianten in Sicht. Allerdings hieß es beim letzten Atmel Workshop, dass die APs "mit Vorsicht zu genießen" sind, weil die weitere Entwicklung ungewiss ist. Auf der Messe hieß es nur, dass die ARM Controller im Bereich der Application Controller die Nase vorne haben, und sich für Atmel daher der Ausbau der APs nicht lohnt. Allerdings, seien die AVR-32 UC Varianten wohl dem Cortex-M3 überlegen. Atmel hat ja auch die Cortex-A8 aktuell in Plaung und will Ende 2010 Controller anbieten. Wie weit jetzt Atmel solchen "Ankündigungen" folgt, entscheidet die Marktlage. Und die iat ja bekanntlich sehr wechselhaft. ------------------------------------------------------------------------ --- Nochmal zu den Büchern: Eine Übersicht über die Kernel Internas bietet: ISBN-13: 978-0-470-34343-2. Das Buch ISBN-13: 978-0-13-239655-4 bietet eine Übersicht über die verschiedenen Kernel Treiber und interne Standardfunktionen (Arbeitswarteschlangen, etc.). Letzteres zeigt einem nur was alles im Kerneltreiber drin steckt, verweist aber hauptsächlich auf die Sourcen. Mit ersterem Buch habe ich mich noch nicht ausführich beschäftigt. (Evtl. die Texte und Bewertungen bei Amazon, etc. lesen).
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.