Zum Thema Logikanalysator ist ja schon viel geschrieben worden. Nun gibt es aus China, Finnland oder Deutschland dieses Gerät LWLA1034: http://www.ebay.de/itm/34CH-USB-125MHz-PC-Logic-Analyzer-34-channels-support-I2C-SPI-UART-and-PWM-/281328283279 http://www.ebay.de/itm/34CH-USB-125MHz-PC-Logic-Analyzer-34-channels-support-I2C-SPI-UART-and-PWM-/111335209130 http://www.ebay.de/itm/USB-Logic-Analyzer-34-Channels-124MHz-/331155858136 Dem Text nach ist da + Eingangswiderstand: 100kΩ + Pegel 0~5V + Stateanalyse + I2C SPI UART und PWM + 34 Kanäle + 12 bzw. 4 Klemmen + tiefer Speicher 256Kbit + USB-Versorgung + Datendarstellung gruppenweise HEX,OCD,DEC 3 Bausteine sollen verbaut sein: + CY7C68013A (usb interface) + EP2C5T208(FPGA) + CY7C1361(DRAM 256M) Kennt jemand dieses Teil aus eigener Anwendung?
Das scheint die Quadratur des Salea 8-Bit LA zu sein - zumindest was das PC-seitige Interface(Cypress) betrifft. Beitrag "10 Euro Logikanalyzer" Dieses Teil scheint relativ neu zu sein. > + tiefer Speicher 256Kbit Da USB 2.0 nicht in der Lage ist, diese Datenmengen bei 125 MHz Samplerate nicht "live" zu übertragen, verwendet dieser LA einen Puffer mit 256kB pro Samplevorgang. Würde mir allerdings nicht reichen. Mit USB 3.0 wäre das evtl. möglich.
:
Bearbeitet durch User
Den direkt kenne ich nicht aber ich hab hier den Open Workbench Logic Sniffer rumliegen mit ähnlicher Speichergröße und muß sagen, daß der nicht grad üppig ist. Da muß man schon bei 16 Kanälen manchmal ganz schön mit den Triggerevents jonglieren um das wichtigste nicht zu verpassen.
Angehängte Dateien:
-
lwla1043.png
220 KB
Bei diesem Gerät stehen mehr Angaben dabei: http://www.ebay.de/itm/100MHz-34-channels-Logic-Analyzer-Timing-State-Logic-Analyzer-16-CH-Counter-/121343145120 Eingang: -1V .. 6V >1.6V logic 1 100kOhm, 5pF.
Danke für die Beiträge ! Ihr seid also der Meinung, der Speicher ist knapp. Hilft nicht die Stateanalyse Speicher zu sparen? Der Intronix LA1034 Logic Port hat im Vergleich dazu + einstellbare Schwelle -6V .. 6V - 2048 Samples selbst wenn das extrem komprimiert sein sollte ist das doch viel weniger als 256k?
Matthias W. schrieb: > Ihr seid also der Meinung, der Speicher ist knapp. Wenn man manchmal digitale Abläufe auf sporadische Fehler untersuchen muß, dann sind 256kBit definitv zu wenig, weil der Fehler evtl. nicht immer auftritt. Es gab vor ca. 4 Jahren jemand in diesem Forum, der das explizit erklärt hat. Das ist bei mir hängen geblieben. Daraufhin habe ich mir einen Tek TLA715 mit einer 64MBit/128 zugelegt und bereue den Kauf nicht. Für serielle Kommunication reicht allerdings der 8-Bit LA von Saleae, da diese Busse relativ langsam sind.
Matthias W. schrieb: > Kennt jemand dieses Teil aus eigener Anwendung? Ich hab mal den Menschen getroffen, der die sigrok-Unterstützung programmiert hat. Beim Treffen war das Teil an einem Z80-System angeschlossen. Sigrok hat einen Protokolldekoder für Z80-Opcodes. Man konnte quasi zugucken, wie die Maschine arbeitet. Ich war gut beeindruckt, habe aber mit dem Teil selbst nicht gearbeitet. Wo willst Du den Logikanalyzer einsetzen? Was sind Deine Erwartungen? Gruß, Patrick
Matthias W. schrieb: > Hilft nicht die Stateanalyse Speicher zu sparen? Das ist das, was ich mit 'mit den Triggerevents jonglieren' umschrieben habe. Du mußt vorher wissen, wie das Ereignis das Du aufzeichnen willst in etwa aussieht und dann einen passenden Trigger setzen. Dann kannst Du die Samplerate so festlegen, daß das gesammte Event in den Speicher passt. Oft hilft es dann, einen Zusätzlichen Kanal für ein Triggersignal zu nutzen und mit Vor- und Nachlauf zu arbeiten. Bei 64MBit hast du dafür das Problem daß Du scrollen mußt um die passende Stelle zu finden ;-)
Patrick schrieb: > Wo willst Du den Logikanalyzer einsetzen? Was sind Deine Erwartungen? Ich habe momentan eine Sweep-Karte im Funktionsgenerator die spinnt. Eine Karte geht, die andere nicht. Es ist ein FPGA darauf - mit 10MHz Quarz daran. Mit einem Logikanalysator wäre es vielleicht wohl möglich herauszufinden wo das klemmt. Das war die Idee. Es gibt allerdings auch noch ein paar analoge Bauteile, die ggf. auch einen Einfluss haben könnten. Das ist halt schwer zu sagen wenn man die Software des Geräts nicht kennt.
Patrick schrieb: > Sigrok hat einen Protokolldekoder für Z80-Opcodes. Man > konnte quasi zugucken, wie die Maschine arbeitet. Das ist natürlich ein Erlebnis. Früher hatte ich Leds am 8085 und konnte diesen im Einzelschritt laufen lassen. So sah ich was passiert. Mit Dekoder-Anzeige ist es einfacher als mit einer LED-Reihe.
Myxo Matrose schrieb: > Wenn man manchmal digitale Abläufe auf sporadische Fehler untersuchen > muß Der Fehler sieht ziemlich robust aus. Der sollte daher schon zu finden sein.
Matthias W. schrieb: > Es ist ein FPGA darauf - mit 10MHz > Quarz daran. FPGAs sind statisch. Die kann man step für step durchtakten.
Myxo Matrose schrieb: > FPGAs sind statisch. Die kann man step für step durchtakten. ok. Die CPU, die die Platine ansteuert hat 16MHz Takt. Der Rechteckpuls hat 500ns Pulsdauer. Keine Ahnung ob das verlangsamt werden könnte oder sollte. Da die Sweep-Karte spinnt gehen auch die Displayausgaben nicht korrekt. Es ist momentan unmöglich das in einen genau definierten Zustand zu bringen, den ich als gemeinsamen Startpunkt nutzen könnte. Ich müsste eine eigene Testumgebung erstellen. Das klingt aufwendig. Die Idee war mit Hilfe des LA einen Fehler zu finden. Nur wenn man die Funktion nicht kennt, wie macht man das dann?
Das FPGA scheint von der externen CPU programmiert zu werden. Ob das richtig klappt ist die Frage. Eine Fehlermeldung kommt nicht beim Booten des Geräts.
Matthias W. schrieb: > Ich habe momentan eine Sweep-Karte im Funktionsgenerator die spinnt. Der Quarz hat 10 MHz. Ich weiß ja nicht was für ein FPGA im Einsatz ist, aber bei halbwegs aktuellen FPGA gibt es interne Taktvervielfacher bzw. PLLs. D.h. intern kann der auch mit 20 bis 150 MHz oder so arbeiten. Wenn auch noch analoge Signale eine Rolle spielen, wäre ein MSO das geeignetere Instrument. Leider gehen die Geräte mit 4 Analog + 16 Digitalkanälen momentan bei 750€ los: http://www.batronix.com/versand/oszilloskope/Rigol-MSO1074Z.html Der Vorteil am MSO ist es, den zeitlichen Zusammenhang zwischen digitalen und analogen Signalen darstellen zu können. Patrick
Patrick schrieb: > Ich weiß ja nicht was für ein FPGA im Einsatz ist, > aber bei halbwegs aktuellen FPGA gibt es interne Taktvervielfacher bzw. > PLLs. D.h. intern kann der auch mit 20 bis 150 MHz oder so arbeiten. das ist ein Uralt-Teil XC2064-50PC68C. > Wenn auch noch analoge Signale eine Rolle spielen, wäre ein MSO das > geeignetere Instrument. Leider gehen die Geräte mit 4 Analog + 16 > Digitalkanälen momentan bei 750€ los: > http://www.batronix.com/versand/oszilloskope/Rigol-MSO1074Z.html ja. Das ist dann schon etwas teuer wenn man das Gerät sonst eher selten braucht. Bis 12 Mpts Speichertiefe steht da. 16 Kanäle sind nicht viel wenn das FPGA 64 Beine hat und es noch externe Schieberegister gibt. > Der Vorteil am MSO ist es, den zeitlichen Zusammenhang zwischen > digitalen und analogen Signalen darstellen zu können. ja. Danke für den Hinweis Patrick.
Matthias W. schrieb: > Das FPGA scheint von der externen CPU programmiert zu werden. Wenn dem so ist, ist davon auszugehen, das sowohl die intakte als auch die defekte FPGA-Karte die gleichen Konfiguratinsdaten für das FPGA bekommt. Mangels jedweder Messgeräte böte ich ein simpler Test mit einem DMM an: Miß mal den (ohmschen)Widerstand sämtlicher Pins (vor allem der I/Os) der beiden FPGAs sowohl gegen GND und Vcc. Möglicherweise hat es einen oder mehrere I/Os des FPGAs der defekten Platine getroffen. Du hast ja das Glück, eine defekte und eine funktionsfähige Platine zu besitzen. Aus Erfahrung gehen ICs meistens an ihrer Peripherie (I/Os) kaputt, selten aber in ihrem Inneren. Du könntest parallel dazu auch einen Z-Test(ähnlich dem Komponententester mancher Hameg-Scopes) der Anschlüsse beider FPGAs/Karten machen und vergleichen.
Myxo Matrose schrieb: > Wenn dem so ist, ist davon auszugehen, das sowohl die intakte als auch > die defekte FPGA-Karte die gleichen Konfiguratinsdaten für das FPGA > bekommt. das ist wohl anzunehmen. > Mangels jedweder Messgeräte böte ich ein simpler Test mit einem DMM an: > Miß mal den (ohmschen)Widerstand sämtlicher Pins (vor allem der I/Os) > der beiden FPGAs sowohl gegen GND und Vcc. Möglicherweise hat es einen > oder mehrere I/Os des FPGAs der defekten Platine getroffen. prima Idee. Mist wäre nur wenn dabei die heile Platine leidet. Zunächst ging die andere auch noch. Dann lötete ich 2 Drähte ab, die jemand drangebastelt hatte und wusch die Platinenrückseite mit Alkohol ab. Seitdem geht das Ding nicht mehr. > Du hast ja das Glück, eine defekte und eine funktionsfähige Platine zu > besitzen. Aus Erfahrung gehen ICs meistens an ihrer Peripherie (I/Os) > kaputt, selten aber in ihrem Inneren. ja. > Du könntest parallel dazu auch einen Z-Test(ähnlich dem > Komponententester mancher Hameg-Scopes) der Anschlüsse beider > FPGAs/Karten machen und vergleichen. Ich habe ein Hameg HM605 mit Komponententester. Der Strom dürfte recht hoch sein. Daher ist die Frage ob es nicht ungefährlicher ist das Ohmmeter zu nehmen mit dem "Low Volt"-Ohm-Messbereich. Schneller reagiert wohl das Keithley 197. Das hat einen höheren Mess-Strom. Ich bin da hin- und hergerissen.
Matthias W. schrieb: > Dann lötete ich 2 Drähte ab, die jemand > drangebastelt hatte und wusch die Platinenrückseite mit Alkohol ab. > Seitdem geht das Ding nicht mehr. Warum? Merke: Never change a running system! Nu' isses wohl zu spät...
Mit dem Komponententester wäre ich vorsichtig, das ist der Strom ggf. schon recht hoch. So etwas wie der 2 KOhm Bereich bei den normalen DMMs arbeitet üblicherweise mit 0.1 mA - mit einem festen 1 K Widerstand in Reihe als Schutz vor ggf. geladenen Kapazitäten sollte das reichen. Je nach Widerstand geht natürlich auch ein höherer Messbereich. Die analogen Signale wird man bei der Platine eher nicht untersuchen müssen - das sind nur Ausgänge, praktisch ohne Rückwirkung. Die alte Schaltung ist relativ langsam. Die Signale für weniger Pins (z.B. 8) könnte im Prinzip noch in Echtzeit über den USB gehen. In wie weit der der USB Logic-analyser das schafft wäre auch interessant. Notfalls wäre dafür ein 2. einfacher 8 Bit Typ dazu passend, der die Daten direkt rüber schickt. Mit 256 K Samples schafft man bei 25 MHz halt gerade einmal 10 ms. Das ist ggf. zu wenig um ein Bedienung von Hand zu sehen. Für ein Signal mit 400-500 ns Pulslänge sollte man schon mit etwa 3-5 MHz abtasten - das wären dann bis knapp 100 ms. So wie ich die Beschreibung verstehe, erfolgt die Protokollanalyse erst am PC - ändert also nichts an der Speichertiefe. Berücksichtigen muss man auch noch die Abgreifpins. Gute Kontakte sind da schon wichtig, damit man keinen Kurzschluss macht.
Ulrich H. schrieb: > Mit dem Komponententester wäre ich vorsichtig, das ist der Strom ggf. > schon recht hoch. So etwas wie der 2 KOhm Bereich bei den normalen DMMs > arbeitet üblicherweise mit 0.1 mA - mit einem festen 1 K Widerstand in > Reihe als Schutz vor ggf. geladenen Kapazitäten sollte das reichen. Je > nach Widerstand geht natürlich auch ein höherer Messbereich. ok. Das alte Conrad-DMM hat den niedrigsten Mess-Strom im Ohm-Bereich. Vielleicht sollte ich erst einmal das nehmen. > Die analogen Signale wird man bei der Platine eher nicht untersuchen > müssen - das sind nur Ausgänge, praktisch ohne Rückwirkung. ok. > Die alte Schaltung ist relativ langsam. Die Signale für weniger Pins > (z.B. 8) könnte im Prinzip noch in Echtzeit über den USB gehen. In wie > weit der der USB Logic-analyser das schafft wäre auch interessant. > Notfalls wäre dafür ein 2. einfacher 8 Bit Typ dazu passend, der die > Daten direkt rüber schickt. der Test dieser 8bit Teile bei Dave Jones war eher nicht so prickelnd. > Mit 256 K Samples schafft man bei 25 MHz halt gerade einmal 10 ms. Das > ist ggf. zu wenig um ein Bedienung von Hand zu sehen. Für ein Signal mit > 400-500 ns Pulslänge sollte man schon mit etwa 3-5 MHz abtasten - das > wären dann bis knapp 100 ms. So wie ich die Beschreibung verstehe, > erfolgt die Protokollanalyse erst am PC - ändert also nichts an der > Speichertiefe. ja. Da hast Du sicher recht. Das ist dann eher Spielzeug - ganz interessant - nur löst es womöglich die gestellte Aufgabe nicht. > Berücksichtigen muss man auch noch die Abgreifpins. Gute Kontakte sind > da schon wichtig, damit man keinen Kurzschluss macht. ja. Das ist ein ganz wichtiger Punkt. Bei dem Teil aus China oder auch Deutschland sind ja nur 4 clips dabei. Das reicht nicht. Auch bei dem Finnland-Teil sind nur wenige Clips. Die Kontaktierung müsste nun an den SMD-Teilen erfolgen. Das wird wohl schwer. An den SMD-Teilen ist es sicher noch schwerer bis hin zu unmöglich. Da kein Teststecker auf dem board ist - wie soll das brauchbar gehen? Ich denke ich schau erst mal was das Ohmmeter sagt. Das macht erst mal mehr Sinn als sich in dieses Abenteuer zu stürzen. Vielen Dank Ulrich, Patrick, Matrose und Oliver für die wertvollen Hinweise.
Patrick schrieb: > Ich hab mal den Menschen getroffen, der die sigrok-Unterstützung > programmiert hat. Das war ich. :) Zu dem LWLA1034 kann ich sagen, dass das Teil für den Preis echt super ist. Der (chinesische) Entwickler hat uns sogar erlaubt, die FPGA-Firmware mit sigrok auszuliefern. Hauptnachteil gegenüber professionellen Geräten dürfte sein, dass die Low/High-Schwelle nicht einstellbar ist und man auch nichts außerhalb von 0 bis 5V anschließen sollte. Das Teil funktioniert aber problemlos für sowohl 3,3V als auch 5V-Ausgänge. Was das Aufnehmen von langsamen Signalen angeht: Der LWLA1034 benutzt eine Form von RLE-Komprimierung. D.h. es ist möglich, sehr lange Aufnahmen von sich nur selten ändernden Signalen zu machen und dabei trotzdem gute Zeitauflösung zu bekommen. Aber selbst für sich schnell ändernde Signal hat das Teil deutlich mehr Speicher als der um einiges teurere Intronix. Übrigens ist die Speichertiefe 256k x 36 bit, d.h. der LWLA1034 kann 256k Samples von allen Kanälen intern speichern. (Die Kompressionsmethode nutzt die zwei zusätzlichen Bits so, dass mindestens 256k Samples selbst im Worst case garantiert sind.) Streaming ist allerdings nicht möglich; man ist also stets auf diesen Puffer beschränkt. Für meine Anwendungen hat das jedoch immer ausgereicht.
Ich bin mit dem Billigteil sehr zufrieden. Hier hab ich mal ein kurzes Review geschrieben: http://www.wolfgangrobel.de/electronics/lwla1034.htm
> Dann lötete ich 2 Drähte ab, die jemand drangebastelt hatte
Dann löte sie wieder ran!
Hallo, hat hier jemand den LA mit sigrok/puleview unter Linux am laufen? Bei mir wird das Gerät erkannt, Bitstream wird ins FPGA geladen aber danach geht nix mehr. Das passiert wenn ich in Pulseview auf "Run" klicke:
1 | sr: session: Starting. |
2 | sr: sysclk-lwla: Device not ready (status 10001). |
3 | sr: session: Failed to commit device settings before starting acquisition (generic/unspecified error) |
Und so sieht es aus wenn ich mit dem sigrok-cli was aufnehmen möchte:
1 | $ sudo sigrok-cli -l 5 --driver sysclk-lwla --config samplerate=1m --samples 64 |
2 | sr: libsigrok loglevel set to 5. |
3 | sr: backend: Sanity-checking all drivers. |
4 | sr: backend: Sanity-checking all input modules. |
5 | sr: backend: Sanity-checking all output modules. |
6 | srd: libsigrokdecode loglevel set to 5. |
7 | sr: hwdriver: Initializing driver 'sysclk-lwla'. |
8 | sr: usb: Trying to find USB device with VID:PID = 2961:6689. |
9 | sr: usb: Found USB device (VID:PID = 2961:6689, bus.address = 3.6). |
10 | sr: usb: Found 1 device(s). |
11 | sr: hwdriver: Scan of 'sysclk-lwla' found 1 devices. |
12 | sr: usb: Trying to open USB device 3.6. |
13 | sr: usb: Opened USB device (VID:PID = 2961:6689, bus.address = 3.6). |
14 | sr: sysclk-lwla: Downloading FPGA bitstream at '/usr/share/sigrok-firmware/sysclk-lwla1034-int.rbf'. |
15 | sr: sysclk-lwla: FPGA bitstream download of 81464 bytes done. |
16 | sr: sysclk-lwla: Received test word 0x12345678 back. |
17 | sr: sysclk-lwla: Received test word 0x12345678 back. |
18 | sr: sysclk-lwla: Received test word 0x12345678 back. |
19 | Failed to open device. |
Hi, Gustl Buheitel schrieb: > Hallo, hat hier jemand den LA mit sigrok/puleview unter Linux am laufen? bei mir läuft der LWLA1034 wunderbar unter Linux. Zu möglichen Problemen habe ich Dir in Deinem anderen Thread geantwortet.
Hallo, ich hänge mich hier mal an, da mein heute eingetroffener LWLA1034 nicht funktioniert. Das Gerät ist per USB 2.0 angebunden, das verwendete USB-Kabel stammt von meinem Drucker und ist definitiv in Ordnung. Sobald das Kabel verbunden ist leuchten die LEDs "Power" und "Status" durchgängig rot und die LED "USB" durchgängig grün. Sigrock und Pulseview (Nightly) sind installiert, WinUSB-Treiber ist ebenfalls installiert. Starte ich nun Pulseview so erhalte ich die Fehlermeldung "generic/unspecified error - Failed to Select Device". Das Gerät scheint allerdings vorhanden zu sein, da es sich mit dem Sigrok-Client finden lässt:
1 | sigrok-cli.exe --scan |
2 | |
3 | sysclk-lwla - SysClk LWLA1034 with 34 channels: CH1 CH2 CH3 CH4 CH5 CH6 |
4 | CH7 CH8 CH9 CH10 CH11 CH12 CH13 CH14 CH15 CH16 CH17 CH18 CH19 CH20 CH21 |
5 | CH22 CH23 CH24 CH25 CH26 CH27 CH28 CH29 CH30 CH31 CH32 CH33 CH34 |
Versuche ich das Gerät per Client zu konfigurieren erhalte ich folgende Ausgabe:
1 | C:\Program Files (x86)\sigrok\sigrok-cli>sigrok-cli.exe -d sysclk-lwla -l 5 --config samplerate=1k --samples 64 |
2 | sr: [00:00.000000] log: libsigrok loglevel set to 5. |
3 | sr: [00:00.000000] backend: libsigrok 0.4.0-git-eb2373f/2:0:0 (rt: 0.4.0-git-eb2373f/2:0:0). |
4 | sr: [00:00.000000] backend: Libs: glib 2.42.1 (rt: 2.42.1/4201:1), libzip 0.11.2, libserialport 0.1.1/0:0:0 (rt: 0.1.1/0:0:0), libusb-1.0 1.0.20.11003-rc3, libftdi 1.2. |
5 | sr: [00:00.000000] backend: Host: i686-w64-mingw32.static, little-endian. |
6 | sr: [00:00.000000] backend: SCPI backends: TCP, serial, USBTMC. |
7 | sr: [00:00.000000] backend: Sanity-checking all drivers. |
8 | sr: [00:00.010000] backend: Sanity-checking all input modules. |
9 | sr: [00:00.010000] backend: Sanity-checking all output modules. |
10 | sr: [00:00.010000] backend: Sanity-checking all transform modules. |
11 | srd: libsigrokdecode loglevel set to 5. |
12 | sr: [00:00.010000] hwdriver: Initializing driver 'sysclk-lwla'. |
13 | sr: [00:00.010000] usb: Trying to find USB device with VID:PID = 2961:6689. |
14 | sr: [00:00.040000] usb: Found USB device (VID:PID = 2961:6689, bus.address = 2.2). |
15 | sr: [00:00.040000] usb: Found 1 device(s). |
16 | sr: [00:00.040000] hwdriver: Scan of 'sysclk-lwla' found 1 devices. |
17 | sr: [00:00.040000] usb: Trying to open USB device 2.2. |
18 | sr: [00:00.080000] usb: Opened USB device (VID:PID = 2961:6689, bus.address = 2.2). |
19 | sr: [00:00.080000] sysclk-lwla: Downloading FPGA bitstream at 'firmware\sysclk-lwla1034-int.rbf'. |
20 | sr: [00:00.080000] sysclk-lwla: Refusing to load bitstream of unreasonable size (6194860048061668044 bytes). |
21 | Failed to open device. |
Irgendetwas scheint beim Laden der Firmware schief zu gehen, allerdings ist diese in Wirklichkeit nur knapp 80 Kilobyte groß und ganz sicher keine 5,3 Exabyte. Nutze ich das mit dem Analyzer mitgelieferte Tool so erhalte ich dort die Meldung "HW Not Detected". Hat irgendjemand schon einmal ein ähnliches Problem gehabt und hat eine Lösung für mich? Aktuell sieht es für mich (noch) nicht 100%ig so aus als wäre der Analyzer defekt. Viele Grüße Daniel
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.