Hallo zusammen,
vielleicht kann mir ja jemand helfen.
Ich habe einen Raspberry Pi 4 und lasse folgendes, sehr einfaches
Programm laufen:
1
import spidev, time
2
import bitstring as bs
3
import RPi.GPIO as GPIO
4
import numpy as np
5
6
GPIO.setmode(GPIO.BCM)
7
8
spi=spidev.SpiDev()
9
spi.open(0,0)
10
11
spi.mode=0b00
12
spi.max_speed_hz = 1000
13
14
while True:
15
spi.writebytes([10000001])
16
17
time.sleep(.1)
18
19
spi.close()
Die drei angehängten Bilder zeigen nun drei Messungen des Signals am
Oszilloskop bei gleicher Zeitachse. Ich frage mich nun, wieso der RPi
nach der falling-Edge des CS (rosa) die CLK (gelb) und das Signal
(hellblau) manchmal früher, manchmal später startet, und wieso die
CLK-Frequenz sich manchmal zu ändern scheint (engere Rechtecke).
Ich hätte gerne, dass das Signal relativ stillsteht am Oszi (weil es
eben bei jeder while-Iteration genau gleich ausgegeben wird).
Was mache ich falsch? Oder ist das ein Anzeigeproblem?
Danke euch für eure Hilfe - das hält mich gerade auf. :(
LG
Luki
Luki B. schrieb:> Was mache ich falsch?
Wenn du dir die verschiedensten SPI Dokus/Datenblätter anschaust, wirst
du finden, dass die Frequenz nur als Maximalfrequenz angegeben ist.
Solange sich alles unterhalb dieser Frequenz abspielt, ist die Welt für
alle Komponenten voll in Ordnung.
Luki B. schrieb:> Messungen des Signals am Oszilloskop
Die Flanken schau man sich mit dem Oszi an.
Ja!
Aber das wars dann auch......
Aber die logischen Signale/Pegel mit einem LogikAnalyser.
Der kommt mit dem Versatz locker klar.
Danke für die schnelle Antwort!
Den Logik Analyzer hab ich schon bestellt, der erste kam zerquetscht an.
Auch wenn ich um ehrlich zu sein das schon sehr praktisch finde, dass
das Oszi das auch so kann.
Du sagst also, das ist völlig normal dass die einzelnen Bytes nicht
gleich lang jeweils sind? Ich finde nämlich, wenn ich mit einem fixen
1kHz-Cursor suche, nirgends im Signal diese Frequenz. Das hat mich schon
immer gewundert. Auch, dass man eine maximale Frequenz angibt statt
einer fixen - in welchem Fall schaltet er denn dann in eine höhere
Frequenz? Sollte die Frequenz sich durch 2^n darstellen lassen damit es
nicht springt?
Sorry für so viele Fragen - bin noch relativ neu in der Materie :)
LG
Luki
EAF schrieb:> Die Flanken schau man sich mit dem Oszi an.> Ja!> Aber das wars dann auch......>> Aber die logischen Signale/Pegel mit einem LogikAnalyser.> Der kommt mit dem Versatz locker klar.
Was meinst du wohl, wofür das "M" in der Typenbezeichnung "MSO5074" des
Oszis steht.
Die Variation im Zeitverlauf kommt beim LA genauso an.
Der Bedientrick heißt Single-Shot und Speichertiefe.
Wolfgang schrieb:> Die Variation im Zeitverlauf kommt beim LA genauso an.
Jeder vernünftige LA hat eine Software dabei, um SPI analysieren zu
können.
Da ist irgendeine zeitliche Verschiebung doch völlig egal.
Der Versatz ist mir egal
Dem RPi egal
Dem SPI Slave egal
Der LA zeigt die Daten korrekt im Klartext.
Der Versatz zwischen /CS und den Daten, oder zwischen Bytes, ist auf
Multitasking Systemen, auch auf µC, völlig üblich. Wenn halt irgendwas
zwischendurch Zeit benötigt, dann gut.
Wenn man das zeitliche Gehackel nicht will, muss man wohl zeitweise
Interrupts sperren und eine DMA mit dem Transfer beauftragen.
Kann der RPI das?
EAF schrieb:> Jeder vernünftige LA hat eine Software dabei, um SPI analysieren zu> können.
Und meinst du, ein MSO5074 kann das nicht?
Für was mag in der Beschreibung wohl stehen: "Serial Protocol
Analysis: RS232/UART, I2C, SPI, CAN, LIN, FlexRay, I2S, and
MIL-STD-1553"
Der Versatz zwischen CS und Data/CLK kommt weil zunächst ein normaler
GPIO (CS-Pin) vom der Software angesprochen wird und dann das SPI
Hardwaremodul loslegt und ohne das Zutun des Betriebssystems die Bits
herausschiebt. Zwischen GPIO und SPI Modul kann noch irgendwas anderes
einpriorisiert werden. Und genau das beobachtet du.
Zum screenshot machen gibt es beim MSO5074 den "quick" button. Dann
tauchen die blöden Menus auch nicht mehr auf.
Alternativ ist es viel bequemer über das web interface. Dazu muss man
das oszi per ethernet verbinden.
> Du sagst also, das ist völlig normal dass die einzelnen Bytes nicht> gleich lang jeweils sind?
Finde dich damit ab. Linux ist ein Multitasking-Betriebssystem, das
muss sich manchmal auch noch um andere Dinge kuemmern. .-)
Ausserdem darf ich dich schon mal auf ein weiteres Problem hinweisen. Du
kannst auf dem Raspberry zwar einen relativ hohen Takt fahren, ich glaub
30 oder 50Mhz, aber irgendwann wirst du merken das zwischen den Bytes
die Pausen immer groesser werden. Auch damit muss man leben wenn man
Luxus eines kompletten Unix fuer ein bisschen SPI haben will.
Olaf
Für exaktes Timing nimmt man einen FPGA.
Doch sobald man ein System mit Interrupt, Taskwechsel, Cache (eben eine
normale CPU) vor sich hat, wird das Timing unscharf.
Die meisten SPI-Slaves können damit umgehen. Nur die Progremmierer vor
dem Bildschirm tun sich damit schwer.
Vielen lieben Dank euch allen :)
Dann lebe ich einfach damit, ich dachte nur irgendwas läuft schief.
Zum Verständnis noch eine hoffentlich letzte Frage: welches ist denn die
Frequenz, die man mit max_speed_hz eingrenzt, die eines ganzen
datacycles oder ein CLK-Takt?
Luki B. schrieb:> welches ist denn die Frequenz, die man mit max_speed_hz eingrenzt
Die maximale Taktfrequenz des SCLK muss begrenzt werden. Das ist der
Wert, der im Datenblatt jedes Slaves angegeben ist.
Luki B. schrieb:> die eines ganzen datacycles
Mal angenommen ein solcher "datacylce" wäre 1 Bypte lang und als
obergrenze dafür wäre 1kHz angegeben. Dann könnte man ja 1 der 8 Bits
mit 0,9999ms Taktdauer ausgeben und anschließend die restlichen 7 Bits
in den verbleibenden 100ns. Das erscheint nach ein paar Minuten
Nachdenken unlogisch...
> Doch sobald man ein System mit Interrupt, Taskwechsel, Cache (eben eine> normale CPU) vor sich hat, wird das Timing unscharf.
Nicht zwangslaeufig. Wenn du eine MCU mit genuegend grossen Buffer,
Interrupt und DMA hast dann kann man das auch ohne FPGA hinbekommen.
Olaf
Thread beobachten
Seitenaufteilung abschalten