www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik NGW100 (AVR32) wer kennt sich mit der Programmerstellung für standard Linux aus?


Autor: Achim_AVR32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uwe Bonnes (Firma: TU Darmstadt) (uwebonnes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aufgezungen? Ach Ihr Armen!
Was haettet Ihr den lieber behandelt?

Autor: Achim_AVR32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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ß!

Autor: Manuel Kampert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: SiO2 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Achim_AVR32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß!

Autor: Achim_AVR32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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...

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau den Link meinte ich.
Wo siehst du denn da Pipeing?

Autor: Achim_AVR32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Achim_AVR32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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       |

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Achim_AVR32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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!

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Achim_AVR32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Claude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Achim_AVR32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Uwe Bonnes (Firma: TU Darmstadt) (uwebonnes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat AVR32öLinux evt auch ein Realtime Scheduler Kernel Modul?

Autor: dachs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Achim_AVR32 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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).

Autor: lucem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: DieNull (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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 ;-)

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: lucem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: lucem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: DieNull (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: lucem (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: troll (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.