erste brauchbare Version meines Signalgenerators

Uiui! :-) Und "mein" feature-request (der pattern generator)? ;-)

Gruß, Nick

Obwohl CORDIC ist mein Schwerpunkt:

Ist denn eine Lookup-Tabelle bei 24 Bit noch genau genug? Wenn ich z.B. wie bei dem Spartan3E Starter Kit aktuell, eine Samplerate von 1 MHz habe und dann z.B. einen schönen sauberen Sinus mit 10 Hz ausgeben will, dann habe ich mit meinem C Programm nachgewiesen, daß der Fehler bei < +- 1 LSB liegen sollte, wenn ich 24 Bit ausgeben würde. Eine Lookup-Tabelle müsste da schon sehr groß sein (ein paar MB), um dasselbe leisten zu können.

Kommt noch. Werde ich aber am besten vorziehen, dann kann ich leichter die Generierung des AES3-Bitstreams testen.

Warum benutzt man eigentlich nicht den Bresenham-Algorithmus. Der brauch auch nur Shift, add, compare.

- Henry

Für die lineare Interpolation zwischen den Werten für eine Lookup-Table wäre das vielleicht eine gute Idee, statt wie ich es letztens per Multiplikation gelöst hatte. Aber wie soll Bresenham einen Sinus berechnen?

Ist schon 20 Jahre her. Da hatte ich auf einem 8051 und angeschlossenem

Die Erweiterung auf achsensymmetrische Ellipsen ist auch einfach.

Guckst du Wikipedia. Bresenham ist nur der Spezialfall einer allgemeineren Algorithmik.

- Henry

Ich würde dir ja gerne helfen (irgendwie) wenn du mir sagst wobei. Leider hab ich von FPGAs null Ahnung.

Gruß & in freudiger Erwartung, Nick

Huebsch! Das waere doch ein geeignetes Produkt, um es als Bausatz zu verkaufen. Bestueckte Leiterplatte, aber die Mechanik muessten die Leute selbst zusammenschrauben. Oder einen Deal mit Bausatzherstellern wie Velleman eingehen. Heathkit gibt's ja leider nicht mehr.

Macht wirklich Spaß, FPGAs zu programmieren. Von Xilinx und Altera gibt es die Tools umsonst zum Download, damit könntest du das lernen, wenn du möchtest. Simulatoren sind enthalten, sodaß man auch ohne Hardware schon seine Konfigurationen testen kann. Braucht man allerdings einige Zeit, bis man die Grundlagen gelernt hat und wie in jeder anderen Programmiersprache lernt man nie aus. Wenn ich heute meinen VHDL-Code von vor 2 Jahren sehe, dann frage ich mich, warum ich das so umständlich geschrieben hatte. Für den Signal Generator habe ich meinen RS232 Sender und Empfänger nochmal überarbeitet. Ist jetzt ca. halb so groß von der Anzahl Quelltextzeilen und das Interface ist auch einfacher geworden.

Einige trickreiche Hardwaredinge kommen dann noch dazu, die auch kein Simulator zeigt, wie z.B. interessante Probleme, wenn du einen externen Pin, der nicht taktsynchron anliegt, ohne Latch direkt auswertest. Hatte ich mal bei meinem RS232 Empfänger gemacht und mich gewundert, warum auf einmal die State-Machine stehengeblieben ist, obwohl die das eigentlich vom Quelltext her gesehen gar nicht konnte :-)

Gute Entwicklerkits mit verschiedenen nützlichen Zusatzbausteinen und Schnittstellen gibt es schon so um die 100 bis 200 Euro.

Ja, an sowas hatte ich auch schon gedacht. Könnte man vielleicht auch als richtiges Produkt rausbringen, da gute Geräte, die man auch programmieren kann, wie die von Audio Precision mit einem Visual Basic Dialekt, so ab

Eine Idee wäre die Steuersoftware auf PC-Seite per Lua scriptbar zu machen (ich habe als Initiator des "Lua Player" Projekts für die PSP mit Lua gute Erfahrungen gemacht; ist insbesondere für Programmieranfänger leicht verwendbar, eine gute Lua Library vorausgesetzt). Man sollte auch GUIs damit leicht für seinen Bedarf schnell zusammenstellen können, so wie Labview, wofür man aber auch ein Interface für den Generator schreiben könnte, um es dort einzubinden.

Das würde aber ein mehrmonatiges Fulltime Projekt werden, wozu ich im Moment leider keine Zeit habe. Daher gibt es gute kommerzielle Produkte in diesem Bereich wohl auch nicht geschenkt.

Ich weiß und ich hab es auch vor (für das nächste Projekt). Ich hab mal da etwas rumgelesen und es ist schon sehr anregend. Überzeugen brauchst du mich also nicht mehr. :-)

Gruß, Nick

Oder rede mal mit John Larkin darueber, dessen Firma baut reihenweise High-End Einschuebe fuer VME. Meist fuer Pruefanlagen:

Für Kreise brauchst du aber y=Sqrt(r²-x²), keinen Sinus, und dement- sprechend ist das, was ich als Bresenham-Kreisalgorithmus kenne, ein Verfahren zum schrittweisen Berechnen von Sqrt(r²-x²).

Stefan

"Frank Buss" schrieb:

Siehe Kreisvariante des Algorithmus:

Aber nur was zum schnell malen, nicht zum rechnen da viiiiel zu langsam! (Tabellen kann man aber so aufbauen, wenn man will.)

Ach ja, AD verwendet in seinen DDSern komprimierte Tabellen hab ich mal irgendwo aufgeschnappt.

? Ist die Berechnung des Bresenham-Kreises nicht eine kontinuierliche Sinus- und Cosinus-Berechnung?

- Henry

Nein, ist es nicht. Einen Kreis kannst du entweder als Menge aller Punkte mit x²+y²=r² ausdrücken, oder als Menge aller Punkte mit x=r*sin(Phi), y=r*cos(Phi). Der Bresenham-Kreisalgorithmus rechnet nun aus einem x,y-Paar unter Nutzung der ersten Formel ein weiteres x,y-Paar aus, und braucht damit nirgendwo den Winkel Phi. Entsprechend gibt's auch keine mir bekannte Möglichkeit, da irgendwo einen Winkel abzulesen oder einzuschleusen.

Stefan

Daß er keinen Winkel benötigt, ist ja gerade der Trick! Das Problem ist ja, das man keine praktische Möglichkeit zur Wahl der Winkelschritte vorhersehen kann, da das Winkelkoordinatensystem sich nicht auf dem rechtwinkligen System abbilden läßt.

Langsam verstehe ich was du vermutlich meinst: Du willst konstante Frequenzen ausgeben und betrachtest daher eine konstante Winkelgeschwindigkeit. Richtig?

- Henry

Henry Kiefer wrote: [Sin/Cos vs. Bresenham]

Ich nicht, aber in wollte Frank einen Sinus ausgeben, und du schlugst dafür den Bresenham vor. Für einen Signalgenerator braucht man nun üblicherweise eine konstante Winkelgeschwindigkeit und die bekommt man mit dem Bresenham nicht hin.

Stefan