Hi, ich hoffe ihr könnt mir helfen. Ich soll für ein Projekt Radar-Signale nachbilden und brauche dafür einen Pulse Train oder Pulse Pattern Generator. Ein Abitrary Waveform Generator würde auch gehen, aber der wäre schon zu überdimensioniert. Benötige eine Auflösung von 25nS, also 40MHz. Es sollen unterschiedliche Pulseweiten abgegeben werden, mit unterschiedlichen Pulsepausen. Das ganze ohne Display und als Embedded Gerät, es soll nicht in einen PC rein. Möglichst über RS232 oder SPI ansteuerbar. Hat einer von Euch eine Idee wo ich so was finde? Danke Thorsten
Ausgehend von meinen AVR-Erfahrungen könnte ich mir was mit einem µC (RS232 und Signal-Bereitstellung) und einigen HC-Logik Schieberegistern vorstellen. Dazu noch ein 40 MHz Oszillator. Das könnte aber auch nur mit einem 40 MHz schnellen µC gemacht werden. Mal sehen, was noch für Vorschläge kommen...
Schön wäre es wenn es da was fertiges gibt. Eine Auflösung von 25nSekunden und bei einer maximalen PRT von 3mSekunden sind das schon 120.000 Schritte je Puls. Wenn ich von max. 15 verschiedenen Pulsen ausgehe dann sind es maximal 1.800.000 zu speichernde Werte. Gibt es solche Schieber? Gruß Thorsten
Der Rigol DG 4102 kostet um die EUR 1000 inkl. Steuer. http://www.eu.rigolna.com/products/waveform-generators/dg4102/ Kann 40 Mhz Rechteck. Ich denke wenn Du mit einer Eigenentwicklung anfängst ist es teurer. Unter diesen Preis fällt mir auch nichts ein. Da eine Rechteckstufe mit 40 MHz eine ziemliche Herausforderung darstellt.
Vielleicht dieser hier: http://www.byteparadigm.com/products/wave-gen-xpress/ Gibt's bei Stantronic für 450€ +MWSt.
Du könntest sowas selbst bauen, durch Verwendung von FIFO-Ram oder Serial-Ram. Beliebiges Bitmuster durch uC reinschreiben und dann auf Befehl oder durch HW-Trigger gesteuert ausgeben. 40 MHz ist eher langsam. Speichertiefe? Auch quasi-analog über schnellen DAC möglich. http://de.mouser.com/Semiconductors/Memory/FIFO/_/N-488uv Gruss
@GB: Danke, der wave-gen-xpress ist schon sehr interessant. Ich will es ja ohne Display und möglichst klein. Problem ist, dass ich es nicht über USB steuern kann. In dem Gerät wo es rein muss ist nur eine serielle RS232 Verbindung zu dem 15 Meter entfernten PC möglich. Kann da auch keine Kabel legen. Muss mal schauen wie ich damit die Pulse generieren kann. @Erich: selber bauen schwebt mir als Option auch vor, nur weis ich nicht wie ich sauber bis zu 1.8Mio Daten in den Speicher schíeben und rausbekommen soll. Gibt es so grosse serielle Schieberegister? Ausserdem ändert sich ja die Speicherlänge, kann man die Resetten, damit die von vorne schieben? Bin für weitere Vorschläge offen. Thorsten
:
Bearbeitet durch User
@ Thorsten F. >nur weis ich nicht wie ich >sauber bis zu 1.8Mio Daten in den Speicher schíeben >und rausbekommen soll. Rein: durch /WR in den Speicher (Fifo-Ram) Raus: durch /RD >1.8Mio Ist dein "Bitmuster" eine "0" / "1" Leitung oder ein (Pseudo-) Analogsignal? Beides geht. Mehr Speicher, mehr Geld, klar. >Gibt es so grosse serielle Schieberegister? Ja. Betrachte einfach ein Datenbit des Fifo-Ram als "Schieberegister". Oder nehme ein externes schnelles Schieberegister (CD74AC299), wobei dann das Fiforam nur mit 1/8 der Frequenz des Schieberegisters getaktet wird. Lösungen mit FPGA sind auch denkbar. Für NF (20 MHz) geht evtl. auch was mit Microchip 23LCV1024. Für den Anfang würde ich dir aber was fertiges empfehlen. Gruss
@Erich: Mein Bitmuster ist nur 0 und 1. Die Fifo´s die ich gefunden habe sind alle nicht so einfach. Ich brauche ja einen seriellen FIFO, wo ich einen clock und data-in habe und hinten dann data-out. Ausserdem muss ich ja in die loop gehen, wenn alle Daten drin sind. wenn ich nur einen 100ns Pulse nutze und 5ms Pulsepause habe, dann sind es ja nur 5,1ms Daten oder 204 Datenwörter (0+1) Wenn es aber 12 Pulse von 2µs bis 3µs sind mit unterschiedlichen Pulsepausen bis zu 2,5ms dann sind es bis zu 1.8Mio Datenwörter, die genau so in den fifo müssen und dann auf loop dauerhaft gesendet werden. Kennst du einen Fifo der dafür in Frage kommt? Ich habe so was schon mal gebaut, allerdings nur mit 256 Datenbits fest und 9kHz Takt. Hier sind es immerhin 40MHz. Danke Thorsten
@Thorsten F. Habe mal was gemacht mit dem TI SN74V263 (=IDT 72V263) http://www.ti.com/product/sn74v263-ep allerdings nur in Modus "schnell schreiben" und vom uC langsam auslesen wenn voll (100 MHz ADC am Eingang). Ob das mit deinem "Loop Mode" gehen würde ist fraglich. Habe auch noch nicht so recht verstanden was du genau für "Pausen" etc. machen möchtest. Wahrscheinlich bräuchtest du doch eine spezielle Lösung, basierend auf FPGA und evtl. einem externen Ram da dran. Die Muster der Pulse und Pausen müsste man mit einer State Machine als Microcode festlegen. GOOGLE: state machine microcode pulse pattern Treffer z.B. http://ir-library.ku.ac.ke/bitstream/handle/123456789/386/Elijah%20Kithuku%20Mithanga.pdf Gruss
@Erich: Danke für deine Antwort. eine logische 1 ist für mich der Pulse, eine logische 0 die Pause. Sorry. Ich muss zwischen 10 und 3.000.000 '1'en und '0'en hintereinander speichern, die ich schnell wieder in einer loop ausgeben kann, getriggert von dem 40MHz quarz. Reinladen kann ruhig langsamer gehen, Hauptsache die Sache läuft rund. Dein IC schaue ich mir mal an. Gruß Thorsten
Vielleicht irgendein Stand-alone-Programmiergerät für Mikrocontroller mit 40MHz Jtag-Clock. Bisher habe ich allerdings nur einen mit USB-Anschluss gefunden (JtagJet von Signum). Vielleicht bei Lattice, Actel und Xilinx suchen.
Kein Problem. 25ns Auflösung heißen 40 Mio bits pro Sekunde. Das klingt viel, ist aber eigentlich trivial zu speichern: Run Length Coding. => RLC kodierte Daten in ein FPGA BRAM packen, der kann den Rotz gaaanz bequem mit 40MHz, wenn du meinst auch 200MHz raushauen. Größe: ein TQFP144 und ein SOT6-Flash. Kosten: 50 Euro für alles zusammen. Falls du die HW nicht selbst machen willst: http://www.xilinx.com/products/boards-and-kits/AES-S6MB-LX9.htm Kost 100 Euro, ist winzig klein, hat sogar Ethernet.
Achso, das Microcode Zeug halte ich für schwachsinn. Man muss nicht gleich aus allem Raketenwissenschaft machen. Eine einfache Statemachine, die RLC dekodiert reicht locker.
Hallo Gast, danke, aber ich möchte es ungerne als RLC abspeichern, dann muss ich es ja auch wieder zurückdekodieren vor dem ausgeben. Damit habe ich nichts gewonnen. Ich würde halt gerne die Bitfolge von 1en und 0en irgendwo reinschieben, Schalter umlegen und diese Bitfolge wird dann andauernd mit dem 40Mhz Clock ausgegeben. So mache ich es jetzt auch mit einem 256bit Schieberegister, nur leider gibt es so was nicht für 3mbit... Gruß Thorsten
Thorsten F. schrieb: > Damit habe ich nichts > gewonnen. Na klar! Du kommst mit weniger Speicherplatz aus...
Die Fa. [www.head-electronic.de] baut u.a. Ansteuerungen für Laser. Vielleicht ist der [http://www.head-electronic.de/57-0-Pulse+Generators.htm] geeignet? Kann RS485 und USB.
Thorsten F. schrieb: > danke, aber ich möchte es ungerne als RLC abspeichern, dann muss ich es > ja auch wieder zurückdekodieren vor dem ausgeben. Damit habe ich nichts > gewonnen. Das macht doch das FPGA intern. Dein ganzes Projekt ist halt ernsthaft eine State Machine, da ist das SPI Interface programmieren ja schon schwieriger als die eigentlich Logik inklusive RLC. Für dich nach außen sieht es so aus als würdest du 1er und 0er direkt speichern, intern macht der FPGA halt RLC. Das heißt, du bringst mehr 1er und 0er im FPGA unter, solange sie einigermaßen korreliert sind. Du sprachst von 120.000 bit pro Puls. Mit RLC werden das halt 32 bit oder so. Wenn du ein bisschen mehr Aussagen über die Pulse machen könntest, wäre das natürlich super. Was heißt übrigens "klein" für die Platine? Wie groß darfs werden? Im zweifel kann man übrigens auch an einen FPGA super externen RAM hängen. Das ist einfach viel besser und sauberer als eine Lösung per Mikrocontroller und kleiner und stromsparender als diskrete Logik.
@PGM: danke, aber der kann nur bis 250ns Pulsebreite, das reicht nicht. @all: Eigentlich brauche ich ja nur was ganz simples. Ich soll einfache Pulse erzeugen. Ein Pulse besteht aus dem Pulse selber, welches als logische 1 gespeichert wird und einer Pulsepause als logische 0. Die Bitfolge gebe ich auf einen schnellen HF-Schalter der mit das HF-Signal durchschaltet oder sperrt. Der Pulse (1) kann von 50ns bis zu 100µs lang sein mit einer 25ns Auflösung. Die Pulsepause (0) von 1µs bis zu 2,9ms lang sein. Es sollen bis zu 15 verschiedene Pulse und Pulspausen nacheinander abgegeben werden können um dann wieder mit dem ersten weiter zu machen. Das ganze wird dann mit einer 40MHz Clock angetrieben. Meine Berechnung war deshalb: maxPulselänge mit Pause = 3ms / kleinste Pulseauflösung 25ns = 120.000 Bitwerte 120.000 Bitwerte * 15 verschiedene Pulse = 1.800.000 max. Bitwerte Ich würde halt gerne die 1en und 0en irgendwo abspeichern (Ringspeicher, FIFO, Schieberegister) und dann die clock drauf schalten, so dass es dann stundenlang diese Pulsefolge ausgibt, bis halt eine neue Pulsefolge reingeladen wird und diese dann ausgegeben wird. Wenn ich es als RLC im FPGA abspeicher, dann muss ich es ja erst wieder dekodieren, auf einen parallel/seriell Schieber geben und mit der clock ausgeben. Dafür muss ich ja immer nach 8 Bit das nächste Byte bearbeiten und bereit stellen. Ich habe schon erfahrungen mit CPLD und FPGA von Xilinx, aber wie ich das hier in VHDL in der ISE reinproggen soll, da fehlt es mir noch an Wissen. Ich bin eher der AVR-progger. Gruß Thorsten
Thorsten F. schrieb: > Wenn ich es als RLC im FPGA abspeicher, dann muss ich es ja erst wieder > dekodieren, auf einen parallel/seriell Schieber geben und mit der clock > ausgeben. Dafür muss ich ja immer nach 8 Bit das nächste Byte bearbeiten > und bereit stellen. > Ich habe schon erfahrungen mit CPLD und FPGA von Xilinx, aber wie ich > das hier in VHDL in der ISE reinproggen soll, da fehlt es mir noch an > Wissen. Ich bin eher der AVR-progger. Das ist Quatsch! Du brauchst NUR das FPGA. Der dekodiert das selbst und gibt es als bitstrom aus. Du brauchst keine Schieberegister, keinen weiteren Takt, nichts. Nur das FPGA, dessen Stromversorgung und einen Konfigurationsflash. Thorsten F. schrieb: > Der Pulse (1) kann von 50ns bis zu 100µs lang sein mit einer 25ns > Auflösung. > Die Pulsepause (0) von 1µs bis zu 2,9ms lang sein. > > Es sollen bis zu 15 verschiedene Pulse und Pulspausen nacheinander > abgegeben werden können um dann wieder mit dem ersten weiter zu machen. > > Das ganze wird dann mit einer 40MHz Clock angetrieben. > > Meine Berechnung war deshalb: > maxPulselänge mit Pause = 3ms / kleinste Pulseauflösung 25ns = 120.000 > Bitwerte > 120.000 Bitwerte * 15 verschiedene Pulse = 1.800.000 max. Bitwerte Trivial mit RLC lösbar. Wirklich. Wenn du 32bit Worte benutzt, kannst du pro 32bit ca 26 Sekunden Pulsdauer/Pause speichern. Auf 25ns genau. Oder auch 5 Sekunden Pulsdauer mit 5ns Auflösung. Das dürfte so das maximum sein, was der FPGA ohne größere Tricks am Ausgang packt. Bei den 75 kBit BRAM die ein XC6SLX4 (10$ bei Digikey in TQFP144) hat, kannst du also 2400 32bit Worte speichern. Falls ein Puls wirklich nur aus 3 32bit Worten besteht (Puls, Pause und Deskiptor) bringst du 800 verschiedene Pulse unter. Ich sehe dein Problem einfach nicht.
Thorsten F. schrieb: > Der Pulse (1) kann von 50ns bis zu 100µs lang sein mit einer 25ns > Auflösung. > Die Pulsepause (0) von 1µs bis zu 2,9ms lang sein. > > Es sollen bis zu 15 verschiedene Pulse und Pulspausen nacheinander > abgegeben werden können um dann wieder mit dem ersten weiter zu machen. > > Das ganze wird dann mit einer 40MHz Clock angetrieben. Ohne jetzt eine konkrete Lösung zu haben, die Pulserzeugung könnte sich u.U. mit einem einzelnen µC machen lassen. Dazu wäre eine höhere Taktfrequenz sehr sinnvoll 80MHz oder besser noch 160MHz. Die Zeiten Puls, Pause, Puls, ... werden per DMA aus einem Ringspeicher in ein output-compare-Register eines Timers geschrieben, welcher jeweils ein Toggeln des betreffenden Ausgangs veranlaßt. Oder man erzeugt mit einem Timer (Monoflop) den Impuls und triggert diesen über einen weiteren Timer, der das Intervall von Puls-Pause erzeugt. Das Nachladen erfogt wiederum per DMA. Ob der STM32F4xx mit 160MHz dafür geeignet ist, habe ich noch nicht überprüft. Einfach und elegant wäre es allemal.
M. N. schrieb: > Ohne jetzt eine konkrete Lösung zu haben, die Pulserzeugung könnte sich > u.U. mit einem einzelnen µC machen lassen. > Dazu wäre eine höhere Taktfrequenz sehr sinnvoll 80MHz oder besser noch > 160MHz. Die Zeiten Puls, Pause, Puls, ... werden per DMA aus einem > Ringspeicher in ein output-compare-Register eines Timers geschrieben, > welcher jeweils ein Toggeln des betreffenden Ausgangs veranlaßt. > Oder man erzeugt mit einem Timer (Monoflop) den Impuls und triggert > diesen über einen weiteren Timer, der das Intervall von Puls-Pause > erzeugt. Das Nachladen erfogt wiederum per DMA. Das halte ich für sehr unsauber. Die CPU müsste alle 4 Takte ein Datenbit raushauen. Das schreit schon nach Assembler Code. Timer dafür benutzen wäre natürlich möglich, finde ich aber sehr komisch und klingt zumindest unflexibel. Was wenn der Timer nur 2 Takte zählt? Kommt dann der Interrupt zum neuen Wert laden früh genug? Alles eher kritisch. Ein FPGA macht das Taktgenau mit 200MHz in der ganzen logik!
Guest schrieb: > Das ist Quatsch! Du brauchst NUR das FPGA. Der dekodiert das selbst und > gibt es als bitstrom aus. Du brauchst keine Schieberegister, keinen > weiteren Takt, nichts. Nur das FPGA, dessen Stromversorgung und einen > Konfigurationsflash. Quatsch ist es nicht. Ich muss es halt alles im FPGA unterbringen und den programmieren. Die Daten müssen da rein, er muss es speichern und ausgeben. Mir ist klar das ein richtig dimensionierter FPGA das kann, nur kann ich den auch dahin proggen, das er es so macht. @M. N. (msx) µc wäre mir ja auch lieber, nur muss ich dann die Routinen dauerhaft laufen lassen mit Timern ums es wirklich sauber auszugeben. Ich mag es lieber wenn ich den µc für die Kommunikation mit dem PC nutze, der die Hardware steuert, evtl. noch Fehler und Temperaturen meldet und sich sonst langweilt. Also µc der die Steuerung und Kommunikation übernimmt und es zum FPGA weiter gibt. Der gibt dann die Pulse aus. @Guest Meinst du deine vorgeschlagene Platine reicht für erste Tests? http://www.xilinx.com/products/boards-and-kits/AES-S6MB-LX9.htm Gruß Thorsten
Thorsten F. schrieb: > Quatsch ist es nicht. Ich muss es halt alles im FPGA unterbringen und > den programmieren. Die Daten müssen da rein, er muss es speichern und > ausgeben. > Mir ist klar das ein richtig dimensionierter FPGA das kann, nur kann ich > den auch dahin proggen, das er es so macht. Statt noch ne Woche mit komischen Mikrocontroller Ansätzen zu verbringen könntest du damit anfangen... Richtig dimensioniert ist übrigens eher ein Witz, der kleinste Spartan6 kann das locker. Das schafft sogar der kleinste Spartan3 würde ich behaupten. Du hast kein Platz-Problem. Thorsten F. schrieb: > @Guest > Meinst du deine vorgeschlagene Platine reicht für erste Tests? > http://www.xilinx.com/products/boards-and-kits/AES-S6MB-LX9.htm Locker. Da ist im Grunde sogar ein Haufen Zeug drauf, das du nicht brauchst. 128MByte RAM den kein Schwein sauber zum laufen bringt zum Beispiel. Oder ein Ethernet Phy. Der FPGA sollte meiner Meinung nach locker reichen, ich denke dass sogar der XC6SLX4 reichen würde. Allerdings kann ich nicht empfehlen erstmal ein Board zu kaufen. Ganz im Gegenteil, mach erstmal den VHDL Code, den kann man wunderbar simulieren. Wenns anfängt in der Simulation gut auszusehen kann man über Hardware nachdenken. Willst du die Pulse eigentlich (im FPGA) persistent speichern, oder ist es egal, wenn die Weg sind wenn der Strom weg ist, weil sie eh ein µC reinläd?
Andere Möglichkeit: PIC32 (oder STM oder oder oder) über 32Bit SPI Transfer raus mit 40MHz. Pro Puls 15kByte. 128k hat z.B. Pic32MX370. Wäre zumindest recht einfach. Es gibt auch die MZ Typen mit 512kByte Ram.
Thomas S. schrieb: > Andere Möglichkeit: PIC32 (oder STM oder oder oder) über 32Bit SPI > Transfer raus mit 40MHz. Pro Puls 15kByte. 128k hat z.B. Pic32MX370. > Wäre zumindest recht einfach. Es gibt auch die MZ Typen mit 512kByte > Ram. 15*15kByte = 225kByte > 128kByte. Auch hier könnte man mit RLC anfangen, dann hat man 25ns*8 = 200ns Zeit. Bei einer 100MHz CPU wären das 20 Takte zum dekodieren. Vermutlich machbar, aber muss das wirklich sein?
Guest schrieb: > Das halte ich für sehr unsauber. Die CPU müsste alle 4 Takte ein > Datenbit raushauen. Das schreit schon nach Assembler Code. Da sollte man mal Klementine fragen: "Was ist sauber und was ist rein?" Die CPU muß garkein Datenbit anfassen, sondern lediglich den DMAC aktivieren und nach Ablauf einer Sequenz eine neue triggern. Dass ich den STM32F4xx genannt hatte, liegt an seiner hohen Taktfrequenz von 160MHz für die Timer. Unter Umständen würde ein Renesas RX62, der auf Grund der 25ns Quantelung nur mit 80MHz laufen dürfte, diese Aufgabe völlig freilaufend schaffen. Neben DMAC hat er noch einen DTC, welche völlig unabhängig von der CPU Daten durch die Gegend schauffeln können. Allerdings können die Timer nur mit halben CPU-Takt laufen, was bei der konkreten Aufgabe einen Tick zu schnell sein könnte. Der RAM-Bedarf wäre mit einer Puls-Pausen-Tabelle und DMA-Ausgabe verschwindend gering. Die Lösung wäre nicht nur sauber oder rein sondern astrein! Bei der jetzigen Witterung denke ich aber nicht weiter darüber nach :-)
Doch noch eine Überlegung. Knackpunkt sind ja die kurzen Pulse, die ein Timer erzeugen müßte. Hier könnte man mit ein bißchen Hardware 'schummeln', indem diese zum Beispiel die '1'-Impulse um 8 Zyklen verkleinert. Um dann einen 50ns Impuls zu erzeugen, wird dieser nicht direkt mit dem Wert 2 erzeugt, sondern mit dem Wert 10, was 250ns entsprechen würde. Dadurch dass die Impulsdauer um 8 Zyklen verkürzt wird, erscheinen am Ausgang wieder nur 50ns Impulse. Da die Intervalle immer >= 1µs sind, stört der 250ns Impuls nicht das restliche Timing. Wer sich daran erinnert, wie seinerzeit beim 68000 das Timeout für das DTACK-Signal per 74LS164 gesteckt wurde, kann den Gedanken schnell nachvollziehen. Ansonsten selber eine kleine Schaltung zur Impulsverkürzung ausdenken.
M. N. schrieb: > Die CPU muß garkein Datenbit anfassen, sondern lediglich den DMAC > aktivieren und nach Ablauf einer Sequenz eine neue triggern. > Dass ich den STM32F4xx genannt hatte, liegt an seiner hohen Taktfrequenz > von 160MHz für die Timer. Das klingt in der Tat nach einer Möglichkeit. Ich selbst habe wenig Erfahrung mit DMA, ich habe es einmal benutzt aber das wars dann auch. M. N. schrieb: > Doch noch eine Überlegung. > Knackpunkt sind ja die kurzen Pulse, die ein Timer erzeugen müßte. Hier > könnte man mit ein bißchen Hardware 'schummeln', indem diese zum > Beispiel die '1'-Impulse um 8 Zyklen verkleinert. Um dann einen 50ns > Impuls zu erzeugen, wird dieser nicht direkt mit dem Wert 2 erzeugt, > sondern mit dem Wert 10, was 250ns entsprechen würde. > Dadurch dass die Impulsdauer um 8 Zyklen verkürzt wird, erscheinen am > Ausgang wieder nur 50ns Impulse. Da die Intervalle immer >= 1µs sind, > stört der 250ns Impuls nicht das restliche Timing. Da hörts dann aber auch ganz schnell wieder auf mit der Reinheit der Lösung. Böse Gedanken sind das! Aber im Ernst, das halte ich für Pfusch, insbesondere extra Elektronik die dann die Pulse verkürzt, also ich weiß nicht. An den OP : Wie GENAU müssen die Pulse eigentlich sein? Auflösung von 25ns ist ja schön und gut, aber wie genau muss das werden?
Mmmh, fertich und billich scheint es nicht zu geben. Je nach persönlichem Geschmack des TO, könnte man sich folgende Lösungen vorstellen: A) falls während der Pulserzeugung nicht mit dem Teil gesprochen werden muss, könnte man in einem STM32F4 eine Assemblerübung abhalten. B) falls während der Pulserzeugung mit dem Host gesprochen werden soll: - Kommunikationsfrontend, - beliebiger uC - Pulsgenerator ( VHDL auf FPGA oder Assemblerübung auf STM32F4), hat beides seinen Charme C) FPGA mit synthesierter CPU als Kommunikationsfrontend Vor ein paar Jahren habe ich einen kleinen Spartan XC3S50AN mit einer PicoBlaze-CPU und VHDL-Logik gefüttert, um Wellenformen zu erzeugen. Dieses FPGA hat einen internen Flash, war damals Anforderung. @Thorsten: Frage am Rande - magst/darfst Du uns was über Dein Projekt erzählen?
M. N. schrieb: > Guest schrieb: >> also ich weiß >> nicht. > > Ja, das merkt man immer wieder sehr deutlich. Ich werd ja wohl noch meine Meinung sagen dürfen. Und Vorschläge von wegen Pulse nachträglich verkürzen, da hab ich immer das Gefühl als nächstes kommt "wir nehmen 2 20MHz AVRs und hängen sie an 180° Phasenversetzte Takte..." Mit DMA und einem entsprechenden ARM könnte das sicher funktionieren, nur kenne ich mich dafür zu wenig aus. Ich weiß nur, dass das ganze in einem FPGA vermutlich nicht weniger Arbeitsaufwand ist, da man eben nicht auf besondere Tricks zurückgreifen muss, ganz im Gegenteil, man kann es exakt so implementieren, wie man im ersten Moment denken würde. Und wenn die Anforderungen mal auf 10ns steigen ist man auch fein raus. Ein einigermaßen erfahrener FPGA Entwickler hat das an einem Wochenende fertig, mit SPI Konfigurations Interface und allem was man braucht. Wenn dann noch die Familie nicht stört kriegt er auch noch das Platinen Layout fertig. Wie es bei der ARM Geschichte aussieht weiß ich nicht, persönlich müsste ich dafür erstmal Datenblätter wälzen um rauszufinden, wie gut DMA und Timer oder SPI zusammenarbeiten um das alles zu ermöglichen.
Marcus H. schrieb: > B) falls während der Pulserzeugung mit dem Host gesprochen werden soll: > - Kommunikationsfrontend, - beliebiger uC > - Pulsgenerator ( VHDL auf FPGA oder Assemblerübung auf STM32F4), hat > beides seinen Charme Ich bin mir nicht sicher, was du mit Kommunikationsfrontend meinst. Ein SPI Interface, mit dem man ein bisschen Konfiguration im FPGA machen kann und ein paar Bitmuster reinladen kann man auch direkt in VHDL bauen. Das dürfte eigentlich kein all zu großer Aufwand sein, zumal man das ja auch mit nem externen µC bräuchte. Was dann außen an dem SPI/UART hängt weiß wohl nur der OP.
Hi Guest, cooler Name! Habe ich etwa zu luxuriös gedacht? Meine Geräte haben seit Jahren grundsätzlich das selbe Commandinterface, mit Portierungen auf den gerade verwendeten Prozessor - z.B. PIC, AVR, TMS320, Picoblaze, STM32. Und einen Commandinterpreter tippe ich persönlich lieber in Assembler (oder C) runter als in VHDL. Deswegen finde ich diese KCPSM3 (Picoblaze) so schön, weil man das Projekt in einem kleinen(!) Chip zwischen VHDL und ASM aufteilen kann. Für die IP bezahlt man nichts extra, außer dass man einen Xilinx Chip einsetzen muss. Cheerio, Marcus P.S.: Vielleicht erfahren wir noch mehr über das Projekt vom TO. ;)
Hi, ich will eine Platine bauen, mit seriellem UART zu einem PC in ca. 15M Entfernung. Drauf ist ein ATMEGA2560 der den VCO ansteuert, mit dem ich eine Frequenz erzeuge, die variabel ist. Ausserdem ein Rauschgenerator mit Amplitudeneinstellung um damit das VCO-Signal zu verrauschen. Dann werden noch ein paar andere Sachen angesteuert und Spannungen und Temperaturen überwacht. Ausserdem will ich vom PC mittels UART auf den ATMEGA die Pulsedaten geben, die dieser dann an den Pulsegenerator weiter gibt. Diese Pulse schalten dann einen HF-Schalter und fertig sind die gepulsten HF-Radar-Signale. Bis auf die Pulseerzeugung habe ich alles schon gemacht und funktioniert auch. Ich freunde mich gerade mit der FPGA-Lösung an und habe mit mal den AVNET AES-S6MB-LX9-G geordert. Dann schaue ich mal wie ich da die Werte vom ATMEGA übergeben bekomme (evtl SPI) und dann sauber die Daten(Pulse) raus bekomme. Danke für die vielen Anregungen, dafür liebe ich dieses Forum. Ich hoffe ihr helft mir weiter wenn das FPGA-Board da ist... Gruß Thorsten
Thorsten F. schrieb: > Ich freunde mich gerade mit der FPGA-Lösung an und habe mit mal den > AVNET AES-S6MB-LX9-G geordert. Dann schaue ich mal wie ich da die Werte > vom ATMEGA übergeben bekomme (evtl SPI) und dann sauber die Daten(Pulse) > raus bekomme. An sich ne gute Sache, jedoch brauchst du das Board wie gesagt nicht direkt, du kannst das wunderbar simulieren. Fang doch erstmal mit der Pulsgenerierung aus RLC Daten an. Das sollte nicht so schwer werden.
Marcus H. schrieb: > Habe ich etwa zu luxuriös gedacht? Meine Geräte haben seit Jahren > grundsätzlich das selbe Commandinterface, mit Portierungen auf den > gerade verwendeten Prozessor - z.B. PIC, AVR, TMS320, Picoblaze, STM32. > Und einen Commandinterpreter tippe ich persönlich lieber in Assembler > (oder C) runter als in VHDL. Deswegen finde ich diese KCPSM3 (Picoblaze) > so schön, weil man das Projekt in einem kleinen(!) Chip zwischen VHDL > und ASM aufteilen kann. Für die IP bezahlt man nichts extra, außer dass > man einen Xilinx Chip einsetzen muss. Nachdem es hier scheinbar nur darum geht ein möglichst einfaches µC-FPGA Interface zu bauen halte ich es wie gesagt für genauso gut das ganze in VHDL zu bauen. Natürlich kann man es auch mit einem Micro Blaze machen, das ist halt wenn man sich nicht damit auskennt ein wenig mehr Aufwand aber evtl schöner.
So, Vorschlag für das Design:
1 | -- Nich RLC Codiertes Wort |
2 | - Falls Aktueller_Datensatz[31] = 0 |
3 | - Falls Zähler = 30 |
4 | - Zähler <= 0 |
5 | - Aktueller_Datensatz <= Nächster_Datensatz |
6 | - Datensatz_Geholt := 1 |
7 | - Sonst |
8 | - Zähler <= Zähler + 1 |
9 | - Ende |
10 | - Output <= Aktueller_Datensatz[Zähler] |
11 | - Sonst |
12 | -- RLC Codiertes Wort |
13 | - Falls Zähler = Aktueller_Datensatz[29-0]-1 |
14 | - Zähler <= 0 |
15 | - Aktueller_Datensatz <= Nächster_Datensatz |
16 | - Datensatz_Geholt := 1 |
17 | - Sonst |
18 | - Zähler <= Zähler + 1 |
19 | - Ende |
20 | - Output <= Aktueller_Datensatz[30] |
21 | - Ende |
22 | |
23 | - Falls Datensatz_Geholt = 1 |
24 | - Nächster_Datensatz <= RAM[Addresse] |
25 | - Falls Addresse = Ende des Musters |
26 | - Addresse <= 0 |
27 | - Sonst |
28 | - Addresse <= Addresse + 1 |
29 | - Ende |
30 | - Datensatz_Geholt := 0 |
31 | - Ende |
Das sollte mal ein funktionierender erster Stand sein, gerade das mit dem Datensatz_Geholt ist nicht besonders schön aber sollte funktionieren. "Ende des Musters" muss eben ein Input sein, den RAM muss man auch irgendwie ansprechen, aber das ist dann ja abhängig von der speziellen Implementierung. Das ist jetzt aus dem Kopf getippt, gibt sicher schönere Lösungen. Nur so als idee, was meint ihr?
@Guest: PicoBlaze, nicht MicroBlaze. Da liegen größenmäßig 1000 Makrozellen dazwischen. Und ein anderes Lizenzkonzept. @Thorsten: Was für ein Radar mit welcher Sendeleistung? Privat? Ich frag nur, weil früher(tm) etliche Leute an Leukämie gestorben sind. Stichwort MIM-23 HAWK.
@Marcus H. Es ist ein Radar-Simulator mit max. 0dmb Ausgangsleistung um spezielle Geräte zu stimulieren und zu triggern. Keine Angst, ich kenne mich mit HF-Strahlung aus. Danke. @all wegen der Genauigkeit. Es wird ja mit einer Clock von 40Mhz getaktet, was dann die 25ns bedeutet für die Pulse. Wenn der Puls nachher 75ns sein soll und 80ns lang ist, dann ist es noch ok. Viele zu generierende Pulse liegen später im kleinen µs Bereich, wenige im ns Bereich. Da ist ein Fehler von 5-10ns kein Problem. Wichtig ist, dass es verschiedene Pulsbreiten nacheinander abfahren kann und diese Pulsekette dann kontinuierlich ohne größere Pausen dazwischen. Wie ein richtiges Radar halt auch. Gruß Thorsten
Marcus H. schrieb: > > @Thorsten: Was für ein Radar mit welcher Sendeleistung? Privat? Ich frag > nur, weil früher(tm) etliche Leute an Leukämie gestorben sind. Stichwort > MIM-23 HAWK. Thorsten F. schrieb: > > Keine Angst, ich kenne mich mit HF-Strahlung aus. Danke. Die Ursache für die Leukämie war aber natürlich die ionisierende Strahlung und nicht die nicht-ionisierende Strahlung. Nur für den Fall, dass es immer noch Leute geben sollte, die dies nicht wissen...
Na dann mach ich mir um Thorsten keine Sorgen... John, ich habe mir damals bei Conrad mal einen Mikrowellentester gekauft. Besteht nur aus einer Diode und einem kleinen Drehspulinstrument. Schon 50m von der Anlage weg gab's da Vollanschlag. Meine alte Korea-Mikrowelle lässt den Zeiger kaum bewegen. Sorry, da bleibt ein blödes Gefühl.
Thorsten F. schrieb: > Wichtig ist, dass es verschiedene Pulsbreiten nacheinander abfahren kann > und diese Pulsekette dann kontinuierlich ohne größere Pausen dazwischen. > Wie ein richtiges Radar halt auch. Das kann mein Ansatz. Sogar ganz ohne Pause wenn ich richtig gerechnet habe. Du kannst also 25ns high auf 25ns low folgen lassen wie es dir gefaellt. Ist nur nicht so arg flexibel, wenn du nur ein kleines Set von Pulsen hast aber eine sehr komplexe Abfolge, waere ein komplexerer Algorithmus vermutlich sinnvoller. So ab 100 Pulsen hintereinander fuer eine Periode wuerd ich mir darueber Gedanken machen.
Lebt der OP noch? Wär gut wenn der sich mal rühren würde, dann könnte man ihm auch weiter helfen.
Ah, noch einer, der sich Sorgen um seine Gesundheit macht. :(
Hi, danke. Ich lebe noch. War ein paar Tage unterwegs, außerdem momentan viel um die Ohren. Habe das FPGA-Board erhalten und versuche mich jetzt mal daran, vorne die Daten rein zu bekommen und dann die Pulse hinten wieder raus. Wenn ich Hilfe brauche schreie ich, wenn ich weiter komme poste ich es auch. Gruß Thorsten
Angehängte Dateien:
Stand von gestern abend. Das ganze läuft mit ca 120MHz. Ich versuch es noch auf 200MHz zu bringen (sollte drinn sein), dann poste ich evtl den code.
So. Das Design macht jetzt auf einem XC6SLX4 der schnellsten Speed Grade fast 220MHz. Auf einem Altera EP4CE6E22 der schnellsten Speed Grade gute 203MHz. Auf dem langsamen XC6SLX4-2 macht es noch über 180MHz, auf einem EP4CE6E22C8 noch knapp 150MHz. Die beiden schnelleren liegen so bei 15 Euro, sind aber bei Digikey nicht lieferbar. Die beiden langsameren sind 10 Euro FPGAs. Eine weitere Optimierung des Designs halte ich für unsinnig, da dann eine sehr große Zahl von Routen die Timings failt. Ich denke für viel mehr als 200MHz muss man sich etwas schlaueres überlegen. Ich räume noch meinen Code auf... Auf einem XC6SLX9CSG324-2, was der FPGA ist, der auf dem AVNet Board sitzt, dass der OP gekauft hat, bei 100% BRAM usage sieht es übrigens so aus: - Register: 2% - LUT: 4% - Slice: 9% - IO: 3% - RAMB16BWER: 100% - BUFG: 6% - Maximum Frequency: 143 MHz Die hohe Slice Auslastung und die geringe Frequenz kommt daher, dass die RAMs über den ganzen FPGA aufgeteilt sind. Das sorgt für stark verteilte Logik und lange Pfade. Dafür stehen 64kByte Speicher für Pulse zur Verfügung, das entspricht ca 4000 Pulsen für eine Periode.
@Guest: wow, das sieht ja gut aus. 143MHz sind ja auch mehr als genug, wie gesagt es soll auf 25ns, also 40 Mhz laufen. Sehe ich es richtig, das du die Pulse-Daten per SPI übergibst? Können die Pulse dann auch in einer loop direkt nacheinander ausgegeben werden, bis neue Daten über SPI gesendet werden? Oder ist zwischen den 2 Pulsefolgen auf dem Bild eine so grosse Zeit mitgegeben worden, weil die ja 2 mal ausgegeben werden. Habe momentan Probleme mit der ISE, habe die 14.6 heute Nacht neu geladen und will die gleich installieren. Wofür brauchen die über 7GB Daten...? Gruß Thorsten
:
Bearbeitet durch User
@all ich war gestern schon am überlegen ob ich mir nicht das "red-pitaya" Board hole: http://www.rs-online.com/designspark/electronics/eng/nodes/view/type:design-centre/slug:red-pitaya Sieht echt nett aus, nur 90% der Sachen die das Board kann brauche ich ja nicht. Kennt einer von euch das Board schon und hat es evtl. im Einsatz? Gruß Thorsten
Thorsten F. schrieb: > wow, das sieht ja gut aus. 143MHz sind ja auch mehr als genug, wie > gesagt es soll auf 25ns, also 40 Mhz laufen. Die 200MHz waren meine eigene Vorgabe. Thorsten F. schrieb: > Sehe ich es richtig, das du die Pulse-Daten per SPI übergibst? Ja, das Protokoll ist einfach, sollte aber ausreichen. Thorsten F. schrieb: > Können die Pulse dann auch in einer loop direkt nacheinander ausgegeben > werden, bis neue Daten über SPI gesendet werden? Werden sie doch. Die 6.4us low sind Teil des Pulses, um zu demonstrieren, dass ich auch laengere Pausen machen kann. 6.4us sind zugegeben nicht sonderlich lang, das Problem mit laengeren Pausen ist nur, dass man auf einem Screenshot dann nurnoch eine Low-Zeit und sonst garnichts mehr sieht. Mein Problem ist aktuell, dass Xilinx einen synchronen Reset braucht um die RAM Bloecke bauen zu koennen, altera mit synchronen Resets extrem ineffizient wird (<150MHz auf der schnelleren Speed Grade). Nachdem ich aber fuer beide die selbe VHDL Code Basis nutzen wuerde, muss ich mir da was ueberlegen. Thorsten F. schrieb: > Habe momentan Probleme mit der ISE, habe die 14.6 heute Nacht neu > geladen und will die gleich installieren. Wofür brauchen die über 7GB > Daten...? Das Webpack braucht, wenn ich mich richtig erinnere, installiert ca 20GB. Wo liegt das Problem? Festplattenspeicher ist heutzutage nicht mehr so arg teuer... Mir hat man uebrigens mal erzaehlt das Webpack ist so gross, weil die FPGA beschreibungsfiles so gross sind, kA ob das stimmt. Die ISE wuerd ich ausserdem eh nicht benutzen, sondern lieber PlanAhead. Das ist auch Teil des Webpacks und viel angenehmer.
Installiere gerade das grosse Xilinx Paket und schaue mir dann auch PlanAhead an. Habe bisher nur mit ISE 11.1 gearbeitet (7GB gross), da gab es das PlanAhead glaube ich noch nicht. Gruß Thorsten
Hier ein Snapshot aus meinem Repo. Sollte alles drinn sein was du brauchst.
Ich bitte zu beachten, dass keine Lizenz beiliegt. Entsprechend muss für jegliche Weiternutzung der Autor (ich) um Einwilligung gebeten werden. Ansonsten wäre das ein Urheberrechtsverstoß. Das gilt insbesondere für kommerzielle Verwendung. Dass ich den Code schön versioniert in meinem privaten Repo habe sollte Beweis genug sein dass ich der Urheber bin. nur falls jemand das wegen meiner Anonymität hier im Forum anzweifelt...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.