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/Gpio...

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.

Hat AVR32öLinux evt auch ein Realtime Scheduler Kernel Modul?

>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...
http://pramode.net/2007/09/08/experiments-with-the...

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.