Hey Leute,
ich nutze auf dem FPGA vom myRIO die "sine wave generation" function. Die gibt mir einen Sinus mit einer Amplitude von +32767 bis -32768 aus. Nun möchte ich diese auf einen analogten Port am Port A geben.
Dieser Port kann nur Werte von 0-4095 verarbeiten, weil er ein 12 bit DAC ist und kann 0V-5V ausgeben.
Wie bearbeite ich den output der Sinusfunktion der I16 ist am ressourcenschonensten, um einen unsigned 12bit Wert zu bekommen. Btw. die LUT der Sinusfunktion hat 1024 Werte und darf keinen offset haben, weil ich den Sinus und Cosinus im 16bit Format noch für etwas anderes unverändert brauche.
Gruß
Slev1n
Hallo Slevin,
Zitat:Amplitude von +32767 bis -32768 aus. … Dieser Port kann nur Werte von 0-4095 verarbeiten
Simple Mathematik: Port = Amplitude /16 + 2048
Bedenke: Die Multiplikation/Division mit 2er Potenzen sind einfache Bitshifts…
Habe mit MyRio noch nicht gearbeitet, aber das ist doch ein einfaches Skalierungsproblem, dass sich doch wohl ähnlich wie im normalen Labview lösen lassen müsste:
[
attachment=55003]
edit @gerd:
Bitshift anstatt Division geht bei negativen Integerwerten aber in die Hose. Es geht nur Division.
Quotient and Remainder ist eine ganz böse Operation unter FPGA, braucht massig Resourcen. Zum Glück gibt es "Scale by Power of 2":
[
attachment=55004]
Gruß, Jens
Ok,
hab noch ne andere Idee.
Wie wäre es wenn ich das den Output einfach mit 32768 addiere. Dann hab ich nur positive integer im U16 Format. Dann nehme ich das Ganze mal 2-^4 (also bitshift).
Ich glaube ich habe mich vorhin falsch ausgedrückt bezüglich offset. Nur in der Funktion selber, die mir den Sinus erstellt kann ich keinen eingeben.
Hier mein LV-Code. Hat in der Simulation funktioniert. Falls ich mich nicht mehr melde hat es auch am FPGA funktioniert. Kann ich erst später sicher testen wenn ich wieder ein Oszi hab.
Hallo Slevin,
ich bezweifle ganz stark, dass dein Code mit DBL-Arrays auf dem FPGA funktionieren wird.
Was an den bisher genannten Beispielen gefällt dir nicht?
Auf dem FPGA verwendest du entweder FXP-Werte oder arbeitest gleich mit (unskalierten) Integerwerten: also nimm einfache ADD/SUB-Funktionen und Bitshifts für Zweierpotenzen! (Integer-Bitshifts benötigen auf dem FPGA so gut wie keine Resourcen…)
@Ludwig:
Zitat:Bitshift anstatt Division geht bei negativen Integerwerten aber in die Hose.
Wenn man das Sign-Bit erhält, ist alles schick: damit landet man nämlich nach Lesen der LabVIEW-Hilfe beim Vorschlag von Jens "Scale By Power of 2"…
(08.01.2016 14:42 )Slev1n schrieb: [ -> ]Ok,
hab noch ne andere Idee.
Wie wäre es wenn ich das den Output einfach mit 32768 addiere. Dann hab ich nur positive integer im U16 Format. Dann nehme ich das Ganze mal 2-^4 (also bitshift).
Ich glaube ich habe mich vorhin falsch ausgedrückt bezüglich offset. Nur in der Funktion selber, die mir den Sinus erstellt kann ich keinen eingeben.
Hier mein LV-Code. Hat in der Simulation funktioniert. Falls ich mich nicht mehr melde hat es auch am FPGA funktioniert. Kann ich erst später sicher testen wenn ich wieder ein Oszi hab.
Jetzt widersprichst du dir selber. Wenn du möglichst resourcensparend arbeiten willst, dann erzeugst du dir deinen Sinus gleich im I16-Format. Dann kannst du aber nicht noch 32768 draufaddieren. Deshalb, erst teilen, dann addieren.
Gruß, Jens
Oder den I16 nach I32 umwandeln, dann Offset=32768 addieren, gefolgt von einem Bitshift=-4…
(Jens' Lösung sieht aber trotzdem effizienter aus!)
(08.01.2016 14:56 )GerdW schrieb: [ -> ]@Ludwig:
Zitat:Bitshift anstatt Division geht bei negativen Integerwerten aber in die Hose.
Wenn man das Sign-Bit erhält, ist alles schick: damit landet man nämlich nach Lesen der LabVIEW-Hilfe beim Vorschlag von Jens "Scale By Power of 2"…
Mein Vorschlag war eine Division y=x/16, der Vorschlag von Jens ist aber ebenfalls keine Shift-Operation, sondern die qasi identische Division y=x/2^4. (Die Labview Funktion y=2^n macht vielleicht intern eine Shift-Operation, das ist aber belanglos. Wichtig ist nur, das der vorzeichenbehaftete x-wert nicht geshiftet, sondern dividiert wird)
Hier der Vergleich:
[
attachment=55006]
Dass Dein neuer Vorschlag zur Reparatur Deines alten Vorschlages "schick" sein könnte, erschließt sich mir nicht. Im Gegenteil: Der Code - selbstverstädlich inklusive Fallunterscheidung positiv/negativ - dürfte gegenüber der einfachen Division so skurril sein, dass man leicht auf die Idee kommen würde, daß es nur darum geht, einen offensichtlichen Irrtum nicht zuzugeben.
Gruß Ludwig
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". Unterschied: SAR behält das höchstwertige Bit bei. Das bedeutet, auch vorzeichenbehaftete Ganzzahlen können vorzichenrichtig geschoben werden. Ich gehe davon aus, ein FPGA
In der Hilfe zu "x*2^n" steht: "Wenn x eine ganze Zahl oder eine Festkommazahl ist, stellt diese Funktion das Äquivalent einer arithmetischen Stellenverschiebung dar." Das fasse ich als SAR auf. (Außerdem steht dort: Verbraucht auf FPGA weder Platz noch Zeit). Der Operator "Gerd" ist selbstverständlich (siehe Hilfe) ein Logisches, also ein nicht-Vorzeichen-beibehaltendes Schieben und ist somit hier fehl am Platz.