Hallo zusammen,
ich habe eine Frage zur Übertragung beim SPI Bus. Im angehängten Bild
ist der CS (gelb) und der SCL (blau) abgebildet. Es werden zyklisch zwei
mal 12 Byte übertragen. DIe frage ist: Warum dauert es ~500µs zwischen
den beiden Übertragungen? Der Code ist auf das Minimum heruntergebrochen
und sollte daher eigentlich keine Limitierungen liefern. Gleichzeitig
ist aber auch die übertragungsdauer nicht konstant, sondern schwankt.
Hat jemand eine Ahnung woran das liegen kann?
Grüße Ihreismaen
Seb E. schrieb:> Der Code ist auf das Minimum heruntergebrochen
Welcher Code?
Und den Prozessor kennen wir auch nicht.
Seb E. schrieb:> sollte daher eigentlich keine Limitierungen liefern
... aber uneigentlich vielleicht schon ....
Da meine Glaskugel in Reparatur ist, müsstest Du uns schon mal den
Source Code zeigen.
Ist das SPI mit DMA? Dann überlege Dir mal wie lange die Verarbeitung im
Interrupt Handler dauert.
Seb E. schrieb:> Hat jemand eine Ahnung woran das liegen kann?
Jetzt ist es mir eingefallen: es ist Arduino Code.
Denn Arduino schützt einem davor zu wissen was man tut.
Seb E. schrieb:> IMG_20191002_091438_1153_.jpg
Da fragt man sich unweigerlich, wozu das Oszi wohl eigentlich rechts
unterm Bildschirm die USB-Buchse besitzt.
Guck mal ins Kapitel "Saving and Recalling Files With a USB Flash Drive"
im User Manual.
Ich vergaß zu erwähnen: der Master ist ein Raspberry, der Code folglich
in Python. Im Code werden wie erwähnt nur zwei Bytearrays übertragen.
Aber warum die Lücke dazwischen? Kann das am Kernel liegen?
Seb E. schrieb:> Ich vergaß zu erwähnen: der Master ist ein Raspberry, ....
Dann wundert mich nichts mehr.
Seb E. schrieb:> der Code folglich in Python.
Ist das zwingend, ja?
Nebel Stocherer schrieb:> Seb E. schrieb:>> Ich vergaß zu erwähnen: der Master ist ein Raspberry, ....>> Dann wundert mich nichts mehr.>> Seb E. schrieb:>> der Code folglich in Python.>> Ist das zwingend, ja?
Hast du auch sinnvolle Kommentare im Angebot, oder nur Sarkasmus?
Seb E. schrieb:> Hast du auch sinnvolle Kommentare im Angebot, oder nur Sarkasmus?
Wenn bei dir aus "Raspberry" die Programmiersprache Python
folgt und das für dich sozusagen selbstverständlich ist ....
Seb E. schrieb:> ich habe eine Frage zur Übertragung beim SPI Bus. Im angehängten Bild> ist der CS (gelb) und der SCL (blau) abgebildet. Es werden zyklisch zwei> mal 12 Byte übertragen.
Ich nehme an, jeweils zwei dicht benachbarte blaue Gezappel sind die
zwei Übertragungen von je 12 Bytes? Und dann wiederholt sich das?
> DIe frage ist: Warum dauert es ~500µs zwischen> den beiden Übertragungen?
Das darfst du uns nicht fragen. Du hast den Code geschrieben. Wie
sieht der aus?
Aber selbst beim minimalistischen
1
while(1){
2
spi_send1();
3
spi_send2();
4
}
kann man nicht erwarten, daß die Pause zwischen spi_send1() und
spi_send2() exakt genauso lang sein wird wie die andere Pause zwischen
spi_send2() undspi_send1(). Weil es das eine Mal linear im Code
weitergeht und das andere Mal ein Rücksprung zum Schleifenanfang
dazwischen liegt. Wieviel das ausmacht, hängt von Details ab, die du
nicht preisgibst.
> Gleichzeitig> ist aber auch die übertragungsdauer nicht konstant, sondern schwankt.
Das kann ich da nicht herauslesen.
> Hat jemand eine Ahnung woran das liegen kann?
Am Code? Am SPI (Hardware, Software, DMA, Puffergröße?)?
Wir kennen ja wirklich gar keine Details. Du schon.
Axel S. schrieb:>> Hat jemand eine Ahnung woran das liegen kann?>> Am Code? Am SPI (Hardware, Software, DMA, Puffergröße?)?> Wir kennen ja wirklich gar keine Details. Du schon.
Wahrscheinlich liegt es auch am Betriebssystem, dessen Echtzeitfähigkeit
nicht die Erwartungen erfüllt und so zu nicht erwarteten Schwankungen in
der Ausführung vom Python Code führt.
Solange am Raspberry ein Display hängt (oder auch nur wenn
die Software des Raspberry meint ein Display antreiben zu
müssen) und dieses Display so klein ist dass es noch über
SPI gesteuert ist dann wird wohl dauernd ein zyklischer
Display-Update dazwischenfunken. Denn externes SPI gibt's
nur einmal.
Tip schrieb:> Da fragt man sich unweigerlich, wozu das Oszi wohl eigentlich rechts> unterm Bildschirm die USB-Buchse besitzt.
Ist doch egal, in einer *.bmp Datei würde man nicht wirklich mehr sehen.
Das Foto ist doch gut.
Tip schrieb:> Seb E. schrieb:>> IMG_20191002_091438_1153_.jpg>> Da fragt man sich unweigerlich, wozu das Oszi wohl eigentlich rechts> unterm Bildschirm die USB-Buchse besitzt.>> Guck mal ins Kapitel "Saving and Recalling Files With a USB Flash Drive"> im User Manual.
Das Oszi ist so alt, dass es USB-Sticks mit maximal 1GB nimmt. Und die
sind hier leider rar.
Nebel Stocherer schrieb:> Solange am Raspberry ein Display hängt (oder auch nur wenn> die Software des Raspberry meint ein Display antreiben zu> müssen) und dieses Display so klein ist dass es noch über> SPI gesteuert ist dann wird wohl dauernd ein zyklischer> Display-Update dazwischenfunken. Denn externes SPI gibt's> nur einmal.
Der Raspi wird mit SSH ferngesteuert, der SPI Bus sitzt an den GPIOs.
Sollte in dem Fall doch kein Porblem sein oder?
Axel S. schrieb:> Du hast den Code geschrieben.
Leider nein, da liegt ja das Problem. Aber ich muss dafür damit klar
kommen. Deswegen besteht das Problem ja.
Seb E. schrieb:> Das Oszi ist so alt, dass es USB-Sticks mit maximal 1GB nimmt. Und die> sind hier leider rar.
Ich habe eins, dass laut Anleitung maximal 2GB nimmt. Aber ich konnte
einen 8GB Stick benutzen, nachdem ich die FAT Partition auf 2GB
verkleinerte (6GB bleiben ungenutzt).
Seb E. schrieb:> Nebel Stocherer schrieb:>> Solange am Raspberry ein Display hängt (oder auch nur wenn>> die Software des Raspberry meint ein Display antreiben zu>> müssen) und dieses Display so klein ist dass es noch über>> SPI gesteuert ist dann wird wohl dauernd ein zyklischer>> Display-Update dazwischenfunken. Denn externes SPI gibt's>> nur einmal.>> Der Raspi wird mit SSH ferngesteuert, der SPI Bus sitzt an den GPIOs.> Sollte in dem Fall doch kein Porblem sein oder?
So wie du hier schreibst hast du nichts verstanden. Da bleibt
auch keine Lust übrig dir das nochmal auseinanderzudröseln.
Ausserdem mangelt es dir stark daran, klar verständlich und
umfassend deine Konfiguration darzustellen. Damit ist dir
nicht zu helfen.
Jim M. schrieb:> Da meine Glaskugel in Reparatur ist, .....
> Der Code ist auf das Minimum heruntergebrochen> und sollte daher eigentlich keine Limitierungen liefern.> der Master ist ein Raspberry, der Code folglich> in Python. Im Code werden wie erwähnt nur zwei Bytearrays übertragen.
Zeige mal den Code!
> Ratespiel accepted: Linux time-slicing 1ms?
Vermute ich auch, irgendwas in dieser Richtung.
Wolfgang schrieb:> Wahrscheinlich liegt es auch am Betriebssystem, dessen Echtzeitfähigkeit> nicht die Erwartungen erfüllt und so zu nicht erwarteten Schwankungen in> der Ausführung vom Python Code führt.
An eine Linux-Distribution, in welcher der Kernel keine der
Echtzeiterweiterungen eingebaut hat, hat man gar keine Erwartungen an
die Echtzeitfähigkeit...
Seb E. schrieb:> Axel S. schrieb:>> Du hast den Code geschrieben.>> Leider nein, da liegt ja das Problem. Aber ich muss dafür damit klar> kommen. Deswegen besteht das Problem ja.
Ich kann ehrlich gesagt nicht erkennen, worin das Problem bestehen soll.
Unter einem Nicht-Echtzeitbetriebssystem und dann auch noch mit einer
Interpretersprache wie Python kannst du genau gar keine Anforderungen
an den zeitlichen Ablauf deiner SPI-Übertragungen stellen.
Falls das irgendwie erwartet wurde, dann sind einfach die Erwartungen
unrealistisch.
John Doe schrieb:> An eine Linux-Distribution, in welcher der Kernel keine der> Echtzeiterweiterungen eingebaut hat, hat man gar keine Erwartungen an> die Echtzeitfähigkeit...
Unsinn, Echtzeitfähigkeit ohne quantitative Angabe ist ein Gummibegriff.
Von jedem Raspberry erwartet man, auch ohne Kernel mit expliziter
Echtzeiterweiterung, dass er in absehbarer Zeit auf äußere Ereignisse
(z.B. einen Tastendruck auf der Tastatur) reagiert.
Wolfgang schrieb:> Von jedem Raspberry erwartet man, auch ohne Kernel mit expliziter> Echtzeiterweiterung, dass er in absehbarer Zeit auf äußere Ereignisse> (z.B. einen Tastendruck auf der Tastatur) reagiert.
z.B. in 1ms? ;-)
Joe F. schrieb:> Wolfgang schrieb:>> Von jedem Raspberry erwartet man, auch ohne Kernel mit expliziter>> Echtzeiterweiterung, dass er in absehbarer Zeit auf äußere Ereignisse>> (z.B. einen Tastendruck auf der Tastatur) reagiert.>> z.B. in 1ms? ;-)
"echtzeitfähig" ist einer der am häufigsten fehlverstandenen Begriffe.
Ein Prof meiner Alma Mater pflegte es so auszudrücken: "echtzeitig ist
rechtzeitig".
Insbesondere hat "Echtzeit" nichts mit "schnell" zu tun. Der springende
Punkt ist, daß es ein Echzeitsystem garantierte maximale Reaktionszeit
auf ein externes Ereignis hat. "Maximal" im Sinne von "es dauert nicht
länger". Ob diese Reaktionszeit nun 1ms, 1s oder 10min ist, ist eine
Frage der Anwendung. Aber für die Beurteilung, ob es ein Echtzeitsystem
ist, zählt lediglich, daß die garantierte Reaktionszeit unter allen
Umständen eingehalten wird.
Auch für das "Problem" des TE ist Echtzeit die falsche Kategorie. Er hat
wohl erwartet, daß es a) schneller und b) gleichmäßiger geht. Leider
sagt er nicht, warum oder in welchen Grenzen. Denn selbstverständlich
kann auch ein stinknormaler Linux-Kernel IO in schnell und gleichmäßig.
Man denke nur an Gigabit-Ethernet oder isochrone USB-Transfers. Nur
implementiert man so etwas halt nicht im Userspace und nicht in Python.
Eine eigene Frage?
Dieser Thread ist über 7 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
IMG_20191002_091438_1153_.jpg
(240 KB)
