|
|
Logic Analyzer-Projekt: Ideen zur HardwareDieser Artikel bezieht sich auf das Projekt 'Logic Analyzer', das von einigen Nutzern dieser Plattform gemeinsam entwickelt wird. Eine Übersicht über verschiedene Projekte, die die Entwicklung eines Logikanalysators zum Ziel haben, gibt es unter Logic Analyzer Project und Logic_Analyzer. Eine Beschreibung, wie ein Logic Analyzer arbeitet, befindet sich auf der Seite Logikanalysator
[Bearbeiten] LastenheftHier mal das Lastenheft für den Logic Analyser (LA). Bitte je nach Anforderung einen Strich mittels ALT GR + <> Taste links neben dem Ypsilon. Die Aufteilung könnt ihr ja ändern/erweitern falls was fehlt. Ich gebe mal meine Maximalanforderungen ein. Kanalanzahl
Samplingfrequenz
Speichertiefe
Anmerkung: Wäre es nicht sinnvoller, die Speichertiefe in "Samples" anzugeben. So macht das nicht viel Sinn, da die Anzahl der Samples wenn man immer nur 8 Bits abspeichert ne andere ist als wie wenn man 32 Bits pro Sample speichert. integrierter Pattern Generator
Anm.: könnte bis zu einer gewissen Geschwindigkeit vom AVR erledigt werden... => u.U. Mega16 drauf --Hans 14:16, 20. Jul 2005 (CEST) Schnittstelle zum Computer
Am PC läuft/wird laufen
Direktausgabe des L.A.
integrierter Data Analyzer
Anmerkung: Wenn man über WxWidgets/Fox-Toolkit/Qt programmiert, hätte man Win, Linux und MAC erschlagen. COM ist kein Problem, bei USB muss man sehen. Da ist noch nicht viel realisiert. Einen einfachen Treiber sollte man aber hinbekommen können, zumal die Hardware und das Protokoll bekannt sind. Anmerkung: Wie ist das mit dem ERC gemeint? gedacht?
[Bearbeiten] Status(-- Ope 20:51, 10. M?2006 (CET)) Da der Logic Analyzer (LA) Thread schnell wächst und entsprechend schwer zu verfolgen ist, ständig sich irgend etwas ändert, kommt hier eine Zusammenfassung der Diskussion. Ich versuche sie halbwegs aktuell zu halten, öfteres Vorbeischauen lohnt sich also. Eine fertige Lösung existiert jedoch noch nicht und einer alleine macht sich tot, zumal derjenige ja auch ein Real-Life hat und kein professioneller Designer für LA ist - daher ist das Projekt auf aktive Hilfe angewiesen sonst wird es sterben! Auch sind die Threads dazu etwas verteilt (thematisch). Hier die großen:
Eine reine AVR Lösung scheint sich hier abzuzeichnen:
[Bearbeiten] Das ZielNun ja, preiswert und universell und für den Großteil der Probleme brauchbar soll er sein. Zudem sollen die Bauteile z. B. auch in Schweiz/Österreich gut verfügbar sein. Dass er sich mit einem LA der großen Hersteller messen lassen kann, ist aufgrund des Hobby Bereiches bzw. Proof-on-Concepts eher unwahrscheinlich. Unter den eben genannten Prämissen sollen die verfügbaren Mittel optimal genutzt werden. Je nach Ergebnis, Lust und Laune wird es irgendwann evtl. eine Fortsetzung geben - aber das ist Zukunftsmusik. [Bearbeiten] Grundlegende ÜberlegungenIm Internet kann man verschiedene, einfache Konzepte für einen LA finden, z. B. mittels Parallelport. Forumgerecht, reicht für einen einfachen LA bereits ein Mikrocontroller aus, der seine Ports pollt um so die Logik Pegel mitzuschneiden. Allerdings ist diese Lösung begrenzt, wenn es um höhere Taktraten geht. Eine erschwingliche Alternative stellt ein CPLD (Complex programmable logic devices) mit Mikrocontroller/AVR dar. Die CPLD z. B. von Xilinx können mit über 100 MHz arbeiten und sind somit für diese Aufgabe prädestiniert. Leider ist die Anzahl der Macro Zellen zu gering, um eine hohe Speichertiefe zu erreichen. Daher werden die Daten vom CPLD in einen externen SRAM geschrieben. Damit ist der CPLD für die Triggerbedingungen des LA, das Speicherinterface und natürlich das eigentliche sampeln der Eingänge verantwortlich. Der Mikrocontroller liest die Daten des SRAM über den CPLD aus und schickt sie an den Computer, übernimmt also die Kommunikation. Die Software stellt die gesampleten Daten sinnvoll und ansprechend dar. Um die Störungen gering zu halten, wird als Versorgungspannung 3,3V Vorzug gegeben - ironischer Weise sind die Xilinx CPLDs der XC95000XL Serie mit dieser Spannung preiswerter als in der 5V Version. Allerdings baut die Lösung mit dem CPLD und externen SRAM sowie Mikrocontroller entsprechend groß und es sollte ja kein Tischgerät werden (CPLD + AVR + SRAM + FT245 + EEPROM + Spannungsregler kämen ungefähr auf Europa-Format). Als Abmessungen wurde die Größe einer Zigarettenschachtel als Ziel für gut befunden. Neben den Abmessungen gibt es auch beim Routen des PCB zwischen CPLD und SRAM keine befriedigende Lösung, insbesondere wenn mehrere SRAMs für's Interleave eingesetzt oder gar Transitional Timing Analysis Mode implementiert wird. Entsprechend dieser Erkenntnis reicher, ist ein FPGA als eine Komponente des LA in's Gespräch gekommen. Diese haben genug Platz für Logik und internen SRAM, konkret die Spartan-2 Serie. Diese gibt es in einem lötbaren TQFP Gehäuse - kommt also ohne BGA aus - zu moderaten Preisen. Da künftig die RS232 Schnittstellen wegfallen und nur noch USB in Hardware unterstützt wird, wird der LA ein USB Interface haben. Dies deckt sich auch mit der Umfrage oben und ist unabhängig von der CPLD+AVR- und FPGA-Lösung. Im Folgenden wird im Anhang auf die CPLD-Lösung eingegangen, einfach um die Gedankengänge festzuhalten - auch wenn es an sich überholt ist. [Bearbeiten] Hardware Komponenten[Bearbeiten] Interface LA <-> DUT (Device under Test)Prinzipiell gibt es zwei Wege, wie der LA an seine Informationen kommt:
[Bearbeiten] Analoge Komparator LösungFür die Komparatorlösung steht momentan der MAX964 und AD8564 zur Debatte. Allerdings ist der MAX964 schwer zu beschaffen und bereits in der Dualvariante teurer als der AD8564 (ca. 10 Euro). Auch müssen diese mit 5V betrieben werden (wegen der TTL-Eingänge und da der Eingangsspannungsbereich von der VCC abhängt), wodurch Pegelwandler wie der 74LVC245 zum CPLD notwendig werden. Auch die Threshold-Reference muss in diesem Bereich liegen. Diese Schwelle wird durch einen DAC vorgegeben, der vom µC über SPI gesteuert wird. Dieser sollte eine interne Referenz besitzen um mit möglichst wenig Bauelementen auszukommen. Zudem sollte er über zwei Kanäle verfügen, da aktuell der LA über 2 pods mit jeweils einem 8 Bit-Channel verfügen soll. Z.Zt. scheint die beste Wahl hinsichtlich Parameter, Preis und Verfügbarkeit die TLV5626, TLV5637 und TLV5638 mit 8, 10 bzw. 12 Bit zu sein. Der Einsatz eines DAC wird wesentlich einfacher als eine PWM per µC mit anschließendem Tiefpass mit OPVs, welches die Fehlerrate steigen lassen kann. Alles in allem eine komplexe Angelegenheit, weshalb sie in der ersten Version des LA fallen gelassen wurde. [Bearbeiten] Digitale LösungDie einfachste Lösung besteht in einem Levelshifter wie dem 74LVC4245 [2]. Er wird mit 2 Betriebsspannungen versorgt - die FPGA-Seite mit 3,3 V und die Eingangsseite mit variabler Spannung bzw. 3,3 V oder 5 V. Diese Spannung kann per PWM durch den Mikrocontroller erzeugt werden und ermöglicht so, variable Logikpegel am DUT abzugreifen. Es müsste auch eine Lösung für 2,5V-kompatible FPGA-Eingänge vorgesehen werden. [Bearbeiten] Sonstige BetrachtungenWeiterhin besteht Einigkeit in der notwendigen Schutzschaltung, damit die Eingangsspannung den max. Input Voltage Range (je nach Typ) bzw. Strom nicht überschreiten kann:
[Bearbeiten] FPGAMomentan ist der XC2S100 bzw. XC2S200 (prefered) (http://direct.xilinx.com/bvdocs/publications/ds001.pdf) Das externe SRAM entfällt durch den internen des FPGA, da die größeren FPGAs ausreichend interne Speichermöglichkeit haben und das Platinenlayout durch einen externen SRAM um ein vielfaches komplizierter werden würde. Für den FPGA haben wir derzeit das PQ208-Gehäuse im Auge, dort ist der FPGA etwa 2/3 so teuer wie im TQ144 und kann noch nach oben erweitert werden - für die, die mehr Speicher brauchen. Der interne Speicher ist 40k bzw 56k, wobei nur Sample-Änderungen abgespeichert werden um den Block-RAM (echter interner RAM) besser ausnützen zu können. Yep, er ist veraltet etc., aber verfügbar und im TQ144 oder PQ208 (prefered, da derzeitig bestellbar) verhältnissmäßig preiswert zu bekommen. Siehe auch http://www.mikrocontroller.net/forum/read-1-204570.html#new. Der FPGA LA Core wird in VHDL geschrieben. [Bearbeiten] Interface zwischen LA und PCIn der FPGA-Lösung bietet sich der FTDI FT2232C [3] (Dual USB UART/FIFO) an, wie er auch im UXIBO [4] Verwendung findet. Damit kann der FPGA per USB über die erste Schnittstelle im Bit-Bang-Mode geflasht werden und über die zweite mit dem PC kommunizieren. Die erste Begeisterung verschwand, nachdem die Preise bekannt waren. Daher wurde ein AT91SAM7S321/64 mit internen USB gewählt, welcher preiswerter ist und zudem die Mikrocontroller-Fähigkeiten in den LA bringt. Der AT91SAM7S wird per USB (nur Buchse und Widerstände erforderlich) über SPI an den FPGA angebunden. Zudem hat der AT91SAM7 den Vorteil, dass er über USB programmierbar ist via SAM Boot Assistant (SAM-BA) (User Guide [5]). [Bearbeiten] StromversorgungDer FPGA benötigt 2,5 V für den Core selbst und eine weitere Spannung für die I/O. Hier bietet sich 3,3 V an, da dann der SAM7 und der Levelshifter 74LVC4245 damit betrieben werden können. TI bietet hierzu den TPS70358 [6] (2.5/2A + 3.3V/1A) an. Dieser besitzt ein Powerpad unter dem Chip, welches die meisten wohl kaum anlöten können. Aber dafür ist die Strombelastbarkeit total überdimensioniert, d.h. etwas Wärmeleitpaste sollte das Problem (hoffentlich) lösen. Für die variable Spannung auf der Probenseite bzw. 74LVC4245 scheint der TPS62222 [7] eine Lösung zu bieten. Er kann eine einstellbare Spannung erzeugen. Die Vorgabe geschieht entweder mit per PWM erzeugter Sollspannung durch den SAM7 (analog zum STK500 [8]) oder durch ein digitales Potentiometer bzw. analogem Switch und Widerständen und Ähnlichen, wobei die PWM-Lösung die preiswertere Alternative darstellt. Indirekt heißt dies aber auch, dass mit einem Bus powered LA nicht zu rechnen ist... [Bearbeiten] Software[Bearbeiten] VHDL LA CoreDieser ist in VHDL geschrieben und imo die Hauptarbeit. Bisher sind:
Die Anbindung FPGA zum Mikrocontroller per SPI fehlt komplett (SPI Cores z. B. von Jörn sind im Forum aber vorhanden). Mit dem VHDL LA Core gehen die eigentlichen Probleme des LA los. Da ich (ope) als einziger LA-Projekt-Programmierer und VHDL-Neuling (bisher nur C/C++) mir das Coden auf die Fahnen geschrieben habe, dauert es entsprechend lange. Das ursprüngliche Ziel, den Core bis Ende 2005 fertig zu bekommen, ist an vielen kleinen Problemen und am Zeitaufwand gescheitert (eben ein Feierabend-Projekt). Viel Zeit nimmt das Schreiben der Testbenches in Anspruch. Weitere Zeit vergeht für die Fehlersuche im Source, aber auch als Bug-Hunter in XST (das übersteigt dann doch meine derzeitigen Fähigkeiten). Da der Speicher intern nur begrenzt ist, wurde ein Transitional Timing Analysis Mode realisiert d.h. nur Bit-Änderungen werden mit einem Timestamp gespeichert. Dummerweise sind 3 Samples beim Auslesen des Speichers am falschen Ende (oberste 3 Addressen), obwohl sie am Anfang sein sollten (unterste 3 Adressen). Irgendwann habe ich dann die Lust verloren, da auch keiner helfen konnte... [Bearbeiten] ARM CoreKeine konkreten Überlegungen bisher? [Bearbeiten] PC FrontendNichts passiert. Für C++ ist WxWindows, Qt und eben Fox-Toolkit interessant. Aber Fox Toolkit [9], [10], [11] ist imo die Alternative zu WxWindows/Qt und von mir (ope) favorisiert. WxWindows/WxWidgets hat Altlasten, die gehen bis Win 3.1 zurück, Qt behagt mir die Geschichte mit den Moc Compiler nicht; auch wenn ich mit Qt bereits (gute) Erfahrung habe, aber die neue Politik unter Windows behagt mir nicht - dir wird der Compiler vorgeschrieben, aber man wird mit dem mingw alleine gelassen. Von der Seite her gibt's für mich keinen Grund unbedingt Qt nehmen zu müssen. FLTK und Gtk lasse ich mal ganz außen vor. Auch sollen viele Dinge in Fox besser gelöst sein, allerdings ist diese auch jünger, so dass wohl auch einige GUI-Klassen geschrieben werden müssen. Mal sehen, ob sich Cairo (http://cairographics.org/introduction) einbinden lässt, dann hätte man gleich PDF Wave Plot Export prints und bessere Screen Graphic (kann aber auch Overkill sein). Jedoch sind diese Aussagen eben ungeprüft. [Bearbeiten] PCBHier muss Dirk schreiben :-) [Bearbeiten] ResumeeKeep-It-Simple ist ein Grundsatz hier. Je komplexer, desto schwerer zu beherrschen. Sicher hat jeder von Komplexität eine andere Vorstellung, aber wir arbeiten daran und hoffen ein nachbaufähiges, stabiles Gerät zu bekommen. Dennoch kommt man bei diesem Projekt um SMD-Löten mit 0,5 mm-Beinchen nicht umhin! [Bearbeiten] Und was soll das kosten?Schwierig, da noch nicht alles feststeht - als Ziel steht aber im Forum mehr oder weniger ungeschrieben die 100€ Marke einschließlich PCB.
[Bearbeiten] Literatur
[Bearbeiten] Anhang A: Die CPLD/AVR Lösung (veraltet)[Bearbeiten] Der CPLD und das SpeicherinterfaceNach einigen Hin- und Her hat sich der XC95144XL TQ144 als beste Option herausgestellt. Auch FPGAs waren kurz im Gespräch, aufgrund der sich im Gespräch herausstellenden Komplexität. Allerdings war die Komplexität des FPGA und der Preis auch gleichzeitig das KO-Kriterium dafür. Kurzinfo XC95144XL TQ144 [30]:
Dieser bietet genug I/O um:
anschließen zu können. Der Grund für die 2 Speicherbänke liegen in den Möglichkeiten, sich den LA selbst zu konfigurieren für:
Beim Interleave werden zwei 16 Bit Samples im CPLD gelatcht und gemeinsam auf den nun 32 bit breiten Datenbus gelegt. Dabei sind die Adressen für die SRAMs folglich identisch. Damit liegt die Schreibrate beim SRAM bei der Hälfte des Sampleclocks, der entsprechend hoch gesetzt werden kann. Bei Verwendung des 2x 256k x 16 Bit SRAM eröffnet sich aber weiterhin die Möglichkeit, den Transitional Timing Analysis Mode zu realisieren, d.h. nur Bit-Änderungen werden mit einem Timestamp gespeichert - also ideal für langsame Busse bei hohen Sampleraten. Hier kann man z. B. eine 16 bit Time-Stamp-Adresse (256k) mit einem 16 bit Pattern speichern, oder ein 24 bit Timestamps für 8 bit. Ein Interleave ist dann allerdings nicht mehr möglich. Als letze Möglichkeit kann man auf alles obige verzichten und nur einen SRAM bestücken. Der heißeste Kandidat für den Speicher ist derzeit die 61LV25616 (256k*16) asynchrone Serie (zB.IS61LV25616), da er gut verfügbar und preiswert sein soll. Bei asynchronen SRAM müssen wie eingangs erwähnt die Adressen und Daten in einem Latch zwischengespeichert werden. Bei einem synchronen SRAM werden die Adressen bei mit 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 Speichertakt anzulegen. Weitere Typen wären Asynchrone SRAM:
Synchrone SRAM:
Den CY7C1327B (TQFP100 256Kx18, 3.3V, 4ns ) gibt's zumindest bei R&S für 11,60€ [Bearbeiten] Interface CPLD <-> uCEine grundlegende Idee ist, dass der CPLD doppelt benutzt wird. Er enthält ja einen Addresszähler zum Schreiben des SRAMs. Dieser kann aber auch zum Lesen des SRAMs benutzt werden. Der SRAM wird immer sequentiell vom PLD geschrieben und gelesen. Die Daten, Statusinfos etc. werden per SPI vom AVR aus dem CPLD gelesen. Vorteil ist dabei, dass man nun auch z. B. 512 KiB SRAMs benutzen kann ohne dass der µC ein kompliziertes Memory Banking benutzen müsste. [Bearbeiten] Interface uC <-> ComputerDa die Daten schnell im PC sein sollen, bietet sich USB an, also mit dem FT245 um schneller (2-3 Mbaud) als der FT232 (1 Mbaud) die Daten zu versenden. FTDI bietet die Treiber für Windows/Linux kostenlos an. Eine Alternative ist der CP2102, der weniger Bauelemente benötigt aber auch wesentlich schwerer zu löten ist. µC mit integrierten USB standen auch in der Disskusion. Aufgrund vieler Unwägbarkeiten, wie Beschaffung, Preis, HID Treiber etc. sind diese Ideen wieder verworfen worden. [Bearbeiten] Clock Rate GenerierungAufgrund seiner Bandbreite bietet sich die Generierung des Systemtaktes durch den CPLD an. Dieser benutzt einen 1/N-Teiler um den Sample-Takt zu generieren. Prinzipiell kann er auch gleichzeitig den Takt für den µC erzeugen - dieser wird also extern getaktet und man erhält dadurch Synchronität zwischen CPLD und µC und spart den Quarz am µC. Allerdings bietet sich auch ein eigener Quarz für den µC an. Man sieht - hier wird noch diskutiert. Zur Generierung des Mastertaktes bieten sich zwei Weg an:
Die Grenzen der Samplefrequenz liegen zum einem in den verwendeten Bauelementen (> 100 MHz), aber vielmehr wird der begrenzende Faktor das Layout und die Leiterplatte sein. Ein 4-Layer-PCB ist aus technischer Sicht sicher das Optimale, nur schaut der Geldbeutel danach sehr leer aus; auch wird ein Komparatoreingang ca. 45 Euro teurer werden als eine Lösung mit 74xxx. [Bearbeiten] StromversorgungTja, auch ein LA braucht Strom. Bei Verwendung eines USB kann dieses elegant gelöst werden, da dieser (nach Anforderungen an das OS) bis zu 500 mA liefern kann. Eine kurze worst-case "Stromrechnung" zeigt:
mit MAX964 8 mA/Comparator x 16 kommen 128 mA hinzu. Die FTDI-Chips haben für Geräte, die über 100 mA ziehen (in diese Kategorie wird wohl der LA u.U. fallen), aber noch bus-powered sein sollen, einen Schaltausgang, an den z. B. ein p-Kanal-FET angeschlossen werden kann, der den stromhungrigen Teil der Schaltung erst nach der Registrierung beim Computer einschaltet. Dazu hat er einen "sleep"-Ausgang, mit dem man den angeschlossenen AVR schlafen legen kann. In den FTDI-Docs bzw. Application Notes finden sich dazu genug Beispiele mit kompletten Schaltbildern. Allerdings ergibt die Überschlagsrechnung, dass ein externes Steckernetzteil notwendig wird. Einsetzbar wäre auch ein LM2575S-3.3 [37] für 2,47€ (Farnell), der sieht gut und einfach in der Handhabung aus im Falle einer externen Stromversorgung. [Bearbeiten] Programmierung[Bearbeiten] AVRRecht früh hat sich im Forum heraus kristallisiert, dass der AVR per Bootloader vom Computer her programmiert werden sollte. Hierdurch sind Firmware Updates sehr einfach möglich und verschiedene Bootloader sind verfügbar. Die Bootloader Option setzt damit einen AVR der ATmega-Serie vorraus. Der AVR braucht folgende Anschlüsse:
Demnach ist ein 40-poliger nötig. Es wird ein ATmega16 angesetzt. [Bearbeiten] CPLDDie Programmierung des CPLD ist dagegen noch nicht konkret. Wünschenswert wäre es, ebenfalls seine Firmware über den Computer updaten zu können. Der Standardweg der Programmierung der Xilinx CPLD sieht einen JTAG Stiftsockel vor. Dann kann die Programmierung z. B. über ein Xilinx JTAG/Parallel Download Cable [38] aus dem ISE/impact geschehen. Einen möglichen Weg stellt die XApp058 [39] dar, darin wird beschrieben, wie der CPLD mittels µC beschrieben wird. Dieses Thema wurde bereits im Forum "AVR Ethernet Platine" aufgegriffen. In diesem Thread [40] kam man allerdings zu der Überzeugung, dass die XSVF Datei mit 45 kB für µC-Verhältnisse extrem groß ist und somit nur in einen ATmega128 (und größer) [41] reinpassen würde, da das SVF JTAG Protokoll riesige Datenbuffer im SRAM benötigt. Dies ist protokollbedingt - es wurden 10 kB für ein FPGA genannt. Dabei sind die Xilinx CPLD Speicherplatz-effizienter als welche von Altera. Leider sind die Xilinx CPLD eben nur über JTAG programmierbar. Allerdings wurde in diesem Zusammenhang auch auf den XSVF Executor [42] verwiesen. Auch ist die Frage noch offen, inwiefern die XSVF Datei über die RS232/USB geladen werden kann, ebenso das Timing der JTAG Schnittstelle. Dies lässt sich z. B. ähnlich dem Projekt in der Codesammlung machen [43]. Dann ist zum Programmieren des CPLDs nur eine Software auf dem PC nötig, die Daten werden über USB oder RS232 an den AVR gesandt und dort umgesetzt. Aufgrund der vielen offenen Fragen ist die schnellste und sicherste Lösung die Anbindung über den JTAG Stecker um den CPLD per JTAG/Parallel Download Cable zu programmieren. Zusätzlich wird eine JTAG-Verbindung zum AVR-Port eingerichtet, falls das Problem irgendwann später gelöst wird. Bisher existiert in VHDL für den CPLD LA Core:
[Bearbeiten] PCBDieses Thema kommt noch intensiv. Dabei sind u.a. die folgenden Application Notes nützlich: für AVR: für CPLD:
[Bearbeiten] Datenblätter, Bezugsquellen und Preise (allg.)... oder was bisher so zusammengetragen wurde.
[Bearbeiten] Sonstiges |
![[1]](http://www.mikrocontroller.net/attachment.php/209385/Scan0004.png){kind=link}