Nichts. Das ist doch das Schöne wenn eine Komponente mit Generics
geschrieben wurde. Dieses Stück Code ist so zu verstehen wie ein
Elektronikbaustein, ein IC, der ist fertig und muss jetzt nurnoch
angeschlossen werden. Die zusätzlichen "Anschlüsse" der Generics können
diesen Baustein parametrisieren.
Okay, das ist ja gut. Wenn ich den Code jetzt als Untermodul
implementiere, muss ich dann alle Signale aus Generic und Port in der
component meiner toplevel definieren?
Also verbinde immer Port und Generic. Aber vielleicht kann man
tatsächlich Generic weglassen, dann ist aber der hier im Code
zugewiesene Wert gültig. Ich würde den Generic verbinden weil du das
dann schön anpassen kannst.
Gustl B. schrieb:> Aber vielleicht kann man> tatsächlich Generic weglassen, dann ist aber der hier im Code> zugewiesene Wert gültig.
Im Generic Map kann man diejenigen Werte weglassen, bei denen der
Default-Wert des Generics passt. (In diesem Code ist ja für jedes
Generic ein Default-Wert vorgesehen.)
Beim Port Map müssen alle Eingänge verbunden werden. (Auch für die
Inputs im Port könnten im Prinzip Default-Werte definiert werden; in
diesem Code ist das allerdings nicht geschehen, und das wird imho auch
eher selten genutzt.) Ausgänge kann man bei der Instanziierung auch
offen lassen (wenn man den entsprechenden Ausgang im Design nicht
benötigt).
VHDL-Frage schrieb im Beitrag #5737698:
> Ich bin mir aber> nicht ganz im klaren, was für Veränderungen ich an dem Code ändern muss.
Du musst wohl bei den Signalen CPHA und CPOL noch ein "in" ergänzen, das
sie als Eingänge festlegt. Das wurde anscheinend vergessen.
Ansonsten gilt wie von Gustl schon gesagt: ändern musst du nichts, nur
passend parametrisieren.
Und dann natürlich noch eine State Machine drumrumbauen, die die
diversen Konfigurationsregister deines Sensors mit den gewünschten
Inhalten beschreibt (außer der Reset-State der Register entspricht
deinen Wünschen) und dann die Status- und Ergebnisregister ausliest.
Erst einmal danke für die Antworten.
Achim S. schrieb:> Und dann natürlich noch eine State Machine drumrumbauen, die die> diversen Konfigurationsregister deines Sensors mit den gewünschten> Inhalten beschreibt (außer der Reset-State der Register entspricht> deinen Wünschen) und dann die Status- und Ergebnisregister ausliest.
Woher kann ich die Information nehmen, welchen Inhalt der Sensor
benötigt bzw. wie viele Konfigurationsregister ich brauche?
Achim S. schrieb:> Beim Port Map müssen alle Eingänge verbunden werden. (Auch für die> Inputs im Port könnten im Prinzip Default-Werte definiert werden; in> diesem Code ist das allerdings nicht geschehen, und das wird imho auch> eher selten genutzt.) Ausgänge kann man bei der Instanziierung auch> offen lassen (wenn man den entsprechenden Ausgang im Design nicht> benötigt).
Also müssten in diesem Fall nur die Port-Signale bzw. die
Eingangssignale von Port in die component, richtig?
VHDL-Frage schrieb im Beitrag #5738107:
> Woher kann ich die Information nehmen, welchen Inhalt der Sensor> benötigt bzw. wie viele Konfigurationsregister ich brauche?
Aus dem Datenblatt des Sensors. Und aus deinen eigenen Anforderungen an
die Messung.
VHDL-Frage schrieb im Beitrag #5738111:
> Also müssten in diesem Fall nur die Port-Signale bzw. die> Eingangssignale von Port in die component, richtig?
Dem Synthesetool würde das ausreichen.
Aber wenn du tatsächlich den Sensor ans FPGA anschließen willst, dann
musst du die entsprechenden Ausgänge der Komponente an die Ausgänge des
FPGAs durchreichen (also SCK und SS).
Und wenn du nicht nur den Sensor ansteuern willst sondern auch am
Ergebnis des Sensors interessiert bist, dann musst du auch diese
Ausgänge sinnvoll anschließen (als RX_Data).
Den Ausgang TX_Done könntest du ggf. tatsächlich offen lassen.
Wahrscheinlich brauchst du ihn nicht unbedingt, aber er erleichtert dir
die Gestaltung der Statmachine, die den SPI-Core benutzt.
Achim S. schrieb:> Dem Synthesetool würde das ausreichen.
Das war vielleicht etwas knapper beschrieben als es sein sollte. Deshalb
diesen Satz noch etwas ausführlicher: dem Synthesetool würde es
tatsächlich reichen, wenn du nur die Eingänge der Komponente bedienst.
Aber wenn du alle Ausgänge ignorierst erkennt das Synthesetool, dass die
Komponente überhaupt nicht benutzt wird und optimiert sie einfach weg.
Achim S. schrieb:> Das war vielleicht etwas knapper beschrieben als es sein sollte. Deshalb> diesen Satz noch etwas ausführlicher: dem Synthesetool würde es> tatsächlich reichen, wenn du nur die Eingänge der Komponente bedienst.> Aber wenn du alle Ausgänge ignorierst erkennt das Synthesetool, dass die> Komponente überhaupt nicht benutzt wird und optimiert sie einfach weg.
Vielen Dank für deine Erklärung. Ich denke ich habe es jetzt verstanden.
Doch eine Frage brennt mir noch auf der Seele:
Ich würde gerne etwas mit den ausgelesenen Daten des Sensors machen.
Sobald der Sensor meldet, dass die Höhe niedriger wird soll ein gpio(1)
<= '1'; angesteuert werden, um eine LED einzuschalten. Muss ich die von
MISO empfangene Daten noch in Dezimalsystem umwandeln, oder gehe ich da
anders ran?
VHDL-Frage schrieb im Beitrag #5738415:
> Muss ich die von> MISO empfangene Daten noch in Dezimalsystem umwandeln, oder gehe ich da> anders ran?
Du musst wissen, ob die Daten vorzeichenbehaftet sind oder immer positiv
(ob also der std_logic_vector als signed oder unsigned zu behandeln
ist). Diese Typanpassung musst du durchführen. Ansonsten musst du dich
nicht um die Zahlendarstellung kümmern.
Auch wenn du den Vergleichswert im VHDL-Code im Dezimalsystem eingibst
wird er in der generierten Logik binär dargestellt.
Bei diesem Sensor sollte man den gesamten Registersatz (mindestens aber
6 Bytes für Druck und Temperatur) "auf einen Rutsch" (Burst Read)
auslesen und nicht Byte für Byte.
Sonst kommt es zu Fehlern, wenn der Sensor während des Messens
"erwischt" wird.
Markus F. schrieb:> Bei diesem Sensor sollte man den gesamten Registersatz (mindestens aber> 6 Bytes für Druck und Temperatur) "auf einen Rutsch" (Burst Read)> auslesen und nicht Byte für Byte.>> Sonst kommt es zu Fehlern, wenn der Sensor während des Messens> "erwischt" wird.
Okay. Weißt du wie es bei diesem Sensor aussieht?
https://www.bluedot.space/sensor-boards/bmp388/
Ist ein BMP388 von BlueDot.
Markus F. schrieb:> Bei diesem Sensor sollte man den gesamten Registersatz (mindestens aber> 6 Bytes für Druck und Temperatur) "auf einen Rutsch" (Burst Read)> auslesen und nicht Byte für Byte.
Ist das eine Annahme von Dir, oder eine Empfehlung oder kommt das von
diesem Sensor?
Ich habe die Erfahrung gemacht, dass es zweckmässig ist, die Störungen
rauszurechnen oder den digitalen Teil gänzlich still zu legen
Weltbester FPGA-Pongo schrieb im Beitrag #5739021:
> Ist das eine Annahme von Dir, oder eine Empfehlung oder kommt das von> diesem Sensor?
Nö. Das steht so im Datenblatt.
VHDL-Frage schrieb im Beitrag #5737698:
> when del_pre => -- SS aktivieren und Zeit> fuer Optokoppler abwarten
Was ich auch noch nicht ganz verstanden habe ist, wofür ich einen
Optokoppler benötige. Auf der Website steht, dass man den Optokoppler
zur Potentialtrennung verwendet.
Doch ich verstehe nicht ganz, wozu das nötig ist. Außerdem wird noch
gesagt, dass auch MISO und MOSI über Optokoppler ans FPGA geführt
werden.
Achim S. schrieb:> Und dann natürlich noch eine State Machine drumrumbauen, die die> diversen Konfigurationsregister deines Sensors mit den gewünschten> Inhalten beschreibt (außer der Reset-State der Register entspricht> deinen Wünschen) und dann die Status- und Ergebnisregister ausliest.
Aber wo implementiere ich meine State Machine? In einem eignene Prozess
oder?
Soll ich die State Machine dann am besten mit einer Case-Anweisung
bauen?
VHDL-Frage schrieb im Beitrag #5746865:
> Aber wo implementiere ich meine State Machine? In einem eignene Prozess> oder?
Das ist zumindest eine Variante, die recht übersichtlich sein dürfte.
> Soll ich die State Machine dann am besten mit einer Case-Anweisung> bauen?
Ja, das bietet sich hier geradezu an:
Hallo Duke, vielen Dank für deine Antwort.
Duke Scarring schrieb:> type state_t is (IDLE, CALC, ..., WRITE, READY);
Wo steht aber, welche States ich für meine state machine brauche?
VHDL-Frage schrieb im Beitrag #5750960:
> Wo steht aber, welche States ich für meine state machine brauche?
Das hängt primär davon ab, was du mit deinen Messwerten machen willst.
Wie häufig liest du sie aus, machst du dazwischen Pausen, wartest du auf
einen Trigger, wie werden die Daten nach dem Auslesen weiterverarbeitet,
....
Ich würde den Sensor alle 0,5s auslesen, die Messwerte im SDRAM
speichern und nach 30s alle Sensorwerte auf einer SD-Karte
speichern(aber das dann in einem anderen Untermodul). Für die pausen
benötige ich dann ja einen Counter.
Muss ich dann in den States die Konfigurationsregister beschreiben?
Hm: ich gehe mal davon aus, dass es dir primär um die Beschäftigung mit
FPGAs und VHDL geht. Denn bisher macht keine deiner Anforderungen den
Einsatz eines FPGAs auch nur annähernd notwendig, so ziemlich jeder
kleine µController könnte mit wenig Aufwand deine Messaufgaben
erledigen.
VHDL-Frage schrieb im Beitrag #5751023:
> Ich würde den Sensor alle 0,5s auslesen, die Messwerte im SDRAM> speichern
Das machst du, weil du das SDRAM-Interface ausprobieren willst, richtig?
Denn um 60Messwerte zwischenzuspeicher bräuchtest du kein 32MByte SDRAM,
da würde der FPGA-interne Speicher lockerst ausreichen.
VHDL-Frage schrieb im Beitrag #5751023:
> Für die pausen> benötige ich dann ja einen Counter.
Ja: im wesentlichen wird dein FPGA-Desing aus Countern bestehen, die die
Pausen abwarten. Und dann zwischendurch mal kurz den Sensor auslesen.
Und wenn der Sensorwert ausgelesen wurde, ihn ins SDRAM speichern. Und
wenn 60 Messwerte ins SDRAM gespeichert wurden, die Werte von dort
abholen und auf das andere Modul übertragen.
Die letzten Zeilen wären so in etwas die Prosa-Beschreibung für den
Entwurf deiner Statemachine.
VHDL-Frage schrieb im Beitrag #5751023:
> Muss ich dann in den States die Konfigurationsregister beschreiben?
Irgendwo in der Statemachine wird es wahrscheinlich einen State "init"
geben (oder eine Folge von solchen States), in denen die notwendigen
Konfigurationsregister deines Sensors beschrieben werden.
Achim S. schrieb:> Das machst du, weil du das SDRAM-Interface ausprobieren willst, richtig?
Die 0,5s sind erstmal nur zum Testzweck. Wenn ich später mein System
synthetisiert und in Hardware getestet habe, werde ich die
Zeitintervalle auf 0,1s reduzieren. Wenn ich das System dann länger
laufen lasse, würde das direkte abspeichern auf die Sd-Karte diese ja
stärker abnutzen.
Achim S. schrieb:> da würde der FPGA-interne Speicher lockerst ausreichen.
Den könnte ich dann natürlich auch benutzen, insofern dies Ressourcen
spart.
VHDL-Frage schrieb im Beitrag #5751124:
> Den könnte ich dann natürlich auch benutzen, insofern dies Ressourcen> spart.
Mit allem, was du bisher beschrieben hast, verwendest du geschätzt weit
unter 0,1% der Ressourcen, die du zur Verfügung hast - der Rest der
Ressourcen wird also vergeudet. Daher nochmal der Hinweis: wenn du das
mit dem FPGA machst, weil du es genau damit machen willst, kannst du es
natürlich verwenden (und gerne auch das 32MByte SDRAM zu weit unter 0,1%
nutzen).
Wenn es dir nicht um die Beschäftigung mit dem FPGA geht sondern um das
Auslesen und Abspeichern von 10 Messwerten pro Sekunde, dann könntest du
mit einem Mikrocontroller eine wesentlich einfachere, billigere und
ressourcenschonendere Lösung umsetzen.
Da hast du natürlich recht. Ich werde diesen Code aber nur als
Untermodul in einem System nutzen. Ich habe schon Module, welche einen
Algorithmus in Hardware berechnen, eins was Servo Motoren steuert,
Beschleunigungssensor, Counter etc. Das würde sich am Ende dann
vielleicht mehr lohnen.