Hi,
ich hab ganz versäumt das sigrok Projekt hier mal "offiziell"
vorzustellen:
Das ist eine Open-Source (GPL), platformübergreifende Software-Suite
(Linux, Mac OS X, FreeBSD, Windows, u.a. geplant) für verschiedenste
Logic Analyzer.
http://sigrok.org
Das Projekt ist im Moment wie folgt aufgebaut:
*libsigrok*: C shared library die die allgemeine Infrastruktur und
modulare "Treiber" für Logic Analyzer Hardware bereitstellt, sowie
modularen Support für Input/Output Dateiformate.
Derzeit unterstützte Hardware:
demo Demo driver, pattern generator
ols Openbench Logic Sniffer
zeroplus-logic-cube Zeroplus Logic Cube LAP-C series
asix-sigma ASIX SIGMA
chronovu-la8 ChronoVu LA8
fx2lafw fx2lafw (FX2 LAs)
fx2lafw ist eine Open-Source Firmware für Cypress FX2 Geräte, u.a.
Saleae Logic, USBee SX, uvm.
http://sigrok.org/wiki/Fx2lafw
Support für viele weitere Logic Analyzer ist schon auf der TODO-Liste,
u.a. RockyLogic Ant8/Ant18e, Ikalogic SCANALOGIC-2 PRO, MiniLA Mockup,
Acute PKLA-1216, Saleae Logic16, PoLabs PoScope Basic2, uvm:
http://sigrok.org/wiki/Supported_hardware
Derzeit unterstützte Dateiformate:
sigrok session Default-Format das alle Metadaten enthält
bits Bits
hex Hexadecimal
ascii ASCII
binary Raw binary
vcd Value Change Dump (VCD)
ols OpenBench Logic Sniffer
gnuplot Gnuplot
chronovu-la8 ChronoVu LA8
csv Comma-separated values (CSV)
*libsigrokdecode*: C shared library für Protocol Decoder Support. Die
einzelnen Protocol Decoder sind in Python (>= 3) geschrieben.
Derzeit unterstützte Decoder:
dcf77 DCF77 time protocol
lpc Low-Pin-Count
mx25lxx05d Macronix MX25Lxx05D
jtag_stm32 Joint Test Action Group / ST STM32
i2s Integrated Interchip Sound
spi Serial Peripheral Interface
edid Extended display identification data
pan1321 Panasonic PAN1321
mlx90614 Melexis MLX90614
jtag Joint Test Action Group
rtc8564 Epson RTC-8564 JE/NB
transitioncounter Pin transition counter
usb Universal Serial Bus
i2cdemux I2C demultiplexer
i2c Inter-Integrated Circuit
i2cfilter I2C filter
mxc6225xu MEMSIC MXC6225XU
uart Universal Asynchronous Receiver/Transmitter
Ein wichtiges Ziel war es hier das Schreiben/Verstehen von Decodern
möglichst einfach und intuitiv zu machen, daher Python (auch wenn das
ein wenig auf Kosten der Performance geht). Ich rechne fest damit, dass
wir innerhalb kürzester Zeit 10-20 weitere Decoder haben werden, sowohl
von uns geschrieben, als auch von anderen Leuten beigesteuerte (hint,
hint).
*sigrok-cli*: Kommandozeilentool, das die beiden Libs benutzt.
Beispielaufrufe:
Eine Millisekunde mit 1MHz sampeln und in Datei schreiben:
$ sigrok-cli -d chronovu-la8:samplerate=1mhz --time 1ms -o test.sr
JTAG Protocol Decoder über eine Datei drüber laufen lassen:
$ sigrok-cli -i test.sr -a jtag:tdi=5:tms=2:tck=3:tdo=7
[...]
jtag: "New state: EXIT1-IR"
jtag: "IR TDI: 11111110, 8 bits"
jtag: "IR TDO: 11110001, 8 bits"
jtag: "New state: UPDATE-IR"
jtag: "New state: RUN-TEST/IDLE"
jtag: "New state: SELECT-DR-SCAN"
jtag: "New state: CAPTURE-DR"
jtag: "New state: SHIFT-DR"
[...]
usw. usw.
Derzeit sind noch zwei GUIs in Arbeit (aber noch nicht gut benutzbar,
eher Alpha-Software): sigrok-gtk und sigrok-qt (GTK+ und Qt basiert),
die jeweils auf libsigrok + libsigrokdecode basieren.
Windows Support ist im Moment leider noch nicht brauchbar, wir sind aber
dran diverse libusb- und Portabilitätsfixes zu implementieren. Installer
EXE-Dateien stehen schon.
Die nächste große Baustelle wird auch Support für Analog-Daten sein,
d.h. Support für Oszis, Multimeter, usw. Dafür brauchts dann auch wieder
nochmal aufwändigen GUI-Support, das kann also noch ein wenig dauern.
Wir sind natürlich immer an Patches interessiert, egal ob Support für
neue Hardware, Bugfixes, neue Protocol Decoder usw... Der Code ist in
Git, es gibt eine Mailingliste und einen IRC-Channel (#sigrok auf
Freenode).
Uwe.
Hallo Uwe,
ich hatte mir damals die Software angesehen, sind inzwischen fast Jahre
vergangen. Damals war sie viel zu langsam, der Protokoll Dekoder kam mit
den 50/100 Mbytes/sec an Daten nicht zurecht. Wie ist es derzeit.
Mein Test war 10Mbit rs485, IRDA, 25Mhz SPI und 2Mbit Glasfaser
(Manchester)
dekodierung, eigentlich alles nicht soo schnell, nur realtime ging es
nicht.
Daten waren mit 100Mbyte/s eingelesen, komprimiert und über usb
übertragen.
Hi,
Chris schrieb:> Hallo Uwe,> ich hatte mir damals die Software angesehen, sind inzwischen fast Jahre> vergangen. Damals war sie viel zu langsam, der Protokoll Dekoder kam mit> den 50/100 Mbytes/sec an Daten nicht zurecht.
Welche Hardware hast du benutzt und welchen Decoder? Soo alt sind die
nun auch wieder nicht, kann noch nicht so lang her sein :) Das, was vor
einigen Monaten noch drin war, war nur Testcode und nicht wirklich zu
gebrauchen.
Prinzipiell ist realtime im Moment eher schwierig ja. Die Logic Analyzer
die durchgehend streamen können (im Großen und Ganzen die FX2-basierten
im Moment) haben generell das Problem, dass sie bei allerspätestens
24MHz Samplerate aussteigen, meist eher sehr sehr viel früher, je nach
sonstigem USB-Traffic im System. Das werden wir noch etwas verbessern
indem wir das Sampeln in einem anderen Thread machen als das Speichern
und Dekodieren, das Grundproblem bleibt aber.
Man kann im Moment in der Therie schon auch "live" sampeln und
dekodieren, nur geht die Performance bei höheren Sampleraten schnell in
die Knie und man kommt nicht hinterher.
Als Ausweichlösung kann man natürlich immer in eine Datei speichern, und
später aus der Datei dekodieren.
> Wie ist es derzeit.> Mein Test war 10Mbit rs485, IRDA, 25Mhz SPI und 2Mbit Glasfaser> (Manchester)> dekodierung, eigentlich alles nicht soo schnell, nur realtime ging es> nicht.> Daten waren mit 100Mbyte/s eingelesen, komprimiert und über usb> übertragen.
Kannst du von den oben genannten Sachen Dumps im .sr Format machen für
unser Repo (Lizenz "Public Domain" falls du nichts anderes bevorzugst)?
Wir sammeln ein paar Test-Dumps für jedes Protokoll zu Debug- und
Test-Zwecken beim Dekoder-Entwickeln. Das wäre super!
Beispiele hier:
http://sigrok.git.sourceforge.net/git/gitweb.cgi?p=sigrok/sigrok-dumps;a=tree
Falls möglich bitte mit Doku was wo wie angeschlossen war, welcher Logic
Analyzer benutzt wurde, welches Protokoll / welche Hardware gedumpt
wurde usw.
Danke, Uwe.
Benutzt wurde Xtag-2 (Xmos) mit LA-SW , kann bis 50Mhz extern
syncronisiert
werden und 100Mhz im free running mode, welche dann komprimiert und mit
ca
50Mbyte/sek über USB hochgeschickt werden, 12Leitungen. Abgesehen von
der Glasfaser müsste ich noch ein paar logs haben. Die HW ist
konkurrenzlos
günstig.
Uwe Bonnes schrieb:> Getriggertes samplen geht wohl noch nicht. Irgendetwas in der Mache?
Sollte an sich schon gehen, hängt aber etwas vom Hardware-Treiber ab:
Beispiel von ASIX Sigma (soweit ich weiss):
To capture data from 4 probes lasting 100ms at 10 MHz starting at the
trigger condition 1:high, 2:rising, 3:low, 4:high, use:
sigrok-cli -d 0:samplerate=10m -p 1-4 --time 100 \
--wait-trigger --triggers 1=1,2=r,3=0,4=1
Chris schrieb:> Benutzt wurde Xtag-2 (Xmos) mit LA-SW , kann bis 50Mhz extern> syncronisiert> werden und 100Mhz im free running mode, welche dann komprimiert und mit> ca> 50Mbyte/sek über USB hochgeschickt werden, 12Leitungen.
Hm, jetzt bin ich etwas verwirrt. Hast du einen Link zu der Software? Du
hast also nicht mit sigrok gesampelt, oder habe ich das falsch
verstanden?
Sehe ich das richtig, du has diese Hardware hier als Logic Analyzer
benutzt?
http://www.xmos.com/products/development-kits/xtag-2-debug-adapter
Wenn ja, mit spezieller Firmware? Woher? Gibts da ein Projekt bzw. eine
URL?
> Abgesehen von> der Glasfaser müsste ich noch ein paar logs haben. Die HW ist> konkurrenzlos günstig.
In der Tat. Und diese Logs waren mit sigrok erstellt oder anderer
Software? Falls letzteres, welches Format?
Danke, Uwe.
> Sehe ich das richtig, du has diese Hardware hier als Logic Analyzer> benutzt?>> http://www.xmos.com/products/development-kits/xtag...>
Genau.
> Wenn ja, mit spezieller Firmware? Woher? Gibts da ein Projekt bzw. eine> URL?
Gab es, Domain und websites sind inzwischen zweimal umgemodelt worden,
(Xmos) und dann habe ich das Projekt nicht mehr publiziert, weil ich
http://www.kickstarter.com/projects/bushing/openvizsla-open-source-usb-protocol-analyzer/posts
gefunden habe, welche damals bereits schon
das Geld eingesammelt hatten und ich nicht meine Arbeit denen zur
Verfügung stellen wollte. Hatte ich kurz zuvor entdeckt als ich es
posten wollte.
>>>> Abgesehen von>> der Glasfaser müsste ich noch ein paar logs haben. Die HW ist>> konkurrenzlos günstig.>> In der Tat. Und diese Logs waren mit sigrok erstellt oder anderer> Software? Falls letzteres, welches Format?
Die waren mit sigrok erstellt, dem damaligen code, natürlich
modifiziert.
Da aber eigentlich nichts funktionierte, und das gleichzeitige
Abspeichern
und einlesen von USB bei 50Mbyte auch nicht ging, es funktionierte nur
mit
Ramdisk, wurde auch nichts committed. Warscheinlich würde es gehen, wenn
man die RLE Daten weiters mit libzip comprimieren würde, ansonsten
schafft es der PCI bus nicht.
>> Danke, Uwe.
Ps. Es lässt sich darüber reden, die Dinger mit modifizierter FW
(encrypted) zu verkaufen, um ein paar Euro mehr, 4 Bits gehen mit 200Mhz
problemlos, ausgetested wurde schon 600Mhz und 2 bits, ob das aber nur
Augenauswischerei ist, kann ich nicht beurteilen, würde dem der das
messen kann so ein Modul schenken.
Hi,
Chris schrieb:>>> Abgesehen von>>> der Glasfaser müsste ich noch ein paar logs haben. Die HW ist>>> konkurrenzlos günstig.>>>> In der Tat. Und diese Logs waren mit sigrok erstellt oder anderer>> Software? Falls letzteres, welches Format?> Die waren mit sigrok erstellt, dem damaligen code, natürlich> modifiziert.> Da aber eigentlich nichts funktionierte, und das gleichzeitige> Abspeichern> und einlesen von USB bei 50Mbyte auch nicht ging, es funktionierte nur> mit> Ramdisk, wurde auch nichts committed. Warscheinlich würde es gehen, wenn> man die RLE Daten weiters mit libzip comprimieren würde, ansonsten> schafft es der PCI bus nicht.
Hm, nochmal zum Verständnis, du hast das XTAG2 als General-Purpose Logic
Analyzer benutzt um externe Signale irgendwo abzugreifen? Oder ist das
so Chipscope-artig nur um XMOS-Interna zu sampeln?
Btw, sigrok benutzt inzwischen libzip intern um die Output files zu
packen (*.sr).
> Ps. Es lässt sich darüber reden, die Dinger mit modifizierter FW> (encrypted) zu verkaufen, um ein paar Euro mehr, 4 Bits gehen mit 200Mhz> problemlos, ausgetested wurde schon 600Mhz und 2 bits, ob das aber nur> Augenauswischerei ist, kann ich nicht beurteilen, würde dem der das> messen kann so ein Modul schenken.
Hast du da ein Produkt daraus gemacht und/oder würdest es machen, oder
wie ist das gemeint? Ich hab nach einigem Suchen, weil mir das alles
irgendwie bekannt vorkam, noch das hier gefunden, das hat Henk Muller
(scheinbar XMOS-Mitarbeiter) vor einiger Zeit angefangen, ich dachte
erst es geht um dieses Projekt, scheint ja aber nicht der Fall zu sein,
oder?
https://github.com/xcore/sw_logic_analyzerhttp://news.gmane.org/gmane.comp.debugging.sigrok.devel
Ich weiss auch nicht was der Stand davon ist, ob es überhaupt läuft usw.
Anyway, wir sind natürlich sehr daran interessiert sigrok Support für
diese Hardware zu haben, falls irgend möglich. Ganz besonders dann wenn
es als General-Purpose LA eingesetzt werden kann.
Uwe.
MikroControllerProgrammierer schrieb:> Eignet sich das auch für den hiesigen LA - > siehe LA ARtikel.> ?
Welchen genau meinst du? Link? Falls "MiniLA Mockup" dann ja, ich habe
so einen daheim und plane dafür einen sigrok Treiber zu machen, weiss
allerdings nicht wann ich dazu kommen werde.
Uwe.
Hallo Uwe,
wird der Beitrag "10 Euro Logikanalyzer" (von
Dealextreme/ dx) auch von sigrok unterstützt?
Er ähnelt optisch diesem hier: http://sigrok.org/wiki/ARMFLY_Mini-Logic
Die Beschriftung lautet angeblich (ich habe noch keinen) "USBEE AX PRO".
Kann man sigrok schon einfach unter Windows nutzen?
Danke,
Thomas
IThomas Sch. schrieb:> Hallo Uwe,>> wird der Beitrag "10 Euro Logikanalyzer" (von> Dealextreme/ dx) auch von sigrok unterstützt?> Er ähnelt optisch diesem hier: http://sigrok.org/wiki/ARMFLY_Mini-Logic> Die Beschriftung lautet angeblich (ich habe noch keinen) "USBEE AX PRO".>> Kann man sigrok schon einfach unter Windows nutzen?>> Danke,> Thomas
Bitte um Antwort bezueglich Windows
Bräuchte das ganze unter Win mit dem usbee clone
lukas schrieb:> IThomas Sch. schrieb:>> Hallo Uwe,>>>> wird der Beitrag "10 Euro Logikanalyzer" (von>> Dealextreme/ dx) auch von sigrok unterstützt?>> Er ähnelt optisch diesem hier: http://sigrok.org/wiki/ARMFLY_Mini-Logic>> Die Beschriftung lautet angeblich (ich habe noch keinen) "USBEE AX PRO".>>>> Kann man sigrok schon einfach unter Windows nutzen?>>>> Danke,>> Thomas>> Bitte um Antwort bezueglich Windows>> Bräuchte das ganze unter Win mit dem usbee clone
Windows Unterstützung ist definitiv geplant, aber im Moment noch nicht
so richtig brauchbar. Wir arbeiten aber dran.
Alle Libraries und Applikationen die zu sigrok gehören sind prinzipiell
portabel ausgelegt, es kompiliert jetzt schon alles ganz gut unter
Linux, Mac OS, Windows, FreeBSD, usw., auch auf x86, ARM, SPARC, PowerPC
etc. etc.
Ich habe schon NSIS Installer für das Kommandozeilentool (sigrok-cli)
und alle derzeitigen GUIs (sigrok-qt, sigrok-gtk, PulseView)
vorbereitet, d.h. es wird später z.B. eine simple
pulseview-installer.exe geben wo alles mit dabei ist was man braucht,
das ist soweit kein Problem.
Für Windows gibt es aber derzeit noch diverse offene Baustellen, so dass
es z.Zt. noch keinen Sinn macht einen Installer zum Download anzubieten.
Sobald ein einigermaßen brauchbarer Stand erreicht ist, wird es
Installer geben. Bis dahin sind Linux, FreeBSD, oder Mac OS X aber
erstmal die bessere Wahl.
Uwe.
Hallo,
das Projekt hört sich ja ganz interessant an. Beim "Blättern" über die
Homepage habe ich aber (zumindest auf die Schnelle) keine HowTo o.ä.
gefunden. Im Eröffnungsthread wird ja der Konsolenmodus als Beispiel
gezeigt und 2 GUI angedeutet.
Wie aber arbeitet man mit der Software in der Praxis? Gibt es da
irgendwelche Doku/Beispiele/Demos, wie man die erzeugte Logdatei dann
mit einem Decoder weiterverarbeitet?
Hi,
Ein wirklich sehr interessantes Projekt. Genauso wie Bär_Tram würde auch
mich der geplante Praxiseinsatz interessieren. Ich denke, dass die GUI
sehr entscheidend für den Projekterfolg sein wird.
Weiterhin würde mich interessieren, vorallem im Bezug GUI, ob ein
Bedienpanel (gerne auch Open-Source) ala
http://www.etc.sk/index.php/en/products/auxiliary-equipment/control-panels/item/136-control-panel-for-usb-oscilloscopes.html
unterstützt werden wird?
Können später mehrere Geräte wie ein Hantek DSO-2090 angeschlossen
werden um mehr als nur 2 Kanäle zu messen?
Grüßle
Andreas
Uwe Hermann schrieb:> Windows Unterstützung ist definitiv geplant, aber im Moment noch nicht> so richtig brauchbar. Wir arbeiten aber dran.
Ich weiss, dass man diese Frage eigentlich nicht stellt (ich selbst
antworte immer mit "2 Wochen" ;) ). Aber gibt es einen ungefähren
Zeitplan?
Hallo,
ich habe eine Frage zu sigrok-cli. Ich habe es dann trotz meiner
geringen Linux-Kenntnisse geschafft alles zu installieren (auf Xubuntu
12.04) und nachdem ich dem Account auch root-Rechte hinzugefügt hatte
wurde auch mein USBee Clone erfolgreich erkannt (firmware hochgeladen).
Ich bekomme nun folgende Liste:
1
xxx@xxx:~$ sigrok-cli -D
2
sr: alsa: Cannot get device info (hw:0,4): No such file or directory.
3
The following devices were found:
4
Demo device with 8 probes: 0 1 2 3 4 5 6 7
5
ALSA: Intel 82801DB-ICH4 Intel 82801DB-ICH4 with 2 probes: Ch_0 Ch_1
6
ALSA: Intel 82801DB-ICH4 Intel 82801DB-ICH4 - MIC ADC with 2 probes: Ch_0 Ch_1
pulseview erkennt auch den USBee, aber ich schaffe es nicht den USBee
von sigrok-cli aus anzusprechen. Was muß ich nach dem Parameter -d
angeben damit ich die Daten lesen kann?
Die Fehlermeldung "sr: alsa: Cannot get device info" kann ich auch nicht
deuten.
Gruß
Volkmar
Hallo Volkmar,
das Problem hat mich auch ein wenig Zeit gekostet, bis ich es verstanden
hatte. Verwende einfach den Parameter "--driver", dann sollte alles
klappen.
Beispiel:
Da du nur ein einziges fx2lafw-Gerät hast, ist bei "-d" keine Angabe der
Device-ID nötig. Ganz auf "-d" verzichten kannst du aber nicht, da du
damit ja die Samplerate einstellst.
Ansonsten häng nochmal "-l 5" mit dran, dann werden die Fehlermeldungen
ein wenig ausführlicher.
Die Parameter sind in der man-Page ganz gut erklärt.
Gibt es irgendwo auch eine "einfache" Anleitung für sigrok? Ich
scheitere schon damit herauszufinden warum es zig GUIs gibt und welches
ich brauche :D
Wie es scheint sind leider bei Ubuntu nur die lib und das cli dabei, und
ich hatte eigentlich gehofft den Compiler nicht anwerfen zu müssen.
Hallo Johannes,
Johannes R. schrieb:> das Problem hat mich auch ein wenig Zeit gekostet, bis ich es verstanden> hatte. Verwende einfach den Parameter "--driver", dann sollte alles> klappen.
Danke für Deine Erklärungen, die haben mir wirklich geholfen. Nun klappt
es und auch die Angabe der Port-Pins und Trigger funktioniert.
Wunderbar!
Johannes R. schrieb:> Da du nur ein einziges fx2lafw-Gerät hast, ist bei "-d" keine Angabe der> Device-ID nötig.
Und wie gebe ich es an, wenn ich 2 von den Dingern hätte?
min schrieb:> Alsa sind die Linux-Soundtreiber (für Soundkartenoszi o.ä). In pulseview> müssten dann das: "CWAV USBee AX" anwählbar sein.
Das mit den Soundtreibern hatte ich schon vermutet, Danke für die
Bestätigung. Pulseview läuft, Danke. Aber da ich dort keine
Protokolldecoder angeben kann, wollte ich es zunächst mit sigrok-cli
versuchen.
Gruß
Volkmar
Die Decoderliste wächst ja erfreulich. Ist es auch mal angedacht, neben
der reinen Decodierung auch einen Interpreter dazuzubringen? So daß z.B.
in pulseview der interpretierte Wert (z.B. "SOF" usw.) über der Kurve
angezeigt wird?
Interessierter schrieb:> Die Decoderliste wächst ja erfreulich. Ist es auch mal angedacht, neben> der reinen Decodierung auch einen Interpreter dazuzubringen? So daß z.B.> in pulseview der interpretierte Wert (z.B. "SOF" usw.) über der Kurve> angezeigt wird?
Ja, natürlich, die Anzeige der dekodierten "Pakete"/Daten soll auf jeden
Fall in den GUIs auftauchen, ist auch derzeit in Arbeit. Bis es soweit
ist, bleibt aber das Kommandozeilentool sigrok-cli die einzige
Möglichkeit die dekodierten Daten auszugeben bzw. in Dateien zu
speichern und evtl. weiterzuverarbeiten.
Uwe.
Ich habe momentan ein seltsames Problem:
In Pulseview kann ich problemlos beliebig viele Samples mit ein
Samplerate von bis zu 12MHz aufnehmen und ansehen.
Da man dort aber bisher nicht Speichern kann, habe ich sigrok-cli
folgendermaßen aufgerufen:
> sigrok-cli --driver fx2lafw -d samplerate=1m -o testsampling.csv -O csv -p> 0=PIN1_G,1=PIN2,2=PIN3_V,3=PIN4,4=PIN5,5=PIN6,6=PIN7,7=PIN8,8=PIN9 --time> 1000
Offensichtlich verschluckt sich Sigrok aber hier an der Datenmenge, denn
ich bekomme immer die Meldung
> Device only sent 235520 samples. (Die Zahl ändert sich dabei)
Irgendwo muss es also einen Unterschied zwischen dem Aufruf von
sigrok-cli und pulseview geben, obwohl doch pulseview eigentlich nur
sigrok-cli aufruft, wenn ich das korrekt verstanden habe?
dfgh schrieb:> Ich habe momentan ein seltsames Problem:>> In Pulseview kann ich problemlos beliebig viele Samples mit ein> Samplerate von bis zu 12MHz aufnehmen und ansehen.>> Da man dort aber bisher nicht Speichern kann, habe ich sigrok-cli> folgendermaßen aufgerufen:>>> sigrok-cli --driver fx2lafw -d samplerate=1m -o testsampling.csv -O csv -p>> 0=PIN1_G,1=PIN2,2=PIN3_V,3=PIN4,4=PIN5,5=PIN6,6=PIN7,7=PIN8,8=PIN9 --time>> 1000>> Offensichtlich verschluckt sich Sigrok aber hier an der Datenmenge, denn> ich bekomme immer die Meldung>>> Device only sent 235520 samples. (Die Zahl ändert sich dabei)>> Irgendwo muss es also einen Unterschied zwischen dem Aufruf von> sigrok-cli und pulseview geben, obwohl doch pulseview eigentlich nur> sigrok-cli aufruft, wenn ich das korrekt verstanden habe?
Nein, Pulseview ist eine GUI die libsigrok benutzt, sigrok-cli ist ein
Kommandozeilentool das ebenfalls libsigrok benutzt. PulseView ruft aber
nicht sigrok-cli auf.
Die "only sent 235520 samples" Meldungen sind das inherente Problem bei
FX2-basierten Logic Analyzern, je nach Samplerate (je höher desto
schlimmer), CPU-Auslastung, USB-Bus Auslastung und sonstigen Umständen
können Samples verloren gehen.
In diesem Fall liegt der Unterschied im CSV Export denke ich, das ganze
Stringmanipulieren dauert relativ lange bei großen Datenmengen, daher
steigt er irgendwann aus. Da gibts sicherlich Optimierungspotenzial
sowohl im CSV-Exporter als auch in libsigrok generell, um weniger oft
Samples zu verlieren.
Als Workaround für den Moment kannst du aber wie üblich ins "normale"
.sr Format speichern (statt CSV), das geht am besten/schnellsten, und
alles weitere dann später "offline" machen (z.B. nach CSV exportieren,
Protokoll Decoder laufen lassen, etc).
$ sigrok-cli --driver fx2lafw -d samplerate=1m -o testsampling.sr -p
0=PIN1_G,1=PIN2,2=PIN3_V,3=PIN4,4=PIN5,5=PIN6,6=PIN7,7=PIN8,8=PIN9
--time 1000
Uwe.
Hallo!
Nachdem ich alle git-repositorys geclont habe und mein Ubuntu 12.04.2
LTS auch alles compilieren und installieren konnte, wollte ich mit
meinem USBee AX PRO-Clone ein paar Samples aufnehmen:
1
$ lsusb
2
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
3
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
4
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
5
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
6
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Ich bekomme 0 Samples :-(
In Worten: null
Im Anhang gibt es noch den ausführlichen Output (-l 5).
Vielleicht kann mir ja jemand weiterhelfen.
Viele Grüße
Franz
hi,
Franz schrieb:> Hallo!>> Nachdem ich alle git-repositorys geclont habe und mein Ubuntu 12.04.2> LTS auch alles compilieren und installieren konnte, wollte ich mit> meinem USBee AX PRO-Clone ein paar Samples aufnehmen:>
1
> $ lsusb
2
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
3
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
4
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
5
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
6
> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
7
> Bus 004 Device 013: ID 08a9:0014
8
>
> USB device ist da, wenn auch ohne Name.
Sieht soweit gut aus, der Name ist optional, das ist kein Bug oder so.
>
> Ich bekomme 0 Samples :-(> In Worten: *null*
Die Kommandozeilenoptionen von sigrok-cli haben sich etwas verändert, es
sollte etwa so aussehen im neuesten git:
sigrok-cli --driver fx2lafw --config samplerate=1m --samples 64
Der Debug-Output sieht trotzdem etwas seltsam aus. Probier mal ohne USB
Hub (falls einer dran ist), und probier definitiv ein "gutes" USB-Kabel,
das mitgelieferte war in vielen Fällen schon kompletter Müll und führt
zu allen möglichen seltsamen Effekten.
Ansonsten müssen noch die Permissions für das USB Device stimmen, also
z.B. als root ausführen oder die udev-Datei benutzen die libsigrok
mitliefert.
Ach ja, und die fx2lafw Firmware muss die neueste sein (0.1.1 oder git),
ältere Versionen haben die "Fake" FX2LP (die eigtl. ältere FX2 sind)
noch nicht unterstützt.
Uwe.
Hallo Uwe!
Uwe Hermann schrieb:> probier definitiv ein "gutes" USB-Kabel,> das mitgelieferte war in vielen Fällen schon kompletter Müll und führt> zu allen möglichen seltsamen Effekten.
Danke, das war der entscheidende Hinweis. Mit dem Kabel von der Digicam
klappt es einwandfrei.
Ich frage mich nur, was man an so einem Kabel eigentlich falsch machen
kann ?!? Selbst mit einem zusätzlichem Klappferrit funktioniert es
nicht.
Und vielen Dank für die nette Software (sigrok-cli). Sieht sehr
vielversprechend aus.
Viele Grüße
Franz
Ich habe mal wieder mit Sigrok/Pulseview gearbeitet (hat mir jetzt schon
einige Male gute Dienste geleistet), dabei sind mir ein paar Funktionen
eingefallen, die die Arbeit erleichtern könnten:
1. In Pulseview existiert File->Open, aber keine Option zum Speichern
der aufgezeichneten Daten. Selbstverständlich kann man so immerhin die
mit sigrok-cli erstellten Dateien öffnen, wenn man aber aus Pulseview
speichern könnte, müsste man nicht so oft zwischen GUI und Kommandozeile
wechseln.
2. Wenn ich den Initialisierungsvorgang eines Gerätes aufzeichnen
möchte, zappeln die Leitungen beim Einschalten des Gerätes natürlich
erst mal sinnlos rum, was je nach Protokoll für Verwirrung beim Dekoder
sorgt (im konkreten Fall SPI). Daher wäre es schön, wenn man beim
Dekodieren so etwas wie "Ignoriere die ersten 1573ms" angeben könnte.
3. In Pulseview könnte man zwischen Pegelwechseln/Datenpaketen klein den
Zeitabstand einblenden (siehe Bild). Alternativ wäre auch eine
Einrastfunktion für die Cursor an den Datenflanken denkbar (z.B.
Strg+Mausziehen). Am besten natürlich beides :-)
Wichtig für mich wäre vor allem der zweite Punkt...
Und dann habe ich noch einen kleinen Bug gefunden: Wenn man in Pulseview
über das rote "Probe"-Symbol einzelne Probes deaktiviert, werden diese
zwar ausgeblendet, reagieren aber noch auf Mausklicks. Wenn man nun ein
paar Probes ausgeblendet hat und den Rest der Signale an die
entsprechende Stelle schiebt, bekommt man bei einem Klick auf das
sichtbare Signal (z.B. zum Ändern der Farbe) die Einstellungen des
ausgeblendeten Signals angezeigt.
An dieser Stelle auch noch mal ein Kompliment: Pulseview ist mit der
neuen Möglichkeit, Dekoder komfortabel in der GUI hinzuzufügen und zu
konfigurieren nochmal ein massives Stück nützlicher geworden. Und die
Dekoderliste wächst ja auch erfreulich...
Es gibt ja mittlerweile Windows binaries "Pulseview" auf eurer Website,
da habe ich es mal mit meinem "Logic" ausprobiert.
Auf den ersten Blick erschließt sich übrigens nicht so recht, dass
Normaluser Pulseview will, sigrok die im Hintergrund werkelnde
Bilbliothek ist, und alle Treiber dabei sind (libusb und der Installer).
Ihr beschreibt es irgendwie andersherum, das hat mich etwas verwirrt und
ich habe angefangen, die zuerst genannten Abhängikeiten runterzuladen..
Es wäre schön, wenn die Info in About.. kopierbar wäre (v 0.2.0).
nightly installer von heute.
Klicke ich einen Kanal an, wird er sofort zum bearbeiten geöffnet. Gut,
wenn man das möchte, zum Löschen muss man dann aber den Bearbeitungsmode
mit esc beenden und dann per DEL löschen.
OK, dafür gibt es wohl das Probe Tool (aber weit weg oben in der
Toolbar).
Kann man die Einstellungen (Kanalnamen, Farben etc) auch ohne
aufgezeichnete Daten speichern?
Die erste Aufzeichnung nach Programmstart ohne Trigger geht (bis 9s von
berechneten 50 s Sample time), die zweite bricht bereits nach kurzer
Zeit (ca 250 ms) ab.
Es gibt dazu keine Fehlermeldung.
Ein Text zum Zustand (ready.. RUN -> running.. STOP -> ??, rot, grün,
grau) wäre eindeutig. Echte Ampel für "Farbenblinde".
Fit zoomt auf den Bereich 0..8 s (wohl von der letzten Aufzeichnung ohne
Abbruch), dabei sind Daten nur etwa 250 ms eingezeichnet.
Fit sollte ein bisschen padding lassen oder die Labels verschieben. So
sehe ich eine halbe Null, einen halben tick, und die Flanke wohl auch
nur halb.
Ah ja: RESOLVED WONTFIX (http://sigrok.org/bugzilla/show_bug.cgi?id=399)
Fazit: sieht vielversprechend gut aus, aber benutzen kann ich es mit dem
FX2-Treiber leider noch nicht richtig. Offenbar steckt die meiste Arbeit
im Backend und den vielen Gerätetreibern.
http://sigrok.org/bugzilla/describecomponents.cgi?product=PulseView
Kann man hier unabhängig von Kategorie nach Datum sortieren?
So:
http://sigrok.org/bugzilla/buglist.cgi?product=PulseView&query_format=advanced&order=changeddate%20DESC%2Cbug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_based_on=
dfgh schrieb:> 2. Wenn ich den Initialisierungsvorgang eines Gerätes aufzeichnen> möchte, zappeln die Leitungen beim Einschalten des Gerätes natürlich> erst mal sinnlos rum, was je nach Protokoll für Verwirrung beim Dekoder> sorgt (im konkreten Fall SPI). Daher wäre es schön, wenn man beim> Dekodieren so etwas wie "Ignoriere die ersten 1573ms" angeben könnte.
Wenn http://sigrok.org/bugzilla/show_bug.cgi?id=304 umgesetzt ist,
kannst du das damit komfortabel erschlagen.
> 3. In Pulseview könnte man zwischen Pegelwechseln/Datenpaketen klein den> Zeitabstand einblenden (siehe Bild). Alternativ wäre auch eine> Einrastfunktion für die Cursor an den Datenflanken denkbar (z.B.> Strg+Mausziehen). Am besten natürlich beides :-)
Ersteres kommt noch (ist mein Lieblingsfeature des Saleae-clients),
zweiteres auch, wobei es da an der internen Datenspeicherung hängt, also
nicht allzu bald kommen dürfte.
Info schrieb:> Auf den ersten Blick erschließt sich übrigens nicht so recht, dass> Normaluser Pulseview will, sigrok die im Hintergrund werkelnde> Bilbliothek ist, und alle Treiber dabei sind (libusb und der Installer).> Ihr beschreibt es irgendwie andersherum, das hat mich etwas verwirrt und> ich habe angefangen, die zuerst genannten Abhängikeiten runterzuladen..
Hmm, wo ist es denn andersherum beschrieben? Die nightly installer gibt
es in den Geschmacksrichtungen sigrok-cli und PulseView, da würde ich
erwarten, daß ein Benutzer eins davon runterlädt und einfach mal
probiert, ob es läuft.
> Es wäre schön, wenn die Info in About.. kopierbar wäre (v 0.2.0).
Unter Linux ist sie das, ist also Windows-spezifisch und du darfst gerne
einen bug aufmachen, wenn dir das wichtig ist.
> Klicke ich einen Kanal an, wird er sofort zum bearbeiten geöffnet. Gut,> wenn man das möchte, zum Löschen muss man dann aber den Bearbeitungsmode> mit esc beenden und dann per DEL löschen.
Mit der rechten Maustaste geht das direkt.
> Kann man die Einstellungen (Kanalnamen, Farben etc) auch ohne> aufgezeichnete Daten speichern?
Derzeit leider nicht.
> Die erste Aufzeichnung nach Programmstart ohne Trigger geht (bis 9s von> berechneten 50 s Sample time), die zweite bricht bereits nach kurzer> Zeit (ca 250 ms) ab.> Es gibt dazu keine Fehlermeldung.
Kann viele Gründe haben, bei FX2-basierten boards wie dem Logic
beispielsweise eine zu hohe Auslastung/Latenz auf dem USB-Bus.
Samplerate verringern hilft hier meist. Und ja, aus der GUI heraus
einsehbare logs fehlen noch. Unter Linux gibt es das kostenlos im
Terminal, daher ist die Motivation für das Feature aktuell nicht so
groß.
> Ein Text zum Zustand (ready.. RUN -> running.. STOP -> ??, rot, grün,> grau) wäre eindeutig. Echte Ampel für "Farbenblinde".
Hmm, verstehe ich gerade nicht. Der RUN-/STOP-button ist ja schon grau
bzw. grün. Meinst du, daß dir das rot fehlt?
> Fit zoomt auf den Bereich 0..8 s (wohl von der letzten Aufzeichnung ohne> Abbruch), dabei sind Daten nur etwa 250 ms eingezeichnet.
Kann ich nichts zu sagen, ggf. bug aufmachen, falls du es (bspw. mittels
abziehen des Logic während der Erfassung) reproduzieren kannst.
> Fit sollte ein bisschen padding lassen oder die Labels verschieben. So> sehe ich eine halbe Null, einen halben tick, und die Flanke wohl auch> nur halb.> Ah ja: RESOLVED WONTFIX (http://sigrok.org/bugzilla/show_bug.cgi?id=399)
Jo, das ist auch mir ein Dorn im Auge, wie du am bug report siehst.
Werde vermutlich einen patch machen und den zum absegnen vorlegen.
> Fazit: sieht vielversprechend gut aus, aber benutzen kann ich es mit dem> FX2-Treiber leider noch nicht richtig. Offenbar steckt die meiste Arbeit> im Backend und den vielen Gerätetreibern.
Jein, unter Linux läuft es richtig gut. Es liegt eher daran, daß Windows
leider nur stiefmütterlich behandelt wird, da alle Entwickler unter
Linux arbeiten und es außer Uwe eigentlich niemanden gibt, der sich der
Windows-Version annimmt. Patches, die die Windows-kompatibilität
verbessern, sind daher sehr willkommen!
Hi Uwe,
ich versuche gerade mal ein Signal welches ich im Rigol DS1052E als CSV
aufgenommen habe mit Pulseview unter Windows zu verarbeiten.
Im Moment klappt das leider gar nicht, auch nicht mit dem Demofile
"fancyblink.bin".
* Ich kann in Pulseview V 0.2.0 nur .sr-Files öffnen (eigentlich sollten
doch auch .bin gehen?)
* Die Konvertierung mit sigrok-cli (V 0.5.0) von .bin nach .sr ergibt
nur ein leeres File ("sigrok-cli.exe -i inputfile.bin -o output.sr")
Bei Loglevel 5 bekomme ich von sigrok-cli die Fehlermeldung
"sr: output/srzip: Error saving zipfile: Renaming temporary file failed:
Invalid argument."
Woran könnte das liegen?
Viele Grüße
Björn
Björn G. schrieb:> Im Moment klappt das leider gar nicht, auch nicht mit dem Demofile> "fancyblink.bin".
Moin Björn,
in sigrok-dumps/jtag/olimex_stm32-h103 liegt ein README, in dem
folgendes steht:
"The firmware flashed to the board is a simple LED-blinking libopencm3
example named 'fancyblink'. The respective fancyblink.bin file is
available as a reference in the same directory as this README."
Die dort ebenfalls liegenden .sr-Dateien sind daher vermutlich eher von
Interesse für dich :)
Was dein ursprüngliches Problem betrifft, so würde ich dich gerne nach
#sigrok auf freenode einladen, da ich diesen thread ungern mit
gerätespezifischer Fehlersuche belasten möchte.
Hi Soeren,
danke für deine schnelle Antwort.
Ich habe die "fancyblink" nur als Beispiel zum Ausprobieren genommen. Um
das gerätespezifische geht's mir hier gar nicht.
Mir geht es darum, wie ich aus einem CSV ein .sr für Pulseview erzeugen
kann. Von CSV zu .bin bin ich schon gekommen ... :-)
-Björn
Moin,
so, wie ich dich verstehe, möchtest du eine bereits aufgenommene Messung
von analogen Signalen in PulseView sichtbar machen. Leider geht (noch)
nicht, denn das CSV-Modul unterstützt derzeit nur Logiksignale.
Falls deine Idee war, auf diese Signale einen der Dekoder anzuwenden, so
muß ich dich leider auch hier enttäuschen, da libsigrok noch keine
Möglichkeit bereitstellt, analoge Kanäle in digitale Kanäle umzuwandeln.
Du kannst mit ein wenig Excel-Magie (oder python oder C oder was auch
immer) das CSV natürlich so massieren, daß es am Ende zwei Logikkanäle
enthält, aber selbst habe ich das noch nicht gemacht.
Danach kannst du das CSV mittels sigrok-cli in ein .sr konvertieren und
mit PV öffnen - oder direkt mit PV öffnen, wenn du keine besonderen
Parameter für das Parsen der CSV-Datei benötigst (siehe
libsigrok-0.3.0/input/csv.c).
Ja, das hast du richtig verstanden. Das Problem ist bei mir nicht
Konvertierung analog->digital, sondern das Einlesen in PV.
"Danach kannst du das CSV mittels sigrok-cli in ein .sr konvertieren und
mit PV öffnen - oder direkt mit PV öffnen, wenn du keine besonderen
Parameter für das Parsen der CSV-Datei benötigst"
Genau das wollte ich machen und das funktioniert bei mir nicht.
Bislang ist es mir mit PV nur gelungen .sr-Files zu öffnen.
Und beim Konvertieren mit sigrok-cli bekomme ich selbst für .bin-Files
die Fehlermeldung "sr: output/srzip: Error saving zipfile: Renaming
temporary file failed: Invalid argument."
Anbei eine Beispieldatei.
Mein Verständnis ist, dass ich diese (wenn's denn funktionieren würde)
mit sigrok-cli in ein .sr-File umwandeln und anschließend in PulseView
öffnen kann.
Als Ausgabe würde ich in diesem Beispiel 8 zeitlich konstante Kanäle
erwarten:
1 1 0 0 0 0 0 1
1 1 0 0 0 0 0 1
1 1 0 0 0 0 0 1
1 1 0 0 0 0 0 1
1 1 0 0 0 0 0 1
...
Oder habe ich etwas falsch verstanden?
Björn G. schrieb:> Anbei eine Beispieldatei.>> Mein Verständnis ist, dass ich diese (wenn's denn funktionieren würde)> mit sigrok-cli in ein .sr-File umwandeln und anschließend in PulseView> öffnen kann.> Als Ausgabe würde ich in diesem Beispiel 8 zeitlich konstante Kanäle> erwarten:> 1 1 0 0 0 0 0 1> 1 1 0 0 0 0 0 1> 1 1 0 0 0 0 0 1> 1 1 0 0 0 0 0 1> 1 1 0 0 0 0 0 1> ...>> Oder habe ich etwas falsch verstanden?
Nö, genau so sollte das klappen (tut es bei mir auch, mit den git
Versionen von libsigrok/sigrok-cli/PulseView von heute):
sigrok-cli -i testing.bin -I binary -o testing.sr
Dann:
pulseview testing.sr
Ich bekomme bei gleichem Kommanda folgende Fehlermeldungen:
----
cli: Received SR_DF_HEADER.
cli: Received SR_DF_LOGIC (4096 bytes, unitsize = 1).
sr: output/srzip: Error saving zipfile: Renaming temporary file failed:
Invalid argument.
cli: Received SR_DF_LOGIC (4096 bytes, unitsize = 1).
sr: output/srzip: Error saving zipfile: Renaming temporary file failed:
Invalid argument.
cli: Received SR_DF_LOGIC (1805 bytes, unitsize = 1).
sr: output/srzip: Error saving zipfile: Renaming temporary file failed:
Invalid argument.
cli: Received SR_DF_END.
----
Ich arbeite mit Win7 in einer normalen Command-Shell (DOS). Du
vermutlich unter Linux?
Könnte es vielleicht sein, dass sigrok-cli unter Windows Probleme mit
Slash/Backslash o. ä. hat?
Ist eigentlich irgendwann mal wieder ein Release von sigrok und Tools
geplant? Das letzte Release ist eine ganze Weile her und Distributionen
verteilen eher selten Versionen direkt aus dem Git-Repositories.
Björn G. schrieb:> Ich bekomme bei gleichem Kommanda folgende Fehlermeldungen:> ----> cli: Received SR_DF_HEADER.> cli: Received SR_DF_LOGIC (4096 bytes, unitsize = 1).> sr: output/srzip: Error saving zipfile: Renaming temporary file failed:> Invalid argument.> cli: Received SR_DF_LOGIC (4096 bytes, unitsize = 1).> sr: output/srzip: Error saving zipfile: Renaming temporary file failed:> Invalid argument.> cli: Received SR_DF_LOGIC (1805 bytes, unitsize = 1).> sr: output/srzip: Error saving zipfile: Renaming temporary file failed:> Invalid argument.> cli: Received SR_DF_END.> ---->> Ich arbeite mit Win7 in einer normalen Command-Shell (DOS). Du> vermutlich unter Linux?>> Könnte es vielleicht sein, dass sigrok-cli unter Windows Probleme mit> Slash/Backslash o. ä. hat?
Möglich ja, ich werd mir das mal anschauen und evtl. einen Bugreport
draus machen falls es unter Windows da ein Problem gibt.
Uwe.
Hi,
drama schrieb:> Ist eigentlich irgendwann mal wieder ein Release von sigrok und Tools> geplant? Das letzte Release ist eine ganze Weile her und Distributionen> verteilen eher selten Versionen direkt aus dem Git-Repositories.
Ist geplant, es wird demnächst zumindest Bugfix-Releases für die derzeit
stabilen Versionen geben (mit kleineren Änderungen). Größere Releases
mit den neuen Features aus git HEAD soll es auch geben, aber das kann
evtl. noch ein wenig dauern da derzeit verschiedene größere Umbauten und
API-Änderungen am Laufen sind.
Uwe.
Hallo Uwe,
Erstmal ein herzliches Dankeschön, für die viele Arbeit.
Die hat sich mM nach wirklich gelohnt! :)
Damit's in Zukunft nicht langweilig wird, an der Stelle ein paar Wünsche
(Falls schon vorhanden / geplant, bitte ich mein nicht vorhandenes
Recherche Talent zu entschuldigen):
- Tabelle von dekodierten Daten / Paketen (Zeitstempe, Typ, Payload,...)
- generischer ASCII Decoder (um z.B. Strings in dPulseview darstellen zu
können)
Btw: wie siehts mit dem Releas aus? das Repo ist ja sehr aktiv!
Lg, Florian
Hallo,
wie kann man selbst Daten für den PulsView generiern? Laut HP kann man
VCD Dateien laden. Ich habe aber nirgends ein entsprechenden Menu Punkt
gefunden ...
Auch keine Beschreibung füe *.sr Dateien
Vielen Dank für eine Hilfe
Hallo, ich bin neu bei sigrok/pulseview und habe ein seltsames Problem:
1
$ sudo sigrok-cli --scan
2
The following devices were found:
3
demo - Demo device with 8 probes: 0 1 2 3 4 5 6 7
4
alsa - ALSA: HDA Intel PCH ALC269VC Analog with 2 probes: Ch_0 Ch_1
Also das findet da nix aber, das Pulseview findet ein Gerät. Das habe
ich auch angeschlossen aber es kann damit nicht reden:
capture failed,
failed to start session
lsusb sagt:
1
Bus 002 Device 004: ID 2232:1018
2
Bus 002 Device 003: ID 8087:07da Intel Corp.
3
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
4
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
5
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
6
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
7
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
8
Bus 003 Device 005: ID 2961:6689
9
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Was muss ich machen? Also muss ich das irgendwelche Firmware auf den
LWLA1034 flashen?
This will install the firmware files into /usr/local/share/sigrok-firmware/, per default.
Wenn ich mal das Pulseview also
1
sudo pulseview -l 5
starte bringt das aber:
1
sr: usb: Trying to open USB device 3.6.
2
sr: usb: Opened USB device (VID:PID = 2961:6689, bus.address = 3.6).
3
sr: sysclk-lwla: Downloading FPGA bitstream at '/usr/share/sigrok-firmware/sysclk-lwla1034-int.rbf'.
Das wurde also nicht gefunden weil war ja in /usr/local/share. Also
Ordner sigrok-firmware nach /usr/share kopiert und ... schon lädt es die
Firmware sobald man in Pulseview das Gerät auswählt (Dropdown).
1
sr: sysclk-lwla: FPGA bitstream download of 81464 bytes done.
2
sr: sysclk-lwla: Received test word 0x87654321 back.
Aber wenn ich dann auf "Run" klicke kommt ein Fehler:
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)
Leider ist der so unspezifisch dass ich da nicht weiter komme.
Oh und wenn ich das über das CLI machen will kommt das:
Gustl Buheitel schrieb:> This will install the firmware files into> /usr/local/share/sigrok-firmware/, per default.
Das gilt wenn man libsigrok selbst baut (/usr/local ist das
Standardpräfix wenn man nichts weiter angibt). Distributionspakete sind
üblicherweise mit Präfix /usr gebaut, und dann sollte sigrok-firmware
auch nach /usr installiert werden.
Aber Du hast es ja bereits hinbekommen, die Firmware zu laden. Zu den
Fehlermeldungen, die Du siehst: Trenn den LWLA1034 mal komplett von USB
und probiere es dann erneut. Manchmal verhält sich das Gerät bei der
Initialisierung komisch; bis jetzt habe ich den Grund dafür leider nicht
finden können. Wenn man es nochmal probiert geht es meist, und nach der
Initialisierung läuft es auch stabil.
Hallo,
ja, genau mal geht es, mal nicht, aber wenn es dann geht dann den ganzen
Tag lang. Jedoch oft nicht schon nach dem zweiten Verbinden sondern erst
etliche Male später.
Ausserdem hat die Samplezahl die man in Pulseview auswählen kann keinen
Einfluss auf die Anzahl der tatsächlichen Samplezahl.
Also welbst wenn ich die Samplerate sehr weit runtersetze so dass das
locker durch USB passt, scheint es ein oberes Limit für die Sampleanzahl
zu geben. Habe ich jetzt noch nicht näher untersucht, aber vermutlich
ist das das lokale RAM auf dem LA. Wäre halt schön, dass wenn die
Datenrate so gering ist dass die direkt durch USB passt, man deutlich
länger aufnehmen könnte wie in das (kleine) RAM passt.
Gustl
Hi,
an meinem Laptop klappt es meist schon beim ersten Mal. Das Problem
scheint aber auch rechnerabhängig zu sein. Ich vermute eine Unsauberkeit
in der USB-Firmware des Geräts -- evtl. auch in der Hardware -- die
unter bestimmten Umständen zu Tage tritt oder halt auch nicht.
Vielleicht auch eine Timing-Abhängigkeit die es eigentlich auf dieser
Protokollebene auch nicht geben sollte.
Es gibt übrigens auch einen Bug dazu:
http://sigrok.org/bugzilla/show_bug.cgi?id=327
Wenn Dir was interessantes am Verhalten auffällt, oder Du anderweitig
eine Idee hast, kannst Du es da reinschreiben.
Wie Du schon festgestellt hast; wenn es einmal läuft dann läuft es, und
das obwohl die Kommunikation mit dem Gerät nach der Initialisierung um
einiges komplexer ist.
Gustl Buheitel schrieb:> Ausserdem hat die Samplezahl die man in Pulseview auswählen kann keinen> Einfluss auf die Anzahl der tatsächlichen Samplezahl.
Doch, damit setzt Du das Maximum an aufzunehmenden Samples.
Der LWLA1034 kann kein Streaming (jedenfalls nicht mit der originalen
FPGA-Firmware). Der Speicher wird vollgelesen und dann per USB an den
Rechner übertragen. Durch die immer aktive RLE-Komprimierung ist die
Aufnahmezeit zusätzlich auch noch von der Signalaktivität abhängig. Die
Komprimierung führt auch zu dem Effekt, dass sich bei niedrigeren
Samplingraten die mögliche Aufnahmezeit nicht proportional erhöht -- die
codierten Lauflängen werden einfach nur kleiner.
(Dass die RLE-Komprimierung nicht abschaltbar ist, ist übrigens durchaus
sinnvoll. Der verwendete SRAM des Geräts ist 36 Bit breit, d.h. 34 für
alle Kanäle und 2 freie Bits, von denen eins anzeigt dass eine Lauflänge
statt einem Datenwort folgt. Der nach außen sichtbare Overhead ist also
quasi null.)
> Also welbst wenn ich die Samplerate sehr weit runtersetze so dass das> locker durch USB passt, scheint es ein oberes Limit für die Sampleanzahl> zu geben. Habe ich jetzt noch nicht näher untersucht, aber vermutlich> ist das das lokale RAM auf dem LA.
Korrekt.
> Wäre halt schön, dass wenn die Datenrate so gering ist dass die direkt durch USB> passt, man deutlich länger aufnehmen könnte wie in das (kleine) RAM passt.
Das würde eine komplett neue FPGA-Firmware erfordern. Ist halt nicht
der Einsatzzweck, für den das Gerät gedacht ist. Der LWLA1034 ist
hingegen sehr gut geeignet, wenn man auch bei niederfrequenten
Signalwechseln eine hohe Zeitauflösung braucht.
Dank der verschiedenen Triggeroptionen bekommt man eigentlich alles in
den Speicher was man für Fehlersuche etc. braucht. Und der Speicher ist
sogar größer als der mancher teurerer Konkurrenzprodukte.
Gruß,
--Daniel
Ok, wenn mir eine Regelmäßgkeit oder so auffallen sollte oder es mit
einer anderen Distribution (statt Ubuntu) besser geht werde ich
berichten.
Das mit dem Samplespeicher ist mir nur aufgefallen weil ich einem großen
Zähler beim Zählen zugucken wollte. Das dauert rund 50 Sekunden und
braucht so 1MS/s. Generell empfinde ich das aber als keine große
Einschränkung, bin eher überrascht für wie kleines Geld man da viele
Kanäle in schnell bekommt.
Gustl Buheitel schrieb:> Ok, wenn mir eine Regelmäßgkeit oder so auffallen sollte oder es mit> einer anderen Distribution (statt Ubuntu) besser geht werde ich> berichten.
Ich nutze ebenfalls Ubuntu (bzw. Ubuntu GNOME).
Bei mir ist es das 14.04 mit allen Updates. Aber kann in der Tat auch am
USB liegen, ein USB-Hub und Cardreader funktionieren hier auch nicht
ganz so wie sie sollten. Ist schon etwas älter das Gerät und die
USB-Buchsen haben schon viele Steckzyklen hinter sich.
Egal, es funktioniert wenn man etwas Geduld mitbringt und dann eben auch
dauerhaft.
Hallo,
Ich Arbeite mit OpenSuse 13.2, istalliert sind sigrok und zugehörigen
Pakete aus dem electronics Repo.
ich möchte mit sigrok/Pulseview die Daten meines DMMs auslesen.
Leider kann ich in der Geräteauswahl jedoch kein DMM Finden, dort sind
nur Oszi's aufgelistet.
Muss ich für das Auslesen von DMM's noch zusätzlich etwas installieren
oder was mache ich falsch....
Danke schon mal für Tipps
Herbert
Jens schrieb:> Was ist denn "Dein" DMM?
Ein HP 90EPC, welches mit QtDmm und der Geräteeinstellung VC820 (oder
anderen DMMs die das gleiche Protokoll verwenden) problemlos ausgelesen
werden kann.
Mein Problem ist, dass ich in der Geräteauswahl kein einziges DMM (aus
der langen Liste der unterstützten Geräte) angezeigt bekomme.
Hallo,
durch aufmerksammeres Lesen der sigrok hp habe ich des Rätsels Lösung
jetzt gefunden:
Die Kombination sigrok/Pulseview ist nur für La's.
Für DMM's bräuchte man sigrok-meter als Gui, welches es aber nicht als
rpm verfügbar ist.
Gruß Herbert
Hallo, ist eine Live-Funktion in Pulseview geplant? Also wie bei einem
Oszi, dass man ein getriggertes Logiksignal sehen kann?
Der von hier http://www.pctestinstruments.com/ mit deren Software kann
das und ist schon cool.
Vielen Dank!
PV zeigt alles live an, was akquiriert wird. Sehe also keinen Grund,
warum das nicht gehen sollte. Hast du es schon probiert und
festgestellt, daß es nicht geht?
Ja dann stelle ich mich wohl nur doof an. Also ja während es aufnimmt
ist das wohl live, aber das scrollt ja dann weg. Ich will dass ich mein
Triggerereignis z. B. in der Mitte vom Bildschirm habe und dann dauernd
neu getriggert wird wenn die Signalform vorher den Bildschirm gefüllt
hat.
Also wie bei einem Oszilloskop nur in Digital. Ich kann hier in
Pulseview nicht unendlich einstellen dass das immer so weiterläuft. Es
soll das Aufgenommene auch gar nicht behalten sondern nur live anzeigen.
Ah, ok. Im aktuellen git ist das besser, aber "Ich will dass ich mein
Triggerereignis z. B. in der Mitte vom Bildschirm habe" ist aktuell
nicht vorgesehen. Ist aber definitiv ein sinnvoller use case, also wenn
du einen bug dafür eröffnen würdest, wäre das schon mal ein erster
Schritt dorthin.
Im aktuellen git wird das neueste Sample immer am rechten Rand
angezeigt, d.h. die Anzeige scrollt permanent, wenn Daten reinkommen.
Damit würdest du dann bei jeder Triggerung mindestens einen
Oszi-Datenframe sehen - wie groß/lang der auch immer sein mag.
Ok ist das wirklich so?! Also 0.2 scrollt auch schon nach rechts.
Ich würde eher vermuten, dass sobald die Triggerbedingung einmal
eintritt das solange aufnimmt bis die eingestellte Zahl an Samples
erreicht ist. Aber nicht, dass es wieder auf einen Trigger wartet.
Hallo!
Mal eine Frage zu den Protokolldecodern: Nach der Installation sind im
Decoders Verzeichnis 56 Decoder installiert; auswählen in Pulseview kann
man aber nur 26. Mache ich was falsch?
> Mal eine Frage zu den Protokolldecodern: Nach der Installation sind im> Decoders Verzeichnis 56 Decoder installiert; auswählen in Pulseview kann> man aber nur 26. Mache ich was falsch?
Jein. Die restlichen Decoder sind Higher-Level "stacked" Decoder.
Z.B. UART Decoder hinzufügen, dann links auf den "Pfeil" von UART
klicken, dann "Stack decoder" klicken für die weiteren.
asdf schrieb:>> Mal eine Frage zu den Protokolldecodern: Nach der Installation sind im>> Decoders Verzeichnis 56 Decoder installiert; auswählen in Pulseview kann>> man aber nur 26. Mache ich was falsch?>> Jein. Die restlichen Decoder sind Higher-Level "stacked" Decoder.>> Z.B. UART Decoder hinzufügen, dann links auf den "Pfeil" von UART> klicken, dann "Stack decoder" klicken für die weiteren.
MIDI z.B. macht auf "Logic"-Ebene (raw Messdaten) keinen Sinn, da es nur
die Ergebnisse von UART auswerten kann.
Kurzes Update, weil es evtl. doch einige interessieren könnte: Ein neues
Set an Releases ist jetzt fertig (Quellcode Tarballs):
https://www.sigrok.org/blog/major-sigrok-releases-libsigrok-libsigrokdecode-sigrok-cli-pulseview
Für Windows gibts wie gehabt den Nightly installer (der immer auf
aktuellstem Stand ist):
http://sigrok.org/wiki/Windows
Es gibt unter Windows nach wie vor TODOs, z.B. für FX2 Logic Analyzer,
wir arbeiten da an einer Lösung mit custom libusb-Modifikationen die
hoffentlich helfen werden:
http://sigrok.org/bugzilla/show_bug.cgi?id=573.
Ansonsten sollte i.A. alles auch unter Windows ganz gut funktionieren,
Tests und Bugreports (+ idealerweise Patches) sind jedoch gerne
willkommen!
Uwe.
Hallo,
keine Ahnung wo mein gestriger Post abgeblieben ist, daher hier nochmal
die Frage.
Ich versuche den Open Bench Logic Sniffer zum Laufen zu bekommen.
Es wird mir ein USB CDC Treiber in der Systemsteuerung/Hardware
angezeigt.
Leider jedoch kein COM-Port.
Was muss ich tun, damit ein Com-Port für die Kommunikation angezeigt
wird.
System ist Win7 64bit.
Ziel ist es, den Analyzer mit Sigrok und OLS zu betreiben.
LG Tom
Tom schrieb:> Ich versuche den Open Bench Logic Sniffer zum Laufen zu bekommen.> Es wird mir ein USB CDC Treiber in der Systemsteuerung/Hardware> angezeigt.> Leider jedoch kein COM-Port.
Windows hat zwar einen CDC-Treiber, aber der erkennt erst in Windows 10
CDC-Geräte automatisch. In älteren Windows-Versionen braucht man eine
.inf-Datei (hier: mchpcdc.inf von Microchip, im OLS-Treiber-Paket
enthalten).
Mich würde stark interessieren, ob auch eine Unterstützung für denn
Logic Analyzer von dreamsourcelab geplant ist. Gibt es dazu was?
http://dreamsourcelab.com/dslogic.html
Ich habe Sigrok schon seit einer ganzen Weile auf dem Radar, ich warte
darauf, dass der Intronix LogicPort LA1034 unterstützt wird. Der steht
schon lange auf "planned", aber ich habe den Eindruck, da tut sich im
Moment nicht viel. Ist diese Information noch aktuell?
Ich habe seit einiger zeit Probleme mit veralteten QT-libs unter
android. Die bringen Pulseview unter Android > 4.2 zuverlässig zum
Absturz.
Wird das noch gemaintained? Kann ich jemandem Testgeräte zur Verfügung
stellen?
Habe hier schon einen Bug reportet, aber noch keine Reaktion gesehen:
http://sigrok.org/bugzilla/show_bug.cgi?id=701
das crosscompilat ist leider auch schon seit Monaten kaputt auf eurem
Jenkins.
Sehr schade für diese doch sehr tolle Software. Ansonsten arbeite ich
sehr gerne mit sigrok.
Flip B. schrieb:> Ich habe seit einiger zeit Probleme mit veralteten QT-libs unter> android. Die bringen Pulseview unter Android > 4.2 zuverlässig zum> Absturz.
Hab das APK gestern nochmal aktualisiert auf Qt 5.5.1, evtl. klappt das
jetzt, bitte nochmal probieren (ja, wird noch maintained, ist alles nur
eine Zeitfrage und/oder ob Leute von extern Patches beisteuern). Sowohl
altes als auch neues APK funktionieren übrigens auf meinem Android 4.4.2
Tablet.
Zu OLS, da muss der "normale" Serial Port Treiber benutzt werden der mit
dem OLS-Treiber-Paket mitgeliefert wird (also in diesem Fall nicht mit
Zadig auf WinUSB umstellen o.ä.). Details hier:
http://sigrok.org/wiki/Windows.
Beim OLS ist derzeit ein Bug offen, bin mir nicht sicher ob der andere
Leute auch betrifft, bitte testen wenn möglich:
http://sigrok.org/bugzilla/show_bug.cgi?id=638.
Zu DSLogic und LogicPort LA1034, die stehen beide auf der Liste, aber in
letzter Zeit hat meines Wissens niemand aktiv daran gearbeitet. Für
DSLogic ist minimaler Code schon im git drin, aber das ist noch nicht
benutzbar, daher auch keine Erwähnung im NEWS file. Bei beiden Geräten
brauchts jemanden dem das wichtig genug ist daran zu arbeiten und den
Code zu schreiben bzw. zu erweitern.
Uwe.
Kurzes Update - Bug #573 (fx2lafw Probleme unter Windows) sollte jetzt
gelöst sein (mittels Spezialbranch von libusb und einem zusätzlichen
libusb Patch für RAW_IO Pipe Policy, beides hoffentlich bald in upstream
libusb enthalten).
Wer bisher Probleme und Abbrüche mit FX2 Logic Analyzern unter Windows
hatte, bitte nochmal testen. Der neueste Installer sollte jetzt deutlich
besser funktionieren mit FX2 Geräten und es sollte deutlich seltener zum
Abbruch der Messung kommen.
Hallo zusammen,
ich versuche einen LogicStudio 16 mit Pulseview zum laufen zu bringen.
Scheitere aber daran, dass ich keine 'lecroy-logicstudio16-fx2lp.fw'
habe. kann mir da jemand weiterhelfen?
Ich verwende Pulsview unter xubunu erfolgreich. Derzeit mit dem LA
Saleae8. Sprich Pulseview und alle libs arbeiten wie sie sollen.
Nachtrag: ich würde mal vermuten, daß die FX2LP-Firmware Bestandteil der
LeCroy-Software ist und dort gefunden werden kann. Mir ist zumindest
kein anderer Ort bekannt, wo man sie finden könnte.
A. Nonym schrieb:> Mit dem Python-Skript kannst du die Firmware extrahieren.
Das Skript habe ich schon angewendet. Da kommen dann die beiden Dateien
'lecroy-logicstudio16-16.bitstream' und
'lecroy-logicstudio16-8.bitstream'.
Diese werden jedoch nicht als Treiber erkannt und ein umbenennen bringt
leider auch nichts...
Die Ordner der Windows Installation habe ich schon alle durchpflügt.
Leider ohne Erfolg...
Noch eine Idee?
Hallo NG,
hat jemand eine Ahnung, ob man mit sigrok-cli unter Linux
den Janatek LA-Gold-36 zum Laufen dringen kann und welchen
Treiber man dafür benötigt?
Ich habe in einer Loop , s.u. alle gelisteten Treiber geladen
und auf meinen USB Port losgelassen, aber leider ohne Erfolg.
>sigrok-cli -L | grep -a55 'Supported hardware drivers:' | awk '{print $1}' | tail
-55
asix-sigma
baylibre-acme
beaglelogic
brymen-bm86x
chronovu-la
demo
ftdi-la
fx2lafw
hantek-6xxx
hantek-dso
hp-3457a
hpib-pps
ikalogic-scanalogic2
ikalogic-scanaplus
kecheng-kc-330b
lascar-el-usb
lecroy-logicstudio
lecroy-xstream
maynuo-m97
p-ols
rigol-ds
saleae-logic16
scpi-pps
sysclk-lwla
tecpel-dmm-8061
tenma-72-7730
tenma-72-7732
tenma-72-7745
tenma-72-7750
tenma-72-9380a
testo
uni-t-ut32x
uni-t-ut372
uni-t-ut60a
uni-t-ut60e
uni-t-ut60g
uni-t-ut61b
uni-t-ut61c
uni-t-ut61d
uni-t-ut61e
uni-t-ut71a
uni-t-ut71b
uni-t-ut71c
uni-t-ut71d
uni-t-ut71e
victor-dmm
voltcraft-vc820
voltcraft-vc830
voltcraft-vc840
voltcraft-vc870
voltcraft-vc920
voltcraft-vc940
voltcraft-vc960
yokogawa-dlm
zeroplus-logic-cube
Der einzige Treiber "uni-t-ut32x" liefert einen Output, der
zunächst vielversprechend aussah, aber sich im Nachhinein
als ungeeignet herausstellte.
sigrok-cli --driver=uni-t-ut32x:conn=0e36.e040 --scan
The following devices were found:
uni-t-ut32x - UNI-T UT32x with 3 channels: T1 T2 T1-T2
#!/bin/bash
for d in `sigrok-cli -L | grep -a55 'Supported hardware drivers:' | awk
'{print $1}' | tail -55`
do
echo $d
sigrok-cli --driver=${d}:conn=0e36.e040 --show
sleep 1
done
Danke für sachdienliche Infos.
Markus
DL8MBY
A. Nonym schrieb:> Da es für das Gerät keinen Eintrag im Wiki gibt, wird es leider auch> nicht unterstützt.
Umgekehrt wird da ein Schuh draus.
Solange sich keiner daran macht, eine Unterstützung/Treiber für das Ding
zu programmieren, wird es auch keinen Eintrag im Wiki geben.
In der Liste der (evtl. auch nicht unterstützten) LA wird der Janatek
zumindest schon mal gelistet:
https://sigrok.org/wiki/Logic_analyzer_comparison
Ich denke als Anfang ist es ganz vernünftig, das Teil einmal
auseinanderzunehmen und Fotos zu machen, wie das bei anderen LAs der
Fall ist, die auch noch nicht unterstützt werden, z.B.
https://sigrok.org/wiki/Sysclk_SLA5032
Außerdem ist natürlich die Ausgabe von lsusb durchaus interessant, in
etwa https://sigrok.org/wiki/Sysclk_SLA5032/Info
Wenn man dann weiß, welche Hardware verbaut ist, kann man viel eher
abschätzen ob man eventuell einen bestehenden Treiber portieren kann
oder nicht.
Ich habe einen miniLA Mockup, der ist zwar in der Sigrok-Liste
aufgeführt, wird aber wohl nicht unterstützt. Z.Zt. habe ich nur hierfür
noch einen uralten (2002) Windows-Rechner mit W2k, aber der wird wohl
nicht mehr lange leben, bin schon damals auf Linux umgestiegen.
Hier -> Beitrag "Re: miniLa Software" hat vor
kurzem auch schon jemand nach Software für Linux gefragt. Gibt es denn
evtl. eine Beschreibung des Protokolls des miniLA Mockup, dann könnte
man sich evtl. einen Treiber für Sigrok basteln oder einen vorhandenen
Treiber anpassen.
Stephan S. schrieb:> Gibt es denn> evtl. eine Beschreibung des Protokolls des miniLA Mockup, dann könnte> man sich evtl. einen Treiber für Sigrok basteln oder einen vorhandenen> Treiber anpassen.
Hier müsstest du alles nötige finden:
https://www.mikrocontroller.net/articles/MiniLA
Links verfolgen!
Die Seiten kenne ich schon. Da sind zwar alle möglichen Source-Codes und
Binaries, aber keine Beschreibung des Protokolls. Möglicherweise ist das
der Grund dafür, dass die Sigrok-Macher das nicht weiter verfolgt haben
(können), denn den miniLA und den miniLA Mockup haben damals sehr viele
Bastler nachgebaut oder die Sammelbestellungen gekauft (irgendwas
zwischen 50 und 100)
Ich habe mal meinen Fundus durchsucht und Doku gefunden. Ich weiß
aber leider nicht mehr, wo die herkam. Vielleicht kann sie ja
jemand brauchen.
Ich hatte auch mal mit einer Lazarus-Anwendung angefangen, das ist
aber halt leider sehr lang her und die FTDI-Treiber möchte ich mir
heute nicht mehr antun. Sigrok wäre schon besser.
Das sieht ja schon mal recht schön aus, sind die Seiten
minila.sourceforge.net/fw/communication_protocol_fw_1.7.pdf und
minila.sourceforge.net/fw/communication_protocol_fw_2.2.pdf.
Das ist aber der normale miniLA ohne die Erweiterung durch mockup, das
läuft das wegen veränderter Hardware wohl anders.
Das ist schon noch "aktuell", mockup hatte wimre nur nochmal
den Speicher vergrößert und den Parport weggelassen. Das
Protokoll ist auch für USB gültig. Wie das über USB läuft,
musst du dir im Originalprogramm zum miniLA anschauen. Dies
benutzt aber die FTDI-Treiber, das müsste mal auf libusb o.ä.
umgeschrieben werden.
Das ist aber dann ein serielles Protokoll, denn der FT2232 macht auf
meiner Linux-Kiste 2 (!) serielle Schnittstellen auf: /dev/ttyUSB0 und
/dev/ttyUSB1
1
uxdx@uxdx-ubuntu:~$ lsusb
2
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
3
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
4
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
5
Bus 005 Device 002: ID 0403:6010 Future Technology Devices International, Ltd FT2232C Dual USB-UART/FIFO IC
6
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
7
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
8
Bus 004 Device 002: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse
9
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
10
Bus 003 Device 002: ID 04f9:01eb Brother Industries, Ltd MFC-7320
11
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
12
Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
13
Bus 008 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Ich war so erfolgreich (siehe auch
https://www.mikrocontroller.net/articles/Minila_Version_MockUp):
download libftd2xx driver
http://www.ftdichip.com/Drivers/D2XX.htm (x86/32bit)
root werden
Entpacken des libftd2xx Driver Paketes
Kopieren der Driverlib
cp ./release/build/libftd2xx.so.1.4.6 /usr/local/lib
Verlinken in den Standardpfad für lib
ln -s /usr/local/lib/libftd2xx.so.1.4.6 /usr/lib/libftd2xx.so.0
Dann muss noch der Modul ftdi_sio entladen werden, der übernimmt sonst
die Kontrolle.
rmmod ftdi_sio
Zumindest die Replacement libftd2xx winelib von
http://coolla.kleinefreiheit.org/winelib.html kann dann mit dem Minila
kommunizieren.
Matthias
ISt ein super Tool, welches mir in den letzten Tagen geholfen hat Daten
zu Analysiern, die mein Kollege an einem anderen Standort mit einem
Hameg Oszi aufgenommen hat.
Das auswerten der Daten mit den Protokol Decodern ist ein super
Instrument.
z.b. die PWM Decoder.
Nun hab ich eine Frage:
kann man die ermittelten analogen PWM Werte ( 0,1..99,9) % auch analog
darstellen?
- Blume
Entschuldigung? schrieb:> Wie kann ich denn mit Pulseview die dekodierten UART-Daten als ASCII> speichern?
Rechts-klick auf die dekodierten Daten und im Kontextmenü exportieren
wählen.
Blume schrieb:> kann man die ermittelten analogen PWM Werte ( 0,1..99,9) % auch analog> darstellen?
Im Moment noch nicht, daran arbeiten wir aber sehr bald. Eventuell hilft
dir bis dahin ja ein Export (siehe vorige Frage) und eine Darstellung
dieser Daten in bspw. Excel.
Ihr könnt den Export übrigens über das Settings-Menü anpassen, da gibt
es einen format string.
Ich überlege mir das Projekt mit weiteren Protokol Dekodern zu
ünterstützen.
Leider ist das offensichtlich unter WIN 10 nicht ganz so einfach,
da das builden der Quellen für Linux ausgelegt ist.
Wie geht man denn vor, wenn man das Projekt auf einem WIN10 Rechner
übersetzen will?
mfg
Blume
Blume schrieb:> Wie geht man denn vor, wenn man das Projekt auf einem WIN10 Rechner> übersetzen will?
Eine Linux VM intallieren. Windows selbst ist eher eine Plattform für
Cloud Dienste und Spiele, nicht zum Programmieren.
Spaß beiseite: Versuche es mal mit der Original Doku
https://sigrok.org/wiki/Windows#Building_from_source
Die empfehlen tatsächlich, das Windows Programm unter Linux zu
erstellen.
Nachdem die Rigol-SW nicht mehr läuft und ich hier den Tip zu sigrok
gefunden hatte, heute mal auf Win7 i7 installiert und siehe da, es geht
was.
Absturz mach 911 Segments bei 100µs/Div
Bemerkenswert war eine Out-of_memory warning vom System, 8GB vorhanden,
4 waren noch verfügbar.
Habs dann auf einen jüngeren Win10 PC mit mehr Power+RAM installiert und
läuft soweit.
Was stört sind inkonsitente Datenformate zwischen sigrok-cli und
PulseView.
Mit ist es nicht gelunden mit der CLI tool eine Messung mit CH1 + 4 LA
Channels zu erzeugen welche sind dann in PulseView einfach importieren
läßt.
Auch nur LA liefert im binary file Texte welche dann mißverstanden
werden, Nacharbeiter vorm Import nötig.
Leider entsteht zwischen den Frames zeitliche Lücken die das olle Rigol
besser kann. Langzeitspeicher und dann reinzoomen bis Faktor 10000 sind
sehr hilfreich.
Aber man muß auch positiv bewerten was da alles geboten wird, womöglich
lösen sich ja die eine oder andere Sache noch auf.
NichtWichtig schrieb:> Bemerkenswert war eine Out-of_memory warning vom System, 8GB vorhanden,> 4 waren noch verfügbar.
Könnte am Filesystem liegen. FAT32 unterstützt maximal 4GB.
Könnte daran liegen, dass das Programm 32bit Integer verwendet, denn die
gehen bis maximal 4 (und ein par zerquetschte) Milliarden.
Stefanus F. schrieb:> Könnte am Filesystem liegen. FAT32 unterstützt maximal 4GB.
Die typische Fehlermeldung unter Windows bei Verletzung dieser Grenze
ist allerdings:
ERROR_HANDLE_DISK_FULL
39 (0x27)
The disk is full.
Also hier doch eher nicht das Problem...
NichtWichtig schrieb:>> Leider entsteht zwischen den Frames zeitliche Lücken die das olle Rigol> besser kann. Langzeitspeicher und dann reinzoomen bis Faktor 10000 sind> sehr hilfreich.
Nochmal genauer untersucht und einen Sinnloscounter zu den i2c Aktionen
addiert, alle 20ms werden 2 chips gelesen und der Dritte bekommt sein
InputInversionRegister incrementiert.
100ms/Div = 1.2s ~ 60 Zugriffe, ab der Hälfte im PulseView ruckelt der
Bildaufbau und der i2c Dekoder zeigt einen Sprung von B1 nach 7A auf, da
fehlen mindestens 200 * 20ms!
Machen das neuere Scopes (Rigols) besser/richtig?
Der nächste Punkt der negativ auffällt ist die nicht einstellbare
samplerate.
Öffnet man einen abgespeicherten Signalverlauf (oder zieht einen
frischen vom Rigol) in der ein Mitschnitt einer seriellen Schnitttstelle
abgebildet ist so verweigert der UART Dekoder seinen Dienst weil er
nicht erkennt welche samplerate vorliegt.
Decoder reported an error.
Auch kommt PulseView nicht damit zurecht das das Rigol einen
Langzeitspeicher hat und nach dem Scan massiv reingezoomt werden kann.
2ms/div werden mit 10MS eingelesen um das ~1M baud Signal zu dekodieren.
Ohne Angabe der samplerate keine Chance.
Weder in der version 0.4.1 (Linux) noch 0.5.0 (Windows) läßt sich dieses
einstellen.
NichtWichtig schrieb:> Nachdem die Rigol-SW nicht mehr läuft und ich hier den Tip zu
Korrektur: Habe nochmal bei Batronix frische Software
gezogen/installiert und nun löpt das olle DS1052D auch mit Win10, mit
viel Features aber OldSchool-Oberfläche/Möglichkeiten.
Da erscheint sigrok/PulseView durchaus modern und die Decoder machen
Appetit.
Sehr schön, PulseView kann auch "analoge" Rohdaten importieren
(https://sigrok.org/wiki/Input_output_formats) - Vielen Dank!
Damit hat Audacity endlich ausgedient, d.h. fast: Audiowiedergabe,
Filter und Analyse sind dort ausgesprochen nützlich (gibt's noch was
besseres, evtl. auch mit FFT und waterfall display?).
Wie könnte man denn ein Analogsignal zu einem Digitalsignal umwandeln,
um dort den PWM-Decoder (https://sigrok.org/wiki/Protocol_decoder:Pwm)
einsetzen zu können?
Und angenommen, das geht ohne weiteres nicht, und ich muss die Daten
vorverarbeiten: welches Format müsste denn
https://sigrok.org/wiki/File_format:Binary haben, um einen Binärkanal
darzustellen? Mit einem Kanal, sind es 8 Samples pro Byte? Ein Beispiel
in der Doku wäre schön.
Hah!
LMB auf den Kanal eröffnet die Möglichkeit zur "conversion"!
- Es wäre toll, wenn der Import-Dialog bei der Frequenzeingabe
Exponenten oder SI-Präfixe verstünde (z.B. 1e9 oder 1G statt
1000000000).
- und wenn der Dialog die eingegebenen Werte behalten würde
- und wenn man beim PWM-Dekoder beide Spuren (Duty-Cycle und Periode)
auf einmal exportieren könnte..
Info schrieb:> - und wenn man beim PWM-Dekoder beide Spuren (Duty-Cycle und Periode)> auf einmal exportieren könnte..
Passiert offenbar mit "export all annotations" (ohne "for this row"),
allerdings nacheinander, also z.B.
1
2
...
3
5990195-5995489 PWM: Duty cycles: 14.998111%
4
50152-55441 PWM: Periods: 5.3 µs
5
...
Und der Import von Binärdaten funktioniert für eine Spur mit dem LSB
eines Bytes.
Sorry, noch ein Wunsch (ich bin doch hier beim Wunschkonzert?): "Klick
auf Add Protocol Decoder" möge bitte das "Decoder Selector" Suchfeld
fokussieren...
Sind die Import-Funktionen eigentlich auch Python-Module?
Info schrieb:> Sorry, noch ein Wunsch (ich bin doch hier beim Wunschkonzert?): "Klick> auf Add Protocol Decoder" möge bitte das "Decoder Selector" Suchfeld> fokussieren...
Ich hätte auch ein Vorschlag zu Pulseview:
Einen Button, der den Bereich des "Auswahl-Markierers" fast
bildfüllend vergrössert und zentriert darstellt, so wie in der Anlage
von pv1.png zu pv2.png, das würde viele Mausklicks und herumwursteln mit
den Laufleisten ersparen.
Wenn ein fx2lafw fälschlicherweise über einen langsamen USB-Isolator
angeschlossen ist, wird das Gerät zwar erkannt, liefert aber keine
brauchbaren Daten - evtl. könnte sigrok/PulseView das erkennen und eine
Warnung ausgeben?
Ähnlich läuft es mit aktivem BT-Dongle am Hub... Datenrate reicht nicht
für 24 MHz..
Übrigens gibt Jenkins gerade "504 Gateway Time-out".
Und im Bugzilla ist SPAM :-(
Gibt's ne Möglichkeit, Digitalkanäle zu filtern, um sporadische
Störungen zu eliminieren? Das bring sonst nämlich die Dekoder sofort aus
dem Tritt..
Covid ging auch an unserem Kernteam (bestehend aus 2) leider nicht
spurlos vorbei, daher ist es aktuell... schwierig. Auch die
Jenkins-Downtime resultiert daraus.
Kanäle filtern ist im Moment leider nicht drin, kann man aber über einen
PD implementieren, da diese nun auch (zumindest in PV nutzbare)
Logiksignale erzeugen können. Siehe put_logic_states in
https://sigrok.org/gitweb/?p=libsigrokdecode.git;a=blob;f=decoders/pca9571/pd.py
und
https://sigrok.org/gitweb/?p=libsigrokdecode.git;a=blob;f=decoders/tca6408a/pd.py
Für die Datensuche in PDs fehlt prinzipiell nur die UI in PV, da es ja
das tabular decoder output view gibt, was unter der Haube die
Qt-Standard-Modellabstraktion verwendet.
"PD ab hier starten" ist auch leicht implementiert, alle Bausteine dafür
sind schon da. Aber wie so oft - es muss eben jemand mal Zeit dafür
finden.
Danke, anonymer Kernentwickler ;-), für das Feedback.
Dann ist Jenkins wohl oben auf der Liste.
Bei den Decodern juckt es mich immer in den Fingern, es auch mal zu
probieren.
Das Filtern ist so eine Sache - wenn der LA den "glitch" sieht, sieht
das Gerät es wohl auch (und das Filtern hilft dann nicht).
Ein Glitch-Detektor wäre aber sinnvoll.
Kann man eigentlich die Ausgaben eines Protokoldecoders an einen
Analogkanal weiterleiten?
Das wäre interessant für PWM, I2S, ...
Notfalls kann ich die Decoder auch selber anpassen, die Frage ist eher,
kann ein Analogkanal quasi auf einen Decoder gestackt werden.
Falls nicht, vielleicht einfach als Idee zum im Hinterkopf behalten.
Habe nicht im Kopf, ob decoder auch Analogdaten ausgeben können. Wenn
ja, könnte man "stacken".
Allerdings ist https://sigrok.org/wiki/Protocol_decoder_API/Queries
gerade für mich down.
Wer selber schreiben will, das Wiki ist leider ein bisschen irreführend
(das HOWTO sollte man ignorieren), stattdessen lieber von aktuellem Code
abgucken.
Jaja schrieb:> Wer selber schreiben will,
Ein beispielcode "für dummies" wäre gut.
In die lib zu gehen und das py file zu editieren ist einfach.
Aber das wichtige zu verstehen nicht so.
Pepe T. schrieb:> Ein beispielcode "für dummies" wäre gut.
Dafür war das HOWTO, aber mittlerweile hat sich der Kern verändert.
Man kommt nicht drumherum, sich einzulesen. Wer programmieren kann,
schafft das. Kostet halt Zeit, auch als nicht-dummy.
Wer sich die Zeit nimmt, könnte gleichzeitig die Doku erweitern. Das ist
als "unwissender" Einsteiger eh besser, aus Sicht der Erfahrenen gibt es
keine Fragen.
Also: aktuellen, einfachen Decoder (weiter oben auch mit konkreten
Vorschlägen) ansehen, und die Wiki-Seiten, wenn Sie wieder erreichbar
sind.
Weitere Hürde ist, dass man die GUI Anwendung neu starten muss, für
jeden Versuch - aber das dürfte mit dem Konsolendekoder schneller gehen.
Ich würde den glitch-detector veröffentlichen, habe aber derzeit keinen
Bedarf und keine Zeit, daran zu arbeiten.
Hallo,
gute Besserung, Sigrok ist ein super Tool. Ich hoffe Jenkins ist bald
wieder "Up and running", mit den Win-Nightlybuilds hatte ich immer gute
Erfahrungen gemacht, das selbst für Windows zu bauen, da bin ich nicht
sicher ob ich das hin zu bekommen.
Wenn es Möglichkeiten gibt euch zu unterstützen, sagt bescheid, ich
verwende den gerne um Studenten auszubilden, nutze einen 10€ Debugger
wenn ich das dicke Scope nicht verwenden will,... .
Plugins würde ich auch gerne schreiben, oder mal einen Studenten dran
setzen, da wäre es auch toll wenn es ein Tutorial mit Beispielen gäbe.
Vielen Dank, Sigrok rockt!
Grüße, Seppel
Hallo,
hat jemand sigrok für windows mal gebaut?
Was ich nicht verstehe, was soll man verwenden? MXE, MSYS2 scheint nicht
alles zu unterstützen,... bin etwas irritiert.
Vielen Dank,
Grüße, Seppel
Der privat gehostete jenkins ist leider gerade down, falls du nicht
warten möchtest bis er wieder kommt, kannst du über das skript bauen:
https://sigrok.org/wiki/Windows#Cross-compile_using_MXE
MSYS2 ist experimentell und nicht empfehlenswert.
Hallo Herr A.Nonym,
Unter dem Abschnitt "Cross-compile using MXE" steht etwas von MXE und
Mingw. Können Sie mir sagen was verwendet werden soll, oder das Wiki
anpassen?
Auch steht dort dass Native-Build nicht unterstützt wird, aber Mingw ist
letztendlich indirekt? MXE läuft auf Linux? In welcher Umgebung soll das
referenzierte Skript verwendet werden?
Wenn dort im Wiki mehr Infos wären würde ich gerne versuchen es zu
bauen, vielleicht auch langfristig mit in die Entwicklung einzusteigen.
Vielen lieben Dank.
MfG Seppel.
P.S. Wenn der Nightly Build wieder funktioniert wäre das natürlich
super.
Der Download klappt wieder.
Mein Zeroplus LAP-C(32128) wird nicht leider gefunden.
Kann mir Jemand sagen, ob eine implementierung geplant ist (der 16032
und 322000 werden lt. Wiki unterstützt) ?
Markus
Kann sigrok-cli die Daten an PulseView über Netzwerk "streamen"?
z.B.: fx2la->Raspberry Pi ... WiFi ... PC (Pulseview)
https://sigrok.org/wiki/Sigrok-clihttps://sigrok.org/wiki/PulseView
Oder geht das (noch) nicht direkt und man muss erst in eine Datei
samplen und kann diese dann mit Pulseview untersuchen?
Oder gibt etwas wie "sigrok-server" der nur die Gerätetreiber enthält,
und selbst als Gerät mit sigrok-cli über Netzwerk angesprochen werden
kann?
Hintergrund:
Die FX2-basierten USB-Logikanalysatoren brauchen 480 Mbit und
funktionieren nicht an den einfachen ADUM3160 (ADUM4160) USB-Isolatoren.
Schnellere Chips für USB 2 High Speed:
ISOUSB211DPEVM ist nicht erhältlich.
ADUM4165 Eval 55+25+x USD (zu teuer)
APISU30-EVA-USBCON ?
Einen FX2-LA und Raspberry Pi Zero W könnte ich mit einer Powerbank
betreiben.
Sieht nicht so aus.
Ob es irgendwelche Kunstgriffe mit virtuellen Dateien und Triggern gibt
- keine Ahnung.
Also erstmal in Dateien schreiben, und dann über Netzwerk öffnen. Für
Windows: https://magpi.raspberrypi.com/articles/samba-file-server
restart samba: https://forums.raspberrypi.com/viewtopic.php?t=102230https://www.raspberrypi.com/software/operating-systems/#raspberry-pi-os-32-bithttps://rufus.ie/en/https://www.raspberrypi.com/documentation/computers/configuration.html#setting-up-a-headless-raspberry-pi
Da sigrok als Debian-Paket verfügbar ist, ist die Installation auf dem
RPi problemlos:
sudo apt install sigrok-firmware-fx2lafw sigrok-cli
sigrok-cli --scan
sigrok-cli -d fx2lafw --channels D0=SDA,D1=SCL --triggers SDA=f
--config samplerate=1M --time 1s --wait-trigger --protocol-decoders i2c
-o test.sr
- die channel-Namen überschreiben die default-Werte, d.h. nach
Definition von "SDA" ist "D0" unbekannt (triggers: "Invalid channel
'D0'.").
- es gibt offenbar leider keine pre-buffer Option, damit kommt z.B. der
i2C Dekoder nicht klar (selbst mit Zuweisung des Anfangszustands)
- der Dekoder schreibt nach stdout und nicht ins outfile. Pulseview weiß
also nichts von den Dekodern. Außerdem kostet es Rechenzeit, kann sein,
dass es dann zu langsam wird ("Device only sent 428149 samples.").
Also
sigrok-cli -d fx2lafw --channels D0=SDA,D1=SCL --triggers SDA=f
--config samplerate=1M --time 1s -o /share/test.sr
Dann \\\raspberrypi\share\test.sr mit Pulseview öffnen (etwas lahm, kann
beim ersten Versuch einen Fhler geben), Dekoder einstellen und dann per
"Reload" neu laden.
Ob der Zero W mit voller Samplerate klarkommt, habe ich noch nicht
ausprobiert. Eher nicht.
Jaja schrieb:> Kann sigrok-cli die Daten an PulseView über Netzwerk "streamen"?
Kann sigrok_cli nicht nach Standardausgabe schreiben und pulseview von
Standardeingabe bzw. /dev/stdin lesen?
Dann macht ein passender Aufruf von netcat bzw. nc den Rest dazwischen.
Klaus W. schrieb:> Kann sigrok_cli nicht nach Standardausgabe schreiben und pulseview von> Standardeingabe bzw. /dev/stdin lesen?> Dann macht ein passender Aufruf von netcat bzw. nc den Rest dazwischen.
Gibt's mit Windows 10 ein stdin? Unter Linux etc. könnte man es mal
ausprobieren, wie PulseView damit klarkommt.
Andererseits hat das Aufzeichnen ja auch seinen Sinn:
1
#!/usr/bin/bash
2
while :
3
do
4
echo waiting for trigger ... saving to $(date-Iseconds).sr
5
sigrok-cli ... -o /share/$(date-Iseconds).sr
6
done
1
pi@raspberrypi:~ $ ./loop.sh
2
waiting for trigger ... saving to 2022-03-14T15:27:59+00:00.sr
3
waiting for trigger ... saving to 2022-03-14T15:28:11+00:00.sr
Jaja schrieb:> Gibt's mit Windows 10 ein stdin?
Das ist eine ziemlich blöde Frage mit starker Tendenz zur Trolligkeit.
However: Die Antwort ist natürlich JA.
c-hater schrieb:> Das ist eine ziemlich blöde Frage mit starker Tendenz zur Trolligkeit.
Vielleicht doch nicht so blöde.
Ich habe es noch nicht probiert, aber ich glaube pulseview kann nicht
ohne weiteres von Standardeingabe lesen. Es hat aber ein Argument -i, um
von einer angegebenen Datei zu lesen.
Gibt man unter Linux da /dev/stdin an, ist es die Standardeingabe.
Wenn ich die man-Page richtig interpretiere, kann man die Eingabe
deshalb nicht direkt aus einer Pipe in pulseview schieben ohne -i
/dev/stdin.
Man kann es natürlich probieren, vielleicht geht es und alles ist ganz
einfach.
Aber ob man unter Windows so einen Pseudodateinamen angeben kann, der
für die Standardeingabe steht?
(Das alles mit Vorbehalt, weder mit mit pulseview noch Windows bin ich
besonders bewandert.
War nur eine Anregung, wie es vielleicht geht.)
Klaus W. schrieb:> Ich habe es noch nicht probiert, aber ich glaube pulseview kann nicht> ohne weiteres von Standardeingabe lesen.
Das wäre dann aber keine Problem von Windows im Allgemeinen oder
Windows10 im Besonderen, sondern einzig ein Problem von PulseView.
Nicht wahr?
pre-buffer für fx2 z.B.: --config samplerate=1M:captureratio=1
Dateinamen besser ohne Doppelpunkte, z.B.: $(date +"%F_%H-%M-%S%z")
Die Trigger sind offenbar UND-verknüpft (wenn ich mehrere einstelle,
triggert es nicht)?
https://sigrok.org/wiki/PulseView
verweist auf
https://sigrok.org/doc/pulseview/unstable/manual.html (Error 404)
Die Suchmaschine findet ein Manual für 0.4.1, das letzte Release ist
aber 0.4.2, also
https://www.sigrok.org/doc/pulseview/0.4.2/manual.html#_triggers
Sagt nichts über mehrere Trigger.
https://www.sigrok.org/doc/pulseview/0.4.2/manual.html#_command_line_interface
C:\Program Files (x86)\sigrok\PulseView>pulseview.exe -h
(keine Ausgabe)
Hier ist etwas broken.
pulseview.exe --version startet offenbar die GUI und zeigt den
Treiber-Ladebalken, dann aber nichts mehr.
Ich konnte aber eine .sr Datei angeben und öffnen.
Pipen der Datei mit CMD (type) und Powershell (cat) mit Dateinamen "-"
hat nicht funktioniert, wird offenbar nicht behandelt:
https://github.com/sigrokproject/pulseview/search?q=argv
main(int argc, char *argv[])
vector<string> open_files;
MainWindow::add_session_with_file
Session::load_init_file
Session::load_file
Aber es müsste dann wohl alles auf stream umgebaut werden.
Aufzeichnen und später angucken ist schon OK.
couldn't find a sendmail executable at /usr/share/perl5/Email/Sender/Transport/Sendmail.pm line 63.
4
Email::Sender::Transport::Sendmail::_find_sendmail(Bugzilla::Sender::Transport::Sendmail=HASH(0x561efbd2e2a8), "sendmail") called at /usr/share/perl5/Email/Sender/Transport/Sendmail.pm line 36
5
Email::Sender::Transport::Sendmail::__ANON__(Bugzilla::Sender::Transport::Sendmail=HASH(0x561efbd2e2a8)) called at (eval 198) line 23
6
Email::Sender::Transport::Sendmail::sendmail(Bugzilla::Sender::Transport::Sendmail=HASH(0x561efbd2e2a8)) called at /usr/share/perl5/Email/Sender/Transport/Sendmail.pm line 41
7
Email::Sender::Transport::Sendmail::BUILD(Bugzilla::Sender::Transport::Sendmail=HASH(0x561efbd2e2a8), HASH(0x561efc4bc4b0)) called at (eval 320) line 68
8
Email::Sender::Transport::Sendmail::new("Bugzilla::Sender::Transport::Sendmail") called at Bugzilla/Mailer.pm line 132
9
Bugzilla::Mailer::MessageToMTA("From: bugzilla-daemon\@sigrok.org\x{a}To: xxx\x{a}Subje"..., 1) called at Bugzilla/Token.pm line 89
10
Bugzilla::Token::issue_new_user_account_token("xxx") called at Bugzilla/User.pm line 2423
11
Bugzilla::User::check_and_send_account_creation_confirmation(Bugzilla::User=HASH(0x561ef84d2a80), "xxx") called at /data/sigrok.org/apache/bugzilla/createaccount.cgi line 39
12
13
For help, please send mail to the webmaster (none@sigrok.org), giving this error message and the time and date of the error.
Was ich berichtet hätte:
Pulseview 0.5.0-git-7e5c839 Windows lädt nicht alle Dekoder (I2C fehlt),
wenn es per .sr Datei gestartet wird. Pulseview starten & Datei öffnen
geht dagegen.
A.Nonym schrieb:> Blume schrieb:>> kann man die ermittelten analogen PWM Werte ( 0,1..99,9) % auch analog>> darstellen?>> Im Moment noch nicht, daran arbeiten wir aber sehr bald. Eventuell hilft> dir bis dahin ja ein Export (siehe vorige Frage) und eine Darstellung> dieser Daten in bspw. Excel.
kann man inzwischen die ermittelten analogen PWM Werte ( 0,1..99,9) %
auch analog darstellen?
hat sich hier was getan?
Hallo,
leider ist sigrok.org wieder down,... weiß jemand ob das Projekt weiter
geht?
Ich verwende Sigrok sehr gerne, ich wäre ich wäre echt traurig wenn das
stirbt.
Viele Grüße, Seppel
Sigrok scheint es besser denn je zu gehen. Schaut euch mal an wie in
letzter Zeit die Liste der unterstützten Hardware gewachsen ist.
https://sigrok.org/wiki/Supported_hardware
Außerdem hat das Projekt eine gewisse "kritische Masse" (inkl. forks)
erreicht, die für das "ewige Leben" bei OSS nötig ist. Ist ja nicht so
wie bei kommerzieller Software, wo ein einziges Liqiditätsproblem zur
Firmenpleite führen kann.
B. G. schrieb:> LA1010 lä
LA1034 ebenfalls seit 10 Jahren "planned"
Aus mir auffällt: Der Arduino ist nicht implementiert! Seltsam. Gerade
so ein Teil hätte ich vorn erwartet.
Thread beobachten
Seitenaufteilung abschalten