Übertragungsverzögerung beim SPI

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.

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?

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:
> 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.

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.

Ratespiel accepted: Linux time-slicing 1ms?

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.

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.