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
Angehängte Dateien:
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.
Beitrag #5992941 wurde von einem Moderator gelöscht.
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.
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.