Guten Tag, wir haben vom Studium aus das NGW100 aufgezwungen bekommen und sollen darauf jetzt innerhalb einer Woche ein kleines Projekt zum laufen bekommen. Als Basis dient das bereits installierte Linux auf dem NGW100. Programmierung sollte unter Windows mit dem AVRstudio32 geschehen - Programm kompilieren, auf SD card und von dort dann starten. Benötigt wird u.a.: - Pinansteuerung (Ausgang) wie möglich? Es muss doch hoffentlich kein eigener Treiber geschrieben werden wie das an einigen Stellen im Web erwähnt wurde!? - Benutzereingaben (was is am einfachsten? RS232 Terminal?) Gibt es soetw. wie KBHIT, damit das Programm ständig läuft & nur wenn auch etw. eingegeben wurde diese Eingabe auswertet? - Gibt es soetw. wie Timer Interrupts mit denen man arbeiten kann? Wie verwendet man diese? Auf die Pins soll dann etw. ausgegeben werden (z.B. binäres Zählen) wofür ein Timer-Interrupt elegant wäre. Der Benutzer soll dann per Eingabe den Ausgabewert verändern können (start, stop, alle Pins high/low). Notfalls könnte man auf den Interrupt wohl auch verzichten und das via KBHIT lösen... Wir (der komplette Kurs) würden uns extrem freuen, wenn sich hier jemand finden würde, der uns mit ein paar Codebeispielen / Beispielprogrammen unter die Arme greifen könnte. Sind eigentlich momentan im Prüfungsstress und haben nicht wirklich Zeit dafür uns in Linux und das NGW ein zu arbeiten grr. Vielen lieben Dank!! fhma_geek ADD yahoo DOT de
Aufgezungen? Ach Ihr Armen! Was haettet Ihr den lieber behandelt?
@Uwe ATmega32 z.B.! da wär das gegebene Projekt für mich - Mit Kaffeepause - nen Zeitaufwand von max. 30min!! Über die ATmegas bekommt man auch, u.a. dank diesem Forum, innerhalb weniger Minuten alle Infos bei die man zum Entwickeln benötigt. Zudem haben wir das ganze Semester nur mit dem ATmega gearbeitet; Das NGW ist bei uns so neu, dass noch nicht mal die Dozenten wissen was das überhaupt ist/was es kann; auch auf Seiten der Dozenten keiner verfügbar ist der sich nur ansatzweise mit Linux auskennt ("Mach mal nicht so schnell. Was hast du da eben eingegeben? 'ls' was macht denn das?"). Das NGW ist als Demoboard bestimmt nicht so schlecht - nur Fehlen mir Ansätze wie ich mit dem Programmieren anfangen kann; wie&wo ich die Befehle finde die ich gerade benötige! Z.B. für das Ansprechen eizelner Pins gibt es im Web informationen, die darauf verweisen, dass man einen eigenen Treiber programmieren muss, diesen in die Kernel einbinden muss und dann die komplette Kernel neu kompilieren muss. Und DAS kann ich mir nun wirklich nicht vorstellen, dass das solche Standardfunktionen im µC Bereich schon so notkompliziert realisiert sind. Gruß!
Ist es nicht so das man als Student auch mal in der Lage sein sollte sich an etwaas neuer 'ran zu wagen? Schön wenn du das mit dem Mega in 30min. schaffst - aber was wäre das dann für ein Lernerfolg???
> Z.B. für das Ansprechen eizelner Pins gibt es im Web informationen, die > darauf verweisen, dass man einen eigenen Treiber programmieren muss, ... Ich frage mich ernsthaft, wie und was ihr da gesucht habt. Mit einem simplen "NGW100" als Suchbegriff habe ich gerade mal 3 Minuten gebraucht, um alle relevanten Infos zu finden. Inklusive einer Seite, wo genauestens erklärt wird, wie man sich ein passendes Device anlegt, und wo auch ein sehr ausführliches Codebeispiel für die Benutzung dieses Device zu finden ist.
"Und DAS kann ich mir nun wirklich nicht vorstellen, dass das solche Standardfunktionen im µC Bereich schon so notkompliziert realisiert sind." Naja, da läuft nen bisschen mehr software als auf nem Mega, und die ist auch ein klein wenig komplexer. Aber nen Kernel brauchste nicht unbedingt. Kanst Deine Programme ja native, ohne OS, laufen lassen :D.
Genau so eine Disskussion wollte ich jetzt auslösen - gratulation! Mit Lernerfolg hat das bei uns nichts mehr zu tun - das is nur noch Marketing was die da betreiben! Lernerfolg hat auch etw. damit zu tun, dass man die dafür notwendige Zeit bekommt! Der Dozent kann nen Integer noch nicht mal von nem boolean unterscheiden und stellt dann Aufgaben die in der Zeit absolut nicht machbar sind. Wir haben nebenbei noch nen Roboter zum laufen zu bekommen, und müssen uns auf 10 Klausuren vorbereiten die die nächsten 3 Wochen zu schreiben sind. Da kann man sich nicht noch nebenbei mal schnell in den Linux Kernel einarbeiten und hunderte Headerfiles des Kompilers durchstöbern ob irgendwo evtl. etw. passendes dabei sein könnte... Dass wir jetzt das NGW aufs Auge gedrückt bekommen haben is eigentlich der Abschuss - nur kann man sich als Student nicht dagegen zur Wehr setzen, der Dozent sagt es, also muss es auch erledigt werden sonnst bleibt man hängen. Und wie soll man zum Lernerfolg kommen, wenn es keine Unterlagen zum Lernen gibt??? C++ Instrucionset findet sich irgendwie nirgends und Beispielprogramme scheint es auch keiner zu haben. Verwiesen wird immer wieder auf irgendwelche Wikis in denen viel geschwafelt wird wie toll doch alles ist aber auf die Programmierung nicht eingegangen wird. Gruß!
@ Stefan Ernst Den Link hättest du nicht zufällig griffbereit? GPIO beschäftigt sich dieser artikel z.B. mit, aber das offensichtlich nur via pipeing, was für Scriptsprachen ganz schön ist - aber im C++ Programm nicht wirklich angebracht ist. http://www.avr32linux.org/twiki/bin/view/Main/GpioDevInterface
Genau den Link meinte ich. Wo siehst du denn da Pipeing?
echo -ne '\x00\x00\x00\xaa' > /dev/gpio0 # Turn on all odd-numbered LEDs Textausgabe von Konsole wird auf LEDs gepiped, soweit ich das sehe... Die Portconfig könnte man wohl über fwrite etc. lösen... So für die saubere Art halte ich das aber nicht - stelle mir das zumindest sehr langsam vor.
Achim_AVR32 wrote: > echo -ne '\x00\x00\x00\xaa' > /dev/gpio0 # Turn on all odd-numbered > LEDs Das ist kein Pipeing sondern eine Ausgabeumlenkung. Auf ein eigenes Programm bezogen ist das einfaches File-IO. Oder findest du es auch nicht "angebracht", in einem C++-Programm in eine Datei namens /dev/gpio0 zu schreiben? > Die Portconfig könnte man wohl über fwrite etc. lösen... So für die > saubere Art halte ich das aber nicht - stelle mir das zumindest sehr > langsam vor. Das ist nun mal die Art, wie unter Linux auf Geräte zugegriffen wird. Unter Linux gilt das "alles ist eine Datei"-Konzept. Natürlich ist das etwas langsamer als ein direkter Portzugriff. Du vergisst aber wohl, das Linux ein Multitasking-Betiebssystem ist. Es könnte ja durchaus sein, dass zwei Programme auf den gleichen Port zugreifen wollen, also muss das irgendwie koordiniert werden. Was meinst du, was es für ein Chaos geben würde, wenn beide Programme einfach direkt am Port "rumfummeln" würden.
Ausgabeumlenkung wäre meine deutsche übersetzung für Pipeing gewesen. Ob die Quellinformationen aus einer Datei, oder einer manuellen Textausgabe stammen und wohin diese dann umgeleitet werden liegt ja in der Flexibilität des Pipeing... Für die Ports hätte ich auf Programmiertechnischer Ebene erwartet, dass sich der Prozess irgendwie bei der Kernel anmeldet "Hi, ich brauche gelegentlich zugriff auf PortX" und wenn man dann schreibend auf den jeweiligen port zugreifen möchte entscheidet dann die Kernel anhand der Taskpriorität welcher Schreibzugriff ausgeführt und welcher verworfen wird. Soll mir recht sein - unter Win ist das schon eine feine Sache über FileRead/Write auf die serielle Schnittstelle zugreifen zu können :] Vielen Dank schonmal für die Info, dass das so üblich ist. Das ist schonmal viel wert! (Als Elektrotechniker bekommt man von der OS-Architektur nicht sonderlich viel mit; da muss man sich irgendwie mit dem möchtegern-Wissen durchschlagen was man sich Hobbymäßig zusammen gesucht hat.) Wie wird das dann mit den Timern koordiniert? Soweit ich das dem Datenblatt entnommen habe stehen nur drei Timer zur Verfügung. Da wären wir dann auch wieder bei der Multitaskingfrage - wie bekommt diese im Programm eingebunden? Es kann ja jetzt sein, dass ein Task alle 100ms einen Interrupt haben möchte und der nächste alle 101ms - das klingt schon so als könnte das nicht gut gehen. THX
Nur kurz zu zur Klärung der Begriffe: Englisch Deutsch von nach Shell-Operator -------------------------------------------------------------------- input redirection Eingabeumlenkung Datei Prozess < output redirection Ausgabeumlenkung Prozess Datei > pipelining Pfeiferei??? :) Prozess Prozess |
> Ausgabeumlenkung wäre meine deutsche übersetzung für Pipeing gewesen. Ob > stammen und wohin diese dann umgeleitet werden liegt ja in der > Flexibilität des Pipeing... Nein, es ist nicht das gleiche. Eine Pipe verbindet die Ein-/Ausgaben zweier Prozesse miteinander. Man kann zwar die Ausgabe in eine Pipe umlenken, aber die Pipe selber ist keine Ausgabeumlenkung. > Für die Ports hätte ich auf Programmiertechnischer Ebene erwartet, dass > sich der Prozess irgendwie bei der Kernel anmeldet "Hi, ich brauche > gelegentlich zugriff auf PortX" und wenn man dann schreibend auf den > jeweiligen port zugreifen möchte entscheidet dann die Kernel anhand der > Taskpriorität welcher Schreibzugriff ausgeführt und welcher verworfen > wird. Und wie sollte diese "Programmiertechnischer Ebene" konkret aussehen? Letztlich musst du (wie du ja auch selber geschrieben hast) den Schreibzugriff anmelden und die zu schreibenden Daten übergeben. Genau das machen doch File-Open und File-Write. Welchen Vorteil sollte es bringen, für den Portzugriff Mechanismen zu haben, die dann zwar anders heißen, aber eigentlich genau das selbe tun. > Soll mir recht sein - unter Win ist das schon eine feine Sache über > FileRead/Write auf die serielle Schnittstelle zugreifen zu können :] Eben, dieses "alles ist eine Datei"-Konzept ist ziemlich flexibel (und ich finde es auch elegant), und Linux verfolgt dieses Konzept sehr viel konsequenter als Windows. > Wie wird das dann mit den Timern koordiniert? Soweit ich das dem > Datenblatt entnommen habe stehen nur drei Timer zur Verfügung. Da wären > wir dann auch wieder bei der Multitaskingfrage - wie bekommt diese im > Programm eingebunden? Du wirst schon die vom Kernel zur Verfügung gestellten Timing-Möglichkeiten nutzen müssen. Wenn die nicht ausreichen, kommst du um einen eigenen Kernel-Treiber nicht herum.
> Welchen Vorteil sollte es bringen, für den Portzugriff Mechanismen zu > haben, die dann zwar anders heißen, aber eigentlich genau das selbe tun. Z.B. Schnellere I/O Performence; Bei dieser DOS Extension (Win95) war es ja auch noch möglich bei Bedarf direkt auf die Hardware zuzugreifen (oft mit blauem Wunder als Resultat). Aber ist mir wirklich lieb so - um paar LEDs leuchten zu lassen tut es wirklich nicht not sich die Kernel zu verbasteln. > Du wirst schon die vom Kernel zur Verfügung gestellten Timing-Möglichkeiten > nutzen müssen. Okey, gibts dazu noch hilfreiche Tipps wie man einen möglichst schnellen, gleichbleibenden Tackt zur Verfügung gestellt bekommt der ggf. auch für PWM Zwecke genutzt werden kann? Da müsste es ne Zeitabfrage in Sekunden seit 1970 geben auf die man zurückgreifen kann, das wär aber zu langsam. Ein Tackt im ms Bereich wäre hilfreich! Wobei - notfalls Endlosschleife die bei Usereingabe (kbhit falls unter linux existent) kurz für die Eingabeauswertung unterbrochen wird :P Nicht sauber aber wird laufen... THX!
> Z.B. Schnellere I/O Performence; Bei dieser DOS Extension (Win95) war es > ja auch noch möglich bei Bedarf direkt auf die Hardware zuzugreifen (oft > mit blauem Wunder als Resultat). Du drehst dich im Kreis. Direkter Zugriff ist bei einem Multitasking-BS alles andere als sinnvoll. Und bei Zugriff über das BS macht es keinen Unterschied, ob man nun auf den Port als File zugreift, oder über irgendein spezielles Port-Konstrukt. > Da müsste es ne Zeitabfrage in Sekunden seit 1970 geben auf die man > zurückgreifen kann, das wär aber zu langsam. Es gehen auch höhere Auflösungen als 1s. Google einfach mal. > Wobei - notfalls Endlosschleife die bei Usereingabe (kbhit falls unter > linux existent) kurz für die Eingabeauswertung unterbrochen wird :P > Nicht sauber aber wird laufen... Nein, es würde nicht laufen, höchstens zufällig. Deine Endlosschleife wird nämlich vom BS regelmäßig unterbrochen, und du kannst keine Vorhersage über die jeweilige Länge der Unterbrechung treffen.
> Nein, es würde nicht laufen, höchstens zufällig. > Deine Endlosschleife wird nämlich vom BS regelmäßig unterbrochen, und du > kannst keine Vorhersage über die jeweilige Länge der Unterbrechung > treffen. Ganz genau DAS! Weiß gar nicht mit was das ding getacktet ist... um die 20MHz? Sagen wir 100 Schleifendurchläufe ^= 100% der PWM und jeder der Durchläufe braucht irgendwas um die 10µs. Das Auge nimmt Filmmern um die 20-80 Hz nicht mehr soo genau wahr, das läge wohl um die 20ms. Sprich, wenn da der Tackt Systembedingt hin und wieder um 500µs daneben liegt, dann wird das schon keinem auffallen :P Schon gar nicht dem 10 EUR Aldi DMM. Für mich selbst würde ich das NIEMALS so lösen, aber ich hab hier neben mir noch 1044 Seiten Script liegen die bis Dienstag gelernt werden müssen, am Mittwoch steht noch nen Referat an und am Freitag folgt auch schon die nächste Klausur. Meine Kurskameraden sind momentan Fahrrad fahren oder sind mit ihren Freundinnen beschäftigt. Irgendwo muss ich da Abstriche machen. Wie schon gesagt, mir fehlt einfach die Zeit mich in die Materie ein zu arbeiten & die Unterstützung ist gleich null... Am liebsten wärs mir eigentlich wenn irgendwer anders sich der Aufgabe annehmen würde - meintewegen gegen einen kleinen Obulus und ich erstmal meine Ruhe damit habe. Dann kann ich das Thema erstmal abharken und mich nach den Klausuren in Ruhe und mit KLAREM KOPF in das Board einarbeiten... Ich brauch eigentlich erstmal nen Monat urlaub von dem ganzen Stress - aber das versteht hier eh keiner, der das nicht selbst durchmachen muss...
>> Nein, es würde nicht laufen, höchstens zufällig. >> Deine Endlosschleife wird nämlich vom BS regelmäßig unterbrochen, und du >> kannst keine Vorhersage über die jeweilige Länge der Unterbrechung >> treffen. > > Ganz genau DAS! Weiß gar nicht mit was das ding getacktet ist... um die > 20MHz? Das, was ich geschrieben habe, hat nichts mit dem Systemtakt zu tun. > Sagen wir 100 Schleifendurchläufe ^= 100% der PWM und jeder der > Durchläufe braucht irgendwas um die 10µs. > Das Auge nimmt Filmmern um die 20-80 Hz nicht mehr soo genau wahr, das > läge wohl um die 20ms. Sprich, wenn da der Tackt Systembedingt hin und > wieder um 500µs daneben liegt, dann wird das schon keinem auffallen :P > Schon gar nicht dem 10 EUR Aldi DMM. Und wenn sich das BS entschließt, erstmal ein paar anderen Prozessen den Prozessor zu geben, und deiner daher für z.B. 200ms auf Eis liegt? Für eine halbwegs genaue PWM im ms-Bereich bräuchtest du entweder ein Kernel-Modul, oder eine Realtime-Erweiterung fürs Linux. Es ist ziemlich deutlich, dass dein Wissen über Linux (sogar über Multitasking-Betriebssysteme im allgemeinen) bei weitem nicht ausreicht, die gestellte Aufgabe zu lösen. Wenn es sich tatsächlich so verhält, wie du geschrieben hast, würde ich mal mit dem Prof reden. Notfalls kann man sich auch an höhere Instanzen wenden. Es ist schließlich ein ziemliches Unding, wenn eine Aufgabe gestellt wird, die der Prof nicht mal selber lösen kann, zumal er dann ja auch nicht einschätzen kann, wie viel Aufwand die Aufgabe verursacht, oder ob die Aufgabe überhaupt im gesetzten Rahmen lösbar ist.
Da ist doch schon ein schönes example in dem Wiki. Eben für GPIO Input , sollte wirklich leicht sein das auf Output umzuschreiben (am meisten wird wohl die "ENTF" Taste belastet ;-) ). Für die Timing Aufgaben würde ich usleep() nutzen , das reicht meistens völlig um ein paar LEDs o.Ä. anzusteuern. Wenn es wirklich schnell und genau werden soll -> Kernel Treiber programmieren / RT preemption patch.
> Das, was ich geschrieben habe, hat nichts mit dem Systemtakt zu tun. Wenn ein anderer Prozess 100% Rechenzeit zugeteilt bekommt und so meine Anwendung nicht mehr durchlaufen wird kann ich auch nichts machen. Ggf. stelle ich meine Prozesspriorität auf "system2 hoch oder kille sämtliche andere Prozesse. Irgend nen Work-Around werd ich da schon finden, dass das Ergebnis halbwegs in die Aufgabenstellung reinpasst. > Es ist ziemlich deutlich, dass dein Wissen über Linux (sogar über > Multitasking-Betriebssysteme im allgemeinen) bei weitem nicht ausreicht, > die gestellte Aufgabe zu lösen. Ganz genau! Das is auch nicht sinn und zweck in nem Elektrotechnik-Studiengang Betriebssysteme ihn ihrer genauen Funktionalität zu zerlegen. Wir konnten ja schon froh sein, dass wir wenigstens in DV2 einen halbwegs fähigen Dozenten erkämpfen konnten! > Es ist schließlich ein ziemliches Unding, wenn eine Aufgabe > gestellt wird, die der Prof nicht mal selber lösen kann, zumal er dann > ja auch nicht einschätzen kann, wie viel Aufwand die Aufgabe verursacht, > oder ob die Aufgabe überhaupt im gesetzten Rahmen lösbar ist. ;( Wie oft haben wir das schon probiert... das Problem ist die elementaren Dozenten sind eingestellt und können nicht abgesägt werden. Und der abteilungsleiter is noch schlimmer... Da kommt ein Mitarbeiter von MS stellt ein neues Produkt vor, dann ist das so genial, dass es sofort für irgendwas eingesetzt werden muss und die Studenten dürfen sich dann mit dem Treck herumärgern, der noch nichtmal die Alpha-Phase erreicht hat... Beschweren darf ich mich eigentlich nicht - wenn wir eins im Studium gelernt haben, dann wie man auch ohne wissen irgendwas zusammenkotzen kann, was irgendwie seine Aufgabe erfüllt. Dann wird jemand von der örtlichen Zeitung eingeladen, bekommt das kurz gezeigt und dann steht die Hochschule wieder gut da. Was danach mit der Projektarbeit passiert interessiert keinen mehr. Der Witz ist ja auch, dass es in erster Linie darum geht sich etw. mit Mikrocontrollern auseinander zu setzten. Und nun dürfen wir auf einmal mit für Linux ne Anwendung entwickeln. Von 20 Personen die noch im Studiengang sind haben gerade mal drei Linux schonmal in ihrem Leben installiert. Wobei das dann auch nur aus installieren und KDE Beschnuppern war. Das darf man eigentlich keinem sagen was da abläuft... > Für die Timing Aufgaben würde ich usleep() nutzen , das reicht meistens > völlig um ein paar LEDs o.Ä. anzusteuern. usleep vermute ich jetzt einmal in delay.h - das wird den Prozess so lange anhalten bis die Zeit verstrichen ist - was wohl auch wieder davon abhängig sein wird welche Prozesse sonnst noch zwischenrein funken (Siehe hinweis von Stefan Ernst). An der Kernel herumbasteln will ich auf keinen fall - so wie ich das herausgelesen habe wäre das aber für eine saubere PWM notwendig. Damit hätten wir die Frage auch soweit schonmal geklärt...
> usleep vermute ich jetzt einmal in delay.h - das wird den Prozess so > lange anhalten bis die Zeit verstrichen ist - was wohl auch wieder davon > abhängig sein wird welche Prozesse sonnst noch zwischenrein funken Nein, usleep ist in unistd.h. Das entscheidende ist aber, dass die Wartezeit nicht einfach im Prozess (z.B. in einer Leerschleife) verbraten wird, sondern der Prozess wird vom BS schlafen gelegt und auch wieder aufgeweckt. Natürlich hast du auch hier keine Garantien, letztlich wird dir nur garantiert, wie lang die Schlafzeit mindestens ist, aber du hast damit eine viel größere Chance auf ein brauchbares (und reproduzierbares) Ergebnis zu kommen, als mit der Endlosschleife.
>mit für Linux ne Anwendung entwickeln. Von 20 Personen die noch im >Studiengang sind haben gerade mal drei Linux schonmal in ihrem Leben >installiert. Wobei das dann auch nur aus installieren und KDE >Beschnuppern war. >Das darf man eigentlich keinem sagen was da abläuft... DAS allerdings sollte man nun wirklich nicht oeffentlich zugeben! Eine - zugegeben nicht representative - Gruppe von 20 Studenten und davon haben DREI schonmal Linux installiert - wobei mein Verdacht dabei noch schlimmer ist, ich glaube das sind die drei, die schon einmal eine Knoppix-CD gestartet haben. Allerdings war ich bisher der Meinung, dass in dieser Generation diejenigen, die ohne viel Ahnung von irgendwas mit minimalem Aufwand studieren und danach richtig Kohle machen wollen in die BWL gehen. Offensichtlich gibt es das also auch in der Studienrichtung ET. Wieder was gelernt. Matth
@dachs Du glaubst doch nicht ernsthaft, dass man während dem Studium etw. lernen würde!? Wenn ich mir alte Klassenkameraden an anderen UNIs anschaue... Da hocken teilweise >100 Studenten im Vorlesungssaal. Darunter sind dann evtl. 5 die sich wirklich mit der Materie auskennen. Das ist dann aber idR nicht der UNI zu verdanken, sondern dass die das privat schon seit Ihrer Kindheit machen. Dann gibts noch ca. 1/3 vom Kurs, der einfach nur zu den Klausuren die Scripte des Dozenten auswendig lernt, oder sich alte klausuren besorgt hat. Und der Rest schwimmt halt irgendwie mit. Spätestens eine Woche nach der Klausur weiß der Durchschnittsstudent nicht mehr worum es in der Vorlesung überhaupt ging. Nen Todesurteil wg. verweigerung Linux im Alltag zu verwenden würde ich jetzt auch nicht aussprechen. Jedes System hat seine darseinsberechtigungen und sollte da eingesetzt werden wo es sich am besten entfalten kann. Zumindest bei mir geht das über die Knoppix CD doch etw. hinaus... Hab da ein schnuckeliges VDR System am laufen, was immer mal wieder etw. Pflege benötigt (z.B. wenn das EXT3 Dateisystem mal wieder meine Daten gefressen hat).
Bei Atmel selbst gibts entsprechende Application Notes im Downloadbereich bei der AVR32 Architektur, die auf die Einbindung in die AVR32 toolchain zwecks compilieren deines Programms (C oder C++) sowie die Verwendung von GPIOs im user space eingehen. Zeitaufwand fürs Einlesen und experimentieren etwa zwei Stunden, und schon läuft dein Programm auch ohne große Ahnung von Linux im allgemeinen. Was also ist das Problem? Zum Thema "Elektrotechnik ist nicht dies oder jenes" - die Elektrotechnik besteht heutzutage aus wesentlich mehr als Schaltungssynthese und -analyse. Gerade im embedded Systems Bereich geht es heute nicht mehr nur ausschließlich um Mikrocontroller der 8bit-Variante, sondern auch um echtzeitfähige Systeme unter marktüblichen POSIX-konformen Betriebssystemen. Damit muss man sich befassen, denn wenn der Arbeitgeber es hinterher verlangt, nützt einem die Ausrede "hab ich nie gehabt" nix.
@ lucem > Zeitaufwand fürs Einlesen und experimentieren etwa zwei Stunden, und > schon läuft dein Programm auch ohne große Ahnung von Linux im > allgemeinen. Ich glaube Du übertreibst. In zwei Stunden halte ich das für Null Ahnung von Linux für nicht machbar. Selbst wenn das Instalieren des Compilers und der Toolchain sofort klappt und es keine Zicken gibt beim ersten Compilerstart. Scheinst ein echter Überflieger zu sein ;-)
lucem wrote: > Zeitaufwand fürs Einlesen und experimentieren etwa zwei Stunden, und > schon läuft dein Programm auch ohne große Ahnung von Linux im > allgemeinen. > > Was also ist das Problem? Das Problem ist, dass er anscheinend eine PWM im ms-Bereich realisieren soll. Das soll also jemand ohne Ahnung von Linux in 2 Std hinbekommen?
@DieNull: Wenn ich von Einlesen und experimentieren spreche bedeutet das nicht, dass damit die zu entwickelnde Zielapplikation gemeint ist. Normale Kenntnisse in C setze ich bei einem Elektrotechniker voraus, und viel mehr als die benötigt man eigentlich für die ersten Schritte auch nicht. In diesem Zusammenhang ist dann auch die andere Nachfrage hinfällig... Meine Antwort bezog sich erstmal auf die Einstiegsprobleme in das System im allgemeinen und die Eingangs gestellte Frage nach Dokumentation bspw. zur Steuerung von GPIOs. Für das PWM-Problem gäbe es unter Linux eigentlich nur eine wirkliche Lösung, nämlich das Anwenden der (hoffentlich) bekannten Realtime-Erweiterungs-Patches auf den Kernel-Source-Tree und darauf folgendes neu compilieren des Kernels. Damit wäre zumindest die Antwortzeit laufender Prozesse deterministisch. Ob die Antwortzeit dann für eine ms-genaue Auflösung für die PWM ausreicht, ist eine andere Frage; evtl kann es unter Linux imlementiert werden, evtl. auch nicht und muss dann "nativ" wie bei einer Standard-Mikrocontroller-Entwicklung gemacht werden, wo man auch direkten Hardwarezugriff hat. Die letztliche Realisierung wird höchstwahrscheinlich das Schreiben eines Kernelmoduls erfordern, was mit ein bisschen Einlesen aber auch machbar ist und bei weitem nicht das Teufelswerk ist, nach dem es aussieht. Ich habe selber auch erst letzte Woche begonnen, mich intensiver mit dem Thema embedded Linux und Kernelmodule auseinanderzusetzen, da ich erst da den Entschluss gefasst habe das NGW100 käuflich zu erwerben. Ob "Überflieger" oder nicht, lasse ich mal dahin gestellt, aber mit vernünftigen C-Kenntnissen und dem Willen, auch ein wenig zu lesen war ich auch ohne genaue Kenntnis der Kernel-interna und ohne spezielle Kenntnis über die Hardware und Besonderheiten Linux-getriebener embedded Systeme innerhalb von zwei Nachmittagen in der Lage, ein entsprechendes Kernelmodul zu schreiben, dass eine Art EBI nachbildet und ein entsprechendes char-file als Interface für user space prozesse exportiert. Und ich habe auch am Anfang wie der Ochs vorm Berg gestanden und wusste nicht wo ich anfangen sollte! Man sieht also, es geht, und der notwendige Zeitaufwand hält sich in Grenzen, sofern man einmal überhaupt angefangen hat. In diesem Zusammenhang haben sich ein Blick in die AN über GPIOs von Atmel sowie das Buch "Linux Driver Development, 3rd Edition" von O'Reilly (welches über einschlägige Suchmaschinen als PDF downloadbar ist) als überaus hilfreich erwiesen. Also, zusammengefasst: - Es ist mit wenig Zeitaufwand möglich, trotz wenig Kenntnis über die Besonderheiten von Linux. - Es kann potentiell realisiert werden (das mit dem PWM) - Es kann allerdings an mangelnder Auflösung des Echtzeitbetriebs scheitern.
http://pramode.net/2007/09/11/experiments-with-the-atngw100-part-6/ http://pramode.net/2007/09/08/experiments-with-the-atngw100-part-5/ Beschreibt die Verwendung von 16bit-Timern und der eingebauten PWM unter Linux...
@lucem Ehrlich, Respekt! Wenn Du das in so kurzer Zeit durchblickst und hinbekommst, dann ziehe ich den Hut. Ich würde das nicht so erwarten. Es gehört schon eine besondere Auffassungsgabe dazu, dieses in so kurzer Zeit zu schaffen. Es hat auch nichts mit C-Kenntnissen zu tun. Allein die gesamte Linux-Materie ist schon komplex, was nicht bedeutet, dass das nicht zu schaffen ist. Gerade wenn man noch nie auf Linux gearbeitet hat und configure + patch + make noch nie angewendet hat. Ich frage mich nebenbei, wofür man ms genaue SW braucht, wenn man die HW-PWM des Timers nutzen kann? Wofür dann realtimefähigkeit? DieNull
Das Problem bei den HW-PWMs ist, dass man an diese auch irgendwie rankommen muss... und evtl die Ports schon anderweitig reserviert sind. In anderen Fällen kann man die aus anderen Gründen nicht verwenden, weil beispielsweise schon alle verwendet sind. In den Fällen muss man dann wieder auf Echtzeitbetrieb zurück, was eh besser ist, weil deterministischer.
> In anderen Fällen kann man die aus anderen Gründen nicht verwenden, weil > beispielsweise schon alle verwendet sind. > In den Fällen muss man dann wieder auf Echtzeitbetrieb zurück, was eh > besser ist, weil deterministischer. Alder vadder. Ja ne is klar, der Programmcode soll also "deterministischer" laufen, als die HW-PWM?! Dir ist schon klar, was (hard/soft)realtime eigentlich sind?! Wenn man kann, nimmt man die HardwarePWM. ist so. alles andere ist unnötigs prozessorquälen. Wenn du Netzwerk benutzt, machst du das ja sicher auch mit 10MBit/s über gehackten kernel mittels drähten am PCI-Bus oder was?!
Bitte 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.