Ich bräuchte Impulse von 560us und Vielfache davon. Kann man die mittels Python auf die ein oder andere Art auf einem Raspberry Pi erzeugen?
Ein Linux-basiertes System taugt nicht gut für solche Echtzeitanwendungen. Zum einen gibt es keine Timer die so fein gehen, zum anderen entzieht das Betriebsystem wg Multitasking deinem Programm ständig die Kontrolle. Von Millisekunden aufwärts und mit großer Toleranz im Timing könnte man was hinfriemeln, aber wirklich kontrollieren Va nicht auf 100us oder weniger kann man es nicht.
Conny G. schrieb: > Ein Linux-basiertes System taugt nicht gut für solche > Echtzeitanwendungen. > Zum einen gibt es keine Timer die so fein gehen, zum anderen entzieht meines Wissens hat die CPU aber Timer die man Programmieren kann, damit kann man auch eine PWM erzeugen. @Milli-Willy Suche dir die Doku von der RaspiCPU und schau ob du den PWM-Timer dazu nutzen kannst.
Ich will keine Probleme, ich will Lösungen angeboten bekommen :-) Wie zB. wird der noch viel schnellere Takt zB. für Grafik, Audio oder USB erzeugt? Für meine Anwendung sind ein paar us mehr oder weniger kein Problem.
Schau dir mal http://pythonhosted.org/RPIO/ an. Damit kannst du mit Hilfe der Hardware-Timer PWM Signale mit einer Auflösung von bis zu 1µs realisieren. Habe die Python Lib selber mal für Servos verwendet und die Signaltimings sind ziemlich präzise. Ciao, Rainer
>Vielleicht hilft das hier: https://pythonhosted.org/RPIO/pwm_py.html
Sieht vielversprechend aus. Danke.
Conny G. schrieb: > Zum einen gibt es keine Timer die so fein gehen, Doch: http://linux.die.net/man/2/setitimer http://linux.die.net/man/3/usleep http://linux.die.net/man/2/nanosleep http://linux.die.net/man/2/clock_nanosleep Allerdings ist da natürlich allenfalls die Mindestzeit garantiert.
A. K. schrieb: > Conny G. schrieb: >> Zum einen gibt es keine Timer die so fein gehen, > > Doch: > http://linux.die.net/man/2/setitimer > http://linux.die.net/man/3/usleep > http://linux.die.net/man/2/nanosleep > http://linux.die.net/man/2/clock_nanosleep > > Allerdings ist da natürlich allenfalls die Mindestzeit garantiert. Das meine ich. Was am Ende genau dabei herauskommt weiss man nicht. Es hängt also von der Anwendung ab, ob man damit hinkommt. Und bzgl. PWM ist die Frage, ob man damit ein moduliertes Signal - wenns um ein Datenprotokoll geht - hinbekommt, das stabil genug ist. Wenn man pro Bit die Zeit wechseln muss - die Frage klingt mir danach, dann muss man einen PWM-Interrupt bedienen. Da wäre mir gerade nicht bekannt, dass man das in Python könnte. Mit C und auf OS-Ebene ist das schon was anderes, da könnte man es schaffen. Wenn der Raspi einen PWM-Interrupt hat.
Conny G. schrieb: > Wenn man pro Bit die Zeit wechseln muss - die Frage klingt mir danach, > dann muss man einen PWM-Interrupt bedienen. Da wäre mir gerade nicht > bekannt, dass man das in Python könnte. PWM habe ich selbst nicht verwendet, aber auf GPIO Interrupts zu reagieren ist problemlos möglich. Siehe WiringPi "gpio wfi". Taster am Pin führt bei mir zu Shutdown vom RasPi.
A. K. schrieb: > Conny G. schrieb: >> Wenn man pro Bit die Zeit wechseln muss - die Frage klingt mir danach, >> dann muss man einen PWM-Interrupt bedienen. Da wäre mir gerade nicht >> bekannt, dass man das in Python könnte. > > PWM habe ich selbst nicht verwendet, aber auf GPIO Interrupts zu > reagieren ist problemlos möglich. Siehe WiringPi "gpio wfi". Taster am > Pin führt bei mir zu Shutdown vom RasPi. Ja, GPIO-Ints habe ich auch gesehen, das wird von RPi.GPIO implementiert. Wenn es PWM-Interrupts gibt, dann müsste man das dafür auch implementieren - ich würde vermuten, dass muss auf Hardware-/Treiber-Level in C geschehen. Ich würde infrage stellen, ob das auf Python-Ebene in Echtzeit ankommt, der Verdacht läge nahe, dass auf Treiber-Ebene ein Flag gesetzt wird, das in Python ankommt, sobald der Thread aktiviert wird - ich habe also doch eine unbekannte Zeitspanne zwischen dem Ereignis und dem Python-Int. Keine Ahnung, ob das mit 500us erfolgreich zusammenspielen kann, wenn das in wesentlich höherer Frequenz als Key-Press geschieht. Genau das meine ich mit: Linux ist kein Echtzeit-Betriebssystem. Ich weiss nie, wann ich auf App-Ebene etwas mitbekomme. Bei einem Mikrocontroller kann ich das auf den Taktzyklus genau ausrechnen / festlegen. Ich habe gerade PWM+DMA-Geschichten gefunden, allerdings wird auch da nicht auf Zeitwechsel pro Bit/PWM-Cycle eingegangen, nur dass man auf ein PWM-Grundsignal Untersignale aufsatteln kann. Anwendung dort eher Servo-Steuerung: http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=36572 Kann dem aber nicht entnehmen, ob man das jeden Zyklus des Grundsignals steuern kann, sieht mir nicht so aus. Wenn, dann wäre das aber der Weg.
Milli-Willy schrieb: > Ich bräuchte Impulse von 560us und Vielfache davon. Kann man die mittels > Python auf die ein oder andere Art auf einem Raspberry Pi erzeugen? Was genau hast Du vor zu tun? Ein Datenprotokoll implementieren?
Conny G. schrieb: > Bei einem Mikrocontroller kann ich das auf den Taktzyklus genau > ausrechnen / festlegen. Weshalb ich bei harten Anforderungen auch keinen RPi verwenden würde, beispielsweise indem die entsprechend Funktion ein angekoppelter Zwerg übernimmt. Aber hier ist nicht genug bekannt. Wen es wirklich nur im die Länge einzelner Impulse geht, nicht aber um genau definiertes Timing aus beliebigen Impulsen und Pausen, dass sollte sich das mit dem verlinkten Modul schon machen lassen.
:
Bearbeitet durch User
Es habe sogar schon Leute geschafft, mit dem PWM eine UKW Sender zu bauen. der RPI hat DMA, damit kann man auch die Daten sehr zeitgenau zum den IO-Pins umleiten. Damit kann man dann auch jedes Protokoll umsetzen wenn man will.
>Was genau hast Du vor zu tun? Ein Datenprotokoll implementieren?
Das NEC IR-Protokoll. Hab hier eine kleine Hifi-Anlage mit DLNA, was
wiederum nicht vollständig implementiert zu sein scheint. Nun würd' ich
gern direkt am Pin des Prozessors an dem der 38kHz IR-Empfänger hängt,
die Bits reinschieben.
Milli-Willy schrieb: > Das NEC IR-Protokoll. Hab hier eine kleine Hifi-Anlage mit DLNA, was > wiederum nicht vollständig implementiert zu sein scheint. Nun würd' ich > gern direkt am Pin des Prozessors an dem der 38kHz IR-Empfänger hängt, > die Bits reinschieben. dann würde ich mal nach dem DMA zeug suchen, das sollte damit Problem los gehen. http://www.icrobotics.co.uk/wiki/index.php/Turning_the_Raspberry_Pi_Into_an_FM_Transmitter
Conny G. schrieb: > Linux ist kein Echtzeit-Betriebssystem Ist zwar etwas OT aber für das Thema Echtzeit ganz interessant. "New Raspbian with real-time kernel [JAN-15]" http://www.emlid.com/new-raspbian-with-real-time-kernel-jan-2015/
Peter II schrieb: > Es habe sogar schon Leute geschafft, mit dem PWM eine UKW Sender zu > bauen. der RPI hat DMA, damit kann man auch die Daten sehr zeitgenau zum > den IO-Pins umleiten. Damit kann man dann auch jedes Protokoll umsetzen > wenn man will. Wenn das so geht, dann hätte man - rein technisch gesehen - gewonnen. Bleibt dann noch die Frage, ob das einfach genug zu realisieren ist im Vergleich zu einem Slave-uC, dem man per SPI die Daten schickt und der macht dann das Protokoll-Timing. Ich habe sowas in Linux / mit Raspi noch nicht genauer angeschaut, was es dafür braucht. Mit Python direkt eher nicht, es braucht sicher Unterstützung über C auf Hardwarelevel. Möglicherweise hat das schon jemand gelöst und veröffentlicht.
Conny G. schrieb: > Es habe sogar schon Leute geschafft, mit dem PWM eine UKW Sender zu >> bauen Ich habe das ausprobiert (mit deren Projekt). Es funktioniert mit erstaunlich guter Qualität. Ich war überrascht.
900ss D. schrieb: > Conny G. schrieb: >> Es habe sogar schon Leute geschafft, mit dem PWM eine UKW Sender zu >>> bauen > > Ich habe das ausprobiert (mit deren Projekt). Es funktioniert mit > erstaunlich guter Qualität. Ich war überrascht. Grade angeschaut, haha, die sind verrückt, die Jungs. Genial. Ich liebe das. Ohne den Code gesehen zu haben müsste der Ansatz auch für niederfrequentere Dinge funktionieren. Im Spiel ist dann die Modifikation des Treibers und die Ansteuerung desselben aus Python. Eine Menge Software-Gefrickel, wenn man das mag. Mir persönlich wäre der Hardwareansatz lieber, weil ich alles dafür da habe, sogar schon fertige Schaltungen: Slave-Mikrocontroller per SPI oder sogar einfach nur UART, und der macht das Protokoll, ich schiebe vom RPi die Daten rüber.
Autor: A. K. (prx)
Datum: 20.02.2015 11:33
>Vielleicht hilft das hier: https://pythonhosted.org/RPIO/pwm_py.html
Hab's eben mal getestet. Das funktioniert ja richtig gut!
Ich kann die Mikrosekunden auf dem Oszi einzeln abzählen.
pi@raspberrypi ~/python_test $ sudo python blink1.py
Using hardware: PWM
PW increments: 10us
Initializing channel 0...
add_channel_pulse: channel=0, gpio=17, start=0, width=120
init_gpio 17
clear_channel_gpio: channel=0, gpio=17
add_channel_pulse: channel=0, gpio=17, start=0, width=200
clear_channel_gpio: channel=0, gpio=17
RELAY_1 blink (grosses Relais)
^Cshutting down dma channel 0
clear_channel: channel=0
pi@raspberrypi ~/python_test $
Danke nochmals für den Tip (und auch den anderen natürlich).
Milli-Willy schrieb: > Ich bräuchte Impulse von 560us und Vielfache davon. Kann man die mittels > Python auf die ein oder andere Art auf einem Raspberry Pi erzeugen? Nein. Schon das OS ist kein Echtzeit-OS und somit nicht in der Lage, verläßliche Timings zu erzeugen. Und eine Interpretersprache ist so ziemlich das Allerletzte, was bei so einer Anforderung sinnvoll ist. Wenn du sowas willst oder brauchst, dann ist nicht der RasPi das Hindernis (die Hardware gibt es her), sondern Linux und Python. Wirf diesen ganzen Scheiß weg und es geht problemlos. "Bare Metal", am Besten noch in 100% Assembler (nicht unbedingt handoptimiert). Nur damit wird das Zeitverhalten deterministisch auch für mehrere Builds des gleichen Codes...
Geht der Mist schon wieder los? Musst du wirklich jeden Thread mit dieser dummen Diskussion kapern wollen? Zudem offenbar nix kapiert von dem, was dahinter steht.
c-hater schrieb: > Wenn du sowas willst oder brauchst, dann ist nicht der RasPi das > Hindernis (die Hardware gibt es her), sondern Linux und Python. Wirf > diesen ganzen Scheiß weg und es geht problemlos. "Bare Metal", am Besten > noch in 100% Assembler (nicht unbedingt handoptimiert). Ja ne, is klar. Bare-Metal auf dem Pi, alle Treiber samt der App in reinstem ASM von der ersten Instruktion beim Einschalten bis zur letzten Instruktion bei der Fertigstellung in 200 Jahren selbst implementiert. Das nenn ich Effizienz. Hast Du noch andere Hobbies?
Naja, der glaubt auch daß so eine Kiste ein exaktes Timing hätte. Die hat Latenz und Durchsatz, aber keine immer gleichen x ns für den Befehl abc. Es gibt da draußen eben vieles, was der Hater noch nicht gesehen hat. Für exaktes Timing hat Broadcom PWM-fähige Timer eingebaut, die man auch mit Scriptsprachen konfigurieren kann. Da kommt es nicht auf Geschwindigkeit an.
Schau dir mal http://abyz.co.uk/rpi/pigpio/index.html an. Das Python API verwendet einen C-Daemon in ND den erwähnten Timer um Signale im US Bereich zu lesen oder erzeugen.
Conny G. schrieb: > Ein Linux-basiertes System taugt nicht gut für solche > Echtzeitanwendungen. > Zum einen gibt es keine Timer die so fein gehen, zum anderen entzieht > das Betriebsystem wg Multitasking deinem Programm ständig die Kontrolle. > Von Millisekunden aufwärts und mit großer Toleranz im Timing könnte man > was hinfriemeln, aber wirklich kontrollieren Va nicht auf 100us oder > weniger kann man es nicht. Siehe https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs3.0.html
Rolf Magnus schrieb: > Conny G. schrieb: >> Ein Linux-basiertes System taugt nicht gut für solche >> Echtzeitanwendungen. >> Zum einen gibt es keine Timer die so fein gehen, zum anderen entzieht >> das Betriebsystem wg Multitasking deinem Programm ständig die Kontrolle. >> Von Millisekunden aufwärts und mit großer Toleranz im Timing könnte man >> was hinfriemeln, aber wirklich kontrollieren Va nicht auf 100us oder >> weniger kann man es nicht. > > Siehe > https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs3.0.html Was bedeutet dieser Chart?
Conny G. schrieb: > Was bedeutet dieser Chart? Er zeigt ein Histogramm der Latenzen des Raspberry Pi mit Raspian und einem PREEMPT_RT-gepatchten Kernel. Hier die Info über das getestete System: https://www.osadl.org/Profile-of-system-in-rack-b-slot-3.qa-profile-rbs3.0.html Da kann man erkennen, wieviel Zeit das Betriebssystem braucht, um einem Echtzeit-Thread die Kontrolle zu geben. Da sind wir beim RPi zwar nicht bei den "100us oder weniger", aber so arg weit weg davon ist man auch nicht.
Milli-Willy schrieb: > Das NEC IR-Protokoll. Hab hier eine kleine Hifi-Anlage mit DLNA, was > wiederum nicht vollständig implementiert zu sein scheint. Nun würd' ich > gern direkt am Pin des Prozessors an dem der 38kHz IR-Empfänger hängt, > die Bits reinschieben. http://manpages.ubuntu.com/manpages/hardy/man1/irsend.1.html ist Teil von http://www.lirc.org/
>http://manpages.ubuntu.com/manpages/hardy/man1/irsend.1.html ist Teil >von http://www.lirc.org/ Mit lirc hab ich Damals(TM) als Motivationsmunition erste Gehversuche auf nem Linux-Rechner gemacht. Ich möchte aber nicht die 38kHz-Impulse (27us Länge) erzeugen sondern gewissermaßen direkt mit dem Raspi den 38kHz TSOP-Empfänger simulieren. Das ganze lässt sich schön per wired-or verknubbeln. Den Raspi möchte ich, wenn alles läuft, in oder hinter der Stereoanlage verstecken.
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.