UART Interrupt in C möglich?

[Klebwax]

Nächste Frage (konnte es selbst noch nicht testen): Wenn ich eine Zeichenkette an das RasPi sende, z. B. "ABC", wird das dann "Zeichen für Zeichen" in die "Empfangsdatei" geschrieben, oder mit einem mal? Also sitzt davor noch ein Buffer oder lese ich im ungünstigsten Falle "AB" aus, weil der Empfang noch nicht fertig war?

Das kommt drauf an, wie du das File behandelst. In Unix gibt es zwei Familien von Filefunktionen, gepuffert und ungepuffert. Schau dir mal die Filefunktionen, die mit f beginnen, wie fopen(), fgets() .. an.

also ich habe es mittlerweile so gelöst, dass ein Programm im Hintergrund läuft und alles was empfangen wird in eine Datei schreibt

Damit hast du also den vorhandenen Mechanismus des bufferd-IO neu erfunden. Wobei ich den Sinn nicht so recht verstehe, jetzt pollst du statt einem Device einen File.

Das UART selbst läuft mit Interrupt und blockiert mit Sicherheit nicht, das geht bei einem Multiuser/Multitasking System garnicht. Die Interrupte landen aber im Kernel. An diesen darf ein Userprozess auch nicht drehen, er könnte ja sonst das Gesamtsystem blockieren. Das was einem Interrupt im Usermode noch am ähnlichsten ist, ist ein Signal. Mache Treiber können ein Signal erzeugen, wenn sich beim IO etwas ändert, muß man mal nachlesen ob der tty-Treiber das macht.

Wenn man in Unix auf Input wartet, nutzt man gerne den select() Systemcall. Zusammen mit der Möglichkeit, einen Timeout zu setzen, kann man so auch State-Machines programmieren.

MfG Klebwax

[Kampi]

Das kommt drauf an, wie du das File behandelst. In Unix gibt es zwei Familien von Filefunktionen, gepuffert und ungepuffert. Schau dir mal die Filefunktionen, die mit f beginnen, wie fopen(), fgets() .. an.



Damit hast du also den vorhandenen Mechanismus des bufferd-IO neu erfunden. Wobei ich den Sinn nicht so recht verstehe, jetzt pollst du statt einem Device einen File.

Das UART selbst läuft mit Interrupt und blockiert mit Sicherheit nicht, das geht bei einem Multiuser/Multitasking System garnicht. Die Interrupte landen aber im Kernel. An diesen darf ein Userprozess auch nicht drehen, er könnte ja sonst das Gesamtsystem blockieren. Das was einem Interrupt im Usermode noch am ähnlichsten ist, ist ein Signal. Mache Treiber können ein Signal erzeugen, wenn sich beim IO etwas ändert, muß man mal nachlesen ob der tty-Treiber das macht.

Wenn man in Unix auf Input wartet, nutzt man gerne den select() Systemcall. Zusammen mit der Möglichkeit, einen Timeout zu setzen, kann man so auch State-Machines programmieren.

MfG Klebwax

Ah danke für die Erklärung.
Der Grund, warum ich das in eine Datei schreibe ist der, weil mehrere Ressourcen auf den Empfangenen Text zugreifen müssen.
Aber das der UART bereits über Interrupt läuft wusste ich nicht.
Hab es bisher so vermutet, dass wenn ich z.B. in Python mit dem "serial.read()" arbeite das er auch den UART einfach nur pollt.

[dremler]

Aus aktuellem Anlass nochmal die Frage: Gibt es in C auf dem Raspberry Pi die Möglichkeit, Timer Interrupts zu nutzen? Ich möchte nur sehr ungern Delay Schleifen nutzen...

[Max Web]

Hallo,

das wird so vermutlich auch nicht gehen. Allerdings gibt es unter sys/time.h einige sehr nützliche Tools zum Thema Timer.
Außerdem bekommst Du drei Timer, die Du mit getitimer() und setitimer() kontrollieren kannst. Diese lösen verschiedene Signale aus, auf die Du reagieren kannst.
Das ist zwar nicht ganz so toll wie das direkte Benutzen von Interrupts, aber sicherlich ein interessanter Ansatz.

[schorsch_76]

Das ist normale C Programmierung. Timer werden in der Regel über separate Threads gelöst welche diese Zeit eben im sleep sind. Persönlich mache ich sowas mit boost in C++, aber unter C geht das prinzipiell genauso. Direkte Interrupts wie du sie auf den AVRs kennst werden in Linux auf PCs anderst gelöst.... eben mit Threads. Siehe dazu auch [1] [2]

Ereignisgesteuert auf UART zu reagieren geht auch mittels select [5] . Unter C++ würde ich das mit boost::asio [3] [4] lösen
Gruß
Georg

[1] http://en.wikipedia.org/wiki/POSIX_Threads
[2] https://computing.llnl.gov/tutorials/pthreads/
[3] http://www.boost.org/doc/libs/1_53_0...oost_asio.html
[4] http://www.boost.org/doc/libs/1_53_0...rial_port.html
[5] http://stackoverflow.com/questions/1...to-work-on-tty

[TheDarkRose]

C Programmierung am Pi ist normale Linuxprogrammierung -> ergo ganz normale C/C++ Programme möglich, Schnittstellen können einfach wie Dateien gelesen werden, ohne Probleme. Interrupts gibt es generell nicht, außer man programmiert ein Kernelmodul. Dafür gibt es aber Threads und Prozesse.