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"
:
Bearbeitet durch Moderator
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)
Been there, done that. https://gus.tl/fpga https://gus.tl/fpga/nexys4_accel_sim.zip Da ist eine Beschreibung samt Testbench. Oder auch im 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. 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!
Beitrag #6323235 wurde von einem Moderator gelöscht.
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...
:
Bearbeitet durch Moderator
Ok, ich werde mir dann doch mal einen LA anschaffen. Vielen Dank! :D
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.
:
Bearbeitet durch User
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)... ;-)
:
Bearbeitet durch Moderator
> 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
:
Bearbeitet durch Moderator
Bitte 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.