Hallo, mein nächstet Projekt wird warscheinlich ein Logicanalyzer sein, ich wollte mal kurz horen was mit einfachen Mitteln für einen Wiederholrate möglich ist. Ich würd einen 20 MHz AVR Typ nehmen der immer wiederholt 1 Port einliest und die Daten in ein RAM schreiben, da ich hierzu keine Sachen wie A/D-Wandler. EEPROM usw nutze sollte doch eine Übertaktung möglich sein. Falls man das RAM wie einen 28er EEPROM ansprechen kann sollte ich es mit sehr wenigen Takten hinbekommen die Daten ins RAM zu legen. Wenns dann voll ist müsste ichs in den Rechner schaufeln um es dann in Excel oder womit man das grafisch macht anzuzeigen. Dazu würde ich am liebsten ein Taktsignal verwenden um keinen größen (PC-)Programmieraufwand betreiben zu müssen. Hat dazu jemand Vorschläge damit ich mir mal die Möglichkeiten durch den Kopf gehen lasse. Welches größere RAM's käme in Frage welches wäre besonderst schnell. Evtl. eine Programmierbare Logic benutzen, da die ja um einiges schneller sind und man dann z.b. 20nSek Rams voll ausnutzen kann was dann etwa 50 MHz entsprechen würde. Wobei mir eine Auflösung von 8 oder 16MHz voll reichen würde und man dann etwas änger aufzeichen kann.
Vergiss den/die Trigger-Leitungen nicht ! Außerdem brauchst du ne TimeBase wenn du nur auf den Triggern reagierst.
Angehängte Dateien:
-
Logic_Analyzer_RAM.png
5,7 KB
Hallo, also ne Triggerung bräuchte ich nur für den Start damit der Ram nicht schon volläuft bevor ein Signal anliegt. Also entweder über Interrupt oder ich vergleiche die Signale auf 0 um das erste Signal zu erkennen und lass dann erst das ganze loslaufen. Die RAM-Adresse zähle ich mit dem µC hoch und die Befehle erhalt das RAM auch vom µC so kann ich die Geschwindigkeit an den abzuhörenden Baustein anpassen. Die Speichertiefe ist halt jetzt die Frage was gibt es da für Bausteine die kein Refresh benötigen.
Ich würde das mit einem schnellen CPLD oder FPGA realisieren. Für die Kommunikation mit dem PC kannst du einen Atmel verwenden. Schau dir mal die ispMach4000 CPLDs von Lattice an. Die können problemlos 100MHz.
Besser als eine Anfangstriggerung ist eine kontinuierliche Aufzeichnung und eine Unterbrechung der Aufzeichnung kurz nach der Triggerung. So kann man sich auch die Daten vor der Triggerung anschauen.
Hi, immer wieder gibt es hier so ein Thread und jedesmal geht er leider in die Versenkung unter. Der ISPMACH4000 CPLD Baustein sieht sehr interessant aus. Ich bin gerade dabei die ersten Gehversuche mit externen RAM an einem AVR µC zumachen, deshalb haette ich diesbezueglich ein paar Fragen. Der CPLD liesst die Daten auf den Portpins ein und gibt diese an einen schnellen Speicherbaustein(FIFO?) weiter. Der AVR ist wiederrum mit diesem Speicherbaustein verbunden und holt sich die Daten aus dem Speicher und gibt diese an den UARt weiter? Ist diese Ueberlegung richtig? Welche Speicherbausteine sollte man nutzen ? Ich habe bis jetzt auch nur FIFO Speicher mit mind. 10ns gesehen , somit wuerde auch ein CPLD der 10ns braucht reichen? Oder muss der CPLD um Faktor X schneller sein als das RAM? Ich wuerde mich freuen , wenn mir jemand diese Fragen beantworten koennte. Gruß, Dirk
Elektor hatte mal nen Artikel dazu. Die haben das mit AVR, FIFOs und eigen Logic-Bausteienn erledigt. Ging bis 40Mhz. Der erste Teil war in 2/2003, nen monat später wurde es abgeschlossen.
Hi, ich besitze diesen Logik Analyzer. Wirklich zufrieden war ich damit nie. Die Softwaere laeuft nur auf Win98.
Bitte nicht die Software auf PC-Seite vergessen. Signale aufzeichnen ist eine Sache, nur die wollen auch komfortabel ausgewertet werden. Genau das war wohl auch das Problem bei der Software vom Elektor-Projekt, die lief entweder garnicht oder sehr instabil.
Für nen 8bit-Analyser musst du bei nem AVR ja schon Takt/3 rechnen, d.h. max. 7MHz, denn: IN (1) + ST X+ (2) = 3 Takte / Sample. Steig wirklich gleich auf nen CPLD um.
Wie oft müßte man eigentlich ein digitales Signal abtasten, um sicher alle Impulse in einem bestimmten Zeitraum zu erfassen?
Kommt aufs Digitale Signal an. Bei Triggerung auf den einzelnen Impulsen reicht theoretisch ein 100Mhz LA, wenn das Signal auch ein 100Mhz rechteck ist. Bei laufender Abtastung gilt das Oszi-Abtast-Theorem
wie wärs damit: XILINX Spartan 3 Starter-Kit kaufen (99 $), Expansion-Header als Inputs, Speicher 2 x 256k x 16 (10ns, onboard) als Ringbuffer verwenden, Firmware vom PC aus laden, Steuerung und Lesen der Daten via Rs232 oder mit vorgeschaltetem USB-RS232 Konverter, Darstellung der Daten am PC z.B. mit TeeChart Grafik Problem: einer muss das FPGA-Design machen und einer die Windows-SW schreiben, aber da sollte sich hier doch jemand finden ?!
Eine beta für ein FPGA Design kann ich beisteuern. Ist aber noch etwas buggie. Stand der Dinge: 8 Kanäle 2k Speicher pro Kanal, werden im internen Blockram abgelegt. Triggerung auf Pegel, steigende/fallende Flanke oder gemischt. Datentransfer über RS232 @ 115,2 kBaud. Gruß Jörn
Hi, ich wuerde das rooten der PCB uebernehmen, wenn interesse besteht und mir jemand ein bischen bei der Schematic helfen wuerde. Gruß, Dirk
Was mir dazu einfällt... ...so du ein Oszi hast, müsstest du eigentlich das auch als ausgabe nutzen können. Müsstest ein entsprechendes Triggersiganl erzeugen, und die unterschiedlichen Kanäle kannst du dann trennen, indem jeder Kanal durch eine externe Beschaltung eine andere Offsetspannung mitbekommt. Ungefähr müsste dann die maximale Frequenz = Oszibandbreite/Kanalzahl sein. Wenn du kein Osti hast... ...vielleicht mal bei Google gucken, was ein Analogoszi (Ist billiger) mit großer Bandbreite gebraucht so kostet. Nur so ´ne Idee... Gruß, Harald
Hallo, @Jörn: hast du nen Schaltplan würde mich mal interessieren wie das mit einem FPGA aussieht. Das Hauptproblem ist bei mir die PC-Software. Digitrace gefällt mir von der Aufmachung ganz gut aber da bin ich voll überfordert sowas zu proggen. Hat jemand mal ein paar RAM Bezeichnungen die in Frage kämen? Denke Reichelt da sowas nicht oder?
Hallo, wie nennen sich eigentlich diese Zählbausteine, die einfach pro Impuls den binären Ausgang um eins erhöhen?
Die Programmierung der PC-Seite könnte ich machen. Allerdings programmiere ich hier normalerweise nur für Linux und nicht für Windows. Mit Qt4 könnte man das Programm aber plattformunabhängig schreiben, so daß es sich ohne Modifikation unter Linux, Windows und MacOS compilieren lässt.
Thomas: Counter Alle: Warum nicht die Idee mit dem FIFOs von Elektor aufgreifen. Sollte den Aufwand deutlich reduzieren.
@Thomas: Die Schaltung ist in VHDL geschrieben und die Schaltpläne ist das Ergebnis der Synthese der ISE.
Hi, was mir von dem 40MHz LA der Elektor im Kopf hängen geblieben ist: - nur Win98 (kam schon), häufig Abstürze - auf der Web Seite kein Projekt mehr erreichbar - Einsatz von FIFOs, Stck > 25Euro - 40MHz bei dem PCB Design -> fraglich, evtl. hat er nur das timing der FIFOs heran gezogen. Mit dem FPGA klingt toll, imo gibt's die Dinger aber nur im BGA Gehäuse und da ist das löten naturgemäß problematisch, d.h. home made ist fast unmöglich. Bleibt also nur CPLD im QFP. BTW, xilinx hat mal ein Appnote dazu: http://www.xilinx.com/bvdocs/appnotes/xapp368.pdf Das mit den Komparatoren löst das Problem mit den verschiedenen Logi-Pegeln elegant. Viele Grüße Olaf
FIFOs sind zwar die einfachste Möglichkeit, aber einfach nur Scheißteuer. Mein 16 Kanal 40MS Logikanalyser besteht aus zwei 128kBx8 VRAMs, gesteuert von einem AVR. Die Takterzeugung der Samplerate und die Triggerung macht ein kleiner CPLD. 2kB RAM klingen zwar ganz gut, würden mir aber nicht reichen. Die 128kB nutze ich oftmals voll aus, wenn ich z.B. den Datentransfer zwischen einem uC und einem LCD betrachte. Meist wird hier am Anfang das LCD zuerst komplett gelöscht, und erst die Daten dahinter sind interessant. Was spricht gegen die Verwendung von schnellen Cache SRAMs aus Mainboards, oder gegen synchrone Cache SRAMs ? In fast jedem etwas neueren P1 Mainboard (oder auf P2/P3s) findet man 2 synchrone SRAMs mit 32kx32 oder sogar 64kx32 8bit reichen für einen Logikanalyser selten, spätestens wenn man sich einen parallel Datenbus anschauen möchte, benötigt man 8 Daten und einige weitere Steuerleitungen. Die 32bit des synchronen SRAMs wären dafür optimal: 8 oder 16bit Daten, bis zu 20 Adressen, Steuerleitungen usw. Und das ganze kompakt in einem IC und bis 66MHz brauchbar.
@ope: FPGAs von Xilinx oder Altera sind auch noch im TQPF 144 oder 208 zu bekommen. @Benedikt: Die 2k pro Kanal waren nur für Testzwecke gedacht. Maximal habe ich 1 MByte Speicher (bis 100 Mhz) zur Verfügung, also z.B. 256kSamples a 32 Bit. Das müßte schon ne Weile reichen. Was für einen CPLD benutzt du? Gruß Jörn
Ich verwende einen XC9536, da die Triggerung (ein einfaches D Latch mit davorgeschaltetem 1 aus 16 Multiplexer) und die Samplerateauswahl (Teiler und Auswahl der Frequenz) keine großen Anforderungen stellen. Was ich vielleicht noch integrieren werde ist eine bessere Triggerung auf bestimmte Werte, da ich den Logikanalyser mit einem ADC auch als Oszillopskop verwende. Bisher kann ich leider nur auf >128, >192, <128 und <64 Triggern. Was kostet eigentlich ein geeigneter FPGA für so ein Projekt ? Bisher hat mich eigentlich immer der Preis davon abgehalten, irgendwelche Projekte damit zu planen. Wenn man einen 5 CPLD abschießt, ist das zwar dumm, aber nicht weiter schlimm. Bei einem FPGA für >20-40 wird das ein teurer Spaß.
also ich denke nach wie vor, ein Dev-KIT vom FPGA- Hersteller ist die preiswerteste Möglichkeit. Wenn man so ein Board selbst machen will, spart man am Ende nichts. Für hohe Taktfrequenzen und Bitbreiten muss man doch sicher mind. eine 4-Lagen-Platine machen, da ist nicht mehr viel mit selber ätzen, die SRAMs müssen vom Pegel her mit den I/Os des FPGAs zusammenspielen, alle Spannungen müssen ordentlich geblockt sein, mehrere Betriebsspannungen sind nötig (3,3V / 1.5...2.5 V ...??) und dann noch das PQ208 mit der Hand löten? Geht alles, aber wie lange soll das dauern? Habe mal so ein Projekt mit einem "alten" Spartan I im PLCC84 und ein paar Cache-RAMs aus'm PC angefangen, die Platine liegt jetzt noch unfertig rum, die Zeit hat nie gereicht, um das mal fertigzumachen.
4 Lagen ist doch schon etwas übertrieben... Selbst viel (vor Pentium) Mainboards kamen mit 2 Lagen aus. Mein 40MS Logikanalyser ist einseitig auf einer Lochrasterplatine aufgebaut, und ich hatte damit bsiher eigentlich keine größeren Probleme, (zumindest seitdem ich wirklich unter jedes IC einen 100nF Kondensator gehängt und die Betriebsspannung ordentlich verlegt hatte.) Am Anfang hatte sich die Schaltung so etwa alle 10-20s aufgehängt, weil der CPLD einen Reset gemacht hat, und der uC auf das Ready Signal vom CPLD gewartet hat, das allerdings nie kam...
@ Benedikt: Die Triggerungsmöglichkeit sind bei dir etwa beschränkt, aber reichen natürlich. Mein Design paßt ohne weiteres in einen 3S50 rein: Preise: XC3S50-4TQ144C 12,30 USD XC3S50-4VQ100C 10,10 USD XC3S50-4PQ208C 13,90 USD XC3S200-4TQ144C 15,10 USD wenn man direkt bei Xilinx bestellt. Wenn ich ein FPGA Baord bauen müßte, würde ich aber zu einem Cyclone greifen. Wie Harry erwähnt hat, brauchen die FPGA mehrere Versorgungsspannungen. Der Altera (Cyclone) brauch nur zwei während der von Xilinx (Spartan3) drei braucht. Wobei ich denke, dass man das Board noch zwei lagig hinbekommen könnte. @ Harry: Preislich und vom Zeitaufwand her wirst du recht haben, dass es sich fast nicht lohnt ein eigenes Board zu machen. Das Starter Kit kostet so um die 100.
Also wenns ein ALTERA-FPGA werden soll, wäre ich bereit, ein vorh. funktionierendes Design auf den ALTERA zu portieren (falls nötig) und zu compilieren/ simulieren. Habe die Quartus II Software Vollversion V5.0 + Modelsim-ALTERA 6.0 laufen. Dev.-Board mit Cyclone habe ich aber nicht, dafür Stratix II :-)
Hi, ich denke das HW Design sollte man locker auf eine doppelseitige 80x100 Platine bekommen. Ich waere wirklich bereit dazu eine Platine zu routen und in Auftrag zugeben. Erstmal muesste aber der FPGA / CPLD geklaert werden. Harry und Joern koennten die Programmierung des FPGA / CPLD vornehmen. Es wuerde nur ein Programmierer fuer die PC Seite fehlen. Wuerde interesse bestehen so ein Gemeinschaftsprojekt zustarten? Gruß Dirk
welche sprache und welches os ?? ;) ich kann derzeit so ziemlich alles was in frage kommt soweit, dass ich was basteln könnte... ich favorisiere c/c++ und irgend ein widgetset... mfc ist meine hauptspielwiese dank firma aber gtk der wxWidget dürfte brauchbarer sein... ich bin zwar derzeit etwas vollgedeckt.. aber innerhalb der nächsten 1-2 wochen würde da sicher eine beta rausschaun... soll das komplett in einem cpld sein oder kommt da noch ein uC dazu??? im prinzip bräuchte ja nur die trigger,zähler und ram-verwalt logik in den cpld rein... dann noch das ganze z.b an nem avr ran und per ext-mem-interface daten schaufeln... aber da lass ich euch mal machen ;) 73
Habt ihr jetzt mal klar abgesteckt, wie es werden soll? Also CPLD oder FPGA? Bei FPGA könnte man ja dessen RAM benutzen, ist zwar nicht sehr groß dürfte aber reichen. Teure Geräte haben nicht unbedingt mehr Speicher. Bei CPLD wäre man auf externen (schnellen) Speicher angewiesen. Wieviele Kanäle? 8 ist zu wenig, 16 eigentlich auch wenn man IDE aufzeichnen will. 32 Kanäle wären nett und sollten meiner Meinung nach unbeding anvisiert werden. Ansonsten macht man später die ganze Arbeit nochmal. Bei 32 Kanälen wirds dann allerdings wieder eng mit internem Speicher, weiß allerdings auch nicht, was da derzei so Stand der Technik ist. Vielleicht sollte man bei Xilinx recherchiert werden. Wie kommen die Daten in den PC? Es sollte eine zunkunftsorientierte Schnittstelle benutzt werden, also fällt RS232 schonmal weg. USB wäre hier sinnvoll, welcher Controller wird dann verwendet? Außerdem sollte man Bauteile wählen, die gut erhältlich sind. Ein FPGA, der nur in VPEs zu 96 Stück bestellt werden kann und sonst extrem teuer ist, bringt nichts. Die Sofware auf PC-Seite könnte in JAVA geschrieben werden. Dadurch ließe sie sich leichter auf verschiedenen Plattformen einsetzen. Also ich wäre an einem Gemeinschaftsprojekt auch sehr interessiert. Vielleicht sollte aber vorher mal eine Art Pflichtenheft erstellt werden denn sonst wirds chaotisch und es kommt immer wieder was hinzu und zum Schluß blickt keiner mehr durch und alles verläuft im Sand wie die ganzen anderen Analyzer-Projekte auch. Gruß Jens
@Jörn: "FPGAs von Xilinx oder Altera sind auch noch im TQPF 144 oder 208 zu bekommen." Dies betrifft (nach einem kurzen Wühlen) nur die Spartan-I und Spartan-II Family, alles darüber BGA. Das xilinx für jede ihrer Package wieder einen eigenen Namen hat ist zum Kotzen... (http://www.xilinx.com/products/design_resources/packaging_resource_page/Xilinx_Package_Code_Glossary.htm) Nun ja, sollten/sind eben diese nicht abgekündigt werden/worden? @Benedikt: "Mein 40MS Logikanalyser ist einseitig auf einer Lochrasterplatine aufgebaut, und ich hatte damit bsiher eigentlich keine größeren Probleme..." Was macht Dich so sicher, dass Du bei diesem Aufbau und 40MHz noch die Pegel der zu untersuchenden Schaltung analysierst? Vcc blocken ist ja nur eins - ground bounce das Nächste, Übersprechen das Weitere, EMI und und und ... Es handelt sich ja nicht gerade um eine kleine Oszillatorschaltung, wo alles noch recht übersichtlich ist. BTW, ein Self-Test wäre nicht schlecht, nur so als Idee. Rein aus Interesse, ab wann (MHz) nimmt man eigentlich LVDS? Viele Grüße Olaf
. "4 Lagen ist doch schon etwas übertrieben... Selbst viel (vor Pentium) Mainboards kamen mit 2 Lagen aus." Ja, der Apple II. Und der Atari ST. Auch PCs mit 8088, aber bereits einen AT (286er) mit zweilagigem Mainboard habe ich nie gesehen. Und der wurde mit lächerlichen Taktfrequenzen von anfänglich gerade mal 6 MHz betrieben.
Wenn das CPLD/FPGA gross genug ist koennte man sich evtl. den AVR sparen und den USB-Chip (z.B. FT245) direkt ansteuern. PC-seitig waere eine Java-Software das beste; ich finde es immer wieder schade wenn jemand viel Muehe und Zeit in ein Programm investiert, das dann nur auf einer oder wenigen Plattformen zufriedenstellend laeuft.
Hi, man ist das ein Tempo hier - das wird sicher wieder ein Monster Thread wie mit dem Labor Netzeil :) Ich hoffe nur, mit einem positiven Ende. @Jens: "Bei CPLD wäre man auf externen (schnellen) Speicher angewiesen." Du kannst RAM Bänke pagen - musst den Bus entsprechend buffern. Tja, ich sehe, man kann sich mal wieder nicht über die Programmiersprache des GUI einigen :) Noch keiner Asm vorgeschlagen ;-) Immerhin kam noch kein CAN Bus als Interface. Leute, macht es so einfach wie möglich für den ersten Wurf. Manchmal ist es billiger mehr Geld hinein zu stecken, als hinterher Monate wegen Kleinkram und damit noch mehr Geld (und hier vor allem Lust) zu verlieren (Thema: FPGA Ev-Kit). Viele Grüße Olaf
Erstellt doch mal eine Wiki-Seite dafuer und schreibt eine genaue (und moeglichst einfache, wie Olaf schon geschrieben hat!) Spezifikation; ansonsten wird das wie das Netzteil-Projekt totdiskutiert.
gegen java lege ich mich strikt quer... dann lieber etwas wirklich nettes... python coden kann ich zwar noch nicht so wirklich gut aber jeder muss einmal richtig anfangen :) dann ist wieder alles 100% portable... usb wäre zwar nett aber dann hat man wieder das treiber problem.. es sei denn man hängt an so einem usb->serial wandler ala ft... wobei von dem hab ich schon horrorgeschichten gehört wenns um viel daten und dauernd und generell... rs232 ist industrie standart.. usb nicht und wenn die was anderes wie rs232 fahren dann can und wenn das denen nicht passt dann nehmen die lan... also lasst uns doch auch lan nehmen G spass bei seite.. das interface zwischen pc und analyzer ist einfach umzustellen wenn man schön oop macht.. und am avr kannst bis 2Mbit das serielle interface hochdrehen.. die frage ist da nur ob der pc mitkommt mit seinen 16byte fifo und 10ms microshit-raster... am besten jeder sagt mit welchen uCs er gut umgehn kann und dann wird der genommen der am günstigesen (für die aufgabe) erscheint... und im übrigen wäre auch ein windows programm, bei dem darauf geachtet wird, dass es unter wine läuft auch kein all zu großes probelm... gegen java hab ich was.. das ist böse und langsam... eigentlich ist jede sprache bei der ich nicht der gott meiner cpu(s) bin böse... ;) und nebenbei soll das ganze doch recht fix laufen..darum würde ich c++ und ein portables widgetset bevorzugen.. das ist einfach das schnellste... gut jetzt stell ich mal auf was ich gerne hätte ;) GUI : C++ und portables widgetset.. uU. python oä. uC : AVR bin mit dem gut vertraut Target => Messdings : 3V/5V inputs reichen Messdings => uC : übers speicherinterface uC => PC : im prinzip wurscht... bevorzugt rs232 da einfach ;) alternativ usb und ft... 73
> gegen java hab ich was.. das ist böse und langsam...
Java langsam, und dann schlaegst du Python vor? Man kann gegen Java
sagen was man will (zu viel Einfluss von C++, hoher Speicherverbrauch),
aber langsam ist es nicht. Benchmarks darfst du dir selber suchen.
es mag schon sein, dass java für "0815-anwendungen" (also programme die nicht auf die hardware zugreifen dürfen) schnell genug ist... aber im prinzip verliert java alle vorzüge damit,dass wir hier auf irgend ein interface zugreifen müssen... und java guis gefallen mir einfach nicht... so jetzt genug meinung kund getan ;)hier ein kleines benchmark ergebnis ;) http://www.twistedmatrix.com/~glyph/rant/python-vs-java.html man beachte die python version.. noch mehr zu dem thema findet sich hier.. http://python.fyxm.net/doc/Comparisons.html#java alles in allem ists wurscht was man nimmt... ;) daran solls nicht scheitern... 73
@ope: Den Spartan 3 gibt es auch als nicht BGA Versionen. Schau mal weiter oben nach, dort habe ich sie aufgeführt mit Preisen. Preisanfrage an Reichelt schick ich heute noch raus. Gruß Jörn
@ope: Schau mal hier: http://www.xilinx.com/bvdocs/publications/ds099-1.pdf auf Seite 4. Dort sind die verfügbaren Packages aufgeführt.
Hans: Dein Benchmark ist 5 Jahre alt. http://shootout.alioth.debian.org/benchmark.php?test=all&lang=java&lang2=python&sort=fullcpu
@Hans >http://www.twistedmatrix.com/~glyph/rant/python-vs-java.html > >man beachte die python version.. man sollte aber auch die getestete Java Version beachten: JDK 1.1.7B! Meine Meinung zum Thema Programmiersprache: Jede hat Vorzüge und auch Nachteile. Die perfekte Lösung gibt es nie - man muss immer den Weg des geringsten Übels nehmen. Peter
Jeder schlägt hier was anderes für die PC-seitige Software vor, aber ist denn auch einer bereit, diese in der von ihm vorgeschlagenen Sprache zu schreiben? Man kann viel vorschlagen, aber wenn's nachher nicht umgesetzt wird, bringt das nix.
@andreas lassen wirs gut sein.. ich mag java nicht besonders und aus ;) sonnst wird das hier noch off topic.... @jörn,ope,... könntet ihr die freundlichkeit haben und einen cpld/fpga nehmen den in at zu bestellen gibt??? ;) z.b bei rs oder farnell oder wen auch immer.. reichelt hat mich das letzte mal seeeeeehr unfreundlich abgefertigt.. 73
Ich wollte jetzt nicht sagen, dass Java genommen werden soll. Man sollte die Programmiersprache nach den Anforderungen aussuchen. Z. B.: Soll die Messung in Echtzeit am PC dargestellt werden? Dann ist Basic sicher nicht die besste wahl. Sollen die Messergebnisse aber nur dargestellt werden, ist die Geschwindigkeit der GUI allemal ausreichend. >Jeder schlägt hier was anderes für die PC-seitige Software vor, aber ist >denn auch einer bereit, diese in der von ihm vorgeschlagenen Sprache zu >schreiben? Wenn ich nicht gerade mitten im Hausbau stecken würde wäre ich gern dabei. Peter
das geringere übel sieht bei mir so aus, dass ich etwas nehme mit dem ich leicht auf schnittstellen zugreifen kann.. wenn geht möglichst nah am os... also würde ich c++ hernehmen... portabilität ist sowieso (fast) wurscht... es sei denn der analyzer bekommt lan... ;) drum c++ und portables widgetset... 73
@Hans: Reichelt war jetzt nur ein Vorschlag. Mal abwarten, ob die die Dinger überhaupt besorgen können.
Hallo, ich denke das die Software auf dem PC nicht so wichtig ist. Da ja alles wegen der Geschwindigkeit in RAM's, FIFO's oder was auch immer abgelegt werden soll. Den PC bräuchte man dann nur um die Daten Grafisch darzustellen, deswegen wird es auch nicht so diegroße Rolle spielen welche Übertragungsart. Besser wäre es evtl. mit externen Taktsignal so das auch keine Baudraten generiert werden müssen, dann kann auch jeder ziemlch einfach sein eigenes PC-Prog schreiben um die Daten zu empfangen. Ich finde das Übertragungsprotokol sollte möglichst einfach sei z.b. eine Reizleitung damit die Daten z.b. in 8Bit Paketen an die Parallelschnittstelle gelangen. Vielleicht lassen sich ja 2 Protokolle integrieren so das man z.b. per Jumper eine Serielle oder parallele Übertragungsart wählen kann. Besser wäre es evtl. mit externen Taktsignal(bei serieller Übertragung) so das auch keine Baudraten generiert werden müssen, dann kann auch jeder ziemlch einfach sein eigenes PC-Prog schreiben um die Daten zu empfangen. Ich würde für dieses Projekt auch was spenden oder bezhalen damit die Hauptentwickler dafür etwas entschädigt werden und evtl. die Platinen bestellt werden können usw. Man müsste mal ein WIKI-Beitrag aufmachen um rauszufinden wie so die Anforderungen sind. Mehr wie 8bit wäre natürlich nicht schlecht. Man könnte da ja auch einfach 2 8bit Speicherbausteine nehmen also fürs Low und fürs High Byte. Kanalanzahl: 8 ||||| ||| 16 ||||| |||| ..... Max. Abtastfrequenz: 10 MHz |||| 20 MHz ||||| ||| 40 MHz |||
Sorry, aber ich bin nach wie vor der Meinung, dass das mit einzelnen FPGAs, von Reichelt oder egal woher nix wird. Wer aus'm Forum hat denn schon z.B. TQ144er per Hand aufgelötet? Beim TQ144 beträgt der Pin-Abstand 0,5 mm - mit Lochrasterplatten ist da lange nix mehr ;-) Mir hat letztens schon ein SSOP28 mit 0,65 mm gereicht (AD9851). Dazu kommen noch haufenweise Stütz-Cs, evt. ext. RAMs, Spannungsregler, LEDs, FT232/245 oder MAX232... Mal ganz provokant: Jemand der Familie, Haus, Job oder gar alles drei hat kann das vergessen. Also m.E. muss ein kostengünstiges, fertiges Board herzu, und dann wie schon von anderen bemerkt ein ordentliches Konzept, Programmiersprache ist erstmal egal, wichtig sind die Interfaces zu definieren.
Hallo, >Wer aus'm Forum hat denn schon z.B. TQ144er per Hand aufgelötet? Ich und werde es wohl auch jeden Tag weiter machen muessen. Sehe deshalb weniger ein Problem so ein FPGA zuverloeten. > Also m.E. muss ein kostengünstiges, fertiges Board herzu, > und dann wie schon von anderen bemerkt ein ordentliches > Konzept, Programmiersprache ist erstmal egal, wichtig > sind die Interfaces zu definieren. Ein kostenguenstiges Board koennte man bauen wie ich es schon Angeboten habe. Aber dazu sollte Wirklich ein Lastenheft geschrieben werden. Zum Thema USB o. RS232 bin ich eher dafuer RS232 zunehmen. Wer USB haben moechte kann sich ein Wandler kaufen fuer 10 Euro. Das ist immer noch billiger als selber ein FTDI Chip zuverbauen. > Sorry, aber ich bin nach wie vor der Meinung, dass das mit > einzelnen FPGAs, von Reichelt oder egal woher nix wird. Sobald man sich auf eine Type festgelegt hat koennte man auch die Verfuegbarkreit pruefen. Wurde schon ein Wiki Artikel eroeffnet? Link? gruß, Dirk
vielleicht wäre es ja eine gute idee den controller per spi dranzumachen.. das bräuchte wenig pins und wäre schnell genug... bei open cores gäbe es da auch einige implementierungen nur weiß ich nicht ob die was taugen da ich keine ahnung vom cpld spielen hab... dem cpld sag ich per spi er soll gefälligst anfangen zu tun und dann warte ich z.b bis der busy pin wieder low wird... alternativ wäre das auch per spi abfragbar.. oder start per pin... was einfacher ist... im übrigen bin ich für die am einfachsten zu realisierende lösung ;) 73
Hi, hier erstmal was zum lesen, was ich so im Laufe der Zeit zu diesem Thema gesammelt habe: - XYZs of Logic Analyzers: http://web.mit.edu/6.111/www/s2005/HANDOUTS/LA.pdf - Handheld Pocket Logic Analyzer (XApp368) http://www.xilinx.com/bvdocs/appnotes/xapp368.pdf - Handheld 1553 Bus Data Analyzer (XApp369) http://www.xilinx.com/bvdocs/appnotes/xapp369.pdf - PC-basierter 32-Kanal-Logik-Analysator http://www.amateurfunkbasteln.de/pcla/pcla.html - eebit.com...home of the FPGA-based Logic Analyzer http://www.freepcb.com/eebit/ Die Idee mit dem PC/104 ist nicht schlecht, ich war schon bei einem VIA EPIA wegen Platz und Schreibtisch..., aber erstmal sollte man kleine Brötchen backen - bitscope http://www.bitscope.com hat auch einen LA Nun mein Senf zu RS232 oder USB: Mein Mother Board hat noch RS232, wenn ich wohl in 3 Jahren ein neues kaufe, werde ich wohl keine mehr haben. Also kann ich mir dann für 15 Euro eine Schnittstellenkarte (wird dann wohl PCIe sein müssen) kaufen. Wer heute die 10 für einen FTDI ausgeben möchte, kann das ja machen - evtl. musst Du es ja morgen selber machen (und jetzt denk mal 3 Jahre wieder zurück, was Du damals gemacht hattest und vor allem warum - und vor allem, wo sind die verfluchten Unterlagen dazu ...) Will sagen: Entweder/oder auf dem PCB bestücken oder per Jumper RS232 bzw. USB scharf machen. Dies war übrigens auch ein Streitpunkt bei dem Netzteil Thread. Noch mehr Senf zum GUI: Der, der es programmiert, sollte das wählen, was er am besten kann - denn er macht die Arbeit und hat die Probleme am Hals und alle anderen profitieren anschließend davon. Ich persöhnlich wäre von allem anderen außer C++/Qt/WxWindows nicht angetan, aber ich hätte (als Nutzer) ein (hoffentlich gut) funktionierendes GUI und wenn ich Lust && Laune habe, kann ich ja mein Eigenes meinetwegen in APL/Algol/Cobol/Fortran ... schreiben und habe eine funktionierende Vorlage (im Source unter GPL idealer Weise)! Aus meiner Projekterfahrung mit C++/Opensource: Ich habe über 2 Jahre gebraucht, um es dahin zu bekommen, wo es hin sollte. Jetzt, wo es dort ist und ich die Erfahrung habe es neu und besser zu schreiben, habe ich etwas die Lust/Interesse verloren. Hier wird es nicht anders werden - gerade wenn man sieht, wie auf sourceforge die high scores für DVD Rip && Crunsh in die Höhe schiessen und man selber froh ist unter die Top 1000 zu kommen. @Dirk: 0.5mm TQ144 löten: Hat es beim ersten Mal sofort geklappt bzw. wieviele haben es nicht überlebt? Ich schätze mit dem Verfahren Lötkolben, Lötzinn auf Beinchen streichen und Brücken mit Litze beseitigen, oder? Bei einem toten CPLD ist es schmerzlich aber zu verkraften, bei einem FPGA für > 35 (farnell) hat man vom reinbeißen bald keine Tischkanten mehr. @Jörn: Spartan III hätte also kein BGA, aber ich schätze, um externen Speicher kommt man nicht 'drum'rum (mit dem erwähnten Interleave). Dies zeigt auch Bennedikts Erfahrung beim Protokoll loggen. In diesem Fall wäre im FPGA nur die Address- und Triggerlogik, imo würde dann auch ein CPLD reichen, womit viele glücklicher wären. Auch könnte man dann von Benndikts Erfahrung profitieren. Aber dies muss erstmal verifiziert werden, d.h. einer muss einen kleinen Entwurf in VHDL (oder will jemand Verilog?) machen. Thema CPLD und Speicher Interleave: Der CPLD müßte die Adressen generieren und den Datenbus für jeden zB. SDRAM buffern. Kurze Rechnung: 14 Bit Addressbus -> 16k Speichertiefe 8 Bit -> 8 Channel ---- 22 Pins + Chip Select + R/W_ ---- 24 Pins * 4 Bänke = 96 Pins Damit kann der LA mit 60MHz und 70ns SDRAM los heizen (sofern der Überschlag stimmt). Mit 8 Pins für den Input sind's schon 104 Pins, hinzu kommt serielle Kommunikation. Nun gut, die XC9500 kommen bis zu 192 I/O, da kann evtl. noch eine 5te/6te Bank genommen werden und 100ns (pauschal) SDRAM verlötet werden oder eben mehr MHz. Wie dem auch sei, es würde heissen je 8 Channel einen CPLD... Jeder könnte selbst soviel zahlen/löten wie er will. Thema FPGA/CPLD und uC: pAVR opencore.org. Macht einen AVR im FPGA, allerdings soll er nur die Kernfunktionalität haben. Sofern keiner damit praktische Erfahrung hat, würde ich empfehlen einen MegaXX einzulöten, zumal imo viele dann austeigen werden (relevant für nächsten Topic). Mit diesem kann mittels DAC die Triggerschwelle eingestellt werden und die Kommunikation der ggf. mehreren CPLD übernehmen. Keep it simple: i2c 4-8 Channel DAC für 1,80 - no PWM (ground bounce, EMI etc.) Thema 4 layer PCB: Auf http://www.soudez.be/Page_Projet2.php ist ein DSO zu sehen, dass mit 100MHz arbeitet. Leider habe ich keinen Hinweis auf das realisierte PCB gesehen, ich habe aber auch keine Lust momentan mich durch http://www.edaboard.com/viewtopic.php?t=41841&highlight=dso zu wälzen ob er ein multi layer hat. Worauf ich hinaus möchte: je mehr sich finden, desto preiswerter wird's für den Einzelnen (sofern Einigung wenigstens in der Hardware besteht) Thema Self test und Safety: Bei keinem LA von oben habe ich Anregungen bekommen wegen Eingangsschutz oder Self Tests. Gesetzt dem Fall ich bekomme Reuma und habe ein Schafsfell auf dem Stuhl, ich bin nervös und rutsche nervös mit dem Hintern in meiner sportlichen Synthetik Trainingshose drauf rum und greife auf die Eingangsklemmen - wieviel kV werden da wohl entstehen (bitte keine jetzt keine erstgemeinten Rechnungen, da ansonsten u.a. Annahmen über die Schubbelgeschwindigkeit getroffen werden müßten :) Auch kommt man manchmal in die Verlegenheit, dem LA zu misstrauen!! Last but not least: Die Probleme kommen von da, wo man sie am wenigsten erwartet. Ich selber kann ein Lied davon singen, je mehr man in's Detail gehen muss, desto mehr muss man feststellen, was man alles nicht weiss oder dann doch nicht berücksichtigt hat. Ebenfalls uch aus meiner Projekterfahrung: Planung ist gut, aber letzlich gelingt es meist doch erst bei dem 2 Entwurf, gerade wenn alles neu ist und man sooo gut alles durchdacht hat. Es ist halt kein 0-8-15 Teil, was man da machen möchte. Viele Grüße Olaf
Hallo, hier ein Wiki Beitrag http://www.mikrocontroller.net/articles/Logic_Analyzer hoffe das ich es richtig abgelegt habe.
Hallo, und wenn man die Schnittstelle möglichst vielseitig macht dann kann da jeder seine Software machen wie er will. Ich sehe es für mich am leichtesten wenn z.B. 8 bits an den Parallelport gelegt werden und dann ein Taktsignal folgt damit der PC weis jetzt Port abfragen. Oder aber 2 Sendeleitungen für ein Serielles Signal also Signalleitung low oder high und dann auch wieder ein Taktsignal damit der PC weiß jetzt Bit einlesen. Dadruch spart man sich schonmal die Baudratengenerierung das start und Stopbit was schonmal über 20% bringt und es wäre sehr leicht zu implantieren. Einfach Bit einlesen in ein Register schieben und nach dem 8ten von neu anfangen.
Hallo, >@Dirk: >0.5mm TQ144 löten: Hat es beim ersten Mal sofort geklappt bzw. >wieviele haben es nicht überlebt? Ich schätze mit dem Verfahren >Lötkolben, Lötzinn auf Beinchen streichen und Brücken mit Litze >beseitigen, oder? Bei einem toten CPLD ist es schmerzlich aber zu >verkraften, bei einem FPGA für > 35 (farnell) hat man vom >reinbeißen bald keine >Tischkanten mehr. das verloeten ist nicht das Problem (ohne Loetbruecke) das schlimmste ist nur das richtige Positionieren. Jeder macht mal Fehler und somit kann mal einer sterben, aber eigentlich hab ich bis jetzt noch keinen gekillt. Industrieflussmittel ist der beste Freund bei solchen Sachen. >Damit kann der LA mit 60MHz und 70ns SDRAM los heizen (sofern der >Überschlag stimmt). Mit 8 Pins für den Input sind's schon 104 Pins, >hinzu kommt serielle Kommunikation. Nun gut, die XC9500 kommen bis zu >192 I/O, da kann evtl. noch eine 5te/6te Bank genommen werden und >100ns (pauschal) SDRAM verlötet werden oder eben mehr MHz. Wie dem >auch sei, es würde heissen je 8 Channel einen CPLD... Jeder könnte >selbst soviel zahlen/löten wie er will. Diesen Vorschlag finde ich extrem gut. Mir wuerde naemlich schon ein 8 Kanal Geraet reichen mit 8kbit Speichertiefe. Der ANT8 liegt bei ca. 250 Euro und duerfte die billigste Konkurrenz sein. Gruß, Dirk
Nur um auch mal meinen Senf zur Schnittstellen-Thematik dazuzugeben: Wenn ich überlege wie glücklich ich bin einen seriellen Programmieradapter zu haben weil das ganze Parallelport-Geraffel nie richtig funktioniert hat, bin ich der Meinung das der Parallelport die denkbar schlechteste Alternative wäre. Außerdem stirbt dieser Port bei den modernen Mainboards genauso aus, wie RS232 und ein USB-Parallel-Wandler hab ich auch noch nirgends gesehen (allerdings hab ich auch noch nicht nach gesucht) Um das LAN nochmal aufzugreifen (ich weiß gar nich obs überhaupt ernstgemeint war): Möglich wärs wohl mit nem RTL8019 o.ä. oder sogar ohne Controller alá Igor UDP, aber die Übertragungsrate wäre wohl alles andere als zufriedenstellend. RS232 oder USB wären also wahrscheinlich schon das sinnvollste. Wobei ich zu einem FT... tendieren würde, da man so wohl die höchste Geschwindigkeit rausbekommen würde, wenn man den Umweg über RS232 + USB Adapter geht hätte man den MAX232 als Flaschenhals (garantierte Geschwindigkeit laut Datenblatt nur 120 - 200kbps, je nach Typ)
Oh, USB-Parallelwandler gibt es, sogar welche mit erweitertem Funktionsumfang zum selberbauen: http://www-user.tu-chemnitz.de/%7Eheha/bastelecke/Rund%20um%20den%20PC/USB2LPT/index.html Wenn doch FTDI-Chips verwendet werden, dann doch wenigstens den FT245, der der LA-Hardware gegenüber ein deutlich schnelleres paralleles Interface aufweist ... RS232 ist zwar immer noch besser als von Hand abmalen, aber bei einer maximal erzielbaren Datenrate von 10 kByte/sec (115200 Baud, schneller wird die serielle Schnittstelle, wie sie noch in üblichen PCs zu finden ist, nun mal nicht).
Hi, wenn man den Platinenplatz nicht beruecksichtigt und ein AVR schon auf dem Board vorhanden ist koennte man noch ein RTL8019s dazubauen. Die billigste aber auch die langsamste Moeglichkeit duerfte RS232 sein.
ich bin zwar kein 8051-freund aber gibts da nicht welche mit usb ??? cypress hat doch so dinger oder??? das würde eingentlich schon viel erschlagen... neben der uc problematik auch gleich das usb zeugs... ich hab da bei rs mal AN2131QC bzw AN2131SC gefunden...cypress meint aber dazu not recomended for new designs... aber im prinzip.. und 14/12e bei rs.. kostet also das was ein ft kostet und bietet die möglichkeit beides(rs232 und usb) fahren zu können... ethernet wäre wirklich eine lösung aber nur in verbindung mit einem netten arm und linux...sonst seh ich da zuviel code, der nie wirklich rennen wird... 73
Hallo, also wenn man eh nur 64 kBytes Speichertiefe hat kann sich ja jeder ausrechnen "wie lange" das mit RS232 dauert. Also ich könnte da mit 6 Sekunden Übertragungsdauer zum PC leben. Aber gut USB ist natürlich der Standart der die nächsten Jahre überleben wird.
Hi, etwas konkreter weiter gesponnen - ich habe mal bei Farnell wegen den SRAM geschaut - bei Reichelt gab's Zeropower SRAM Dil-28 32Kx8 70ns und Zeropower SRAM Dil-28 32Kx8 70ns - we soll das denn kaufen? Zurück zu Farnell: Der AS7C3256A-15TCN 32K x 8 / 15ns TSOP mit 3.3V http://de.farnell.com/jsp/endecaSearch/partDetail.jsp?SKU=7772955&N=401 bzw http://www.farnell.com/datasheets/54444.pdf für 2,84 Euro klingt schon mal gut. Da waren meine 70ns etwas großzügig bemessen. Es reichen für >50MHz auch 2 Bänke. Allerdings TSOP mit 0.5mm. In SOJ gibt's die aber auch im Datasheet. Wie Dirk schreibt, ist das Positionieren nichts für Grobmotoriker - aber was ist das schon in der Elektronik :) Die 3.3V habe ich bewußt ausgesucht, um die Störpegel gering zu halten. Auch für den CPLD. Ein XC9536XL-5VQ64C http://de.farnell.com/jsp/endecaSearch/partDetail.jsp?SKU=3849030&N=401 bzw http://www.farnell.com/datasheets/28287.pdf kostet 5,90 (Farnell) mit 5ns und 36 I/O, damit sind 178MHz machbar, na wer will immer noch bei den Möglichkeiten Lochraster nehmen :) Falls die I/O knapp werden: XC9572XL-10TQ100C http://de.farnell.com/jsp/endecaSearch/partDetail.jsp?SKU=3849090&N=401 bzw http://www.farnell.com/datasheets/28289.pdf mit 10ns, 72 I/O und 178 MHz max für 10,10. Mal kurz rechnen: 15 Adressleitungen -> 32k 8 Datenbus 3 Steuerleitungen --- 26 I/O per SRAM bei 2 Bänke (52 I/O) und 8 Inputs sind noch 12 I/O für Kommunikation o.a. frei. Offenbar liegen hier die Grenzen und ist ein XC9572 zwingend - oder man macht Abstriche und nimmt eine Bank. Immerhin bekommt man für ~15Euro 8x 133 MHz Channels, ohne Input Stage. Thema Taktgenerierung: VCO per uC programmierbar, damit kann man dann echt die Grenzen austesten. Die Chips dazu gibt's bei Maxim/AD und den anderen üblichen Verdächtigen. Aber danach zu suchen ist mir heute zu spät. Wichtig dürfte geringer Jitter sein, also PLL - wie gesagt ... schon was gefunden? Thema xxx MHz: Wenn ich mir die Möglichkeiten so ansehe, wird wohl ein Multilayer notwendig sein, ansonsten sind's Perlen für die Säue... Was mir etwas Sorgen bereitet sind die Langen Leitungen von der Messstelle zum CPLD. Einige LA (Tek/Agilent) scheinen eine Box zu haben, wo die ca 5 cm langen Messtrippen rauskommen und dann ein Twisted Flachband von ca. 30cm ... wohl aus gutem Grund. Ich vermute mal, in der Box sind die Level Trigger und eine Art Bus Treiber zum eigentlichen Gerät - wer weiss mehr? Thema Input Stage: siehe zuvor. Schnelle Komperatoren gibts bei den üblichen Verdächtigen, aber heute zu spät schon ... Nur die Schutzmaßnahmen am Eingang... Das Elko schlägt Transis anstelle von Dioden vor (Ableitung auf Betriebsspg./Erde) aber wie sieht das aus der HF Technik aus? Thema Cache aus Motherboard: Dann müssten alle bei ebay das gleiche Motherboard kaufen was unverhältnismäßig die Preise in die Höhe treibt ... Auch schafft dies keine allgemein zugängliche Lösung. BTW, bei den SRAM preisen würde sich das auch nicht lohnen. Thema prinzipieller Natur: Alles hier beruht auf der Annahme, das es mit einem CPLD machbar ist. Proof of Concept fehlt also, evtl. nicht ganz -> Bennedikt. Es wird auch nichts für Beginner werden, alleine schon das Löten gibt Anlass zur Freude :-) Thema organisatorischer Natur: gibt's morgen, ich sehe schon Eagle <-> Protel <-> .... Viele Grüße und gute Nacht Olaf PS: Man, schon wieder soviel geschrieben, dabei bin ich ein ganz stiller Typ :)
Hallo, wenns sich genug Leute finden würden, wäre das bestücken lassen warscheinlich auch kein Problem oder? Hat schomal jemand so ne kleine Serie Platinen inkl Bestückung fertigen lassen? Mit welchen Preisen ist da zu rechnen?
ich greif dem morgen gleich mal vor und schmeiss das thema geda ein ;) hat damit schon mal wer gearbeitet?? wenn wie vernünftig ist das teil??? nachdem mir mein raid jetzt offiziell tot ist muss ich mir jetzt keine gedanken mehr um windows machen => komplettumstieg auf linux => geda wird interessant... zum thema clock.. CY22393,CY22394,CY22395 CY22393 liesse 6 unterschiedliche clocks zu...wäre doch geil ;) 6 module mit unterschiedlichen zeitbasen G die frage ist nur..wozu G dummerweise gibt nur den 5er bei rs und bei farnell überhaupt keinen... 73
Ich stimme der Meinung zu, das die parallele Schnittstelle nicht die erste Wahl ist. Wir haben auf der Arbeit 2 Personal Logic Analyzer von Agilent und immer wenn wir die Teile an einen neuen PC haengen gibts Probleme mit den Schnittstellen. Das Teil braucht ganz bestimmte Schnittstellenmodi und mit manchen Rechnern will es auch gar nicht spielen. Ich wuerde die Variante RS232 mit einer Bestueckungsoption fuer den FTDI... vorziehen. Auch den Vorschlag, das ganze aus Modulen mit je einer 8-Bit- oder meinetwegen auch 16-Bit-Capture-Unit mit eigenem Speicher aufzubauen finde ich gut. So kann jeder selbst bestimmen wie viele Kanaele er implementiert. Das Problem oder besser die Herausforderung ist dabei halt die Verbindung der Module untereinander und mit dem Controller (gemeinsamer Takt, Triggersignale, Daten auslesen). Das wuerde auch gleich die Frage nach dem Steuerbaustein beantworten, ich denke da passt ein PLD pro Modul am besten. Das ganze wuerde dann schon recht nahe an meine bisherigen Vorstellungen fuer einen modularen LA herankommen. Hier mal kurz einige der bisherigen Gedanken: Das Controllermodul enthaellt die Schnittstelle zum PC, den Addresszaehler fuer alle Module und die Takterzeugung fuer alle Module. Hier koennte man auch so Sachen wie Pre-/Posttrigger, Sampletakt, Speichertiefe konfigurieren. Die Capture-Module enthalten je einen PLD und den Speicher. Der PLD integriert die Triggerlogik und die Steuerung der Transfers zum und vom Speicher (evtl. verschachtelte Zugriffe auf 2 Speicher). Auf allen Modulen lassen sich Triggerbedingungen konfigurieren (Pegel, Flanke) und die entsprechenden Ausgangssignale werden auf dem Controllermodul im PLD ausgewertet. Noch voellig offen und nicht minder wichtig sind aber so Sachen wie Anpassung der Triggerlevel und Eingangsschutzbeschaltung. Da haetten wir also eine weitere Variante im grossen Ringen um die perfekte Loesung. Wie waere es wenn einfach mal einer derjenigen,die schon angefangenen Code haben diesen etwas genauer vorstellen und ausgehend davon entschieden wird wie es weitergeht. Ideen gibt es sicher genug, aber wenn schon etwas brauchbares da ist waere es doch schlecht das zu ignorieren. Nochwas, koennen wir die Wahl der Softwareumgebung erstmal ausklammern? Das wird erst interessant sobald ein Stueck funktionierende Hardware vorliegt. Der Weg bis dahin ist variantenreich genug. Jens PS: Falls noch ueber verschiedene Parameter abgestimmt wird, hier ist meine Wunschliste: Speichertiefe: >=8k Sampletakt: >=32MHz Kanaele: 32
hmmm dann bekommt jeder cpld (der captured) einen cs-pin dazu... der schaltet den spi auf threestate... also hängen alle module am spi bus.. immer eins wird ausgewähl und wird konfiguriert.. alternativ könnte man auch i2c nehmen... aber ich bezweifle, dass es dann spass macht grössere speicher zu kopieren... und am besten sieht man alte isa stecker am "mainboard" vor wo der controller drauf ist und steckt dann dort die module rein... wenn damals 16mhz gingen.. und pci immerhin auch als 66Mhz version verfügbar ist düfte damit das clk-verteilen kein problem mehr sein... bleibt noch die frage nach einem geeigneten controller.. ich bin für "am schnellsten" und "am meisten ram"... da würde z.b ein LPC2106 ganz gut passen... der bekommt dann noch die gzip-lib rein und macht immmer 16kb blöcke die er komprimiert überträgt.. sollte doch ganz gut gehn und dadurch dürfte auch rs232 schnell genug werden ;) gut also was haben wir jetzt alles auf der wishlist... möglichst billig modular modular möglichst simpl was hätten wir an vorschlägen was bauteile betrifft... XC9536XL oder XC9572XL =>cpld AS7C3256A =>sram avr/arm =>controller CY22393/CY22394/CY22395 =>clockgen interfaces cpld=>controller : spi,i2c controller=>pc : rs232(,usb,ethernet)
Hallo, ich denke mal mit Porttreiber gibt keine Probleme unter XP auf die parallele Schnittstelle zuzugreifen. Auf jedenfall ist es mit einem Basic-Interpreter sehr einfach darauf zuzugreifen und die Daten in eine Datei abzulegen. Ich würde mir zur Datenübertragung an den PC eine AVR wünschen so kann jeder das ganze auf seine Zwecke anpassen nen LPD kann warshceinich nicht jeder programmieren. So stel ich mir das inzwischen vor. Die einzelnes Bytes (16bit) z.b. auf je einen Speicherbaustein geben. Mit der Logic werden die Adressen an die RAMS übertragen und die Schreibbefehle gesendet bis diese voll sind. Und um das ganze dan auszulesen kann man sich z.b. eines AVR's mit einpaar Latches bedienen, so kann jeder sein gewünschtes Protokoll verwenden. Gut fände ich wenn man die Samplerrate per Dipschalter vorgeben kann, auch könnte man durch z.b. einen 4bit Code(Dipschalter) dem PLD mitteilen wie groß die Speicherbausteine sind damit man vorwählt wie weit der PLD hochzählt bis er stopt, so kann jeder die gewünschte / finanzierbare Speichergröße verbauen.
Angehängte Dateien:
-
Logic_Analyzer_RAM2.png
16 KB
Hallo, Habe meine Gedanken auch mal in einen Schaltplan gefasst. Was haltet ihr davon? Auflösung ist etwas hoch gewählt. Ich stelle es mir so vor: Von oben rechts kommen die Signale rein die dann direkt an den I/O's des Speichers anliegen. Links gehen die Leitungen weiter zum PLD für die Triggerung. Über die Dipschalter kann man jetzt den Kanal zum triggern auswahlen, die Triggerart einstellen, die Größe der Speicherbausteine und wie schnell der PLD die Adressen hochzählt und die Schreibbefehle übermittelt. Das würde jetzt alles komplett selbständig ablaufen. Wenn der PLD seine Adressen komplett durchgezählt schaltet er die Adressleitungen wieder auf 0 und schaltet eine Leitung des AVRs auf High so das dieser weiß er kann jetzt mit der Datenübertragung beginnen. Er gibt jetzt über die 2te Leitung einen Takt zum PLD so das dieser jedesmal die Adresse höher stellt, der AVR steuert die Befehle zum lesen so das die Daten an 2 Ports anliegen die er dan einlesen kann. Und ja nach Protokoll was dann jeder selbst schreiben kann gibt der AVR die Daten an den PC aus.
Ich bin auf jedenfall auch ein Gegener der Idee den Parallelport zur Datenübertragung zu verwenden. Zu DOS Zeiten ging das noch ganz gut, aber mittlerweile blockiert mein Druckertreiber den Port (bzw. verändert anscheinend einfach mal so zwischendurch ein paar Pins, um den Status des Druckers abzufragen.) Früher habe ich viel mit dem LPT gemacht, aber seitdem ich diesen Laserdrucker habe, mache ich alles nur noch über RS232. Das umfasst sowohl echtes RS232 als auch den FT232 mit immerhin 75kByte/s. Außerdem hat der LPT keine Zukunft. RS232 wird es dank FT232 und uC noch in vielen Jahrzehnten geben. Die Datenübertragung von meinem Logikanalyser (mit 256kByte Speicher) läuft noch mit 115,2kBaud, dauert bei 256kB also ziemlich lange. Wenn man aber bedenkt, wie lange es dauert bis man die Daten durchgesehen hat, dann ist das noch eine akzeptable Zeit. Für eine schnelle Darstellung reduziere ich einfach die Datenmenge, indem ich nur 1kB der Daten übertrage. Das passt genau auf eine Bilschirmseite und man erkennt ob der geünschte Datenstrom über das Gerät läuft, so dass man die eigentliche Aufzeichnung starten kann. Ich würde das ganze auch mit CPLD (als synchroner Adresszähler, evtl. mit Interleaving und als Triggerung) machen. Man könnte entweder einen Globalen Adresszähler einbauen, und für jedes Modul einen weiteren CPLD für die Triggerung verwenden, oder für jedes Modul einen eigenen CPLD der den Adresszähler und die Triggerung beinhaltet. Die Module arbeiten dann im Pronzipt nur als FIFO: Schnell einlesen, langsam ausgeben. Die Daten würde ich dann zu einem AVR schicken, indem dieser die Adresszhähler resettet und der Reihe nach alle Bytes ausliest, ehe er zum nächten Word springt. Die Daten eventuell komprimieren (z.B. nur Änderungen speichert), das funktioniert eigentlich ziemlich gut. Bei vielen Signalen kann ich so die 256kByte auf wenige kByte reduzieren. Nur wenn ich sehr viele Änderungen habe (z.B. Datenbus eines uP) dann geht die Datenmenge in den MB Bereich.
Bem.: zur Schaltung wenn die Inputs direkt an die Daten-Pins des SRAM(Typ?) gehen, dann gibt es ein Problem in dem Moment, wenn der AVR die Daten lesen will (Kollision auf dem Bus) also entweder muss noch ganz vorn am Eingang ein Bustreiber rein, den man auf Tristate schalten kann oder man muss jedesmal abstecken, bevor man die Daten lesen kann. Bei 256kBytes Adressraum wird schon ein 18bit Adresscounter benötigt, damit sind die Hälfte aller Macrozellen im XC9536 weg, halte es für schwierig, die restliche Logik (Triggerung...) noch mit reinzuquetschen, ein XC9572 scheint mir das Minimum zu sein.
Hallo, ja ne Bustrennung wäre bestimmt nicht verkehrt, damit beim Lesen keine Eingangssignale auf den Bus gelangen. Evtl. 2 8Bit-Latch(573) nehmen diese kann man ja Tristate schalten.
@Tim Sehe ich auch so. @FPGA-User >Bei 256kBytes Adressraum wird schon ein 18bit Adresscounter >benötigt, damit sind die Hälfte aller Macrozellen im XC9536 >weg, halte es für schwierig, die restliche Logik (Triggerung...) >noch mit reinzuquetschen, ein XC9572 scheint mir das Minimum >zu sein Besser wäre es, 2 oder 3 XC9536 einzusetzen. Schließlich wird dieses Bauteil für EUR 1,50 bei eBay angeboten.
Ich würde bei einem solchen Projekt auf einen grösseren FPGA setzen. Ein XC3S400 hat z.B. 288k dual-ported Blockram und 4 DCMs mit denen sich ein vernünftiges Clocksignal erzeugen lässt. Als Schnittstelle ein FT245BM , der sich relativ leicht vom FPGA aus ansteuern lässt. Durch die PC-seitigen Treiber von FTDI gibt's auch keine Problem beim Software-Interface auf dem PC. Den XC3S400 gibt es als TQFP144 oder PQFP208. Ich würde aber trotzdem die Lösung mit einem fertigen Eval-Board favorisieren. Da gibt's ja eine ganz nette Auswahl.
also ich würde das interface zwischen controller und cpld über spi machen... weil der avr kann nur 16bit adressieren... ports einzeln umsetzen finde ich insofern nicht gut weils einfach langsam ist... spi kann er schnell und da gibts doch burst read wenn ich das richtig sehe... => pfuscherei wenn mans übers speicherinterface einbindet 2Mbit/sec über SPI dürften doch reichen.. sind immerhin 256kb/sec wobei ich hier immer noch 1-2sec/auslesen (also capturen => anzeige) anpeilen möchte... zum thema avr: ich würd einen arm nehmen der viel ram hat... ist zum komprimieren notwendig.. und die 64k die der lpc2106 hat sind auch schon eng....so um 1MB wär gerade richtig.. dann kann man die ganzen daten auf einem rutsch holen, komprimieren und weiterschicken... prinzipiell würde aber ein avr reichen... für die kompression müsste das halt blockweise machen... oder weglassen... ich bin auf jeden fall für die modularisierung sprich: - im besten fall einen clock-gen am mainboard der für jedes modul eine unterschiedliche timebase machen könnte - jedes modul hat seinen eigenen counter,trigger,speicher die module zu syncronisieren sollte eigentlich kein problem sein, da der clock-gen eh die clocks aus der gleichen referenz herunterteilt... => wenn man sie gleich vorgeladen werden sollten sie auch nicht großartig verschoben sein... wenn man mehrere serielle interfaces auf einem uc-board hat kann man dann ohne probleme überall ein modul ranmachen und braucht nicht dauernd umstecken udgl.. dafür bekommt dann der cpld auch noch einen ext-trigger damit man auch alle gelichzeitig an einem signal arbeiten lassen kann... @patrik: und was kostet da so ein eval board??? ich bin wie gesagt stark für die variante mit dem wenigsten aufwand ;) und kein uc der scheisse baun kann ist in meinen augen VIEL weniger aufwand ... meine ideen sind damit zwar alle hinfällig.. der preis sollte eigentlich durch die 1fpga+1ft245-lösung auch nicht so tragisch sein.. sonnst kommen ja noch ram,uc, schittstellentreiber udgl dazu... 73
... und ich dachte gestern, ich wäre spät dran :-) @Tim Sehe ich auch so. Aber evtl. kommt wenigstens ein tragfähiges Konzept raus, wenn die Software und Schnittstellenwünsche außen vor bleiben. @JME Das mit dem Clock und Trigger Event Distibution bereitet mir wegen der Laufzeit/hohen Frequenzen auch etwas Kopfzerbrechen, immerhin müssen die einzelnen CPLD untereinander kommunizieren, der uC ist zu langsam dafür; dh. Trigger Logik/Clock unabhängig vom uC! Immerhin kann ein 8bit Channel zB. den Bus abhorchen, während mit dem 2ten 8Bit Channel das Trigger Signal rausgefischt wird (CS, RW etc). Insofern sind 16Bit Breite Minimum. @Thomas O. Dipschalter: wozu, wenn doch ein uC vorhanden ist. Wichtiger wäre vielmehr ein Hardware Code Feld, wo Anzahl Channel, PCB Revision etc. vermerkt sind, damit die Firmware weiss, was sie unter sich hat. Schaltplan: Mal abgesehen vom Tristate Problem hat der uC ein Timing Problem (e.g. >50MHz vs. 16MHz) und muß zudem den Interleave wieder zusammenflicken. Sinnvoller wäre es, die Daten über den CPLD auszulesen, d.h. von den 12 verbleibenden I/O fallen 8 (daten) + 2 (cs, rd/wr_) = 10 wieder weg. Es wird also eng. Mit diesem Mini-8bit-Bus kann man aber recht einfach kommunizieren (CPLD <-> uC). Es müssen (sampled) Daten gelesen und Konfig/Trigger Daten (wenn auch wenige) geschrieben werden. Evtl. kann man ja mit den verbleibenden 2 I/O einen 4-Mode Adress Select generieren (Mode1: uC liest Daten, Mode2: uC schreibt Trigger Daten, ....) Falls die I/O bei konkreter Betrachtung nicht reicht, müssen eben Nibbles (4Byte) übertragen werden. @FPGA-User Wieso 18Bit Counter? 2^18 = 256k Evtl. wäre es für einen Delay Timer sinnvoller/notwendig? aber nicht für die SRAMs. Die Lösung mit den SRAM Bänken geht davon aus, das im CPLD das Latch realisiert wird, daher auch der höhe I/O Verbrauch. Wenn externe Buffer wieder verwendet werden (müssen), geht der kompakte/einfache Aufbau wieder verloren und man sollte eine FPGA Lösung favorisieren. Wo ich jetzt wieder hänge: 2x SRAM (2x 32kx8) + CPLD, passt das nicht in ein FPGA? Hintergrund: Das Timing innerhalb des FPGA ist berechenbar, bei einem PCB kommen mehrere Faktoren zusammen und löten muss man bei beiden Lösungen 0.5mm Beinchen ... Also, passt dies dort ein FPGA rein? Eine Lösung nun mit 2-3 CPLD zu realisieren kann nicht gut sein, da mit der Anzahl der zu verlötenden BE auch die Fehlerwahrscheinlichkit steigt -> FPGA Lösung. Offenbar bereitet die Wahl der Schnittstelle, technisch gesehen, die geringsten Probleme - evtl. sollte man diese wie auch die Softwarerealisierung ertmal ausklammern. Viele Grüße Olaf
@Hans Ich hab das Altium Board. Hat mich 120.- inkl. Versand gekostet. Allerdings bin ich mir nicht sicher ob es das Board von Altium noch gibt. Das wäre aber kein Problem, Xilinx hat eine Reihe Eval-Boards gelistet, die in Frage kommen und sich in einem ähnlichen Preisrahmen bewegen. Zudem hätte ein solches Board noch den Vorteil, dass man es auch für andere Projekte nutzen kann.
@ope ganz meiner Meinung, das wird Brühe mit mehreren CPLDs, wenn man eine 32-Kanal-Version haben will, lötet man tagelang rum um am Ende festzustellen, dass nichts geht, weil man irgendwo eine Brücke reingelötet hat und dadurch evt. noch ein Bauteil kaputt gegangen ist -> von vorn anfangen. Mit einem FPGA hätte man auf Anhieb die Mögl. für 32 Kanäle, interne Block-RAMs reichen für eine Alpha-Version sicher (z.B. 3S200 : 200 kBit Block-RAMs ergibt ca. 6k x 32 Kanäle.) Da man sowieso immer den PC dran hat, bräuchte man nichtmal ein Config-PROM und die Taktaufbereitung mit DCMs oder PLLs wäre wesentlich eleganter als beim CPLD. Synchronisation zwischen CPLDs entfällt. Eine FPGA-Version würde m.E. den uC überflüssig machen -> wieder 1 Bauteil und 1 Software weniger !
Hallo, @Olaf: In meinem Vorschlag hat der AVR nur die Funktion die Daten zum PC zu übertragen nachdem sie schon im RAM liegen, so kann jeder sein gewünschtes Protokoll integrieren und da gibts dann auch keine Timingprobleme weil der halt einfach langsamer auslesen kann und die Daten gemütlich zum PC überträgt. Zur Speicherung der Daten wird alles durch ein FPGA bzw. CLPD gemacht weil nur dieser die Geschwindigkeit aufbringt. Ok das mit den Dipschaltern ist nicht so gut, man könnte es aber vom PC an ein Schieberegister schicken so das man dann dem FPGA 255 Befehle für die Triggerart, Startverzögerung, Samplegeschwindigkeit usw zusenden kann, falls das Projekt später ja mal zuwachs bekommt.
@Thomas O. Man kann sich die ganze Synchronisiererei zwischen CPLD, AVR und Speicher sparen, wenn man alles in einem FPGA hat. Die Spartan3 haben alle dual-ported RAM was die Zugriffe von zwei getrennten Prozessen (Daten Speichern und Daten übertragen) erheblich vereinfacht. Wenn man einen FPGA verwendet ist der AVR im meine Augen überflüssig und bringt eigentlich nur zusätzliche Probleme.
Mein Vorschlag: fangt erst mal klein an, sprich 8 oder sogar 4 Kanaele (meistens hat man es sowieso mit seriellen Verbindungen zu tun) und wenige MHz Samplerate. Das sollte sich mit einem kleinen CPLD + SRAM realisieren lassen. Wenn ihr gleich mit 32 Kanaelen, zig MHz, 4-lagiger Platine, Spartan-3 und 256 kB anfangen wollt kann ich euch garantieren dass das Projekt einschlaeft.
ich habe gerade etwas im inet gestöbert und was nettes gefunden.. auf http://shop.trenz-electronic.de/ Spartan-3 200k Mikromodul 79.00EUR (91.64EUR inkl. MWSt) Spartan-3 400K Mikromodul 119.00EUR (138.04EUR inkl. MWSt) oder Xilinx Spartan-3 Starter Kit DO-SPAR3-DK 99.00EUR(114.84EUR inkl. MWSt) die preise finde ich eigentlich garnicht soo schlimm... wobei letztes hätte keinen usb2 transceiver... 73
Zum Thema klein anfangen: man nehme einen schnellen µC, lege die Signale an einen Port, tastet diesen ab und speichere die Daten im internen RAM.
Na gut, das ist dann aber wirklich "klein". Mehr als 1 MHz ist da nicht drin.
Idee für die Kommunikation (Version 0.alpha) : das FPGA bekommt einen UART-Core und extern einen MAX 232 o.ä., Es gibt Register Schreib/Lesebefehle vom PC, Acknowledge vom FPGA und Daten vom FPGA. Ein Register-Schreibbefehl geht meinetwegen mit 0x55 los, dann kommt z.B. die Adresse des Registers im FPGA, dass man beschreiben möchte und dann die Daten(Bytes) Am Schluss ein Prüfbyte, FPGA checkt das und sendet ein Ack zurück, meinetwegen 0x66 für OK und 0x77 für Fehler. Wenn der PC 0x66 zurückbekommt -> OK, 0x77 -> Fehlerausgabe an User oder Befehl wiederholen (3 mal, dann Error). Register Lesen : beginnt meinetwegen mit 0x88, dann die Register- adresse die gelesen werden soll, FPGA sendet daraufhin x Bytes mit dem Inhalt des Registers + Prüfbyte. Spezialbefehl Datenblock Lesen: FPGA sendet auf diesen Befehl hin den kompletten RAM-Block byteweise Version Beta: FPGA sendet Daten komprimiert, d.h. nur Änderungen werden übertragen Ein Register könnte z.B. den Triggertyp beinhalten, ein weiteres ein Trigger-BitMuster, dann eine Triggermaske usw. Wenn die Registermap bekannt ist, kann jeder seine eigene Software schreiben
Hallo, nagut also FPGA jetzt bin ich vollends auf euch angewiesen. Hat mal jemand eie Bezugquelle und eine Bezeichnung für ein geeignetes SRAM für mich, möchte mir mal ein Datenblatt zu anschauen. Ich habe hier ein IS61C64A-20 SRAM finde aber nur ein Datenblatt des IS61C64B Typen. Wie groß sind eigentlich diese Blockram Dinger
@Andreas > Mehr als 1 MHz ist da nicht drin. Habe das mal mit einem dsPIC gemacht (30MHz), dank seiner nützlichen Adressierungarten dauerte ein Abtasten und Speichern nur 2 Takte (ohne Delays). mov $100, W1 ; (1) Startadresse des Buffers do 2048, loop ; (2) 2048 mal abtasten mov PORTB, W0 ; (1) loop: mov W0, [W1++] ; (1) ... Habs jetzt mal aus dem Kopf hingeschrieben, ich hoffe es stimmt alles. Es ist somit viel mehr als 1MHz möglich.
Und der IO-Port macht 15 MHz mit? Dann waere das allerdings eine interessante Alternative.
Abtasten und speichern ist das eine, aber wenn nebenbei noch die Triggerung gemacht werden soll, dann wird der uC doch wieder langsam - oder ? Oder soll die Triggerung jetzt entfallen ?
Auf 15MHz wirds nicht kommen, da man ja auch langsam abtasten möchte. Daher müßte innerhalb des Schleifenkörpers noch ein delay rein: mov $100, W1 ; (1) Startadresse des Buffers do 2048, loop ; (2) 2048 mal abtasten mov PORTB, W0 ; (1) repeat "val" ; (1) 0 <= val < 16384 (min. 1 Takt, max. 16384 Takte) nop ; (1) loop: mov W0, [W1++] ; (1) ... So wären wir bei mindestens 4 Takten, also max. 7.5MHz und min. 1.8kHz.
@FPGA-User Natürlich ist klar, daß das ganze auf Kosten der Triggerung geht. Ich wollte damals einfach nur einen seriellen Bitstrom untersuchen und wartete einfach in einer Schleife auf die fallende Flanke des Signals und fing dann mit der Aufzeichnung an.
Ich weis nicht so recht. Der Schritt von einem CPLD zu einem FPGA ist nicht nur ein Schritt von unterschiedlicher Hardware und unterschiedlichen Möglichkeiten. 1.) ein reiner FPGA Analyser hat nichts mehr mit diesem Forum zu tun 2.) auch wenn FPGA's intern schneller getaktet werden können so sind sie denoch bei weitem langsammer als CPLD's. 3.) die Signale innerhalb FPGA's jitterfrei zu bekommen ist viel komplizierter als beim CPLD Ich würde es so machen: Gemeinsammer Datenbus, angeschlossen der AVR, SRAM und CPLD. Der CPLD ist deaktiviert = HighZ und der AVR übernimmt den Datenbus. Vor einer Messung trennt sich der AVR vom Datenbus = HighZ und startet das CPLD. Dieser legt über Bustreiber die Messignale auf den Datenbus und erhöht mit vorgebenen Takt einfach den Addresszähler. Das macht der CPLD so lange wie der AVR ihn über ein zusätzliches Signal arbeiten lassen möchte. SRAM's gibts asynchrone statische mit 15ns. Das Auslesen des SRAM's durch den AVR kann nun auf zwei Wegen erfolgen: 1.) der AVR ist ein ATMega162 oder 128 mit XMEM Interface und kann so direkt das SRAM auslesen 2.) der CPLD wird doppelt benutzt. Er enthält ja einen Addresszähler zum Schreiben des SRAM's. Dieser kann aber auch zu Lesen des SRAM's benutzt werden. Der SRAM wird immer sequentiell geschrieben und gelesen. Der AVR, ein ATMega8 zb. muß einen 8 Bit Port freimachen und diesen auf den Datenbus legen. Der CPLD taktet nun gesteuert vom AVR die Addresse langsam hoch. Der ATMega8 liest daraufhin seinen 8 Bit Port ein. Das ist pro Byte mit 3 Takten erledigt. Vorteil ist dabei das man nun auch zb. 512Kb statische SRAM's benutzen kann ohne das der ATMega8 oder CPLD ein kompliziertes Memory Banking benutzen müssen. Mit einem AVR + kleinen CPLD + SRAM + Bustreiber + Komparatoren ist ein Mini-Analyser mit bis zu 32Mhz Samplerate möglich. Bei dieser einfachen Version liegen im Grunde nur der SRAM Addressbus komplett am CPLD, also 16-19 Leitungen. Dann noch OE,WR,CS Steuerleitung des SRAMs, der Clock Eingang und eine Steuerleitung für den AVR. Der AVR selber benötigt einen 8Bit Port zum Lesen des Datenbusses. Dann noch zwei Steuerleitungen eine für den CPLD und eine zum Aktivieren der Bustreiber. Der Bustreiber liegt ebenfalls parallel zum AVR am Datenbus. Der CPLD stellt nur einen variabel getakteten 18Bit Zähler dar, mehr nicht. Der AVR bestimmt nun mit welchem Takt der CPLD hochzählt, kann also auch manuel Step by Step getaktet werden. Gruß Hagen
So habe ich mir das auch gedacht (Moeglichkeit 2).
Hallo, ja das ist im großen und ganzen so wie ichs gemeint habe. Denke das ist die einfachste Möglichkeit es sei denn es gibt einen Baustein wo alles integriert ist.
Hallo, falls doch die Entscheidung auf ein Spartan3 FPGA fallen sollte und einem das Loeten nicht liegt. Ein TQ144 Sockel koennte man kaufen, somit ist der FPGA tauschbar. >2.) auch wenn FPGA's intern schneller getaktet werden können so sind >sie denoch bei weitem langsammer als CPLD's. Wieviel waere den mit einem FPGA Moeglich? Gruß, Dirk
@Hagen: Das Memory Banking kam eigentlich wegen des langsamen (70ns) Speichers der sich in der Grabbel Kiste tummelt. Bei zwei Bänken wird nur das LSB des Adresszählers genibbelt und als Chip Select benutzt. Einige SRAM haben ja (CS0, CS1_) so dass mit intelligenten Layout es recht einfach wird. Das Problem ist ja das Timing des (langsamen) SRAM, da Adressen/Daten für eine gewisse Zeit stabil anlegen müssen. Kann der XC9572 nicht tristate (bzw HIGHZ) selber, so dass man den Bus driver umgehen kann: " IOPin <= 'Z'; ?? Das erinnert mich alles so an meine Z80 Zeiten und TTL Gräber .... Viele Grüße Olaf
Anbei mal mein Quellecode für den LA (Projekt für ISE 7.1). @FPGA-User: Ähnelt deiner Beschreibung... Kommunikation über RS232. Befehle setzen sich aus zwei Bytes zusammen. -erstes Byte : Adresse des zu schreibenden Registers -zweies Byte : Wert. Die gespeicherten Werte werden automatisch zum PC gesendet, wenn ein Trigger gefunden wurde und der Speicher voll ist. Gruß Jörn
@Hagen 2) und 3) stimmen so nicht, ich kann im FPGA z.B. mit 500 MHz arbeiten wenns denn sein muss, abhängig vom Speed-Grade des FPGAs. 3) was meinst Du mit jitterfrei bekommen? Bei einem CPLD wird auch nur eine max. Tpd garantiert, die Laufzeiten im CPLD sind auch von der Implementierung abhängig, das Routing über eine Switch-Matrix hilft da nicht immer. Bei einem synchronen FPGA-Design sehe ich keinerlei Probleme. Das einfache hochzählen der Adressen wird übrigens nicht reichen, ich nehme mal an, dass zumindest noch die /WE-Leitung bedient werden muss, dann aber auf die Setup- und hold-Zeiten der Adresse und min. WE-low-Time achten. Und Achtung, wenn man den Adresscounter im CPLD einfach auf die Pins rauslegt, kommt jedes Bit beim CPLD zu einem anderen Zeitpunkt raus, die Diff. wird einige ns betragen, beim FPGA nehme ich die Flip-Flops im IOB und hab damit alle Adressbits praktisch gleichzeitig auf'm Bus.
@Jörn na, das ist doch schonmal was. Lässt sich zwar besch... lesen (schlechte Formatierung) aber daraus könnte man was machen. Also wenn man nich jahrelang rumbasteln will, sollte man ein XILINX Starter-Kit kaufen, diesen VHDL-Code implementieren und ne ordentliche Software dazu schreiben, das wars.
Hi, >Also wenn man nich jahrelang rumbasteln will, sollte man ein >XILINX Starter-Kit kaufen, diesen VHDL-Code implementieren >und ne ordentliche Software dazu schreiben, das wars. ich habe mir dieses Starterkit angeschaut und werde es mir bestellen, nachdem einige Leute mir vom Xess Board abgeraten haben. Ich werde den weg wie FPGA-USER es beschrieben hat einschlagen. Um die Daten etwas schneller an den PC zusenden werde ich noch den FT245 mit anschliessen. Gruß, Dirk
@Dirk Wenn du noch etwas warten kannst: http://www.xilinx.com/products/spartan3e/s3eboards.htm Leider erst ab Q3/05 verfügbar.
Hi, danke fuer den Hinweis. Werde aber nicht solange warten und ein grosser Pluspunkt bei dem jetztigen Starterkit sind die 10ns SRAM auf dem Board. Gruß, Dirk
Also wirklich... lese hier schon länger, aber was hier so abläuft ;-)? Erst AVR... dann CPLD... dann mehrere CPLDs... dann FPGA... jetzt auch das fertige Board... Und noch eine Idee am Rande: falls ihr euch für Spartan 3 Kit entscheidet, könnte ihr alles ohne Rechner machen - ausgabe über VGA. Dank Microblaze und co ist alles kein Problem (nur so ;-)) Wenn es nur AVR und CPLD wären, würde ich mitmachen, so aber ist das zu groß (nicht für mich ;-)) konstantin p.s.: trotzdem ist alles ganz spannend :-)
wie wärs denn damit... der cpld bekommt den ram exklusiv daten wandern per spi zum uc.. natürlich im burst read ;) dann noch z.b avr,max232 und ft232 vorsehen und fertig... die triggerung reißt man auch noch aus dem cpld wenn das zu viel sein sollte.. die sollte alle möglichkeiten abdecken.. also auch trigger auf i2c start ;) hier wäre noch eine gute idee gefragt... evtl fpga den man so läd wie mans gerade braucht??? das dürfte dann die einfachste variante sein... 73
das Problem bei der FPGA-Variante sind die 100 EUR für das Dev-Kit, wenn ich das richtig verstehe? mit der CPLD-Variante wirds aber auch mindestens 50 kosten, oder will jeder sein Board selber ätzen ? Zur Motivation: Beim FPGA wären vermutlich mit den 512kBytes(?) SRAM 50 MHz drin, 32 bit parallel, ohne dass man irgendwelche Kopfstände machen müsste. Bei Nutzung der internen Block-RAMs gehe ich von 100 MHz aus bei verringerter Speichertiefe. Die Triggerung könnte extrem komfortabel sein, also z.B. "Triggern wenn Adresse = 0x0300 auf 0x500 folgt und dann warten bis /WE = 0 ist" oder so...
Hi, >Also wirklich...lese hier schon länger, aber was hier so abläuft ;-)? @K. Schmidt Erstmal muessen Ideen gesammelt werden um die Wunschtraeume auszusortieren. >Das Problem bei der FPGA-Variante sind die 100 EUR für >das Dev-Kit, wenn ich das richtig verstehe? Wenn es auf dem DEV Board laeuft kann man immer noch eine Platine routen und in Auftrag geben und bei richtiger Abnahmemasse sollten die Platinen auch nicht teuerer werden. > mit der CPLD-Variante wirds aber auch mindestens 50 kosten, oder > will jeder sein Board selber ätzen ? Auch wenn die CPLD Platine billiger werden duerfte als die FPGA Platine so ein grossen Unterschied sehe ich da nicht. Ich sehe auch viel mehr den Zeitaufwand die CPLD Platine + AVR zuverloeten. Leider kenne ich mich in der CPLD+FPGA Welt nicht so aus, aber als Anfaenger finde ich die FPGA Variante die einfachste. >Beim FPGA wären vermutlich mit den 512kBytes(?) SRAM 50 MHz drin, >32 bit parallel, ohne dass man irgendwelche Kopfstände machen müsste. >Bei Nutzung der internen Block-RAMs gehe ich von 100 MHz aus bei >verringerter Speichertiefe. Die Geschwindigkeit des FPGA's macht mir weniger Kopfschmerzen, sondern eher die Eingangsbeschaltung der LA Inputs. Normales Datenbuskabel mit Abgreifklemmen duerfte bei der Geschwindigkeit garnicht mehr funktionieren. Das Platinenlayout duerfte auch eine entscheidene Rolle spielen. Gruß, Dirk
Ok soweit ich das derzeit beurteiln kann gibts hier jetzt 4 lager 1. viele ios, viel speed (~100mhz) 2. viele ios, speed nicht im vordergrund aber schon über 10-20Mhz 3. wenige ios, viel speed <= z.b highspeed i2c,spi,usb (?) 4. wenige ios, wenig speed <= z.b i2c anschaun udgl dementsprechend glaube ich, dass es zweckmäßig sein könnt hier jetzt einige sachen vorzuschlagen... interface wenig speed : rs232 interface viel speed : usb bei der wenig speed variante könnte ich mir sogar eine avr-only version vorstellen... quasi extrem wenig speed... bei wenig ios glaube ich, dass 8 ios schon genügen würden... vielleicht noch 16 aber 32 wäre sicher overkill um sich z.b am memoryinterface eines mega128 zu klemmen...es gibt ja immerhin 18bit srams.. warum nicht so eins füllen... soweit so gut.. ich sehe jetzt folgende lösung... man lässt die fraktionen ihr eigenes süppchen kochen und schaut, dass die interfaces irgendwie kompatibel bleiben => alle haben was davon, weil ein und die selbe software mit allen capture einheiten läuft... also ich oute mich mal als ein wenig io,wenig speed typ ;) vielleicht sollte man mal im wiki dementsprechende artikel einführen und wunschlisten aufstellen ... aber zuerst wird gegessen g 73
eben gefunden, ein weiterer Link: http://sourceforge.net/projects/minila/ Leider meint der Kerl, das alle Tchechisch oder so können ... auch sind keine genaueren Angaben/Schematics/Layouts etc da, lediglich sein Kommunikations Protokoll. Nur einsam in ISE Files steht, das er einen xc95288xl verbaut hat. Kennt jemand genaueres über das Projekt? @Dirk: Tja, an den LA Inputs hänge ich auch, bisher kam dazu aber keine Ideen (außer meine Schutzdioden). Immerhin scheint die Schnittstellen- und Software Thematik endlich abgeklungen zu sein - und das ist gut so! Je mehr ich über FPGA lese, desto mehr muss ich sagen, es wird sich für viele zu einer 2ten Baustelle entwickeln, welche Kraft (und Geld) kostet... (auch wenn ein FPGA Dev Kit sicher keine Fehlinvestion ist). Viele Grüße Olaf
Wenn es um wenig Speed geht, dann könnte ich demnächst eine einfache Low Cost Schaltung mit AVR und 32kB SRAM entwerfen. Bei meinem LCD Controller schiebt ein AVR mit 18,432MHz durchschnittlich 2,4MByte/s übers SRAM. Wenn ich mich nicht verrechnet habe, dann benötige ich für die Schleife genau 7 Takte, macht also 2,6MHz Sampletakt. Das sollte für eine Low Cost Version (AVR, 32kB SRAM, 2-3 HCMOS ICs) reichen. Eventuell könnte man die Windows Software von dem großen Logik Analyser so anpassen, dass man auch diesen damit verwenden kann. Somit wäre auch die Gruppe zu frieden, die für wenig Geld einen einfachen Logikanalyser haben möchte.
die software bastle ich sowieso so hin,dass es wurscht ist ob der analyzer jetzt 4,32 oder wenn wir lustig sind 128 input hat ;) idee für die high-speed leute.... target=>(cmos/ttl->lvds wandler)=>scsi kabel(ultra-320)=>capture unit nachdem bei ulta 320 scsi immerhin 320MB/sec übertragen werden können ergibt sich daraus, dass 160Mhz signal(16bit busbreite) bei 12(!)m kabellänge eigentlich kein problem darstellen darf.. das sollte doch einige probleme lösen oder??? und wenn ein netter fpga verwendung findet dann wirds eben ein typ mit lvds interface ;) und ganz nebenbei so ein cmos/lvds interface kann nicht die welt kosten.. drum rein in einen passenden stecker und mit einer "scsi-verlängerung" gehts dann zur capture unit... denk ich da jetzt verkehrt oder würde das nicht einige probleme lösen? 73
Das Kabel Problem sollte man nicht unterschätzen. Auch die Eingangskapazität des Eingangsverstärkers sollte die zu messende Schaltung nicht allzusehr belasten. Bei meiner 40MHz Version verwende ich 74AHC245 als Eingangsbuffer. Am Anfang hatte ich eind 10 adriges 30cm Flachbandkabel dran, und hatte extremes übersprechen. Die nächste Version hatte ein 16 poliges Kabel mit je einer Masse zwischen 2 Signalen. Es war besser was das Übersprechen betrifft, aber die Kapazität war zu hoch. Jetzt habe ich direkt die Abgreifklemmen über 15cm Kabel dran.
es müsste doch mit den passenden lvds-treibern recht weit übertragbar sein... wie gesagt müsste man testen... zur weiteren inspiration: http://alternatezone.com/electronics/pcla.htm http://www.bitscope.com/ 73
http://eebit.com/ hin und wieder wäre ein edit schön... an dem teil könnte man sich schon orientieren... 73
@Hans nicht gleich mit der Keule losschlagen, lass mal LVDS außen vor, da gibts noch paar andere Probleme vorher. Klar wirds schwer, mit z.B. 50 MHz über ein Flachbandkabel zu gehen, aber das kann man in einem 2ten Schritt angehen. Bin eher ein Freund von stufenweisen Projekten, wenn erstmal die Hardware was tut und die Software läuft ist schon viel gewonnen. Und eine hohe Abtastrate kann für viele Anwendungen interessant sein, man könnte z.B. einen A/D-Wandler mit 50 MS/s anschliessen, der Triggerwert wäre dann praktisch der Analogpegel. Könnte das ein interessantes Feature sein? Beim CPLD-Lowcost-Projekt wäre das recht schwierig nachzurüsten. Für die Kabel zum Testobjekt findet sich bestimmt ein Spezialist mit einer praktikablen Lösung.
@FPGA-User: "nicht gleich mit der Keule losschlagen, lass mal LVDS außen vor, da gibts noch paar andere Probleme vorher." Yep! "Und eine hohe Abtastrate kann für viele Anwendungen interessant sein, man könnte z.B. einen A/D-Wandler mit 50 MS/s anschliessen, der Triggerwert wäre dann praktisch der Analogpegel. Könnte das ein interessantes Feature sein? Beim CPLD-Lowcost-Projekt wäre das recht schwierig nachzurüsten." Bitscope ist so'n Projekt, solche Scope nennen sich auch Mixed-signal Oscilloscopes MSO, zB Agilent http://www.home.agilent.com/cgi-bin/pub/agilent/Product/cp_Product.jsp?NAV_ID=-14104.0.00&LANGUAGE_CODE=eng&COUNTRY_CODE=US&cmpid=93375. Aber wie soll hier ein MSO geschweige DSO entstehen, wenn es keine Einigkeit über den simplen LA gibt? -> s.o. Ich selber hänge gerade im Eagle an einer fehlenden Bibliothek für den XC9572PQ100. Hat jemand eine zufällig? Damit geht eine Baustelle schon los, die an sich mit dem LA nichts zu tun hat. Interessanter Weise bin ich mit meinen 2 interleaved SRAM (70ns) per CPLD Lösung bei 2x 8Channel auf einen 3ten CPLD für Controlling angekommen - die Beinchen eines reichen einfach nicht ... Immerhin könnte ich dann ein 4MHz i2c (btw, AVR macht 400kHz max) zwischen den CPLD etablieren zum Datenabtransport ... Beim detailierten Betrachten explodiert plötzlich alles, Bustreiber für den SRAM möchte ich mir noch nicht antun (den 8bit datenbus in ein latch, spart 8 Pins je CPLD). Immerhin bietet dieses Design die Möglichkeit, das Problem mit den langen Test Leitungen zu umgehen - 8 Kanäle per CPLD mit RAM für eine (lokale) Probe, die per i2c/4MHz mit dem Master (CPLD, uC) kommunizieren, die oben bereits von mir erwähnte Black Box. Indirekt heisst dies, N Proben für N x 8 BitChannel; da i2c/4MHz im Ctrl CPLD, sind selbst 128 BitChannel kein Problem mehr - auch die Synchronisation wird einfacher (wieder mehr Trigger Leitungen zur Verfügung), und gemäß Teile-und-Herrsche sollten die einzelnen Baugruppen auch einfacher zu beherrschen sein. Später kann man ja sogar eine galvanische Trennung per Probe bauen, später wie gesagt. Ich bin noch immer in der Konzept Phase :( Viele Grüße Olaf
@ope poste doch maln Blockschaltbild, wie Du Dir das vorstellst. Von I2C würde ich im CPLD abraten, 72 Macrozellen scheinen mir zu knapp für die gesamte Logik, nimm doch einfach eine Clock- und eine Datenleitung. Schreib mal alle Funktionen zusammen, die ins CPLD sollen, dann kann man grob abschätzen, ob das Konzept ne Chance hat.
Hi, ich habe gestern angefangen eine FPGA Platine mit SRAM und FTDI245 USB Chip zurouten. Ich habe gestern auch mein FPGA Starterkit bestellt. Leider sehe ich immmer mehr das ich als Anfaenger alleine es niemals fertig kriegen werde. Aus diesem Grund wollte ich Fragen wer mit mir diesen Weg einschlagen wuerde? Das Protokoll zum PC sollte dem entsprechen welches hier hoffentlich entsteht. Gruß, Dirk
@Dirk aus Zeitmangel bin ich leider nicht in der Lage, komplette FPGA-Designs for free zu erstellen, aber wenn Du einen Tipp brauchst oder eine Frage zu FPGAs/CPLDs hast kannste mich gern kontaktieren. Die Frage sollte aber nicht lauten : Wie programmiere ich einen LA in VHDL :-))) - also Du weisst, was ich meine. Ist Deine E-Mail Ok die da oben steht ?
und wie willst du dann einen trigger auf z.b eine 16bit adresse setzen??? ;) ich glaube, dass du auf jeden fall alle inputs in einen cpld/fpga laufen lassen musst um allein mal den trigger zu machen... aber ich lasse mich gerne eines besseren belehren... 73
post war auf ope bezogen.. man sollte nicht ewig ohne refresh irgendwelche fenster offen haben ;) @dirk protokoll kannst so machen wies dir spaß macht.. denn der software wird das egal sein woher die daten kommen.. ich bin auch schon am überlegen ob es für die linuxer nicht vielleicht auch interessant sein könnte direkt von der parallelen zu sampeln... also insofern ists wurscht... ;) 73
Hi, @ FPGA-User > Die Frage sollte aber nicht lauten : Wie programmiere ich einen LA > in VHDL :-))) - also Du weisst, was ich meine. Das ist schon klar. Danke fuer deine Unterstuetzung. Meine richtige Email Adresse lautet fbl2000 AT gmx.net Ich hoffe das die Lieferung des Starter Kits nicht zulange dauert. Gruß, Dirk
Hier mein (aktuelles) Konzept auf Papier mit Bleistift. Ein paar Worte: - billig, ich möchte nur ungern über 100Euro in ein FPGA DevKit stecken, wenn das Ergebniss unbekannt ist, daher ist das ganze mehr ein Proof-on-Concept. Vieles weitere wird sich erst dann ergeben. Hier hat Benidikt die Nase mit seinen Erfahrungen vorn. - Zwei Speicherbänke mit 70ns BS62LV1024 (gab's bei ebay 5Stck. 1,99) um auch mal jenseits der 10MHz sampeln zu können. Damit wären so 25MHz mit diesen Teilen machbar. Hieran kann man auch schon mal üben, wenn es irgendwann 'mal an Transitional Timing analysis geht, d.h. es werden Timestamps mit abgespeichert (spätestens hier wird der CPLD nicht mehr reichen, der Timestamp braucht mind. 24Bit + 8 bit Daten =>32Bit SRAM) - Die Adressierung entweder per LSB nibble (lt. FPGA-User reicht ja einfaches herausführen der Adresse nicht), oder mittels 2 Odd/Even Adresszähler oder Adresszähler mit 2 Latches (was braucht weniger?). - OE_ ist immer auf Low, da ich kein Tristate hier brauche. Ich muss mir aber das Datenblatt noch genauer ansehen, ob das alles so rechtens ist. - via i2c/4MHz wird mit dem Master kommuniziert, jeder POD hat seinen eigenen i2c zum Master! Der Master sollte entsprechend schnell sein. - Clock vom Master für Slaves. Evtl. kommen hier Probleme bei höheren clock Raten => Treiber oder/und Diff.mode. Immerhin kann der Master so verschiedene Slaves verschieden takten. - JTAG frisst auch 4 I/O! Irgendwie müssen die Teile ja auch programmiert und debuggt werden. - 8 Eingänge, für mehr reicht es nicht. Der Eingang der Komperatoren (und die Typen natürlich) sind noch nicht konkret. Viele hauen einfach einen Pullup mit 100k in den Input... - Trigger: Solange der Trigger bei einem Byte channel bleibt kann man ja per Kombinatorik und/oder FSM die Triggerbedingungen finden, wenn diese aber auf einem anderen liegen, so dachte ich mir mangels Leitungen, muss eine Art Interupt Trigger Leitung - controlled by Master - herhalten. Er weiss ja, wer wen triggern muss. - Wegen Synchronität und Sparsamkeit/Geit ;-) wird der uC extern vom Master mit getaktet. - Parallel Interface Master - uC - uC bekommt Daten von Master, Master vom Slave (ohne Interleave). - Die treshhold level für die Komperatoren kommen per i2c und DAC (8bit sollten reichen, keine Rechnung aber bisher dazu). Evtl. kann man das genauer regeln, als einen 1%/0.5% Wdstd. o.ö. benutzen zu müssen. Ist aber i.A. kein Problem (=>geregelte Stromquelle). Wie gesagt, es wird alles sehr eng und geht über die ursprüngliche Idee (1x CPLD etc) hinaus. Aber ein 8bit-uC System würde ich schon gern analysieren wollen. Mit diesem SRAM wären das für Timing Analyse ca. 8MHz ... Na ja, für den ersten Schuss ... Eine Frage: JTAG kann man ja in der Chain betreiben, hat jemand Erfahrung? Ich möchte nur ungern 3 JTAG pin header und einen für avr/isp einbuddeln. Apropos, den JTAG habe ich beim Master vergessen einzuzeichnen. Vieel Grüße Olaf
Angehängte Dateien:
-
Scan0001.png
600 KB
jetzt hat das boad mein Bild vergessen.... @Hans: Durch die globale Triggerleitung sollte ein Word Trigger möglich sein. Evtl. gibt es Timing Probleme, da aber alles Synchron läuft und man auch die Vorgeschichte mitschneidet, sollte es gehen. Belehrt ;-) oder bist Du jetzt wieder 'dran ?? Viele Grüße Olaf
kurzer Überschlag für den Slave: - 2x17 Macrocellen für Odd/Even Adresszähler, ich denke ein Latch benötigt auch so viele. - 10 MC für i2c - 8 MC Input Latch verbleiben 20 MC für Trigger, Config Register u.a. Liege ich richtig? Viele Grüße Olaf
ich meinte trigger bei denen sich die bedingung über mehrere module hinwegzieht... sprich an 2 modulen liegt die adresse und an 1nem der status.. jetzt will ich über adresse und statusleitungen eine triggerbedingung setzen... hätte aber dafür schon eine lösung: du schreibst in alle module eine triggerbedinung und wenn die erfüllt ist stetzt du einen pin (trig-out) die trig-out pins legst du dann auf deinen master der sie per und verknüpft (könnte auch ein hc(t) sein oder so..) auf jeden fall geht der ausgang von diesem und wieder zurück auf alle module über den pin trig-in.. wenn trig-in fangen alle an.. weitere idee... alle capturen immer.. nur der adress-counter wird per trigger eingeschalten... an adresse 0-sagenwir mal 15 liegen nicht im ram sondern sind eigentlich im cpld als fifo... den counter lässt man auf adresse 16 losstarten und fertig... vor trigger: daten wandern in den fifo... bei trigger counter lässt die daten in den ram wandern.. 0-15 sind praktisch vor trigger und der rest nach trigger.. damit sollte man den delay der triggerschaltung eleminieren können... am we werd ich mich mal in die möglichkeiten eines cplds einlesen... weil mir scheint ein fifo und dann herumcodieren ist doch etwas aufwendig... btw kann man nichst den jtag als spi port misbrauchsen wie bei den avrs??? das würde dir doch ein paar pins sparen.. nur mit debug ist dann nix... 73
Ich würde auch zu einer ähnlichen Lösung wie ope tendieren, aber mit ein paar Änderungen: Wieso 70ns RAM, wenn man problemlos 15ns RAMs bekommt ? Damit sind ohne Interleaving bereits 66MHz möglich, was eigentlich für die meisten Sachen reichen sollte. Bei 66MHz kommt man auch noch mit "normalen" ICs aus (also AHCMOS und Co.) Wiso I2C ? Das ist a) langsam b) schwierig auf einem CPLD zu realisieren. SPI ist schneller, sehr einfach und weniger störanfällig (man muss keine Adressen vergeben usw.) Ich würde das ganze so relisieren: Ein CPLD dient als dummer (Interleaved) Adresszähler für die SRAMs. Dieser hat als Eingänge nur Enable, Takt, Reset und liefert eventuell ein fertig Signal wenn der Speicher voll ist. Ein weiterer CPLD wird mit den Eingängen und den Datenleitungen des/der SRAM(s) verbunden. Die Daten werden per SPI oder parallel oder sonst wie aus den SRAMs gelesen und an den uC gesendet. Zusätzlich macht der CPLD die komplette Triggerung. Da die Daten und Adressen von getrennten CPLDs verarbeitet werden, und auch so mechanisch getrennt sind, hat man schonmal weniger Störungen. Die XC95xx CPLDs erzeugen extrem steile Flanken und die Eingänge sind scheiß empfindlich, die reagieren auf jeden Spike. Beim Bau meines Logik Analysers hat sich die Schaltung jedesmal aufgehängt, sobald ich mit der Tastkopfspitze ein der Adressleitungen berührt habe. Von mir aus könnte es auch ein FPGA werden, aber kein Eva Board. Die sind weder kompakt, noch optimal für sowas angepasst. Ob man bei denen so ohne weiteres >100MHz bei 32bit über die Pinleisten schieben kann ? Für einen 100MHz 32bit LA wäre ich bereit bis etwa 100 auszugeben.
dann teil den trigger noch auf wie ich das gedacht hab... (trig-in trig-out) dann sparst du dir den zusatz cpld.. weil die cplds einzeln abfragen und konfigurieren kann ein uc auch.. und für die trigger generierung reicht ein "normales" nor.. und die wirds doch schnell genug geben ;) also ein 4fach nor+n*cpld +uc macht ein n*8bit logic analyzer... sehe ich das richtig??? 73
Angehängte Dateien:
-
Scan0002.png
290 KB
Noch eine Variante, die mit 2 PCLD auskommt, jedoch auf 16Bit beschränkt bleibt. Dafür bleiben einige I/O übrig, falls bei konkreter Betrachtung wieder einige I/O fehlen. Der eine CPLD macht einen "Memory Hub"/Master und kommuniziert mit dem uC. Der zweite macht allen möglichen Triggerkram und gibt ihn mit Full Speed an den Master. Meine 70ns gab's wie gesagt sehr günstig bei ebay - schnellere sind selbstverständlich willkommen (in Gedanken verbaue ich die Teile schon :-). i2c ist evtl. bei diesem Aufbau overkill, da ja die Adressaten bekannt sind. SPI wäre also angebrachter. Viele Grüße Olaf
Ich vergaß: bei diesem ist allerdings kein Interleave mehr möglich (PIN Mangel)!
Hallo, bei Meilhaus gibts ein ANT 8 bzw 16 das kleine schafft 500 MHz! und das große noch 100 MHz, womit haben die den das verwirklicht weil das Teil ja super kompakt ist. Man kann dem Datenblatt nicht soviel entnehmen zwecks Speicher usw. Low/High wird bei denen bei 0,5V unterschieden, was warscheinlich auch hilfreich sein wird bei der hohen Samplingrate. http://www.meilhaus.de/pdf/ant8u16.pdf
500MHz über alle Kanäle oder multiplex? Da waren doch sicher wieder diese Marketing Leute am Werk ... Genau genommen sind da für alle Kanäle 32k Speicher drauf. Wir wollen aber höher hinaus :) Olaf
Hier http://www.nci-usa.com/default.htm was evtl. machbar wäre wenn nicht .... Nun ja, die Videos und Doks sind sehr interessant. Gefällt mir persöhnlich sehr gut, aber am Preis müssen wir noch etwas arbeiten :) Olaf
noch ne kurze Bem. zum SRAM BS62LV1024, 70ns Write Cycle Time (also 14,2 MHz) sind nur drin, wenn man im CPLD mit 100 MHz arbeitet, damit man ein 10 ns Zeitraster hat. Die Adress-Setup-Time ist 70 ns, /WE muss beim Adresswechsel '1' sein (und somit bei jedem Schreibbefehl getoggelt werden) und mind. 50 ns breit sein. Nachdenklich stimmt mich die Setup-Zeit von 30ns bei den Daten bezügl. steigender Flanke /WE. d.h. wenn sich die Daten innerhalb dieser 30 ns ändern ist nicht garantiert, ob 0 oder 1 gespeichert wird. D.h. ein Datenbus bei dem sich alle 8 bit gleichzeitig ändern sieht auf dem Bildschirm dann ganz anders aus. Wenn man die Daten im CPLD/FPGA eintaktet verringert sich diese Unsicherheit auf ca. 3ns, je nach Device!
Hi, >500MHz über alle Kanäle oder multiplex? Da waren doch sicher wieder >diese Marketing Leute am Werk ... Genau genommen sind da für alle >Kanäle 32k Speicher drauf. Wir wollen aber höher hinaus :) >Olaf Marketing pur. 500Mhz ueber solche Abgreifklemmen..... Naja man kann viel schreiben, ob es nun stimmt. Mfg Dirk
Was wäre denn realistisch bei solchen Abgreifklemmen? Ähnliche habe ich auch schon bei Geräten, die preislich bei mehreren 10k liegen, gesehen.
@Marcel: >Wenn man die Daten im CPLD/FPGA eintaktet verringert sich >diese Unsicherheit auf ca. 3ns, je nach Device! Kannst Du das genauer erklären? Das Timing hatte ich mir wie gesagt noch nicht angeschaut, da erstmal prinzipielle Dinge zu lösen sind. Genau genommen ist der/die 17Bit (256kx8) Adresszähler ja noch nicht alles. Es wird noch ein "SRAM-Hold-State-Timer"-Counter (10ns Raster hast Du konkret ja gesagt, 3bit -> 80ns) und noch mind. 2 Compare Register nebst logik benötigt um meinen/den SRAM allg. ansteuern zu können. (Immerhin ist man dann mit der Bestückung rel. flexibel). Na ja, die Zahl der freien Macrozellen sinkt allerings stetig. Evtl. muss man ja zu einem XC95108 PQ100 oder PQ160 mit 81 bzw. 108 I/O greifen http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=xc9500_page, bei Farnell scheint bei 9572 Schluss zu sein, bei R&S wird's teuer: XC95108-10PQ100C für 38,75 und XC95108-7PQ160C für 91,45 - damit fällt diese Lösung flach. Himmel, was rechtfertigt diesen Preis-Sprung?, Pfui, pfui, bäh :-/ Ist also auch kein (CPLD) Weg. Wie gesagt, ich scheue mich >100 Euro für einen ungewissen Ausgang vom Haushaltsgeld abzuzweigen. So langsam gehen mir die Ideen aus, oder man muss halt mit einer kleinen CPLD Lösung leben für den ersten Wurf, kleiner als bereits heruntergebrochen wurde... @Thomas O.: Wenn ich mal ganz heroisch vom bisherigen Entwurf rede: -> 2048 Mbit Deep Memory (2x 128k x8 [mit schnellen SRAM]) -> 800 MS/s (50MHz x 16 Bit-Channel) Cool, damit kannst Du dann mit HP und Agilent (und wie sie alle heissen mögen) tapfer mithalten :) Thema CPLD und AVR: Hat jemand konkrete Erfahrung mit dieser Kombo? 8bit Daten, eine Clock Leitung, über Timerinterupt gesteuertes Auslesen? Der auszulesende CPLD dürfte wohl intern ein 8bit-FIFO/Stack haben. Evtl. sollte man den Thread hier nach "Programmierbare Logik" verschieben, da er nun doch stark danach lastig geworden ist. Viele Grüße Olaf
Kleine CPLD Lösung heisst, 10ns SRAM oder/und Adress/Datenbus für 2 SRAM buffern, damit wieder ein I/O frei werden - wobei speziell beim letzteren das PCB entsscheidend mit ist.
Hallo Ope, Schau mal nach http://www.darisus.de/Elektonikshop/Framesets/Shopset1.php unter Programmierbare Logik. Der Link ging mal vor einiger Zeit durchs Progr. Logik-Forum, habe aber noch keine Erfahrungen mit dem Laden. Ansonsten bin ich im Moment auch eher ein Anhaenger der PLD- Loesung. Fuer die Kommunikation mit den PLD's wuerde ich auch SPI oder falls die Gates/Pin's es hergeben ein paralleles Interface vorschlagen. Im folgenden gehe ich mal von einer Loesung mit 1 PLD pro 8-Bit Daten aus. Da koennte jeder dieser PLD's den Trigger ueber seine eigenen Eingaenge erzeugen und zusaetzlich noch einen Eingang vom vorhergehenden PLD mit auswerten. Da koennte man dann (je nach Laufzeit der Signale zwischen den PLD's) eine Art Kette bilden, an deren Ende dann das eigentliche Signal ueber alle Kanaele rauskommt. Jens
@ope Erklärung Setup-Zeit: Die Daten werden ja mit dem Takt des Analyzers eingelesen, bin mal nicht davon ausgegangen, dass ein ext. Takt verwendet wird, sondern das man höher als mit dem Systemtakt des DeviceUnderTest abtastet. Beim genannten SRAM erfolgt das Schreiben offenbar mit der steigenden /WE-Flanke, 30ns vorher MÜSSEN die Daten stabil sein, sonst ist nicht sicher, was man einschreibt. Im CPLD/FPGA sind die Setup-Zeiten der Daten bezogen auf die Clock-Flanke wesentlich geringer, hängt vom Typ ab, also es kann reichen, wenn die Daten 3ns vor der Clockflanke stabil sind, dann wird mit Sicherheit das richtige eingelesen. Sollten sich die Datenleitungen gerade in diesen 3 ns ändern, hat man natürlich dasselbe Problem, aber bezogen auf z.B. 100ns sind hier die Unsicherheiten kleiner.
Was spricht gegen die schnellere 3,3V Version ? Den XC95144XL-5TQ144C gibts bei Digikey für 16,85$ Der XC95108-7PQ100C kostet auch 36.70$, die 5V Version ist eben langsam ein Auslaufmodel mit geringeren Stückzahlen und deshalb vermutlich teurer.
@ope: Preise bei Reichelt: XC 95144-15TQ100 22,30 Euro XC 95144XL TQ100 (10ns), 11,20 Euro Wobei die XL-Varianten mit 3,3V laufen, aber 5V-kompatible I/O haben. Markus
@Marcel: Jetzt habe ich geschnallt, was Du meintest - den RAM ins PLD verlegen (wenn den genügend vorhanden wäre) wegen des Timings. Gegen die 30ms hilft nur ein Latch, braucht dieses auch Macrozellen entsprechend der Bitbreite? @JME: coole Preise! Danke! XC95144XL10TQG14 144Macro, 117 I/O, 10ns, TQFP144 für 9,396. Jetzt wird es mit dem CPLD wieder attraktiv. Mich irritieren nur die 1/10 Cent, was solls :) Anscheinend wollen die (xilinx/r&s) den Absatz forcieren. Den entsprechenden RAM gibt's dort auch, zB: SM614016VHSA10T SRAM HS as 3,3V 256Kx16 10ns TSO für 3,271, allerdings sieht es mit den Datenblatt mau aus ... 50 MHz Oszillatoren gibt's auch ... Das Porto dort ist auch fair - über Lieferzeit schreiben sie erstmal nichts (oder kann ich schlecht sehen?). Ob das mit den 16bit klappt (2x 8-Bit-Channel) muss man erstmal auf dem Papier durchprobieren (2-fach Interleave Variante). @Benedikt: Yep, da habe ich mich wohl zu früh in's Boxhorn jagen lassen, zumal ich selbst ja schon die 3.3V Variante vorgeschlagen hatte, aber meistens waren 3.3V Technologie teuer als 5V (wo ich geschaut hatte). Viele Grüße Olaf
Das Teil (XC95144XL10TQG14 ) ist cool, kurze Rechnung: 2x SRAM 256k x 16: 18 AD, 16 DB, 3 Ctrl = 2x 37 I/O = 74 I/O 2x 8-bit-Channel: 16 I/O uC parallel Port: 8 DB, Ctrl (CS_ und R/W_) = 10 I/O 2x Clock (CPLD und uC externer Takt) 2 I/O JTAG 4 I/O Summe: 106 von 117 I/O Da kann man fast versuchen, 2 CPLD zu synchronisieren, zumindest entsprechend andenken für 32 Channel. Der Rest mit dem uC und DA bleibt, der CPLD und die Komplexität war ja das Problem. M.E. ein preiswertes und tragfähiges Konzept bis jetzt. Jetzt muss man nur prüfen, inwiefern das alles da rein passt, also Anzahl der Macro Zellen abschätzen ... BTW, aufgrund der 2x 256k x 16 Bit eröffnet sich ja die Möglichkeit, den Transitional Timing analysis mode zu realisieren, auch wenn die 16Bit den möglichen Adressbereich nicht ganz abdecken und der Interleave mode zwangsläufig nicht mehr geht (kurz: Nur Änderungen werden mit Timestamp gespeichert - ideal für langsame Busse). Oder diesen nur für 8Bit möglich machen (24 Bit Adresse für Timestamp und 8 byte Bit-Pattern); na oder eben 18bit Adresse (256k) und 14Bit Bit-Pattern. Aber erstmal kleine Brötchen .... :-) Viele Grüße Olaf
Hi, fuer die Eingangsbeschaltung sollte man schnelle Komperatoren nehmen diese koennte man den per PWM (DAC) einstellen. Mfg Dirk
ich nerv na nur ungern.. aber wie zum teufel willst du diesen 8 bit port ohne adressen vernünftig verwenden??? oder schickst du einmal command byte und einmal daten-byte??? mach doch gleich spi und spar dir die pins.. oder mach ein paar adress leitungen.. 2 würden ja schon reichen... trigger-byte config (start, trigger mode,reset adress couner,..) daten (nach jedem read adress counter inkrementieren) für die zukunft ;) oder so... dann kann man das teil schöner ans ext-mem interface des zukünfigen controllers hängen.. wie gesagt alternativ spi.. 73
Thema Clock Generation: ADF4360-8 mit 3-wire serial interface ist evtl. etwas zu hoch gegriffen (65-400 MHz) und gibt's weder bei R&S noch Farnell. Die Teile von Maxim http://para.maxim-ic.com/compare.asp?Fam=clockgenerators werden dort auch nicht verkauft. Was ist denn so handels üblich dort? Bei Reichelt traue ich mich erst gar nicht nach zuschauen (zu speziell). Thema DA: Mh, PWM. 8Bit PWM auf die Ports knallen und OPV mit TP dahinter imo. Ob ein einfaches RC ausreicht ist mir einfach zu "billig"??? Immerhin sind das bei 5V 20mV Auflösung und der Trigger Level sollte stabil sein. In Trampert/"AVR-RISC Mikrokontroller" ist ein Konzept, das mir zumindest gefällt: Butterworth TP 2.Ordnung mit Mehrfachgegenkopplung. Aufgrund des inversen Charakters des TP wird per PWM eine negative Referenzspannung am inv. Eingang draufgeknallt. Er macht mit einem TL084 und 74HC4053 einen 3Channel 10bit DAC ... Evtl. nicht doch einen AD5337 (8-BIT DAC 2WIRE I/F DUAL) für 2,53 bei Farnell? Da weiß man was man hat :) Die gibt's auch als 10/12 bit pinkompatibel (je nach Wunsch) und nehmen kaum mehr Platz ein als ein RC. Thema Comperatoren: Jemand eine gute Idee? Ein Übersprechen im 4fach-OPV sollte hier kaum relevant sein, ist ja keine Analogtechnik :) Die Teile müssen auch eine kleine Hysterese haben/bekommen, ansonsten schwingt's Thema Trigger Level Spannung an den Komperator bringen: ich wollte 1% Widerstande jedem Eingang verpassen, mit (yep) 16-fach Stromspiegel in diesem Fall. Alle Komp.eingänge zusammen an Uref ranknippern würde ich aber auch nicht wollen. Na, evtl. fällt uns da ja noch was gescheiteres ein :) Thema Stromversorgung: XC95144XL pauschal 150mA worst-case (lt. DB), Speicher?, AVR xyz ?? Ich denke 500mA sind ausreichend, lasse mich aber gerne eines besseren belehren. => LM2574M-3.3 (Switching) für 1,83 solange Vorrat reicht (Farnell), mmhh => LM2575S-3.3 (Switching) für 2,47 (Farnell), der sieht gut und einfach in der Handhabung aus http://www.national.com/ds/LM/LM1575.pdf Wie gesagt: preiswert und verfügbar. Ich übersehe aber nicht, inwiefern SPS hier stören kann - evtl. linear Regler bei den Strömen oder entfernt unterbringen. Thema uC: Alle für AVR heben die Hand :^) Thema Schnittstelle PC: Bitte noch nicht! farnell ist nicht Pflicht, ist nur bequem :) Viele Grüße Olaf
@Hans: Nun ja, mit PLD <-> uC ist noch nicht ganz ausgegoren bei mir. Aber es sind ja noch ein paar I/O frei - welch ein Glück. Die Frage ist ja eher, paralleles oder serielles Auslesen. Was wäre die maximale Rate, was der AVR (seriell) zum PC schaffen würde? Da gibt's dann einen Hinweis. Bei seriell muss er ja 10bit (? SPI) einlesen, ggf. behandeln (komprimieren), und zum PC durchprügeln. Wenn er dann 10 Takte warten muss sinkt die Datenrate intern unnötig ab, da er diese hätte besser verwenden können (oder war SPI transparent mit eigenen Shift-Register und Interrupt? - hab noch nie damit gearbeitet - endlich mal passend zum Forum Topic :) Die Idee, den PLD als ext. memory zu verwalten klingt interessant. In den AVR AN habe ich allerdings nichts dazu gefunden. Viele Grüße Olaf
ext.memory siehe z.b mega128 datenblatt ;) zum pc über sie serielle wenns denn sein muss 1Mbaud bei 0% error @16Mhz takt ;) lt mega128 datasheet... das soll der pc mal schlucken ;) und den spi würd ich sowieso dann nur pollen.. sprich datenbyte anfordern und das vorhergehende zum versand fertig machen und weg damit... dann vielleicht waren bis das byte da ist und gleich das nächste holn... spi-takt lt datenblatt kann bis zu fosc/2 sein => 8Mhz spi takt.. macht 1MB/sec ;) das sollte doch eigentlich reichen oder ;) achja ich hab mal im wiki gefuhrwerkt... eine logic analyzer projekt kategorie in die projekte kategorie.. dann noch einen software artikel und alles noch zusammengelinkt... auf der software-seite sollte man auch mal brainstormen... weil zumindest ein konzept sollte da schon dahinter sein... obwohl software design ala "klingonische softwareentwickler" hätte auch mal was g 73
Nabend, >spi-takt lt datenblatt kann bis zu fosc/2 sein => 8Mhz spi takt.. >macht >1MB/sec ;) das sollte doch eigentlich reichen oder ;) Bei dieser Aussage muss ich leider wiedersprechen. Im SPI Master Mode ist es moeglich fosc/2 , aber im Spi Slave Mode nur fosc/4. Datenblatt Seite 168 Gruß, Dirk
@Hans: "zum pc über sie serielle wenns denn sein muss 1Mbaud bei 0% error @16Mhz takt ;) lt mega128 datasheet... das soll der pc mal schlucken ;)" Das kann der PC nicht schlucken, da dessen serielle Schnittstellen nicht mehr als 115200 Baud unterstützt. Nur spezielle Schnittstellenkarte oder USB-Seriell-Konverter erlauben höhere Baudraten.
naja rufus das hängt wieder vom im motherboard-chipset verbauten uart ab... ich hab mal geizhals gefragt und das gefunden ;) Q-Tec 102P 2 Port Serial PCI Card 2 port serial interface card PCI Fast 16550 serial port Plug and Play in Windows. Data transfer up to 921Kb/sec Drivers for all Windows OS NetMos nm9835CV chipset was die chips on-board teile so können ist fraglich.. auf jeden fall haben die das problem, dass sie normal nur 16byte fifo haben (so wie der nm9835 lt datenblatt)... und da wirds eng.. aber müsste man ausprobieren... 115k sollten noch gehn.. über 230k dürfts schon probleme geben unter win... 73
na, da werde ich mal das Mega128 DB wälzen dürfen. Irgend jemand schrieb hier (man findet nichts wieder), das er keine Probleme hat, wenn er wegen der Datenmenge etwas auf dem Rechner warten muss - ich widerspreche dem kategorisch! Jede Unterbrechung des Gedankenflusses ist tötlich. Man will ja schnell eine Hypothese überprüfen, wenn man/ich abgelenkt bin (auch durch warten - die Gedanken streifen weiter) habe ich vergessen, was ich wollte. Bitte, sagt jetzt nicht, ich habe Alzheimer, das wäre nicht fair ;-) Ich denke, die Parallel und die SPI Variante verbrauchen die gleiche Anzahl an Macro Zellen. 1 Mbaud = 125kByte/s, d.h. der komplette Speicher (256k x 16 = 512kByte) wäre in 4s im PC Speicher (worst-case). In der Zeit ist meine Kaffee Tasse runter gefallen und ich habe die nächste wieder aufgefüllt, effektiv kommt 20% Protokoll Overhead hinzu ... Was macht USB2.0 nochmal? Hinzu kommt die Zeit, die das Programm benötigt u.U. (je nach Klingonen Stil :) BTW, hat jemand ein Datenblatt für SM614016VHSA10T, ansonsten muss bei farnell nach einer Alternative gesucht werden. Mit SPI Interface hat man natürlich den Vorteil der Kaskadierung bzw. verschiedener links, dh. 32,64...Kanäle etc. easy expanded. Dann ist die Schnittstelle uC <-> PC wirklich der Engpass (=>100BaseT, na später mal :). Apropos, passt das UART auch noch in den CPLD?, Xilinx hat eine Reference App dazu (noch nicht angesehen), dann USB20 Anbindung an den CPLD? Weiter gesponnen: der DAC Data kommt vom i2c des CPLD und der uC wäre überflüssig. Dies setzt genug Macrocells vorraus! Jemand eine Idee für die sinnvolle Verwendung der ggf. verbleibenden I/O? Thema Software: Modell-View-Controller (Gamma et all) Pattern unbedingt! Nur so bekommt man bei verschieden Ansichten der Daten diese auch konsistent dargestellt. Aber dies ist imo noch zu früh zum diskutieren. Any comments zu (s.o.) - Clock - DA - Comperator - Vcc ?? So, gute Nacht! Olaf
Ich war doch neugierig auf's wiki http://www.mikrocontroller.net/articles/Logic_Analyzer_Software. Allen ernstes SQLite? C++ im Prinzip: class Data { std::vector<uint32_t> la_data; // platz für 32bit LA version void notify(); } class View { public: void attach(...); void detach(); const std::vector<uint8_t>& pod(uint8_t n); }; Yep, Observer Pattern. Gott, ist mein C++ lange her. Viele Grüße Olaf
@Hans: Du zitierst eine PCI-Karte, und das ist keine Onboard-Schnittstelle. Mit einer solchen Karte ist natürlich alles mögliche drin, aber wenn man so etwas verwendet, dann ist der Vorzug der Portabilität durch Verwendung einer Standardschnittstelle nicht mehr erkennbar. Die Onboard-Schnittstelle von PCs ist mit einem 8250 bzw. dessen Nachfolger 16550 aufgebaut, dessen Baudratengenerator mit 1.8432 MHz Takt betrieben wird. Dieser wird durch 16 geteilt und kann dann mit einem Baudratenteilerregister durch ganzzahlige Werte weiter geteilt werden. Der Wert 1 im Teilerregister ergibt 1.8432 / 16 = 115200 Baud.
hmmmm wie gesagt es gäbe da bei opencores usb implementierungen ;) um ethernet nutzen zu können müsste man einen arm und uclinux laufen haben.. derzeit zu teuer weil man einfach zuviel sram für die lpc22xx brauchst... und einen arm7 der billig ist, mit dram kann und nicht ich weis nicht was an perepherie braucht hab ich noch nicht gesehen... alternativ könnte ich mir aber so einen lustigen usb/rs232 chip vorstellen.. siehe wiki da hab ich eine nette type die gut beschaffbar sein dürfte gepostet.. natürlich könnte auch irgend ein verrückter die pci-bridge von opencores testen G firewire gäbe es dann ja auch noch... aber ich glaube usb wirds werden... irgendwann am anfang hatte ich eh schon mal bemerkt, dass rs232 warscheinlich eh nur zum capturen von seriellen verbindungen geeignet sein wird... natürlich müsste man abchecken ob man nicht doch mit einem uc und kompression die datenübertragung wieder in einen vernünftigen bereich bringen könnte... wie gesagt... es bräuchte mal testdaten ;) ich werde mich morgen nachmittag mal hinsetzen und daten von einem mega32 generieren lassen (rein in ein stk500, quick&dirty code.. und dann die rs232 angucken)... aber ich kann mir gut vorstellen, dass sich so ein durchschnitts-stream gut komprimieren lassen wird... andere möglichkeit: der controller macht eine Transitional Timing analysis ;) das wäre damit einfach zu implementieren...und sollte eigentlich auch eine schöne reduktion mit sich bringen... so gute nacht.. ich muss mal drüber schlafen g 73
ich darf nicht soo lange tippen.. da posten so viele leute in der zwischenzeit ;) @ope warum nicht sqlite?? mein 1. hintergedanke : ---------------------------------- Beginning with version 2.6.3, SQLite should be able to read and write database files regardless of byte order of the machine on which the file was created. ---------------------------------- xml stell ich mir nicht allzu geeignet vor.... und am pc sind mir ein paar kb an overhead wurscht... hauptsache ich als programmier hab kein problem mehr mit portieren usw ;) aber ich lass ja mit mir reden ;) ich hab den artikel ja gemacht damit man solche "kleinigkeiten" diskutieren kann ;) @rufus schon klar... aber wenn ich um 15e mir 30e an cpld,.. sparen kann.. warum nicht.. wobei usb ehrlich gesagt um einiges interessanter wäre... 73 & n8
Hallo, wenn man per RS232 übertragt und eine 2te Leitung mit den Takt hat, spart man sich die Übertragung des Start und Stopbits also ein Geschwindigkeitsgewinn von 20%. 115200 / 8 = 14400 Bytes pro Sek. Und parallel hätte man da schon 14,4kB x8 = 1 MB und beides wäre programmiertechnisch sehr einfach zu bewerkstelligen.
@ope einen günstigen schnellen SRAM 256KB x 16 könnte der IC61LV25616 sein. Den gibt es für 8ns, 10ns, 12ns. Kostet derzeit bei Glyn etwa 2,70 EUR.
also wenn ich das hier so lese: 2 - 3 CPLDs, Mikrocontroller, dazu noch MAX232 oder FT245 oder noch was andres, Takt-Generator-IC, 1-2 SRAMs, Stromversorgungs-ICs, dann noch irgendwelche DACs, Komparatoren, alle ICs selbst auflöten, Massen von Block-Cs dazu... und das alles für einen LA, der am Ende 8..16 bit mit vielleicht 10 MHz einliest, nee das is nix für mich. Sorry, die Zeiten, wo ich IC-Gräber zusammenlöten konnte sind vorbei. Ich schau in nem halben Jahr mal wieder rein, mal sehen, ob dann schon ein Board fertig ist.
@Hans: > ich darf nicht soo lange tippen.. da posten so viele leute in > der zwischenzeit :) Also SQLite nur wegen dem Endian? Da gibt's doch hton* und ntoh* macros, die kommen aus der Netzwerk Programmierung, da die TCP/IP und Netzwerkbitorder, Gott - wenn ich mich recht entsinne Big Endian war, und Intel Little Endian hatte (oder war das umgekehrt?) http://www.cs.vu.nl/pub/minix/2.0.0/wwwman/man3/hton.3.html XML ist zum Speichern/Laden toll, man braucht keinen Parser zu schreiben und die Tagnamen sind frei wählbar. Man muss ja nicht immer die volle Power nutzen ;-) Auf dem CPLD wird wohl kein Platz für IP/Opencore sein, daher UART mit FTDI oder CP2102 @Steffen: Danke! Die Preisekalkulieren und wo man obendrein möglichst alles komplett bekommt, wird auch noch mal abendteuerlich. Viele Grüße Olaf
ich weis nicht... ich kann mir nicht vorstellen, dass man blobs einfach in xml packen kann... da muss der parser ja schon verrückt werden wenn er da aufeinmal 00-bytes findet udgl... ----------- XML ist zum Speichern/Laden toll, man braucht keinen Parser zu schreiben und die Tagnamen sind frei wählbar. Man muss ja nicht immer die volle Power nutzen ;-) ----------- türlich brauchst einen parser... und wennst den nicht selbst machst musst dir halt eine lib orgen... wo jetzt der große unterschied in beiden möglichkeiten ist sehe ich nicht... bis auf den "vorteil", dass ich mich bei sqlite nicht um die blobs kümmer muss ;) in xml könnte man wiederum die daten strukturiert ablegen... wir sollten diese und weitere diskussionen ins wiki oder in einen neuen thread legen... sonnst köpfen uns glaub ich die hardware-bastler G 73
>Evtl. sollte man den Thread hier nach "Programmierbare Logik" >verschieben, da er nun doch stark danach lastig geworden ist. Das sehe ich anders: momentan ist es sehr PLL (Programmierbare Logik Lastig ;), aber das wird sich ändern, sobald mal entschieden wurde, was verwendet werden soll. Dann kommen nämlich weider mehr die Elektronikaspekte zum Vorschein: Eingangsbeschaltung, Spannungsversorgung, Leiterplattendesign etc...
Ich hätte gerne Bluetooth, um die LA-Daten drahtlos an den PC zu senden. Nee, ernsthaft jetzt. Man verliert langsam den Überblick, habt ihr euch jetzt mal auf was geeinigt? Ich denke, die erste Version wird eh nicht perfekt, ganz im Gegenteil!
eben.. man bastle mal eine proof-of-concept 8-bit capture engine.. aber bitte so, dass man sie möglichst schnell takten kann... dann noch einen x-beliebigen uc dran (vorzugsweise wie mega16,32,... kleiner hab ich sie nicht daheim ;) und dann schaun wir mal wo probleme entstehen.. das sollte doch billig lösbar sein... und zum input-stage testen reichts alle mal... 73
@OldBug Yep, das stimmt, evtl. sollten 3 Threads geöffnet werden in: - µC & Elektronik - Programmierbare Logik - PC-Programmierung Der Überblick wird dadurch allerdings nicht besser. Evtl. wäre ein neues Forum Projekte besser geeignet. Immerhin scheint ja hier auch der Digitaler Funktionsgenerator entstanden zu sein - wie lief es da ab? Thema SQL: Wegen eines BLOBs? D&D: "An SQL BLOB is a built-in type that stores a Binary Large Object as a column value in a row of a database table. ", also nur wegen der Binary Repräsentation? Für Messungen mußte ich mal mehrere Tausend Datensätze in eine SQL schicken - ist schon cool, mit dem select ... aber hier Overkill imo. Thema Parser/XML: Ein Parser ist so'n Teil das auf Grammatik und Semantik achtet, also das yacc & lex Gespann und Abkömmlinge. Die Interpretation ist wieder Anwender Sache. Schau mal auf http://libxmlplusplus.sourceforge.net/, wie einfach es gehen kann. Die Möglichkeiten gehen aber über das hier benötigte weit hinaus (serialization, object creation etc). Aber unabhängig davon, halte ich die Repräsentation des "Speicherdumps" des LA als Vector als am einfachsten - vieles wird sich erst bei genauer Betrachtung ergeben. Es muss erstmal ein stabiler Software Prototype her, dann kommt des Redesign - und so entwickelt sich Software, u.a. auch Windows - sind wir nicht alle Beta Tester? :) "in xml könnte man wiederum die daten strukturiert ablegen" Trennung von Daten und deren Repräsentation - sonst gibt's schnell ein heilloses Durcheinander! Thema CPLD: Tja, mit dem CPLD wäre also (hardwaremäßig) halbwegs geklärt. Die andere Hälfte betrifft dessen Innerein, also: wer hat den Kern schon mal geschrieben und bestätigt: er passt rein? Ein wühlen brachte http://home.comcast.net/%7Emike_treseler/uart.vhd zu Tage, passt er rein und kann man daran ein CP/FTDI 'ran stöpseln? BTW, macht FTDI nur USB1.1? @Marcel: TTL Gräber sind out, ist schon richtig, aber ein Großteil ging hier ja gerade darum, den Aufwand gering zu halten; daher ein CPLD. Der Dac hat 8 Beine - entgegen der PWM Lösung, wo mit viel Aufwand eine GS gemacht werden muss. Was spricht gegen 1 CPLD, 2 SRAM 1 uC, 1 DAC, 1 Spg.regler ggf., 1 Port-IC (USB kann den LA mit versorgen), 4 Quad-Comperatoren oder 2x 74AHC245 oder 3x 74ACT14, 1 Quarzoszillator um bei den aktiven zu bleiben?? Imo hat man mit wenigen BE das Maximum erreicht (PCB ist eine andere Sache). Würdest Du sagen, SMD ist scheisse zu löten, muss ich Dir allerdings recht geben :-) Man kann aber auch nicht erwarten, das innerhalb einer Woche sofort ein tragfähiges Konzept entstehen kann, zumal wir hier nicht an einem gemeinsamen Tisch physisch sitzen und noch andere Verpflichtungen haben! Also, wieder Forengerecht - Input: Das Thema wurde in http://www.progforum.com/showthread.php?t=4619&page=1&pp=15&highlight=logik schon mal etwas durchgekaut - allerdings mit Logik IC. Evtl. sollte dazu ein neuer Thread aufgemacht werden, um das Thema stärker konzentrieren zu können. Netter Weise hat man bei http://www.xilinx.com/bvdocs/appnotes/xapp368.pdf die konkrete Eingangsbeschaltung vergessen. Was evtl. problematisch ist, ist 3.3V für einen Komperator, da wahrscheinlich dessen Slew Rate ins Bodenlose sinkt - sofern überhaupt einer das mitmacht. Wer hat einen guten Draht zu Datenbüchern? Viele Grüße Olaf
@Dirk: mit dem USB AVR (48Mhz) klingt gut, zumal damit wieder ein Chip entfällt. Woher nehmen und wie teuer ist der? Gängig scheint ja die ATmega Reihe zu sein. BTW, der Trend scheint ja nun eindeutig in Richtung USB zu gehen, aufgrund der Gegebenheiten. Olaf
ich sehe beim usb-avr das problem.. wie macht man ein hid device ;) ich kenn mich mit usb noch nüsse aus... in 2 wochen bin ich wieder weg von der firma.. dann max. 1ne woche daheim.. dann 3wochen spanien.. also muss die soft recht schnell stehn... die idee hinter sql war, dass alle daten in einer file sind und einfachst rausgeholt werden können..gut xml würds auch noch geben ..aber wie gesagt ich mach die software sowieso komplett modular über plugins => die daten kommen von irgendwoher in ein schönes array ;) dann noch einen member wie viele byte pro sample und fertig.. der ftdi macht usb1.1 .. der cp2102 macht full speed usb2 und gäbe es bei farnell.. im gegensatz zum ftdi... oder war rs... hab ich weiter oben gepostet.. der kann übrigends bis 1mbaud, einige 100byte an buffer und hat on-chip 3,3V spannungs-reg der 100mA liefern kann... damit spart man sich wieder was...aja ab ich schon erwähnt, dass der chip einen 48Mhz oszillator schon drauf hat?? ;) das gehäuse sieht seltsam aus..aber bis auf gnd seh ich kein porblem beim löten.. ich muss mir den mal bestellen... hier im forum gabs aber einen thread wo dem teil nur gute eigenschaften bescheinigt wurden....
Thema Comparator: Wie wäre es mit einem Max964 http://pdfserv.maxim-ic.com/en/ds/MAX961-MAX999.pdf - 4.5 Typ Prop. Delay (ns) - Supply 2.7 to 5.5 Voltage (V) - 8000 Max Supply Current per Comp. (µA) - also 8mA/C = 32mA/IC worst-case - VEE-0.10 to VCC+0.10 Input Voltage Range (V) - 5.5$ Price @ 1k allerdings nicht bei Farnell zu finden. Layout Hinweise/Bsp gibt es. Eingänge sind gegenüber den Ausgängen, diese alle auf einer Seite, damit wird das Layout auch einfacher. Interessant ist der Shut Down Mode um den Strombedarf zu senken (wieder ein Pin vom uC weg). Sorgen bereitet mir allerdings der Input Voltage Range, da muss eine schnelle und begrenzende Eingangsbeschaltung her. Gefallen tut mir auch der Preis nicht, da 2Stck für 8Bit benötigt werden, also in der 16 Bit Variante 4 Stck ca. 20Euro. Die 128mA fallen da gar nicht so groß auf :-) benötigen aber ein gutes Layout (ground bounce). BTW, Ob dieser Speed mit einem 10ns CPLD wirklich gefahren werden kann, ist noch offen. Viele Grüße Olaf
Zum Thema HID-Device: nehmt einen PIC18F4550, HID-Firmware gibts gratis von Microchip. Nutze die Firmware auch bei meinem 10 Kanal Datenlogger.
ich hab mal bei atmel reingeschaut.. auf der hp steht was von registrieren dann bekommt man die software.. angeblich sogar ein wizard der einem eine schöne firmware ausspuckt... nur dürfte der gleich gut zu bekommen sein wie dein pic.... ;) 73
@Hans: wenn ich mir die Package des CPLD mit 0.5mm ansehe, schrecke ich vor dem cp2102 auch nicht mehr zurück - zumal weniger Teile, schneller und billiger. Mit dem Gnd hab' ich auch gelesen; seltsam, sein Masse unter dem chip zu legen. Ich denke, es soll die EMV Konformität erzwingen wegen der 48MHz (gerschirmtes Gehäuse). Bietet Atmel nicht eigene Treiber für ihren USB Stuff an, wie es auch FTDI und SILABS machen? HID ist ja Host/PC Seite. Um ehrlich zu sein, wir können froh sein, wenn in diesem Monat ein geroutetes Layout entstanden ist ;-) Yep, Ihr lest richtig :) Kannst also ruhig nach Spanien fahren - im September bin ich für 3 Wochen weg. Viele Grüße Olaf
gut .. also pünktlich zum unibegin haben wir dann eine funktionierende hardware/software lösung ;) btw ich bin grad am überlegen ob ich der software nicht auch schon grundlegenden support für die nutzung als digi-scope mitgeben soll.. wäre nur etwas geschicktere klassenstruktur nötig und schon müsste das hinhaun....wär doch was.. einen freerunning adc drann.. dann den trigger dazu.. und schon hätte man ein einfaches scope ;) aja den pic bekommt man um 8e bei farnell.... der atmel kostet 6$ bei digikey.. und das teil kann lt. homepage 10mbit spi.. das klingt seeeeeehr gut ;) und ganz nebenbei ein tqfp44 ;) 0,5mm pin abstand geht schon.. tqfp44 ist dagegen zwar was für notorische grobmotoriker aber mit ein bisserl guten willen und halbwegs vernünftigem flussmittel.... 73
Hallo, ich finde man sollte sich erstmal auf einen Speicherbaustein festlegen, der schnell genug ist oder von dem man notfalls 2 parallel nimmt und sie abwechselnd beschreibt. Was gibt es da z.b bei Reichelt was man verwenden könnte. bzw welche Anforderungne gibt an die Speichertiefe? Evtl. in den LA-Artikel mit einfügen. http://www.mikrocontroller.net/articles/Logic_Analyzer
@Steffen/Speicherinterface: Auf http://www.icsi.com.tw/english/products/products-frame.asp?Title=Datasheet-Async%20SRAM&URL=http%3A//web.icsi.com.tw/English/Datasheets/ASYNCHRONOUSSTATICRAM.html bzw. http://web.icsi.com.tw/domino/packinfo.nsf/F384F466ECEF4C1F48256F320003B3E6/$FILE/ic61LV25616.pdf ist er zu finden. 256K X 16 IC61LV25616 3.3V 8,10,12,15 [K, KG, T, TG, B] MP Was allerdings als Status Available MP bedeutet, verschließt sich mir. Der Preis ist natürlich top. Alternative Farnell: AS7C34098-12TCN (256K X 16; Zeit, Zugriff:12ns;) für 13,17 wäre das nahe liegenste, oder eben AS7C31026B-12TCN (64k x 16, 12ns) für 4,99. Viele Grüße Olaf
> der ftdi macht usb1.1 .. der cp2102 macht full speed usb2 und gäbe es > bei farnell.. im gegensatz zum ftdi... oder war rs... hab ich weiter > oben gepostet.. Macht das einen Unterschied? Beides 12mBit. und der cp2102 dürfte wesentlich schwerer zu löten sein, da nich nur das GND unten drunter is sondern auch alle restlichen Pins... Sollte aber auch nicht unmöglich sein, nur eben wesentlich schwerer als normnales 0,5mm TQFP. Die FTDI Chips gibs übrigens u.a. bei Segor.
Hab meinen CP2102 unten nicht verlötet, geht! Aber ist natürlich nicht das gelbe vom Ei :)
@Thomas O./Speicherinterface: Reichelt habe ich am Anfang schon erodiert - gibt nichts vernünftiges dort, leider. Aktuell ist ein 16Bit SRAM. 16Bit, da der ausgesuchte CPLD XC95144XL10TQG14 genug I/O hat um 2x 8bit-Channel zu sampeln. Er hat sogar soviel I/O, dass man den Speicher im Interleave (odd/even Adressen) betreiben kann. Mit den 16Bit in einem Chip sinkt auch die Fehlerwahrscheinlichkeit, zB. da nur noch einer, anstelle von 2x 8Bit ICs, verlötet werden muss. Letzlich ist es die Frage nach dem Timing und Bittiefe eine Geld- und Anforderungsfrage. M.E. kann dieses noch in letzter Sekunde entschieden werden, zB. werden dann weniger Adressleitungen benutzt bzw. die maximale Samplerate wird stark von der Zugriffszeit dominiert. Spätestens beim PCB Entwurf muss es aber feststehen, klaro. BTW, weiss eigentlich jemand was POD im Zusammenhang mit dem LA bedeutet? Probe on Device? Irgend welche Hinweise Inputstage? Viele Grüße Olaf
Was spricht eigentlich gegen synchrone SRAMs ? Die sind doch für sowas optimal, oder ? Die Adressen werden bei der Flanke gespeichert, ebenso die Daten. Die Setup und Hold Zeiten gehen daher gegen Null... Außerdem muss man WR\ nicht toggeln, was wertvolle Zeit kostet, sondern es reicht den Sampletakt anzulegen.
@Benedikt: hast Du einen konkreten Vorschlag, bei Farnell kann ich nach synchron/asynchron nicht direkt suchen und ich bin zu faul derzeit alle Datenblätter durchzuwühlen - ich habe nicht mal einen Drucker hier :( Deshalb auch keine genaueren Analysen/Datenblattstudien bisher. Wenn ein Konzept steht, kann man es ja anhand der DB prüfen. An sich klingt es toll, da es das Speicherinterface vereinfachen würde. @ALLE: Ich habe meinen Schreibfluss mal auf's Wiki gerichtet. Dies vereinfacht Quer- und Wiedereinsteigern hoffentlich die Diskussion, es fehlt aber noch einiges. Viele Grüße Olaf
Ich dachte so an CY7C1325F oder CY7C1327F (256k*18). Kosten <=10, und gibt es bis 4ns = 250MHz Was genau der Unterschied zwischen Piplined und Flow Trough ist, weiß ich auch nicht, habe bisher noch nicht so wirklich viel damit gemacht.
Hallo, ich werd jetzt mal schauen was aufzubauen und würde was für zahlen wenn mir jemand ein leichtgestriktes FPGA bzw. CLPD programmieren kann. Meine Anforderunge sind ja nicht ganz so hoch wenn ich mal die Datem im SRAM habe kann ich das auch mit nem AVR auslesen. Ich möchte dem FPGA bzw. CLPD einen 2 externen Signale zuführen einmal den Sampletakt(evtl. über VCO) und einmal das Triggersignal und dann soll er einfach die Schreibbefehle für das SRAM senden, die Daten lege ich mit Latches oder sonst irgendwelchen Treibern direkt auf die Dateneingänge des SRAMs. Wo bekommt man eigentlich diese schnellen Vieher her?
@Benedikt: Klingt super, allerdings Farnel: CY7C132-55PC wird nicht mehr hergestellt - Nicht mehr lieferbar, Produkt abgekündigt 12,30 R&S: CY7C1327B-133AC TQFP100256Kx18 3,3 11,60 klingt gut, die 18Bit können wir auch verbraten, genug I/O haben wir ja noch. Allerdings gibts zu der B Variante bei R&S kein Datenblatt - nur G und F (http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=39&rpn=CY7C1327F bzw http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=39&rpn=CY7C1327G) Wer kennt sich aus? Viele Grüße Olaf Viele Grüße Olaf
Wieso bekomme ich bei der Signatur im Wiki meine IP Adresse angezeigt - ist das aus Datenrechtlicher Sicht zulässig? :)
@ope zum Clock kann ich den ICS502 von ICS empfehlen. Das ist ein PLL Clock Multiplier mit einer max. Ausgangsfrequenz von 160 MHz. Bei einen Quarz von 20 MHz kann man 50MHz, 60MHz usw. erzeugen. Kostet etwa 0,90 EUR und gibt es bei Memec Insight. Einfach mal anschauen.
Hallo, oder ICS525 gibts auch bei Reichelt, dieser hat nen VCO eingebaut den man über 9 Bit einstellen kann und dahinter ist noch ein 3bit Teiler womit man dann nochmal die Frequenz von 1-8 Teilen kann. http://www.icst.com/icscs/SiteSearch.aspx?q=ics525 http://www.icst.com/datasheets/ics5250102.pdf
@Steffen Leider habe ich den ICS502 auf http://www.memec.com/?cmd=search&search=ICS502+&x=30&y=9 nicht gefunden. Vom Datenblatt http://www.mikrocontroller.net/attachment.php/207130/ics502.pdf her sieht er gut aus, wenig Beine, Jitter +/-70ps und kommt bis 120/140MHz - die wollen erstmal erreicht werden. @Thomas O. Dieser hat wiederum viele Beinchen http://www.icst.com/datasheets/ics5250102.pdf, kann bis 100MHz (525-01) bzw. 200MHz (525-02) bei 3.3V bei einem Jitter von +/- 85ps, allerdings bei Reichelt 5,90 (die haben dort keine Beschreibung - wissen die nicht, was sie haben?) Beim Anschauen der DB ist mir allerdings ein Henne-Ei Problem aufgefallen. Mit dem PLL Clock Multiplier kann ich den Clock für den AVR und LA generieren, der AVR soll aber mit einer festen Frequenz unabhängig vom Mastertakt arbeiten, d.h. setze ich den Master Clock hoch/runter, läuft auch der AVR schneller/langsamer. Den ICS502 und ics525 kann ich per DIP konfigurieren, aber wie sage ich den CPLD/uC, was eingestellt wurde - der ICS502 macht noch vom Tristate Eingang bei siner Konfiguration Gebrauch? Der ics525 ist da einfacher (low oder high). BTW, macht der AVR Tristate? Viele Grüße Olaf
dem avr einen eigenen quarz geben..dann die frequenz fest... wo ist das problem ;) ich mein warum sich unnötig probleme schaffen??? hat nebenbei den vorteil, dass ich an den clock-gen auch irgend einen quarz-oszillator dranhängen kann mit z.b 40Mhz.. sprich man kann sich dann die frequenz selbst aussuchen..einfach quarz oder eben einen quarz oszillator im layout vorsehen und dann steckt rein was du willst... 73
stimmt schon, ich fand es nur klever, alles an einem Quarz/Teiler zu hängen, da es dann auch schön synchron alles ist. Knippern wieder also wieder einen eigenen Quarz an den uC, sofern uns nicht noch etwas einfacheres einfällt :-) Viele Grüße Olaf
@ope bei dem Multiplier wird der Quarzclock per REF durchgreicht. Bei einem festen Quarz bleibt auch REF. z.B. Quarz beim ICS502 16MHz = REF = 16MHz und Clock kann 32MHz, 48MHz und 64MHz sein. Es ist also möglich den AVR mit dem Multiplier zu versorgen.
das Problem mit dem Masterclock/PLL/uC ist weitreichender als ich bisher annahm: Gesetz dem Fall, aufgrund verschiedener Gründe, was auch immer, macht der LA bei einem 100MHz und bei einem anderen 25MHz, bei einem dritten .... Das Binary im uC ist aber bei allen gleich - ansonsten müßte jeder seinen Source speziell anpassen (nicht jeder setzt runde Quarze ein - hier explodieren die Varianten) und compilieren (Bootloader Option wird schwieriger für generic binaries). Ein gleiches Binary für alle erleichtert vieles, auch von Seiten der PC/Software her, da diese nur noch dem uC fragen muss: was kannste und haste denn? Daher die eingangs erwähnte Idee mit dem hardcoden von PCB Revision, Channel etc. an einem Port des uC (einfaches Config-Port einlesen der 256 möglichen Configs reicht dann). Wegen dem Quarz/Osz. kann man einfach bestimmen: 25MHz - friss oder stirb. Das Problem mit dem unbekannten Multiplier, zB. per DIP Schalter einzustellen, bleibt dennoch bestehen. Der ics502 hat 6 mögliche Multiplier, das wären schon 3 Konfig Bits. Wer weiss, was noch so alles kommt. Werden diese hard wired, kann wiederum ein Fehler auftreten, wenn Konfig Bits != Multiplier am DIP des ics502. Mit dem DIP (oder Lötklecks auf einem Pad) den Multiplier einstellen, ist imo eine gute Sache, nur wie sag' ich es dem uC? Kann der AVR einen offenen Eingang/TriState feststellen? Imo nein. Einen weiteren Chip für solche Tests einsetzen wäre nicht gut. Der Tristate des DIP ist das Problem bei der Erkennung des Mulitpliers! Dann kann er über den Mulitplier-Port einlesen bekannt gemacht werden. Bei dem ICS502 den REF Clock durchschleifen ist 'ne gute Idee. Bei Verwendung von 25MHz als Standard kann ja der CPLD diesen durch 2 oder 3 teilen (Achtung: asynchrones Übertragen zum Computer notwendig, Baudraten sind nicht mehr normgerecht - macht des dem USB Chips etwas? imo nein, da intern asynch FIFO) und an den uC weiter reichen. PS: Beim PCB sollte man auch worst-case rechnen, d.h. Multiplier = 1, d.h. Ref-Clk per Lötbrücke/-pad an den CPLD! Viele Grüße Olaf
ähm bitte für was soll das config port gut sein???? dem uc kann es vollkommen egal sein wie schnell gesampelt wird.. das muss nur die software am pc wissen um die zeit richtig anzeigen zu können aber im prinzip kann das dem uc vollkommen egal sein !!!! anderseits kann der avr auch den multiplier einstelln !!! weil ausgänge auf high-z schalten kann er... 73
dem uC ja, aber der Desktop Software nicht, da ggf. ein "falsches Timing" angezeigt wird, da zB. die SW von 100MHz ausgeht, der LA aber nur mit 75MHz arbeiten kann bei Lola, 25MHz bei Rudi .... Die Version u.ä. codieren deshalb, weil es evtl. ja eine neue Variante irgendwann mal gibt - dann weiss die (weitsichtig programmierte) Software, was sie bedient und muss nicht (vollkommen) neu geschrieben werden. Also nur eine Art Serial/Config Number Auswertung. Letzlich werden nur einige Port Pins auf GND geklebt, intern Pullup scharf gemacht - also kein bemerkenswerter Aufwand für Weitsicht. Wie kriegt man die AVR Ports in HighZ? Ich kenne nur low/high/Pullup intern. Viele Grüße Olaf
HighZ=Port auf Eingang + Pullup aus Es gibt doch taustende per I2C oder SPI programmierbaren Taktgeneratoren, wieso also unbedingt diese parallelen ? Die sind nur dafür gedacht, um eine Frequenz zu erzeugen (bzw. ein paar wenige, wie auf einem Mainboard).
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.