Hallo zusammen,
ich möchte auf meinem Nexys 4 DDR gerne den on-board
Beschleunigungssensor nutzen. Dieser kommuniziert über eine
SPI-Schnittstelle mit dem FPGA.
Nach einigen Versuchen habe ich in der Simulation nun diese Waveforms
erhalten (siehe Anhang).
Zu den Waveforms:
Der Sensor soll als erstes eingeschaltet werden, daher ein Write-Befehl
("00001010") für das Power-Register ("00101101") mit den Daten "0000
0010". Hier nach sollte der Sensor anfangen die Beschleunigungen zu
messen.
Als nächste möchte ich dann das Register mit den X-Beschleunigungen
auslesen. Dazu ein Read-Befehl ("00001011") für das Register "00001000".
Schließlich warte ich nur noch auf die Daten, die über den MISO-Kanal
reinkommen. Diese Bits sollen dann in ein Register geschoben werden und
über die LEDs auf dem Board ausgegeben werden.
In der Testbench habe ich dazu einfach ein paar Bits auf MISO gelegt und
geschaut, ob die Bits auch im Vektor der LEDs auftauchen.
Den SCLK-Takt habe ich auf 1MHz gesetzt (in den Waveforms ist es der
Übersichtlichkeit halber ein anderer (25MHz)).
Das CS-Signal (Chipselect) passt meines Erachtens auch zur Übertragung.
Mache ich irgendwas grundlegend falsch (ist meine erste
SPI-Schnittstelle)? Falls noch weitere Informationen gebraucht werden,
einfach kurz schreiben.
Hier noch der Link zu Datenblatt des Sensors:
https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL362.pdf
Und der zu dem Datenblatt des Nexys:
https://reference.digilentinc.com/_media/nexys4-ddr:nexys4ddr_rm.pdf
Bin für jede Anmerkung dankbar!
Euer Karlsson
Fragen:
* wieso bleibt in Deiner Simulation der System-Takt (clk) bei ca. 1800
ns stehen???
* Verdächtige Meldungen/Warnungen bei der Synthese?
* Du hast den Beispielcode von Digilent für das Auslesen des AXL in der
Nexys4-DDR Demo gefunden?
Karlsson schrieb:> Achso und auf dem Board leuchten bei Bewegung KEINE LEDs.
Oder sie leuchten so kurz auf, dass Du es nicht siehst? Grundsätzlich
kann alles mögliche passieren - oder eben auch nicht, ob Dein
Peripheriegerät mit Dir kommuniziert oder nicht, kannst Du sehen, wenn
Du die SPI-Signale auf einen Pmod nach außen führst und mit einem
Logic-Analyzer (zur Not mit einem Oszi) anschaust. Ob Deine Prosa
Beschreibung sich mit dem Synthese-Ergebnis deckt, lässt sich nur anhand
des Source-Codes überprüfen.
Karlsson schrieb:> Nach einigen Versuchen habe ich in der Simulation nun diese Waveforms> erhalten (siehe Anhang).
Irgendwie passt das ja nicht so richtig zu dem Timing, das im Datenblatt
des Sensors gefordert wird. Im Datenblatt sind MOSI und MISO bei der
steigenden SCLK-Flanke stabil. Bei deiner Waveform ändern sie sich genau
da, obwohl tsu und thd eigentlich jeweils mindestens 20ns sein müssen.
Du hast also schon mal die falsche Phase.
Warum hält die Simulation mitten in der Übertragung an?
Karlsson schrieb:> Achso und auf dem Board leuchten bei Bewegung KEINE LEDs.
Du wirst da sowieso mit einem LogicAnalyzer oder einem Speicheroszi ran
müssen, um zu kontrollieren, ob die Realität das macht, was die
Simulation verspricht.
Karlsson schrieb:> in den Waveforms ist es der Übersichtlichkeit halber ein anderer
Warum? Die Waveform kann man doch beliebig zoomen und den FPGA Takt
ausblenden, wenn der grüne Balken stört...
------------------------------------------------------------------------
--
EDIT: Eine Anmerkung zum Screenshot vom Datenblatt findet sich dort im
Beitrag "Re: Nexys 4 DDR - accelerometer/Beschleunigungssensor"
Versuche mal, ein SPI-Slave Modell dranzuhängen und zu schauen, ob das
überhaupt stimmig ist. Dann wäre mal die Antwort des realen Slaves
aufzuzeichnen. (OSCI)
> Irgendwie passt das ja nicht so richtig zu dem Timing, das im Datenblatt> des Sensors gefordert wird. Im Datenblatt sind MOSI und MISO bei der> steigenden SCLK-Flanke stabil. Bei deiner Waveform ändern sie sich genau> da, obwohl tsu und thd eigentlich jeweils mindestens 20ns sein müssen.> Du hast also schon mal die falsche Phase.
Ohja, stimmt! Habe ich nun geändert (siehe Anhang).
> Warum hält die Simulation mitten in der Übertragung an?
Wollte ja nur sehen, ob die Bits überhaupt reingeshifted werden. Habe
ich jetzt aber auch mal angepasst.
> Du wirst da soweiso mit einem LogicAnalyzer oder einem Speicheroszi ran> müssen, um zu kontrollieren, ob die Realität das macht, was die> Simulation verspricht.
Ich habe leider weder einen LogicAnalyzer noch ein Oszi...
Ich habe jetzt ein weiteres Register eingebaut, welches sich zweimal die
Sekunde updatet (das sollte man ja mit dem Auge sehen können).
> Warum? Die Waveform kann man doch beliebig zoomen und den FPGA Takt> ausblenden, wenn der grüne Balken sört...
Ja, stimmt schon.
Es funktioniert immer noch nicht. Meine Vermutung ist gerade, dass ich
t_CSH nicht einhalte (siehe Datenblatt). Bin noch am tüfteln, wie ich
das umsetze...
Oder kann ich nach dem PowerOn einfach direkt den read-Befehl
nachschicken, ohne vorher CS noch einmal auf high zu setzen?
Schon mal vielen Dank!
Karlsson A. schrieb:> ohne vorher CS noch einmal auf high zu setzen?
Nein. SS# ist für die Kommunikation zwingend notwendig. Jeder Transfer
wird mit SS# umrahmt. SS# zeigt an, wann eine Übertragung beginnt und
wann die Daten übernommen werden können.
> ohne vorher CS noch einmal auf high zu setzen?
Mach es einfach so wie im Datenblatt beschrieben. Dort steht, man müsse
SS# zwichen zwei Übertragungen für mindestens 20ns auf high setzen.
> Ich habe leider weder einen LogicAnalyzer noch ein Oszi...
Im Prinzip braucht man eigentlich beides: das Oszi zum Bewerten der
Signalqualität (Potentiale, Flanken, Überschwinger, Spikes, ...) und den
LA zum Analysieren des Protokolls.
Wenn du kein Oszi hast, dann kannst du mit kurzen Leitungen und
technisch gutem Aufbau vermutlich die Signalqualität ausreichend gut
hinbekommen. Ob die Pegel passen, solltest du allerdings trotzdem mal
statisch mit dem Multimeter nachmessen.
Und dann kauf dir bei Ebay so einen 8-Kanal-LA für 10€. Ohne Oszi und
ohne LA ist die Inbetriebnahme einer seriellen Schnitte so ähnlich wie
Autofahren nach Gehör: kann mit viel Glück gutgehen...
> Es funktioniert immer noch nicht
Was denn? Was erwartest du und was tut sich stattdessen?
Und im Zweifelsfall musst du eben "Divide et impera!" anwenden und
zuerst mal sicherstellen, dass aus deinem FPGA überhaupt was rauskommt
und reingeht:
was passiert denn, wenn du den ADXL abklemmst, und du dann MISO dauernd
auf High oder Low klemmst?
Und was passiert, wenn du ohne ADXL den MOSI auf MISO brückst und dann
z.B. 0x55 0xaa 0x5a sendest? Bekommst du eines der drei Bytes wieder
"zurück"?
> Es funktioniert immer noch nicht
Ich kann leider mangels deinem Code nicht beurteilen, was da passieren
könnte/würde/sollte...
Karlsson A. schrieb:> Ok, ich werde mir dann doch mal einen LA anschaffen.
Nein, den brauchst du dazu nicht. Die Simulation reicht. Aber noch
wichtiger ist es das Datenblatt
https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL362.pdf
zu lesen.
Wenn ich deinen Screenshot der Simulation sehe dann sendest du die
falsche Instruktion. Die sollte immer mit 00001 beginnen, bei dir sind
es aber 5 mal die Null. Auf weitere Fehler habe ich nicht geguckt.
Lothar M. schrieb:> Wenn du kein Oszi hast, dann kannst du mit kurzen Leitungen und> technisch gutem Aufbau vermutlich die Signalqualität ausreichend gut> hinbekommen. Ob die Pegel passen, solltest du allerdings trotzdem mal> statisch mit dem Multimeter nachmessen.
Ähm ... das ist ein fertiges FPGA Board auf dem der Sensor verbaut ist.
Da hat der Fragende hier nix selber gelötet. Es interessiert also nur
das Timing und das was da gesendet wird, das kann er simulieren.
Gustl B. schrieb:> Ähm ... das ist ein fertiges FPGA Board auf dem der Sensor verbaut ist.
Ja, da muss er die Signalintegrität tatsächlich nicht prüfen. Das haben
schon andere gemacht. Trotzdem ist so ein LA in der Schublade
langfristig recht nützlich.
> Es interessiert also nur das Timing und das was da gesendet wird, das> kann er simulieren.
Wenn das Design hübsch synchron aufgebaut ist. Denn wir sehen ja nicht,
ob da irgendwelche Tricks drin sind, deren Seitenwirkungen eine
funktionale Simulation nicht zeigt.
> Aber noch wichtiger ist es das Datenblatt zu lesen.
Und es zu verstehen und es anzuwenden, denn natürlich muss dann auch der
Rest der Simulation erst mal zum Datenblatt passen. Und demzufolge auch
der MISO nicht bei der fallenden Flanke, sondern bei der steigenden SCLK
Flanke eingelesen werden. Denn dieser Baustein speichert Daten bei der
steigenden Flanke.
> Aber noch wichtiger ist es das Datenblatt zu lesen.
Zum Thema "Datenblatt lesen und verstehen": wenn man das DB verstanden
hat, findet man dann auch leichter die Fehler, die darin versteckt sind
(siehe angehängter Screenshot)... ;-)
> Nein, den brauchst du dazu nicht. Die Simulation reicht. Aber noch> wichtiger ist es das Datenblatt> https://www.analog.com/media/en/technical-documentation/data-sheets/ADXL362.pdf> zu lesen.
Ok, hatte ich eigentlich auch gedacht.
> Wenn ich deinen Screenshot der Simulation sehe dann sendest du die> falsche Instruktion. Die sollte immer mit 00001 beginnen, bei dir sind> es aber 5 mal die Null. Auf weitere Fehler habe ich nicht geguckt.
Ohh upps... danke :D
Ich hab mir deinen Code auch mal angesehen. Du zählst ja scheinbar die
Flanken und sendest entsprechend die Bits raus, oder?
Ja. Mein Code ist nicht besonders toll oder so, aber das Prinzip ist für
Bausteine mit SPI sehr einfach.
Man nimmt einen Zähler. Das/eines der untersten Bits wird die SPI Clock.
Und in Abhängigkeit der höheren Bits werden Daten raus gegeben oder
eingelesen.
Karlsson A. schrieb:> Du zählst ja scheinbar die Flanken und sendest entsprechend die Bits> raus, oder?
Richtig, da wird beim Ausgeben und beim Einlesen jeweils ein Multiplexer
verwendet.
Ich mache das nur bei CPLDs, weil die gewaltige Produktterme haben, die
einen Multiplexer leicht machen. In FPGAs nehme ich normalerweise
Schieberegister, weil dort die Flipflops recht effizient verbunden
werden können:
http://www.lothar-miller.de/s9y/categories/45-SPI-Master
Waveform.PNG
(20 KB)
