+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Module (/Forum-LabVIEW-Module)
+---- Forum: LabVIEW FPGA (/Forum-LabVIEW-FPGA)
+---- Thema: Zahlenumwandlung (/Thread-Zahlenumwandlung)
RE: Zahlenumwandlung - GerdW - 09.01.2016 20:59
Hallo Ludwig,
ja, die Nutzung eines LSRs ist bei signed integers ein Fehler.
Aber "Scale by Power of 2" ist auf dem FPGA ein Bitshift, noch dazu ohne Resourcenverbrauch!
Und Slevin will auf einem FPGA resourcenschonend arbeiten…
RE: Zahlenumwandlung - Lucki - 09.01.2016 23:56
(09.01.2016 17:52 )IchSelbst schrieb: Zumindest die 8086-Prozessoren (ich gehe davon aus, alle anderen auch) kennen zwei Typen von Schiebebefehlen: der eine heißt SAR "Shift Arithmetic right", der andere SHR "Shift Logic Bit Right".Sehr gut, das hilft weiter. Zur Veranschaulichung, wie SAR funktioniert, hier ein Bild aus Wikipedia, "arithmetic shift"
[attachment=55011]
SAR ist damit identisch mit einer Division durch 2, und zwar auch bei negativen Integerwerten. Die Funktion SAR gibt es in Labview nicht. Man kann sie sich aber aus zwei in Labview verfügbaren anderen Shift-Funktionen zusammenbasteln. (Variante 5 im Bild unten)
Damit dürfte auch das Geheimnis um Gerds "schicken" Code gelüftet sein
[attachment=55012]
RE: Zahlenumwandlung - IchSelbst - 10.01.2016 11:36
(09.01.2016 23:56 )Lucki schrieb: Die Funktion SAR gibt es in Labview nicht.Es anders zu sehen, bringt viele Vorteile.
LabVIEW fällt unter "deklaratives Programmierparadigma", also nicht unter "imperatives Programmierparadigma". Imperativ heißt, die Programmiersprache kennt auf Programmierer-Ebene den Befehl SAR (zumindest manche).
Deklarativ heißt in diesem Falle nichts anders als "beschreiben": Der Programmierer platziert (irgendwohin) Elemente (ich will mal noch nicht sagen "Objekte"), die vom Menschen aus gesehen intuitiv sind, z.B. die Addition. Dann schließt der Mensch an die beiden Eingänge im Allgemeinen "Typ-identische", oft auch nur "Typ-verträgliche"(!) "Instanzen" an: Der Typ wäre z.B. Obst, Instanzen wären dann Birne und Apfel. Das Ergebnis wäre Marmelade. Man kann an Addition natürlich auch die Typen Integer, Float, Array of Zahl, etc. anschließen (warum man nicht Strings "addieren" kann, ist mir deklarativ gesehen noch immer ein Rätsel) Kaum einer wird Typ-unverträgliche Instanzen anschließen: Apfel und Fußabstreifer. Das Ergebnis wäre ein gebrochenes Herz, pardon Pfeil.
Die Addition, die ich ja nur wegen des guten Beispiels der Marmelade gewählt habe, ersetzen wir nun durch die 2er-Potenz-Multiplikation.
Das Problem, das LV jetzt hat, ist: Wie bekommt ich - eigentlich mein Kompiler - das "deklarative Format" in ein "imperatives Format", das der Prozessor versteht, der letztendlich die 2er-Potenz-Multiplikation durchführen soll. Der Kompiler wird also die Eingänge begutachten (vergleiche http://www.ni.com/tutorial/11472/de/, siehe http://www.labviewforum.de/Thread-Speicherauslastung-von-LabView) und sich letztendlich überlegen, mit welchem Prozessorbefehl oder mit welcher Prozessorbefehl-Sequenz er dieses "Element" am besten abbilden kann. Der Kompiler wird sich also für einen SAR entscheiden genau in dem Falle, wenn x eine Ganzzahl ist.
Man kann eigentlich gar nicht sagen, LV kennt den Prozessorbefehl SAR oder kennt ihn nicht. Die Programmierer-Ebene, auf der deklariert wird, ist komplett abstrahiert von der imperativen Ausführungsebene.
RE: Zahlenumwandlung - Lucki - 10.01.2016 13:47
(10.01.2016 11:36 )IchSelbst schrieb:Ich meinte natürlich: SAR gibt es nicht in der Funktions-Palette. (Weil es dort überflüssig ist. SAR ist nämlich in der viel universelleren Funktion "Mit Potenz von 2 multiplizieren" als Spezialfall für n=-1 enthalten)(09.01.2016 23:56 )Lucki schrieb: Die Funktion SAR gibt es in Labview nicht..
RE: Zahlenumwandlung - GerdW - 11.01.2016 08:47
Hallo Ludwig,
schön, dass du so schönen Code für ein SAR entworfen hast.
Leider ist der nicht gerade resourcensparend auf einem FPGA (und verursacht aufgrund Schieberegister auch noch Latenzen)…
Sowas dagegen ist resourcensparend:
[attachment=55013]
(Die Konstanten "8" und "12" sind hier nur zum "abzählen, die können weg. Der Rest belegt keine FPGA-Resourcen.)
Ansonsten gilt weiterhin Beitrag #6: "damit landet man nämlich … beim Vorschlag von Jens 'Scale By Power of 2' "
RE: Zahlenumwandlung - jg - 11.01.2016 09:22
(11.01.2016 08:47 )GerdW schrieb: Ansonsten gilt weiterhin Beitrag #6: "damit landet man nämlich … beim Vorschlag von Jens 'Scale By Power of 2' "Und damit das mal hervorgehoben wird, habe ich mir erlaubt, dies als Lösung zu markieren...
RE: Zahlenumwandlung - Stephan235 - 07.12.2020 16:01
Hallo,
dieses Thema möchte ich gern nochmals aufgreifen.
Mit dem Sine Wave Gen. möchte ich gern auf FPGA Ebene (cRIO-9035) ein 800Hz Sinus
mit einem NI-Modul 9263 auf einem AO ausgeben.
Als Grundlage habe ich das "Sin Wave.lvproj" aus den Beispielen genommen.
Grundlegend funktioniert das auch, am Ausgang soll aber ein Sinus von 0-5 V ausgegeben werden.
Über Faktor und Offset bekomme ich das so nicht hin.
Was muss ich noch beachten?
LG
Stephan
RE: Zahlenumwandlung - GerdW - 07.12.2020 16:20
Hallo Stephan,
Zitat:Grundlegend funktioniert das auch, am Ausgang soll aber ein Sinus von 0-5 V ausgegeben werden. Über Faktor und Offset bekomme ich das so nicht hin.Was bekommst du den hin?
Was muss ich noch beachten?
Was für ein Signal erhälst du momentan am Ausgang?
Was funktioniert an Faktor/Offset nicht?
RE: Zahlenumwandlung - Stephan235 - 07.12.2020 16:34
Hallo Gerd,
am Oszi sehe ich ein 800 Hz Sinussignal, aber nur von 0-600 mV.
(Amplitude Offset = 0, Faktor Skalierung 0,0001)
Wenn ich mit den Eingangsparametern spiele komme ich gerade nicht an's Ziel.
RE: Zahlenumwandlung - GerdW - 07.12.2020 17:50
Hallo Stephan,
aus dem SinusFGen kommt ein Integer heraus. Dieses wird mit einem fetten CoercionDot mit einem FXP multipliziert: welche Datentypen kommen hier zum Einsatz?
Hat dir schon mal jemand gesagt, das man Bilder mit LabVIEW ganz schlecht editieren/debuggen kann?