Hallo Leute, ich muss jetzt echt nochmal mit nem ganz alten Thema kommen: Hat jemand Lust mit mir einen privat-labortauglichen LA zu bauen? Ich denke, dass es sich hierbei um ein Gerät handelt, dass jeder schon mindestens einmal vermisst hat. Es soll kein Tektronix oder HP für 10 mille werden, einfach ein Standalonegerät mit einigen MHz, mit PC-Mainboard (ist vielleicht hilfreich einfach) und einer oder zwei ISA karten ( für jeden nachzubauen) unter 2-3 hekto-Euro. Die Komponenten an sich lassen sich ja bei ebay für ein Appel und ein Ei erstehen. Ich überlege seit langem, wie ich die eigentliche LA-Karte realisiere: etwas SRAM (8Mx16 oder 4Mx32, in der Richtung halt...), ein bis zwei CPLDs oder FPGAs und dann müsste das doch eigentlich schon tuen. Evtl, sollte die Kiste in der Lage sein, noch andere Karten zu bedienen, vielleicht einen Logic-Sequencer oder wie man das eben nennt; also eine Karte, die definierte digitale Pegel auf 16-32 Kanälen ausgibt, synchron und extern triggerbar, versteht sich (vielleicht einen Logic Generator!?!?) Man müsste ein derartiges Projekt auf mehrere Teilnehmer verteilen, denke ich. Einer oder zwei die Soft-(bzw.Firm-)ware und ein bis zwei Leute für die Hardware der einzelnen Komponenten. Das ganze Projekt, für den unwahrscheinlichen Fall, dass es was wird, soll selbst verständlich vollständig kostenlos und allen Interessierten frei zugänglich sein. Ich persönlich könnte Bauteile liefern. Das schließt RAMS, CPLDs und evtl sogar die Bestückung der PCBs ein. Also, falls jemand was dazu zu sagen hat, bitte jetzt sprechen. Ist es gut, scheiße, machbar oder kann man es vergessen!?!? Es ist doch ein "relativ"-simples Gerät, so ein LA, oder irre ich da.... Lasst mich nicht hängen Danke schonmal und Grüße aus Esslingen am schönen Neckar Boris
Hallo Boris, den Weg mit einem Selbstbau wollte ich auch schon mehrfach gehen. Ich habe dann ein Teil aus Elektor nachgebaut (echter Mist, gerade die Software). Dann habe ich überlegt, das Ding zu modifizieren und angefangen die Software neu zu schreiben. Ich denke jetzt habe ich eine Lösung. Ich nehme das Lifedesign FPGA-Board von Altium. Das Gerät hat u.a. auch Cores für Logikanalysatoren. Die sind zwar eigentlich für interne FPGA-Analyse gedacht, man ihre Eingänge aber natürlich auch nach außen legen. Für die 100 Brutto bekommt man einen 50 MHz LA und 'ne Menge mehr. Die Software ist nicht super, reicht aber für den Heimgebrauch. Vielleicht eine Anregung. Gruß aus dem westlichen Niedersachsen Einhart
Also gegen eine PC-Hardware spricht IMHO das es dann gleich eine recht fette sache wird. Und dieser fette Klotz, vielleicht sogar mit Monitor, steht unmittelbar an deinem Arbeitsplatz weil du keine grossen Kabellaengen haben willst wenn du einen schnellen Logikanalyzer baust. Mein Logicanalyser besteht aus einem Einschub fuer die Tek7000er. Zwar 20Jahre alt, aber macht auch 100Mhz und laeuft gut. Hat ausserdem fast nichts gekostet. Selbstbau lohnt IMHO nicht solange man nicht wirklich kompliziertere Sachen implementiert, also z.B auch eine Analyse von I2C oder gar USB auf Protokollebene. Aber der Aufwand dafuer ist natuerlich sehr gross. Wenn ich uebrigens so drueber nachdenke, das meiste was man macht findet heute doch innerhalb des Microcontrollers statt. Externes Ram, oder gar Portbausteine sind doch eher selten. Wenn man mit externer Hardware komuniziert dann ist das fast immer ein serielles Protokoll. Also I2C, 1Wire, USB, RS232, MMC/SD, dafuer reicht dann aber ein Ossi. Interessant waere wirklich ein Analyser auf Protokollebene, und da vor allem fuer USB. Ich wuerd sogar vermuten das man damit noch gut Geld verdienen koennte weil jeder dessen FAehigkeiten ein wenig ueber Elektor und FTDI232 hinausgewachsen ist danach schreien wird. .-) Olaf
Hallo, ein sehr interessantes Projekt, ich will sowas schon seit langem mal bauen und habe mir auch schon Gedanken gemacht, nur so was richtig brauchbares ist da bisher nicht zustande gekommen. Ich habe neulich bei eBay einen 8-Kanal LA mit 500MHz gesehen, den man direkt an USB stecken konnte. Das Teil war in einem Minigehäuse untergebracht und enthielt so wie ich das gesehen habe, einen einzelnen Chip. Ich vermute mal, daß es irgendein FPGA mit internem RAM war. Wie die USB-Verbindung zustande kam, kann ich nicht sagen. Vielleicht war doch noch ein weiterer Chip mit drauf. Es ist die Frage, ob man wirklich 8Mx16 bzw. 4Mx32 braucht oder ob man ein FPGA mit viel RAM nehmen könnte. Das würde jedenfalls die Hardware ungemein vereinfachen, zumal es FPGAs mit Dual Port RAM gibt. Wenn du (ihr) für eine Lösung mit externem RAM seit, so wäre ich auch unbedingt für SRAM. Der Ansatz von Elektor verwendet diese sehr teuren FIFOs die zudem in kleinen Stückzahlen schwer erhältlich sind. Soweit mal meine Gedanken dazun. Also wie gesagt ich wäre sehr interessiert an dem Projekt. Ich habe mir mal ein Mini-LA mit nem PIC programmiert. Abtastrate waren 2MHz und an speicher hatte ich 2Kx16 vorgesehen. Das hat mir schon sehr geholfen bei der Analyse von IR Fernbedienungssignalen. Gruß Thorsten
Hallo, sorry dass ich mich jetzt erst wieder melde... ja, wenn dann mit SRAM, deshalb auch so großer Speicher, die 4Mx8 chips habe ich zahlreich zur hand, deshalb. Fifos sind doch eigentlich nicht nötig oder? das kann ja dann der FPGA oder CPLD managen. Probleme macht mir noch der Eingangsteil, er soll 3,3 und 5V kompatibel sein, am Bestem ohne Umschaltung, wenn doch, dann für jeden Kanal separat. (Probleme mit Überspannung, Kurzen etc...) Vielleicht kann ich ja mit dem einen oder anderen da mal näher ins Gespräch kommen.. Gruß Boris
Der Logicanalyzer von Elektor der da angesprochen wurde ist ein ziemlicher Rueckschritt. 1996 gabs im Elektor (basierend auf Lattice 1016) einen 16/32/48/64 kanaligen 50Mhz Analyzer der wirklich gut als Basis fuer was neues geeignet waere. Helmut
Und noch ergaenzend - da gibt es doch von www.braintechnology.de einen recht netten LA zu kaufen. Das war mal ein SW Gewinnerprojekt bie Elektor, ist aber nie ins Heft gekommen - war wohl zu gut. Auf der Elektor PC Software 98/99 ist da alles drauf (Schaltung/Platine/../PC SW in Source).. recht lesenswert. Helmut
man könnte da ja einfach mehrere cache-RAMs sozusagen parallel verwenden, d.h. erstes byte in RAM #1, zweites byte in RAM #2, drittes byte in RAM #1 etc. damit müsste man mit 15ns cache-RAMs auf 100MHz kommen. moderne FPGAs haben ja genug pins, um zwei oder mehr address-busse zu steuern (z.B. xilinx XC3S400) im TQFP208-gehäuse. die datenleitungen könnte man mit bus-buffern direkt von den eingängen treiben, z.B. mit 74AHCT244. die haben im optimalsten fall eine durchlaufzeit von 1ns und wenn man die kapazität niedrig hält, dann kommt man da vermutlich "nahe" ran, also etwa 3ns. zum auslesen über USB könnte man ja einfach die bus-buffer für die datenleitungen tristate schalten und dann mit einem AVR draufgehen, um die daten auszulesen. ideal wären meiner meinung nach mindestens 128K samples für jeden kanal. da ganze könnte man ja modular aufbauen, z.B. 32 kanäle pro platine. wenn man dann will, könnte man sich einfach noch eine zusatzplatine draufmachen, die nochmal 32 kanäle zur verfügung stellt. mit dem PC verbunden werden würde aber immer nur die master platine, die verbindung der platinen untereinander müsste irgendwie anders erfolgen. die idee mit dem PC finde ich allerdings nicht so gut, weil das wäre noch eine kiste mehr. lieber ein schlankes gehäuse mit USB-anschluss, dass man nahe an der zu testenden schaltung plazieren kann und nicht die zu testende schaltung hinter den PC legen muss, damit die leitungen kurz genug sind. just my 2 centz
Bevor man die Bauteile aussucht sollte man eigentlich festlegen was man moechte, also Anzahl der Kanaele und max. Frequenz denn eigentlich soll so ein Selbstbau ja erschwinglich sein. Die teuersten Bauteile sind die schnellen Speicher. Wenn man also da von Vorneherein sagt man moechte Cache Chips (16k*8) mit 15 oder 12nS verwenden ist das meiner Meinung fuer den Heimwerker vernuenftig und ergibt eine max Frequenz von gut 50MHz. Die typische Speichertiefe bei LA's ist 8k, mit den Cache Chips haetten wir 16k. 128k finde ich da leicht uebertrieben. Die Methode des alternativen Zugriffs ist mehr was fuer Drams (wegen der Wartezeit zwischen 2 Zugriffen), bei Srams habe ich da etwas Bedenken ob das so leicht geht. Wenn es also unbedingt 100Mhz sein muss ist das nur ein Kostenfaktor, Srams mit 7.5ns gibt es. Helmut
Mal so ganz nebenbei sollte auch die Software auf PC-Seite bedacht werden. Gibts da schon ne fertige Lösung? Ansonsten wird dies auch einiges an Zeit in Anspruch nehmen, wenns vernünftig sein soll.
Die PC SW ist wahrscheinlich der Hauptaufwand. Die Hardware, abgesehen vom PGA (ist ja fast schon SW) ist nicht wirklich kompliziert. Von dem einen Elektor Projekt gibt es auch die Sourcen (VB) aber wieweit man die verwenden darf (ausser fuer den privaten Gebrauch wenn man die CD gekauft hat..)??
Stimme ich voll zu. Die Software ist deutlich aufwendiger als die Hardware. Ich glaube allerdings nicht, dass man den Source-Code aus Elektor einfach so weiterverwenden darf, aber ich bin da auch kein Fachmann :) Programmiert ihr das FPGA in VHDL? Wäre glaube ich das beste für diese Aufgabe. Viel wichtiger wäre allerdings eine Triggerlogik, d.h. ab wann beginnt er zu samplen. Kann man ja einfach ins FPGA integrieren. An Möglichkeiten sollte man wie immer haben: '1', '0', 'x' (don't care). Außerdem solle es möglich sein, eines der Eingangssignale als Clock verwenden zu können (z.B. LE-Pin eines Latches oder Clock eines uC) MfG - cl
Angehängte Dateien:
-
IMG_0388.jpg
100 KB
Hallo Leute Also ich beschäftige mich nun auch schon gut 2 Jahre mit dem Thema. Wobei ich für eine Lösung mit ADWandler 2 Kanal und 32 Kanal Logik Analysator wäre. Habe das auch schon des öfteren auf Steckplatinen aufgebaut, im Moment bin ich leider mit dem Studium (Elektrotechnik) zu beschäftigt, aber in den Sommerferien möchte ich das Projekt nun endlich durchbringen. Die ersten Tests mit den für die analogen Kanäle notwendigen OPVs waren schon recht zufriedenstellend. Habe auch den LA Teil mal gesondert aufgebaut. Habe dafür einen Xilinx 9536 verwendet. Das Problem ist wirklich das die Cache RAMs sehr langsam sind. Habe 2 Schieberegister verwendet. Der Xilinx kann max in der -5ns Ausführung mit 100MHz schalten. Durch den parallelen Aufbau von 2 Schieberegistern, die beim Takteingang sich nur durch einen Puffer mit durchlaufzeit 5ns unterscheiden wären 200MHz drinnen. Allerdings braucht man dann einen Cachebaustein für EINEN Kanal. Hat dann bei mir mit 160MHz Abtastrate sehr gut funktioniert, ist aber leichter Overkill ;-) Jetzt erst kürzlich habe ich mir eine Platine geätzt (siehe angehängtes Bild). Auf dieser sind schon 4 Cachebausteine oben, und ein Xilinx 9536, welcher die Adressenansteuerung übernimmt. An den Pins kann man dann 4 * 8 Bit = 32 Bit = 4 Byte Daten anlegen. Eigentlich muss das ganze nur mehr mit ein paar Pufferbausteinen mit einem µC verbunden werden und fertig ist der LA. Damit wären dann knapp 50MHz drinnen, nur mit der Triggerung ist dann halt Essig, da müsste man sich noch etwas überlegen. Vielleicht einen vorgeschalteten großen Xilinx 95188 mit vielen Pins, leider komm ich an solche Bauteile aber nur schwer heran in Österreich... MfG Martin W -------------------------------
Schaut schonmal sehr gut aus. Wie hast Du eigentlich die Durchkontaktierungen gemacht? So große CPLDs sind aber doch sehr teuer, v.a. in der 5V-Version. So ein XC3S400-4TQ144 (FPGA, Spartan III, 400000 Gates, TQFP144) kostet beim Reichelt ca. 25 Euro (bei einer Liefermenge von 3 Stück). Ich hab mal von ca. 6 Wochen interessehalber angefragt. Da bekommt man dann alles rein: Triggerlogic, RAM-Steuerung etc. Ein Problem könnte allerdings noch sein, dass diese FPGAs 3.3V I/O-Spannung haben. 5V tolerante Eingänge haben sie ja AFAIK. Nur die Buffer sollten extern sein, damit im Falle eines Fehlers nicht alles in Rauch aufgeht.
Ach ja nochwas Wegen der Software. Ich habe nur ein kleines Programm in Visual Basic verwendet, welches die Daten über die serielle Schnittstelle bekommt, natürlich viel zu langsam selbst mit 115200 Baud. Da müsste man schon USB verwenden, hab auch schon die PICs mit integriertem USB bei mir liegen (bin PIC Fan) nur leider hatte ich noch keine Zeit mich damit zu beschäftigen. C++ zum programmieren am PC ist auch kein Problem, nur die grafische Oberfläche für eine anständige Darstellung der Signale, die macht mir sorgen, damit kenn ich mich nämlich garnet aus... Vorallem ist mir wichtig, dass bei einer live Darstellung, das Bild nicht flakert, also bei schwarzem Hintergrund beim Aktualisieren kurz weiß wird... vielleicht könnte ja jemand diesen Part übernehmen ;-) Mfg Martin Wiessflecker ---------------------------------- http://www.sbox.tugraz.at/home/m/martinw
Das mit dem Copyright und was ich als Kaufer der CD damit machen darf ist eine Frage fuer den Rechtsverdreher. Aber wenn Elektor das zum privatem Nachbau veroeffentlicht darf ich es doch auch weiterentwickeln? Die Triggerlogik (solange nur auf 1/0/x getriggert werden muss) ist einfach: da sind 2 Register im PLD (1/0, care/dontcare) die mit den Eingangssignalen verglichen werden. Heikler ist das ob die Daten im Ram gueltig sind (normal wird das Ram im Kreis angefuellt bis der Trigger kommt. Wenn der Trigger aber vorher kommt weiss man nicht so recht woher die Daten im Ram stammen) Ein externer und interner Clock mit einem einstellbaren Teiler ist klar das man so etwas braucht. Reversi
Also die Durchkontaktierung, da hat ja jeder seine eigene Methode, aber viele würden sich die Platinen wahrscheinlich eh irgendwo bestellen. Ich stecke meistens einen dünnen Drat durch und verlöte dann oben und unten, versuche aber schon beim Layout so gut es geht sie zu vermeiden. Man kann z.B. 8Bit die von einem AD Wandler kommen, irgendwie an den Port vom µC anhängen, und dann die Bits im µC wieder richtig stellen, ist zwar programmierarbeit, aber gibt ein schöneres Layout. Also der Xilinx ist bei mir in der XL - also 3,3 Volt Bauart, deswegen auch der kleine Spannungswandler auf der Platine. Also bei mir hat das RAM keine Probleme mit der niedrigen Spannung und der Xilinx ist ja auch 5V tolerant. Einen ganz großen FPGA zu verwenden wäre natürlich auch toll. Einfaches Platinen Layout, kurze Leiterbahnen, etc... Nur einen so großen Chip löten ist die andere Seite der Medailie, ich bevorzuge fürs erste einen modularen Aufbau ;-) Hab außerdem schon mal irgendwo im Web so einen Aufbau mit FPGA gesehen. Der hat dort einen Cache Baustein mit 4 Byte Breite verwendet, welcher auch deutlich schneller war, gibt ja solche bei denen man sequentiel schreiben kann. Weiß jetzt nicht genau wie man diese Funktion nennt! Burst? Naja jedenfalls sehr schön nur alles super kleines SMD ;-) Mfg Martin Wiessflecker ---------------------------------- http://www.sbox.tugraz.at/home/m/martinw
@martinw Könntest du den Quellcode für den CPLD hier reinstellen ? Ich arbeite an einem ähnliche Projekt, habe aber mit dem SRAM Timing, vor allem mit dem WE\ Signal ziemliche Probleme bei hohen Geschwindigkeiten.
@Benedikt Also ich habe den CPLD mit dem Schematic Editor programmiert, ich kann nämlich noch kein VHDL oder ähnliches. Mit dem WE sollte es kein Problem geben. Einfach das SRAM auf schreiben einstellen und dann die Adressen hochzählen. Du musst das WE Signal nicht jedesmal bei jedem einzelnem Schreibvorgang setzen und wieder löschen... Bei mir gibt es einfach einen Clock-Eingang welcher in einen Zähler geht. Dessen Ausgänge werden herausgeführt für die Adressen des SRAM. Dann noch einen Multiplexer und ein FlipFlop, welcher beim Erreichen einer gewissen Adresse das Weiterzählen anhält, also wenn der Speicher voll ist. Hoffe ich konnte helfen.. Mfg Martin Wiessflecker ---------------------------------- http://www.sbox.tugraz.at/home/m/martinw
Da es sich echt lohnt, VHDL zu lernen, stelle ich mal ein paar Links online: http://www.vhdl-online.de/tutorial http://www.cs.ucr.edu/content/esd/labs/tutorial/ Der obere Link ist mehr ne Referenz, aber der untere ist wirklich gut. Ich behaupte mal, dass man wenn man sich mit VHDL beschäftigt, die Logik im CPLD von martinw nach spätestens 12h Beschäftigung programmieren kann. MfG - cl
Angehängte Dateien:
-
billoLogicAna.png
13 KB
Hallo, wäre auch an einem "richtigen" LA interresiert. Software auf PC-Seite aollte auch nicht soo das Problem sein. Hab mir vor ein paar Tagen mal nen Billo 2-Kanal LA mit nem AVR aufgebaut um nen I2C Bus zu debuggen. Die Daten hab ich über UART an den PC gesendet und da erstmal in ein File gespeichert und dieses dann mit nem Java Prog interpretiert. Nen bissel umständlich aber das Programmieren hat auch nur nen halben Tag gedauert :) Für die FTDI Chips gibs fertige Bibliotheken das man sie direkt in Java ansprechen kann, damit sollte dann auch die Übertragung via USB und Darstellung in Echtzeit kein Problem sein. Im Anhang mal nen Bild von meiner SW.
Hallo ape, ist über Deinen Billo mehr zu erfahren, bzw. kann man Deinen Code einsehen? Codesammlung? MfG Achim
Naja das Ding war nur ganz schnell mit heißer nadel zusammengestrickt und verfügt über so einige beschränkungen (kein vernünftiger Trigger, recht umständliches Handling mit dem Daten Empfang, usw.), das ich eigentlich nich beabsichtigt hatte es zu veröffentlichen. Ich hab einfach nen mega128 genommen. Das Programm wartet bis sich was an PB0 oder PB1 tut (einfacher Trigger). Bei einer Änderung samplet er einfach in einer Schleife das komplette interne SRAM voll (4kB, also 16k Samples pro Kanal). Ein Schleifendurchlauf dauert 20 Takte, damit war aber der Speicher zu schnell voll, daher hab ichs auf 35 Takte erhöht (etwas über 500kHz bei 18,432MHz Takt). Danach wird der komplette Speicherinhalt via UART an den PC gesendet (binär, ohne jegliches Protokoll). Der Sample-Vorgang wird nicht wiederholt, um ein weiteres Mal zu samplen, muss man den AVR resetten :) Am PC empfange ich die Daten mit BrayTerminal und kopier die dezimale Ausgabe in nen File das ich dann mit meinem Java Prog öffne, das nimmt die Werte dann auseinander, stellt die Signale dar und interpretiert das I2C Protokoll. Ich hab das Programm mal angehangen, das asm is sogar halbwegs kommentiert, das Java Programm eher weniger :) Achja und wie gesagt is sehr fix geschrieben das ganze und daher an manchen Stellen vielleicht etwas häßlich :)
Hallo @ape super! Vielen Dank. Ich bin neu in diesem Atmelgeschäft. Ich habe mir ne Platine von Guido mit dem AEthernet geordert, da werde ich mal Versuchen sowas übers Ethernet anzukoppeln. Kein Problem wegen der Java Kommentierung, da habe ich mehr Ahnung als mit Atmels. Viele Grüße und vielen Dank Achim
@martinw Könntest du trotzdem mal die Datei hier reinstellen (oder mir per Email schicken) ? Diese einfache Lösung, mit WE\ andauernd auf Low ist eigentlich falsch. Laut Datenblatt muss das WE\ während dem Adresswechsel auf High gehen. Ich habe da nämlich ein paar SRAMs die das auch so haben wollen. Bei den meisten ist das zum Glück aber egal. Ich versuche ein superbilliges Oszi zu bauen, das mindestens 32MS/s schafft, und aus einem uC (als PC Interface), dem CPLD, einem SRAM und einem ADS830 besteht. Leider sind die Daten irgendwie total zerstückelt im SRAM, und das lustigste ist: Irgendwie hängt sich der Synchronzähler im CPLD auf, wenn ich an einen Ausgang einen 10k PullUp gegen +5V hänge.
@ Ape Also in Java ist das ganze ja vielleicht schön Platformunabhängig, aber ziemlich langsam. Das ganze wäre in C++ doch schon um einiges schneller. Vorallem wenn man dann mit FFT für die analogen Werte auch arbeiten will. Das Programm muss auch sehr flexibel sein. Heißt man muss Signal verschieben/ausblenden/gruppieren/anders Darstellen (Hex, Dez, Ascii, Bin)/einfärben/zoomen/scalieren und vieles mehr können. @ Benedikt Datei ist angehängt. Also bei mir funktioniert das wenn ich WE immer auf Low habe bestens. in meinem ECA mem Buch steht auch nichts davon... Wenn die Daten zerstückelt sind, kann es sein dass zwei Adressleitungen verwechselt wurden, oder du zu hoch taktest und einige Daten nicht übernommen werden. Ich überprüfe das ganze immer so, dass ich einen synchronen Zähler an dem SRAM anschließe und zählen lasse. Am Computer müsste dann eine Treppenspannung zu sehen sein, wenn man die Werte plottet... Aber ich habe sowieso vor SRAMs mit 1MBit speicher zu verwenden, die sind zwar nur 25ns schnell, aber bei 4 parallel sollte man trotzdem 100Mhz erreichen können. Nur bei 0,5MByte pro Kanal wird dann die Übertragung mit serieller Schnittstelle einfach inakzeptabel :-) Mfg Martin Wiessflecker ---------------------------------- http://www.sbox.tugraz.at/home/m/martinw
@martinw Du hast natürlich Recht Java is verdammt langsam, so dass eine Vollbilddarstellung eines Signals vielleicht nicht 200mal pro Sekunde, sondern nur 50 mal/s refreshed werden würde. Und so lächerlich Dinge wie eine FFT zu berechnen, sollte auch mit Java kein Problem sein. Auf dem AVR ist es vielleicht schwierig eine schnelle FFT zu realisieren, aber für einem halbwegs modernen PC sollte das keine groß Herausforderung sein (natürlich nur so lange sie nich zu umfangreich wird, aber ich denke 1024 Punkte sollten hier locker ausreichen) Abgesehen davon war ich auch noch von einem reinen Logik Analyser ohne Oszilloskop-Funktion ausgegangen. Die anderen von dir genannten Funktionen sind ja auch nur programmiertechnische Details, ob man das nun in Java macht oder in einer andern Sprache sollte sich nicht viel nehmen. Ich bin halt Fan von Java :) und das es zu langsam ist, ist bei den Geschwindigkeiten moderner PCs mittlerweile einfach nicht mehr wahr. So 1GHz sollte der Rechner allerdings schon haben um da vernünftige Darstellungsraten zu erreichen denk ich.
Hallo Alle, Ich spiele schon länger mit die gedanke, aber ich wollte es dann modular aufbauen. in ein 19" kasten und unterschiedliche mess module: - 16/32 bit logikanalyzer > 100 MHz - 2 kanal Digital oszi > 100 Ms/s - multimeter. und dann über USB oder ethernet zum PC. Grüße Mark,
Angehängte Dateien:
@ Ape Ich weiß nur, dass mein altes Programm in Basic schon viel zu langsam wahr. Und der Zugriff auf die serielle Schnittstelle war auch alles andere als effizient. Also wenn das ein gemeinschafts Projekt werden soll, dann sollte das schon in Delphi oder C oder was anständigem geschrieben werden, so dass es auch noch auf alten Rechnern (auch wichtig für Laptops) halbwegs läuft. Java ist eine feine Sprache aber die Geschwindigkeitsunterschiede sind noch schlimmer als zwischen C und Assembler! Die FFT wäre für 0,5MByte Daten sicher schon nicht mehr so einfach in Java und Echtzeit realisierbar ;-) Aber nur für einen LA dürfte es wohl reichen, auch wenns mir nicht sympatisch ist... Aber wir wollen uns hier ja jetzt nicht über das Programm streiten... Sondern über den Aufbau des Gerätes :-) Angehängt noch ein Screeny von dem Oszi bei 30Ms/s Mfg Martin Wiessflecker ---------------------------------- http://www.sbox.tugraz.at/home/m/martinw
Ich bin natürlich für C als Programmiersprache :-). Java ist ungeeignet, schon alleine deswegen, weils keine Pointer gibt. Sorry an alle Java Fans, dass ich ihre Sprache jetzt so durch den Dreck ziehe. Was für ein Proggi sollen wir den nehmen, um den Schaltplan zu zeichnen??? Ich persönlich würde gEDA vorschlagen, weil wenn das Projekt wirklich frei sein soll, dann soll auch das Programm mit dem es erstellt wurde, frei (also kostenlos oder frei im Sinne der GPL) sein. Meinetwegen können wir es auch mit Protel machen, aber das kostet $$$. Das Problem der proprietären Tools ist, dass wenn man nur ganz wenige Änderungen machen will, gezwungen ist, den ganzen Plan abzuzeichnen. Mit gEDA kann man Netlists für ca. 20 andere Progs erzeugen. z.B. für Eagle, für Protel, AFAIK für Target3001 (auch wenn das wahrscheinlich niemand mit ernsten Ambitionen nutzt) und für viele andere. Das heißt, dass Layout kann man dann wieder mit dem Tool seiner Wahl machen. MfG - cl
mhmm gEDA sieht ganz toll aus aber soweit ich das auf die schnelle sehen konnte gibs binaries nur für linux und mac oder? Im übrigen komt man bei Java auch klasse ohne Pointer aus und überhaupt ist es tollste Sprache der Welt :P Aber die Diskussion führt nur ins OT :)
so jetzt muss ich mich auch mal einmischen ;) ich bin stark für eine script sprache... z.b python... das schaut eigentlich ganz gut geeignet aus für sowas... c++ gut und schön...aber irgendwann überlegt man sich ob das alles soo toll ist mit plattformabhängigkeit... python ist schön und es kommt mir eigentlich auch ganz flott vor... fall doch was mit dem c++ prog unter der mfc werden sollte... dank meiner arbeitsstätte in der nicht-uni-zeit bin ich ziemlich gut drauf... da könnt ich locker helfen... btw was spricht tatsächlich gegen einen pc???? oder gleich sowas... http://www.olimex.com/dev/cs-e9301.html gibts zwar noch ned aber das ist dann die eierlegende wollmilchsau... ;) ich mein was will man mehr... die daten rassln dann über ethernet rein.. und nachdem das teil SPI bus hat... macht man die ganze samplerei gemütlich in den cache...den zieht man sich per spi in den arm und der vergewaltigt alles so das man am pc möglichst wenig herummurksn muss (damit wird die anzeigesoft schön einfach) ;) überhaupt bin ich sehr für ethernet... 1. schnell... 2. hats jeder 3. kein driverprob (usb => win und linux driver ;/ und die realtime geschichte ist auch nicht soo schlimm... bedenke viel mehr als 25Hz bringen sich eh nicht.. ka wieviel puffer du machen willst...aber bedenke immer du wirst nicht immer bei 100MHz samplen... da war doch mal im elektor vor einiger zeit von cypress eine schöne pll ... damit könnte man gemütlich die sampelfrequenz einstellen... oder in den fpga einfach einen nco rein ;D fpgas würden mich schon reizen.. muss ich unbedingt in nächster zeit machen... also mein fazit: -> das ding muss Ethernet können -> die soft am pc sollte portabel sein -> script sprache wie python + z.b wxPython als widgetset -> sampelfrequenz einstellbar -> weniger daten ;) sooo jetz noch was für diejenigen die meinen fft muss unbedingt in c/c++ gemacht werden damit alte pcs auch noch damit klarkommen... python kann c/cpp libs invoken ;) also lib in c und rest in python... lib kann man portabel gestalten... das kompilierst auf jeder beliebigen plattform im gcc.. nur wenn du ein dummes widgetset hast (z.b MFC) dann darfst du alles für ein gescheits auf einer anderen plattform NEU schreiben... es gibt zwar auch portable widgetsets...aber... der compiler... also gleich python her... und alle sind glücklich und zufrieden (vor allem die linux user ;) und wenn tatsächlich einer mal drauf kommen sollte das teil komplett stand alone zu machen und soeinen arm von olimex rein tut... der nimmt einen mit genug ram und grafik... x drauf.. python drauf und LCD dran ;) fertig ist dann der stand alone la... und wer denkt das wär krank und abartig.. es gibt speicherscopes mit XP drauf !!! :D so genug getippt.. 73 de oe6jwf / hans (auch einer von der tu-graz.. und auch einer im 2. semester e-technik ;D
vielleicht ist es besser, wir vergessen die Programmiersprachen, sonst gibt's hier noch nen Flame War. Aber C ist immer noch am besten :-) @ape: Mit mingw (http://sourceforge.net/projects/mingw/) müsste man es für Windows kompilieren können. Hab ich aber nicht ausprobiert, ich hab's einfach unter Linux kompiliert und fertich. Ich kann ja mal auf der Mailinglist von gEDA nachfragen ... Vielleicht schaffe ich es, morgen nen Beitrag für die Liste zu schreiben. Ich werde Euch dann über die Ergebnisse informieren. Die Binaries für Linux sind allerdings ziemlich alt. @Hans: Was Speicherscopes mit XP??? Deren Display braucht doch sowieso nur die Farbe Blau, genau wie alle anderen Systeme wo Windoze läuft. ;) MfG - cl
Eure Spezifikationen fuer das was ihr da bauen moechtet sind noch ziemlich vage, meint Ihr nicht ? Ich bin da wirklich gespannt was das wird. Helmut
Ich denke auch bevor es hier zum Krieg um die beste Programmiersprache kommt sollte erstmal die Hardware feststehen. Also: - Kanäle: 32 oder 64? - Weitere Kanäle per weiterem Modul nachrüstbar ja/nein? - Sampling-Rate: 50MHz oder 100? - Speichertiefe? - Schnittstelle USB oder Ethernet? - Wie großes PLD/FPGA, welcher Funktionsumfang (Trigger etc.) - Oszilloskop ja/nein/Zusatz Modul Für mich persönlich wären 32 Kanäle bei weitem genug, daher müsste das ganze auch nicht unbedingt aufrüstbar sein. Sampling-Rate würden mir 50MHz auch reichen denke ich. Bei der Speichertiefe, solltens schon 64k Samples pro Kanal sein (wären dann bei 32 Kanälen ins Gesamt 256kB) Die Schnittstelle könnte man im Zweifelsfall so gestalten das sich da jeder ranhängen kann was er will: nen FTDI USB Chip oder einen wie auch immer realisierten Ethernet-Adapter. Das man bei allen Kanälen und maximaler Speichertiefe keine 25fps mehr schafft sollte jedem klar sein... Mit Programmierbaren Logik Bausteinen hab ich noch keine Erfahrung, also keine Ahnung wie groß der sein muss. Oszilloskop brauch ich nicht, da hab ich schon eins :) Vielleicht nachrüstbar, als Modul? Anzeige-Software könnte sich im Zweifelsfall ja auch jeder mit der Programmiersprache seiner Wahl selbst schreiben. @Hans: Einen ARM9 da rein zu knallen halte ich für übertrieben, das wäre einfach Geld-Verschwendung und ein PC ist einfach mal zu groß und steht nur im Weg rum.
Die Anforderungen von ape klingt ja schon viel realistischer. Was ich nicht verstehe ist weswegen ihr alle so riesige Speichertiefen wollt. Dr LA den ich mir ab und zu von der Fa. ausborge hat 4k u d das ist schon viel zum schaun. Mich interresiert doch eigentlich nur die Gegend um den Trigger. Uebrigens 64k x 32 = 2MB. Ist aber egal. Beim Speichedr muss man sowiso Kompromisse eingehen und sich daran richten was es zu kaufen gibt. Wie ich schon gesagt habe, das ergibt eine recht einfache (und auch leistbar < 100Euro) Hardware. zB moegliche Komponenten fuer einen 32 kanaligen LA mit min. 50MHz: 4 x 74lvc541 als Buffer 2 x Sram 32k x 16 12nS 3v3 FPGA (Altera ?)3v3 FTDI FT245 USB Helmut
@Helmut > Dr LA den ich mir ab und zu von der Fa. ausborge hat 4k u d das > ist schon viel zum schaun. Das sehe ich genauso. Und dann sind wir doch eigentlich schon bei der Lösung ohne externes RAM. Von Xilinx gibts z. B. FPGAs aus der Spartan-II Serie mit 96kBit Speicher in noch handlebarem Gehäuse. Reicht das nicht? Und was die Software angeht: bitte kein Java und keine seltsamen Scriptsprachen, die keiner kann :) Thorsten
Ich habe leider nur wenig Ahnung von modernen (grossen) FPGA's - Hast aber wahrscheinlich recht. Sind diese Kaefer einzeln kaufbar / erschwinglich ist die naechste Frage. Und auch das Expertenwissen wird wohl zum programmieren hoeher sein. Mich stoeren die externen Rams eigentlich nicht. Da die Bauteilanzahl sowiso schon gering ist und die Pinzuordnung bei den FPGA's so flexibel ist glaube ich sogar an eine einseitige Platine. Helmut
Der Anforderungskatalog von Helmut ist (für mich) in Ordnung. Ich kann ja mal ein paar VHDL Experimente anstellen, wie groß das FPGA sein soll. Den Code kann ich hier ja nachher posten (IDE: Xilinx ISE Webpack). Ich versuche auch mal den internen RAM auszunutzen. @Helmut: Wo bekommst Du die 74lvc541? - cl
Noch eine kleine Idee zur Hardware: der FTDI FT245 USB hat einen "Bit bang mode" der zum programmieren von FPGA's dient (statt dem ser. EEprom). Da gibet es auch eine Appnode (mit Bsp Altera Flex 10k) dafuer. Koennte ein wirklich nettes Feature sein. Helmut PS: zur PC SW: Delphi wuerde sich da auch gut eignen
@C. Lechner ich wünsch dir viel spass bei mingw und gui ;) lieber gleich python und wxPython... da bist in 0,nix mit der gui fertig und nebenbei geht das auch ganz gut unter lin und win ;) und das mit scopes mit xp ist kein scherz (siehe elektor nr ka... da war mal son scope-test :) @ape 2MB per usb übertragen mit ftdi-chips.. viel spass ;) so und nun zum thema speicher... CY7C1340F-100AC CYP TQFP100 4M 128Kx32 11,25e (rs-components) das teil sollte doch schon ganz gut passen find ich... zumindest dürfte das reinsamplen sich als recht einfach erweisen... unter umständen wärs glaubich nicht verkehrt z.b einen mega8 o.ä mit uart dazuzutun (oder einfach einen AVR ins fpga zu packen => opencores.org)... der könnte dann gemütlich die daten aus den ram über was auch immer für eine schnittstelle schaufeln... btw opencores hätte auch eine pci brige ;) 73 de oe6jwf / hans
Das mit mingw war wegen gEDA, also vergessen ;) Momentan designe ich das VHDL Modell für die Block RAMs des FPGA. 4096 Samples/Kanal bei 32 Kanälen und 100MHz scheinen möglich zu sein. Dem FPGA würde ich ein serielles Interface verpassen, dass dan von einem uC gesteuert wird. Der uC stellt die Verbindung zum PC her. Soweit mein Plan. Der pAVR (oder meinst Du was anderes) ist zu aufwendig. Ein "richtiger" ATmega ist bei unseren Stückzahlen billiger. Ich schreibe grade am Testbench. BlockRAM läuft auch schon (zumindest in der Simulation). Hat wer ein SpartanIII Eval-Board???
Ein Sample von einem Kanal belegt ein Bit und nicht ein Byte. Das wären dann also 64kBit = 8kByte pro Kanal und 8 x 32 ergibt i.d.R. 256 und nicht 2048 :P Die große Speichertiefe hätte ich nur gerne um auch bei einem seriellen Bus ein bisschen mehr Daten drauf zu kriegen. Aber das könnte man ja auch lösen, in dem man eine Option vorsieht, die es ermöglicht weniger Kanäle zu samplen und dennoch den gesamten Speicher zu nutzen, so dass die Speichertiefe pro Kanal dann entsprechend größer ist.
Mein aktueller Stand. Für die, die es interessiert. Ist zwar noch buggy, aber einfach mal in Xilinx ISE laden (ich verwende Version 6.3) und im Simulator bis ca. 58us laufen lassen (das Testbench). Da kommen die Daten, die vorher aufgenommen wurden wieder schön langsam raus. Jetzt code ich noch ein serielles Interface und dann lasse ich es mal vorerst.
@ape Schande ueber mein Haupt! Als (hoffentliche) Entschuldigung kann ich nur anfuehren: Bin absolut kein Morgenmensch!! In Zukunft werde Ich das Orakel von Excel (und Word dazu, da habe ich auch Probleme) befragen. Servus,Helmut
Hallo Für alle, die recht schnell und relativ kostengünstig zu einem Selbstbau LA kommen wollen: http://www.amateurfunkbasteln.de/pcla/pcla.html oder hier: http://alternatezone.com/electronics/pcla.htm Habe ihn mir selber auch aufgebaut (einseitige Platine). Ein Programmiergerät für die LSI-Bausteine kann man sich mit einigen Handgriffen selbst zusammen bauen. Die SW gibt es dazu kostenlos bei Lattice Beste Grüsse Geri
[QUOTE=Helmut] Und noch ergaenzend - da gibt es doch von www.braintechnology.de einen recht netten LA zu kaufen. Das war mal ein SW Gewinnerprojekt bie Elektor, ist aber nie ins Heft gekommen - war wohl zu gut. Auf der Elektor PC Software 98/99 ist da alles drauf (Schaltung/Platine/../PC SW in Source).. recht lesenswert. [/QUOTE] Kannst Du genauere Zielangaben machen (konkret Monat/Jahr)? Viele Grüße ope
Ich kann euch für semi-prof. Arbeiten diesen LA empfehlen: http://www.pctestinstruments.com/?gclid=CK6yhOW2pYUCFUlrEAodrVmcwQ Den habe ich privat seit einigen Monaten und bin ziemlich zufrieden. Insbesondere die PC-Software gefällt mir sehr gut. Vielleicht ein Nachteil ist die nicht sehr grosse 2k Speichertiefe pro Kanal (34-Kanäle). Das wird allerdings ein wenig durch die Komprimierung aufgefangen, d.h. es werden nur Pegelübergänge gespeichert, d.h. man kann mit sehr feiner Zeitauflösung auch sehr selten auftretene Ereignisse über einen langen Zeitraum messen. Ich muss allerdings zugeben, dass ich ihn noch nicht bis zur Spezifikationsgrenze belastet habe. Z.B. war meine max. Frequenz 20MHz, d.h. weit weg von den versprochenen 500MHz... P.S: Die Lieferung nach Deutschland war völlig problemlos und sehr schnell.
SuUs, If you are only getting 20MHz, then you are doing something very wrong. The analyze will indeed sample at 500MHz. Please see this post: http://www.mikrocontroller.net/forum/read-3-219109.html Regards, Harrison Young Intronix
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.