Da fällt mir ein: das HP6633 wollte mit dem AR488 gar nicht reden. Hab den USBTMC dann dafür genommen.
Zu den Problemen bei vielen Geräten am Bus: Vielleicht mal mit PE (Pullup Enable) des SN75160B experimentieren, eventuell ändert das was.
Daher wundert mich auch etwas, dass der Aufbau eines größeren Busses damit doch etwas problematisch ist.
Mich auch... Ich hätte erwartet, dass ein voller Bus kein Problem macht.
Obwohl das natürlich stimmen könnte:
900ss schrieb:
Ich kann mich erinnern, als ich mich irgendwann so 2008 rum mit einem DIY Adapter beschäftigte, da hieß es, dass ein AVR an eine Stelle das Timing verletzt weil es in SW schlicht zu langsam ist.
Ging mir auch so, ja. Aber hier ist ja ein ESP32 drauf, der sollte schon ein Stück schneller sein. Kann aber natürlich trotzdem sein, dass ein Handshake in Software problematisch ist. Als man den Bus definiert hat, hat man an dieser Stelle komplett auf (TTL-)Hardware gesetzt.
In dem ursprünglichen hpib Guide sind noch eine extra Terminierung beschrieben, die ich nur in einer einzigen Hardwareumsetzung gesehen habe.
Auch auf Fotos NI Karten habe ich die nicht gesehen. Die SN7516x sollten die aber eigentlich integriert haben (so lese ich zumindest das Datenblatt).
Ja, der esp32 ist verhältnismäßig schnell - die GPIO bitbanging ist aber immer so eine Sache... Wird es stabiler wenn du mit -Ofast compilierst? Das würde die timing-theorie stützen.
73
Welche der früheren GPIB-Karten aus den PCs hatte denn die Treiber-ICs in Fassungen?
Die Teile wurden wohl spaeter auch gar nicht mehr gebraucht!
Ich hab hier gerade einen SMT02 von R&S auf dem Tisch. Da ist ein TNT4882 drin. Datenblatt gibt es hier:
https://www.ni.com/de-de/shop/model/tnt4882.html
Da sind die Treiber seit 1995 bereits integriert.
BTW: Sollte man diesen Thread nicht mal verschieben? 90% hier ist ja garnicht mehr "Markt"
Vanye
Ja, der esp32 ist verhältnismäßig schnell - die GPIO bitbanging ist aber immer so eine Sache... Wird es stabiler wenn du mit -Ofast compilierst?
Muss ich mal gucken, im Moment habe ich Dieters Binary laufen.
Ja, der esp32 ist verhältnismäßig schnell - die GPIO bitbanging ist aber immer so eine Sache.
Was mir dazu noch einfällt: die Probleme, wenn paar Geräte mehr am Bus waren, waren fast immer Datenverfälschungen, also gekippte Bits. Wie / warum der HP6633 nicht reagiert, habe ich aber keine Ahnung.
Ich seh schon, ich muss mir demnächst mal noch einen GPIB-auf-LA-Adapter bauen. ;-)
Zu PE des SN75160B gibt es in der Doku des TMS9914A ein paar Hinweise:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
Zu den Problemen bei vielen Geräten am Bus: Vielleicht mal mit PE (Pullup Enable) des SN75160B experimentieren, eventuell ändert das was.
Der hat einen Pullup dran, müsste also standardmäßig aktiv sein, falls die Software das nicht irgendwie überschreibt (da habe ich noch nicht rein geschaut).
Dieter S. schrieb:
Zu den Problemen bei vielen Geräten am Bus: Vielleicht mal mit PE (Pullup Enable) des SN75160B experimentieren, eventuell ändert das was.
Der hat einen Pullup dran, müsste also standardmäßig aktiv sein, falls die Software das nicht irgendwie überschreibt (da habe ich noch nicht rein geschaut).
PE an einen gpio zu legen war eine "Eingebung" von mir. Die Firmware geht von einer fixen Verdrahtung aus.
73
PE an einen gpio zu legen war eine "Eingebung" von mir. Die Firmware geht von einer fixen Verdrahtung aus.
Damit sollten die Pullups am Bus aber dauerhaft aktiv sein, wenn ich das Zitat oben richtig verstehe.
Hans W. schrieb:
PE an einen gpio zu legen war eine "Eingebung" von mir. Die Firmware geht von einer fixen Verdrahtung aus.
Damit sollten die Pullups am Bus aber dauerhaft aktiv sein, wenn ich das Zitat oben richtig verstehe.
Nein, ich bin mir ziemlich sicher, dass die konfiguration tristate und nicht open-drain ist.
73
mich irritiert immer noch das Schaltbild, schaue ich auf https://www.lcsc.com/datasheet/lcsc_datasheet_2501211440_hongjiacheng-H5VU25U_C7420374.pdf gibt es keine Serien R und mehr Dioden nach + und -
Angehängte Dateien:
-
H5VU25U_small.jpg
(8,4 KB)
-
H5VU25U_small2.jpg
(7,4 KB)
mich irritiert immer noch das Schaltbild
Ja, und? Man hätte das Teil auch einfach nur als Blackbox in den Schaltplan zeichnen können, du musst eigentlich nur wissen, dass es ein Schutzdioden-Array ist. Für die reine Funktion der Schaltung ist das Teil doch komplett unerheblich.
Das Pseudo-Schaltbild im Datenblatt dokumentiert beispielsweise auch nicht, dass der empfohlene Footprint Pin 1 und 8 miteinander verbindet.
Für die reine Funktion der Schaltung ist das Teil doch komplett unerheblich
mir war aber so als wenn du Probleme mit der Ansteuerung von mehreren GPIB Geräten hast und da der ESP eben nicht 5V fähig ist schaut man woran es liegen könnte und da sehe ich als Ungereimtheiten. Solange ich es nicht besser weiß wird eben dahin geschaut! Man kann aber auch blind weiterraten.
da der ESP eben nicht 5V fähig ist
Dass er das nicht ist, spielt doch hier keine Rolle. Das Diodenarray hängt am Bus, aber der ESP ist mit den 7516x-Treibern vom Bus entkoppelt.
Habe jetzt mal versucht, einen etwas größeren Bus damit aufzubauen, das war ziemlich fummelig (Aussuchen von "gängigen" Kabeln) und nur begrenzt möglich.
Allmählich kommt wohl Klarheit. ;-)
@Dieter kann es sein, dass bei deinem Arduino-Build die Optimierung zu wenig oder gar ganz ausgeschaltet war?
Wenn ich den PlatformIO-Build nehme und noch die nervigen Meldungen rauswerfen, während er im Listen-only-Modus auf Zeichen wartet, dann funktioniert jetzt schon recht viel, und es sieht auch so aus, als ob ich einen ordentlich langen Bus damit aufbauen kann.
Ich habe mal noch den alten HP54512B mit dran gehängt, neben dem HP6633B eines der Geräte, die auch SCPI machen – einige andere hier machen es nicht.
Das Problem beim HP6633B lag nur daran, dass mein Test im Terminal standardmäßig kein CR-LF sendet, das scheinen sie dort zu mögen. Mit einem manuellen CR-LF oder mit ++auto 2 reagieren sie beide auf *IDN?
Lediglich der Rückweg aus dem Listen-only ist nach wie vor etwas fummelig, da sehr oft die ++-Kommandos dort nicht akzeptiert werden. Mit mehrfachem copy&paste eines "++mode 1" geht es dann irgendwann. Wäre interessant, ob sich das noch irgendwie verbessern lässt.
Angehängte Dateien:
-
plot-advantest.png
(3,2 KB)
-
plot-hp54512.png
(2,9 KB)
Wäre interessant, ob sich das noch irgendwie verbessern lässt.
Was mir dazu noch in den Sinn kam: die Modem-Interface-Signale sollten sich ja problemlos out of band verarbeiten lassen. Damit könnte man den Adapter zumindest durch ein Schließen des Host-Devices wieder aus dem listen / device mode wieder in den Grundzustand zurücksetzen.
@Hans Dieter (ds1) hatte einige Änderungen in den Code gebaut, die es u.a. auch erlauben, beim Bus-Timing kleine "settling times" einzufügen. Mit diesen Änderungen (und DC vom 75161 an IO45) funktioniert bei Dieter und bei mir jetzt alles – inklusive eines „gut besetzten“ Busses (6 Geräte).
Ich habe Dieters Änderungen noch ein wenig aufgeräumt¹ und dir einen pull request daraus gemacht.
¹u.a. habe ich seinen Debugging-Code bei mir in einen eigenen Branch gesetzt und aus dem PR rausgelassen. Es gibt da auch schon andere Debug-Optionen, und nachdem auch bei ihm jetzt alles läuft, muss man das ++debug ja vielleicht nicht unbedingt im primären Code haben.
Falls nochmal jemand drüber stolpern sollte: pymeasure.adapters.PrologixAdapter sollte man mit dem pyvisa-py backend benutzen:
1 |
|
2 |
|
3 |
|
Mit der normalen IVIVisaLibrary (ohne "visa_library=" Paramter) kracht es ansonsten:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
https://github.com/pyvisa/pyvisa/issues/261
Scheint ein Bug in der VISA Library zu sein, dass sie eine Methode nicht implementiert haben, die dokumentiert ist.
Ich bin etwas spät dran, das Ding in Betrieb zu nehmen, nun versuche ich es aber. ;-)
Scheiterte bisher an PlatformIO, das hatte ich noch nicht. Nun habe ich es als VS Code Extension (unter Windows) installiert. Mit dem Repo von Hans habe ich die Rev 4 übersetzt und auch geflasht bekommen. Aber dann, was nun, wie soll sich das Gerät denn darstellen, als was für eine Schnittstelle?
Beim Anstöpseln an USB passiert augenscheinlich nichts. Der Windows-Gerätemanager zuckt nicht, ich sehe keine neue serielle Schnittstelle, kein Netzwerkinterface, im WLAN keinen neuen AP.
Sorry, habe noch keine Ahnung von GPIB-Adaptern. Gegoogelt habe ich den Eindruck, so ein Prologix-Clone sollte eine serielle Schnittstelle sein?
Edit: Habe UART-Pads gefunden und dran gemessen. Die Applikation kommt wohl nicht hoch, ich lese in schneller Folge (alle 218ms): ESP-ROM:esp32s2-rc4-20191025 Build:Oct 25 2019 rst:0x3 (RTC_SW_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT) Saved PC:0x400262cf SPIWP:0xee mode:DIO, clock div:1 load:0x3ffe5110,len:0x1270 load:0x4004a000,len:0x4 load:0x4004a004,len:0xa04 load:0x4004e000,len:0x3540 entry 0x4004a15c
Hat jemand eine Idee? Ich habe nichts am geclonten Repo verändert.
Hast du die PCBs umgebaut bekommen oder hast du das selbst gemacht?
Falls du das selbst gemacht hast, prüf Mal ob du nicht vergessen hast die beiden Widerstände in der Versorgung zu Brücken.
Übrigens habe ich den Arduino code auf Stand gebracht... Irgendwas ist dabei aber komisch... Mein Rohde SMY01 liefert mit der neueren Revision eine falsche Response auf IDN...
Ich muss da aber noch herausfinden ab welcher Revision das Problem Auftritt. Könnte aber auch mit der Umstellung auf tinyusb sein, damit ich die Mac Adresse als usb-seriennummer setzen kann...
73
Ich hatte es selbst umgebaut. Den Widerstand R14 habe ich durch einen mit 0 Ohm ersetzt. Gerade nocmal mit dem Oszi gesucht, ob die Spannungen stabil sind, scheint aber der Fall zu sein. Ich habe nichts gefunden, was sich synchron zu dieser 218ms Boot-Loop bewegt. Edit: Die beiden großen Tranceiver-Chips werden handwarm, ist das normal?
Ja, die werden tatsächlich gut warm.
Am ehesten passt was mit der Firmware nicht... Also z.b falscher Chip gewählt.
Probier mal meine Arduino Firmware...die wird imho ohnehin regelmäßiger gewartet.
https://github.com/WilheJo-Org1/AR488/commit/33b4f1b4e589c14d27f53c5d96d2ea9f9de14243 die revision geht mit allen meiner Geräte..die neueste erwirft bei mir am SMY01 den 1. Buchstaben beim IDN Kommando. Ich hätte das Update im Nachhinein in einem eigenen branch machen sollen...
73
Probier mal meine Arduino Firmware...die wird imho ohnehin regelmäßiger gewartet.
Ist auch meine Empfehlung, die funktioniert insgesamt besser.
Hans, ich hatte dir einen Pullrequest dafür gemacht, auch dank Dieters Korrekturen. Essenziell ist der Hardware-Umbau bezüglich des DC-Signals, wenn man das Teil nicht nur als Controller, sondern auch als Device benutzen will. Das funktioniert nur nach dem Umbau.
Ansonsten habe ich noch einen intensiven Dialog mit Dieter hinsichtlich der Plot-Funktion meines Advantest R4136, aber das Problem dort scheint tatsächlich die Firmware des Spekkis bzw. der darin enthaltene TMS9914 zu sein.
Tatsächlich... Hab ich übersehen, sorry!
Montag ist bei mir eng.. ich Versuch am Dienstag per disect das Problem mit dem SMY01 einzugrenzen, dann übernehme die natürlich und schau, dass das ggf auch Richtung upstream weitergeht.
Ich hoffe, dass ist keine Limitierung durch den tinyusb Stack... Die 0 bei der Seriennummer ist leider der IDF geschuldet und die will ich im arduino-kontext nicht angreifen... Leider ist da kein Hook vorgesehen, damit man die beim Starten dynamisch setzten kann.
73
Eigentlich ist es ja kein Problem des AR488 bzw. des Advantest R4136 oder TMS9914. Es liegt an der Anwendung:
-
AR488 ist "Controller" und sagt dem "Device" Advantest R4136 dass die Screen Daten auf den Plotter ausgegeben werden sollen.
-
AR488 schaltet von "Controller" auf "Device" um damit er als Plotter die Daten empfangen kann.
-
Advantest R4136 schaltet annähernd gleichzeitig von "Device" auf "Controller" um damit er die Daten an den Plotter senden kann. Das klappt nicht weil wohl der AR488 noch "Controller" ist.
OK, nach Installation der Arduino IDE habe ich den Commit probiert. Lässt sich übersetzen und flashen, danach kommt ähnlich wie bei PlatformIO noch ein Fehler weil die USB-serielle Schnittstelle des Bootloaders verschwindet. Es gibt keine Boot Loop mehr, die Meldung auf dem UART sehe ich nur einmal. Was für ein Board soll ich denn auswählen? Ich habe bisher diese ausprobiert: ESP32S2 Dev Module ESP32S2 Native USB Mit dem ersten sehe nach Start ich ein paar Zeichen Schrott auf dem UART, mit dem zweiten nichts.
Nochmal: Was sollte denn passieren, was für eine Schnittstelle entsteht ggf.? Ich habe das Board lose auf dem Tisch, kein GPIB angeschlossen, ist das vielleicht Voraussetzung?
Hans hat die Konfiguration für die Arduino IDE doch dokumentiert (das Bild im Anhang ist von seiner Seite dazu).
Angehängte Dateien:
-
ArduinoTargetConfig.png
(63 KB)
Die 0 bei der Seriennummer ist leider der IDF geschuldet und die will ich im arduino-kontext nicht angreifen... Leider ist da kein Hook vorgesehen, damit man die beim Starten dynamisch setzten kann.
Ja, das hatte ich auch schon gesehen. Ist nicht so tragisch, solange man nur einen davon im System hat.
Eigentlich ist es ja kein Problem des AR488 bzw. des Advantest R4136 oder TMS9914.
Ja, gut. Das Problem das R4136 ist eher, dass es keine Funktion gibt, den Plot normal als Device zu starten, sondern halt nur, indem man die Tastenfunktionen via GPIB sendet.
Aber danke auch hier mal für deine Hilfe, Dieter!
Nochmal: Was sollte denn passieren, was für eine Schnittstelle entsteht ggf.? Ich habe das Board lose auf dem Tisch, kein GPIB angeschlossen, ist das vielleicht Voraussetzung?
Ein COM-Port, bzw /dev/tty.
Das funktioniert auch ohne Gerät am Bus. Über Terminal "++ver\r\n" senden sollte eine Antwort liefern.
Nochmal: Was sollte denn passieren, was für eine Schnittstelle entsteht ggf.?
1 |
|
Details:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
15 |
|
16 |
|
17 |
|
18 |
|
Ist jetzt die Ausgabe von usbconfig auf FreeBSD, aber ich denke, die wesentlichen Details kann man erkennen. Insbesondere entsteht halt ein "umodem0" (CDC) sowie ein "umass0" (MSC).
War mir klar, dass das an irgendeinem Punkt peinlich für mich wird... ;-)
Hans hat die Konfiguration für die Arduino IDE doch dokumentiert (das Bild im Anhang ist von seiner Seite dazu).
Aha, danke, habe ich erstens übersehen und wusste zweitens nicht, dass das bei Arduino so üblich ist. (Scheint auch versionsabhängig zu sein, bei mir ist mindestens die Sortierung anders.) Zwei Punkte waren unterschiedlich, "USB CDC on Boot" und "Upload Mode". Nun habe ich auch nach dem Bootloader noch einen COM-Port.
Ein COM-Port, bzw /dev/tty.
Das funktioniert auch ohne Gerät am Bus. Über Terminal "++ver\r\n" senden sollte eine Antwort liefern.
Aha, danke. Prima, mein neuer Port liefert die Antwort "AR488 GPIB controller, ver. 0.51.29 (JW), 29/01/2025". Dann kann der Spaß ja losgehen.
Ich bin erst jetzt dazu gekommen, den AR488 in mein Messprogramm einzubinden und sodann gründlich zu testen. Zuvor hatte ich jahrelang den Prologix Ethernet-Controller benutzt, der stets völlig zuverlässig arbeitete.
Direkt gab es mit dem neuen AR488 jede Menge Probleme, das Messprogramm wollte nur mit einigen Geräten fehlerfrei zusammenarbeiten. Deshalb habe ich ein kleines Testprogramm geschrieben um die Fehler eingrenzen, aber auch, um die Performance des AR488 mit dem Prologix vergleichen zu können.
Für einen Teil der Probleme war auch mein Messprogramm verantwortlich, aber der Fehler konnte mit dem Prologix aus bestimmten Gründen nicht auftreten.
Nach Beseitigung des Fehlers ergab sich bei den 5 getesteten Geräten folgendes Bild:
Das Senden über den AR488 zum Gerät arbeitet fehlerfrei.
Beim Lesen mit ++read 10 ergab sich folgende Situation:
Mit Prologix:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
Mit AR488:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
15 |
|
16 |
|
17 |
|
Der time stamp ist in Sekunden mit einer Auflösung von 1µs und mit der Funktion getnl wird das Ergebnis eingelesen. Im Unterschied zum Prologix kommt die Antwort nicht in einem kompletten Rutsch sondern die Bytes kommen mehr oder weniger einzeln an. Das ist offensichtlich ungünstig auf dem AR488 programmiert.
Dennoch sind die Gesamtzeiten mehr oder weniger identisch und liegen bei etwa 4ms. Das ist für die Transferzeit ein durchaus brauchbarer Wert, wenn man bedenkt, wie lange z.B. ein Voltmeter braucht, um einen Wert zu messen: bei höheren Genauigkeiten im Sekundenbereich.
Eine nähere Inspektion ergab dann, dass dies an der internen Verarbeitung des ++read liegt, das kann man beim AR488 auch an der Differenz der time stamps zwischen "start getnl" und Eintreffen des
- Zeichens im Vergleich zu den weiteren Differenzen erkennen.
Nun gut, nicht optimal, aber beileibe kein Beinbruch. Man muss das nur wissen, damit es beim Programmieren keine unerwarteten Resultate gibt.
Beim auto ++auto 1 gibt es ein gemischtes Bild und es hängt auch noch von dem Ort ab, an welcher Stelle man es einsetzt.
Um das zu verstehen, eine kurze Ablaufbeschreibung des Testprogramms
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
Das auto 1 ist ohnehin problematisch, weil es Geräte gibt, die eine Fehlermeldung ausgeben, wenn ein Kommando keinen Rückgabewert hat. Von daher kommt eigentlich nur die Methode "beforereading" in Betracht, also das Anschalten vor dem Lesen und ein Ausschalten direkt danach.
Das "beforereading funktioniert mit dem AR488 bei allen getesteten Geräten nicht.
"beforetrigger" funktioniert bei 3 von 5 Geräten nicht, "once" bei 1 nicht.
Beim Prologix hingegen funktionieren bei allen Geräten alle Betriebsarten ohne Probleme.
Also sollte man beim Programmieren auf ++auto verzichten, zu unzuverlässig, mal blockiert das getnl, mal kommt Datenmüll und hin und wieder funktioniert es. Beim interaktiven Einsatz ("once") sollte es normalerweise funktionieren.
Ich vermute, dass dieser Fehler nicht esp32 spezifisch, sondern im allgemeinen Programmteil lokalisiert ist. Dass deshalb, weil ich bei einem Chinaclone des Prologix ähnliche Fehler bei auto feststellen kann. Ansonsten sehr schön klein, ist in einem Stecker für ein GPIB Kabel eingebaut und hat eine bessere Performance als Prologix und AR488.
Es hat eine Transferzeit von 1,7ms und kostete vor ca. 5 Jahren etwa 40€ beim Ali.
Das Testprogramm in Python anbei.
Gruß Dieter
Ich vermute, dass dieser Fehler nicht esp32 spezifisch
Tatsächlich läuft die Diskussion zur Firmware hier: https://www.eevblog.com/forum/projects/ar488-arduino-based-gpib-adapter/
Bisher habe ich die Internas nur grob überflogen. Dort werden solche Reports aber recht schnell beantwortet.
Zum Transfer Speed... Da könnte mit dem tiny-usb Stack ggf noch Luft sein. Immerhin kann man dann Transferarten, Paketgrößen,... beeinflussen.
Mit dem pull-request müsste man ja mit 2 AR488 Daten im Kreis schicken können... Da sollte sich dann ein Unterschied zeigen.
Hans W. schrieb:
Die 0 bei der Seriennummer ist leider der IDF geschuldet und die will ich im arduino-kontext nicht angreifen... Leider ist da kein Hook vorgesehen, damit man die beim Starten dynamisch setzten kann.
Ja, das hatte ich auch schon gesehen. Ist nicht so tragisch, solange man nur einen davon im System hat.
Ich habe oft 2-3 auf einmal in Betrieb. Gerade bei der Geschwindigkeit hilft das extrem, weil man beim Umschalten zwischen geräten am Bus einfach zuviel Overhead produziert.
73
Die 0 bei der Seriennummer ist leider der IDF geschuldet und die will ich im arduino-kontext nicht angreifen..
Ich weiß gar nicht, was sich jetzt geändert hat, ich habe nach deinen letzten Merges versucht, Dieters Änderungen zu aktualisieren. Nach dem Flashen jetzt:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
15 |
|
16 |
|
17 |
|
Es ist kein umass0 (MSC) mehr da, aber dafür eine Seriennummer.
Eine weitere Beobachtung: ++spoll crasht die Firmware (reboot, wie bei ++rst). Weiß nicht, ob das nur meinen lokalen Build betrifft, aber es ist reproduzierbar.
Ansonsten scheint die Firmware mit den aktualisierten Änderungen von Dieter wieder so zu funktionieren wie vorher (Branch "ds1_fixes" in meinem Repo).
Ich werde noch ein wenig vergleichen und testen und dann gelegentlich den pull request neu stellen.
Hast du vllt vorher das msd-on-boot flag in der arduino die ein gehabt?
Ja, ich habe jetzt Code im master eingefügt der automatisch cdc über tinyusb nutzt wenn cdc-on-boot deaktiviert ist. Dabei nutze ich eine der Mac Adressen als Seriennummer und setze die Strings auf sinnvolle werte.
Aber vorsicht, der Master liefert bei mir eine korrupte Response auf IDN bei meinem R&S SMY01. Die letzte funktionierende Version ist 0.52.26 von Mitte März. Debug Daten habe ich schon generiert - issue ist aber noch nicht geschrieben...
Eure Patches habe ich in einen branch gezogen. Der merge mit dem master-branch ist aber ziemlich schwierig. Da hat sich wirklich viel an der Code strukz verändert...
73
Hast du vllt vorher das msd-on-boot flag in der arduino die ein gehabt?
Möglich
Ja, ich habe jetzt Code im master eingefügt der automatisch cdc über tinyusb nutzt wenn cdc-on-boot deaktiviert ist. Dabei nutze ich eine der Mac Adressen als Seriennummer und setze die Strings auf sinnvolle werte.
Das ist auf jeden Fall ein Fortschritt. Da ich bei mir semi-permanente Gerätenamen für die seriellen USB-Schnittstellen generiere (ähnlich wie Linux /dev/serial/by-id), kommt da jetzt ein sinnvoller Name raus.
Aber vorsicht, der Master liefert bei mir eine korrupte Response auf IDN bei meinem R&S SMY01.
Müsste ich nochmal bei den Geräten gucken, die bei mir SCPI-kompatibel sind. Die meisten sind es nicht.
Funktioniert bei dir ++spoll, oder crasht das ebenfalls?
Eure Patches habe ich in einen branch gezogen. Der merge mit dem master-branch ist aber ziemlich schwierig. Da hat sich wirklich viel an der Code strukz verändert...
Daher habe ich ja gestern Abend selbst mal versucht, das anzugleichen. Insbesondere ist ja jetzt aus setGpibState() ein setGpibCtrlDir() und setGpibCtrlState() geworden.
Die Anordnung der Dokumentation scheint sich auch geändert zu haben, da habe ich Dieters Ergänzungen allerdings in meinem Branch noch nicht nachgezogen.
Es ist kein umass0 (MSC) mehr da, aber dafür eine Seriennummer.
Die SN ist so nicht in Ordnung. MSC macht Einschränkungen wie die SN auszusehen hat. (max 12 Zeichen, keine Sonderzeichen)
Die SN ist so nicht in Ordnung. MSC macht Einschränkungen wie die SN auszusehen hat.
Ist egal, es gibt ja kein MSC mehr, nur noch ein CDC.
Da das ja urprünglich mal ein Markteintrag war (und ich zu spät): Meine Adapter von Hans- die ich jetzt erst angefragt habe sind auch angekommen (einige wenige hat/te er noch) - vielen Dank!
Aber vorsicht, der Master liefert bei mir eine korrupte Response auf IDN bei meinem R&S SMY01. Die letzte funktionierende Version ist 0.52.26 von Mitte März. Debug Daten habe ich schon generiert - issue ist aber noch nicht geschrieben...
Hast du da irgendein Update?
Diese Version crasht konsistent bei einem ++spoll.
Ohne Dieters Patches geht der device mode nicht, mit den Patches funktioniert meine Plotter-Emulation, solange ich "++lon 1" benutze. Mein Spekki versucht aber eigentlich, den Plotter auf Adresse 5 anzusprechen. Wenn ich statt "++lon 1" dann mit "++addr 5" im device mode arbeite, crasht die Firmware ebenfalls. Ich vermute mal, dass das nicht mit Dieters Patches zusammenhängt sondern die gleiche Ursache hat wie der Crash beim serial poll.
Wie würde man den Crash debuggen, da muss ich dann eine serielle Console anklemmen, oder?
Ich habe kürzlich 2 unserer Boards nach UK gesendet, damit sich waveydipol das genauer ansehen kann. An der Plotter emulation ist er übrigens auch sehr interessiert...
Kannst du wegen der von dir entdeckt Probleme auch ein issue im twighlight-logic ar488 repo machen? Ich hab dein Problem zwar erwähnt - ich befürchte aber, dass könnte ohne issue untergehen...
Ich hoffe das Packerl wird demnächst zugestellt... Ist schon 7 Tage unterwegs...
73
Wie würde man den Crash debuggen, da muss ich dann eine serielle Console anklemmen, oder?
Ich bin mir nicht sicher wie man das aktiviert, es sollte aber mit dem s3 möglich sein per USB jtag debug zu machen...angeblich auch mit parallelem cdc device.
Ansonsten gibt's auch semi-hosted gdb Server über uart... Habe ich aber auch noch nicht verwendet.
73
An der Plotter emulation ist er übrigens auch sehr interessiert...
Ist eigentlich gar nicht so sehr besonders. Man muss halt auf Traffic auf dem Bus hören. Im Moment im listen-only mode, als eine Art "sniffer". Wenn es funktionieren würde, müsste es sogar direkt adressiert funktionieren, weil mein Analyzer das nach Adresse 5 sendet.
Der Rest ist dann eine sinnvolle Ende-Erkennung; kann man mit Timeout machen, im Moment mache ich es, indem ich stoppe, wenn ich den String "PA00000,00000" gesehen habe, der bei mir das Ende der Plot-Daten kennzeichnet.
Danach übergibt man das, was man eingesammelt hat, an hp2xx, was daraus ein PNG macht.
Kannst du wegen der von dir entdeckt Probleme auch ein issue im twighlight-logic ar488 repo machen?
https://github.com/Twilight-Logic/AR488/issues/62
Mal gucken, ob ich mir das mit dem Debuggen antun will. Heute Abend nicht mehr. ;-)
Jörg W. schrieb:
Wie würde man den Crash debuggen, da muss ich dann eine serielle Console anklemmen, oder?
Ich bin mir nicht sicher wie man das aktiviert, es sollte aber mit dem s3 möglich sein per USB jtag debug zu machen...angeblich auch mit parallelem cdc device.
Ist das Teil jetzt kompatibel zu einem ESP32S2 oder ESP32S3?
Wenn ich einen S2 auswähle, dann möchte das OpenOCD einen externen JTAG-Debugger sehen (welches im einfachsten Falle ein MPSSE-fähiger FTDI sein kann). Aber ich fürchte, die JTAG-Pins haben wir beim AR488 nicht frei, oder?
Wenn ich den S3 auswähle, sagt er mir, dass er kein passendes Gerät findet.
Eine weitere Beobachtung: ++spoll crasht die Firmware
War jetzt gar nicht so schwierig zu finden und zu reparieren. ;-)
https://github.com/WilheJo-Org1/AR488/pull/5
Habe auch noch einen PR für Dieters Modifikationen gemacht. Der trennt insbesondere die idle states in "controller idle" und "device idle" auf, weil beide eine (teilweise) separate Behandlung notwendig machen. Außerdem führt er noch zwei Kommandos ein, mit denen man die Vorhaltezeit für Senden oder Empfangen konfigurieren kann.
Aber @Hans, um es nochmal ganz explizit zu schreiben: ich bin dir außerordentlich dankbar für die Initiative und das Projekt. Was bei mir inzwischen damit läuft ersetzt vollständig und erweitert meine früheren GPIB-Setups. Es ist auch wirklich gut, dass die 7516x-Interface-ICs da noch reingekommen sind, damit lässt sich problemlos selbst ein größerer Bus handhaben.
Ich habe ja auch noch den USBTMC mitgenommen damals. Eigentlich weiß ich jetzt schon gar nicht mehr richtig, wofür ich den noch brauche, so gut, wie der AR488 inzwischen funktioniert. ;-)
Alles, was ich da inzwischen als PRs eingetütet habe, versteht sich als mein kleiner Beitrag zur Weiterentwicklung des Projekts insgesamt.
Nach dem ++id name tty-esp32-<Nr> darf man ein ++savecfg nicht vergessen,
Bei mir funktioniert ein ++savecfg nicht: "EEPROM not supported." Liegt daran, dass "E2END" in ar488.ino nicht definiert ist. Ändert man das, scheint ein Speichern zu funktionieren. Beim Neustart sind die Einstellungen jedoch verschwunden. Ich bin zwar kein Programmierer, aber ich denke das liegt an der Art der Speicherung mit EEPROM.put(addr,cfgdata); das "put" bestimmt per "sizeof", wieviele Daten gespeichert werden. Da cfgdata jedoch nur ein Pointer ist, wird nur der Pointer gespeichert und nicht die cfgsize-Bytes, auf die er zeigt. Wenn ich nun das über eine Schleife mache (natürlich auch das Lesen), funktioniert es:
for (i=0; i<cfgsize; i++){ EEPROM.write(i+EESTART,cfgdata[i]);
Der Code ist allerdings auch im upstream "Twilight-Logic/AR488"-Repo vorhanden und kann meiner Meinung nicht so funktionieren. Ich denke, ich mache da mal ein Issue auf.
und dort schon gefixt, das ging schnell
Der Code ist allerdings auch im upstream "Twilight-Logic/AR488"-Repo vorhanden und kann meiner Meinung nicht so funktionieren. Ich denke, ich mache da mal ein Issue auf.
Sorry, dass ich hier so spärlich schreibe... Aber der thread verschwindet in dem Forum einfach zu schnell von der main-page....
Danke für alle fixes!
Der Problem mit dem 1. Zeichen beim IDN sollte nun upstream gefixt sein...aber anscheinend macht der esp32 neuerdings Probleme mit dem Arduino weil irgendwas im Hintergrund umgedreht würde...zumindest gibt's in UK da sehr seltsames verhalten...der Controller meldet sich per USB, gibt aber nix aus.
Wie dem auch sei, ich werde das Anfang nächster Woche mir anschauen, alles Merten und upstream weitergeben.
73
Ich sehe, dass im Twilight-Logic-Repo einige meiner Vorschläge akzeptiert und umgesetzt worden sind. Es lohnt sich also, sich mit den Details zu beschäftigen und auch Bugfixes einzureichen. ;-)
Sooo... ich habe mal alle repos wieder (im DC-pin-feature Branch) zusammengeführt.
Leider ist es immer noch so, dass ich am Rode&Schwarz SMY01 vom IDN Befehl das 1. Zeichen nicht bekomme.
Das geht mit einer älteren Version problemlos... ich bin da noch in Abklärung wo das Problem tatsächlich liegt... mit meinem SMIQ06 geht es jedenfalls.
Bei mir compiliert übrigens upstream gerade nicht... das liegt an einer falschen forward-declaration in der AR488_Eeprom.cpp.
Ich habe jetzt auch support für ein Composite-Device mit 2 CDC devices. Beispielsweise ist dann ttyACM0 für die eigentliche Kommunikation zuständig und ttyACM1 bekommt die Debug-Ausgaben.
73
OK https://github.com/WilheJo-Org1/AR488 ist jetzt wieder synchron mit upstream.
zumindest bei mir ist das Problem mit dem SMY01 gefixt. ++read habe ich nebenbei auch wieder funktional gemacht... da war auch ein bug drinnen.
73
ich weiss, bin spät dran...beim nächsten Mal würde ich mitmachen!
Tim
Ja, wird noch mal ein Batch aufgelegt? Ich würde auch mit 5 Stück mitmachen.
Ja, wird noch mal ein Batch aufgelegt? Ich würde auch mit 5 Stück mitmachen.
Der erste der fragt muss es machen, alte Internettradition. :-)
Vanye
Ja, ich habe tatsächlich vor kurzem erst wieder festgestellt, dass ich selber noch ein paar brauchen könnte...
Es wird einfach immer mehr equipment und dauernd umstecken hat den nachteil, dass man sich merken muss, wo denn nun gerade einer dransteckt :)
Wieviele würden es denn sein? Das letzte mal waren es insgesamt schon eine größere Menge...
73
Wieviele würden es denn sein? Das letzte mal waren es insgesamt schon eine größere Menge...
Hatte Dich schon per PN angeschrieben, sorry dafür ;P Ich wäre mit 5 Stück dabei. 3 brauche ich, einer Reserve, einer zum Mitentwickeln.
Ethernet wäre mir zwar noch lieber als Bäume aus USB Kabeln, aber die sind immerhin deutlich flexibler als die IEEE Kabel.
Hatte Dich schon per PN angeschrieben, sorry dafür ;P Ich wäre mit 5 Stück dabei.
Habe ich schon wohlwollend vernommen :)
Naja, nichts würde dich daran hindern die Dinger ins wlan zu setzen. Ich habe mir dazu auch schon einige gedanken gemacht... das würde aber auf ein mittelgroßes Umbauen des Dispatchers hinauslaufen, damit man das USB und Ethernet/Wlan interface trennen kann. Ich habe mir noch nicht angesehen, in welche richtung das refactoring im AR488 repo hinausläuft... vielleicht ginge das dann einfacher.
Ethernet hatte ich aber tatsächlich schon seit einiger Zeit im Auge. Nur ist dort dann wieder das mit der Versorgung ein Problem.
Bleibt die Versorgung bei USB-C, sehe ich eigentlich keinen vorteil von Ethernet ggü. WLAN.
Und das sage ich, der mit Vorliebe ein Equipment in die EMV Kammer schiebt :D
73
Ich denke tatsächlich darüber nach, die Dinger optional ins WLAN zu setzen. Ich würde aber dann ESP32 bevorzugen, die 5 GHz verwenden, weil das weite genug weg ist von dem, was ich so messen möchte. Aber erst mal benötige ich eine Menge Geräte erreichbar für Python und dann sehen wir weiter.
Einen wirklich drahtlosen GPIB Adapter find ich super praktisch, denn ich habe genug Zeugs zu reparieren, wenn es auf Rolltischen steht oder auf Drehtellern auf dem Tisch steht. Jedes Kabel weniger hilft! So einen Adapter mit LiPo Akku zu versehen ist aber auch kein Akt, der Chinamann hat mir davon genug Platinchen für andere Projekte geliefert.
Aktuell ist das ja ein überschaubares Arduino Projekt mit angenehmer Code Qualität. Es lebt vom Port vom AVR auf die ESP als Arduino Projekt weiter, wie viele Projekte. Als reines ESP Projekt hätte es direkt auf FreeRTOS laufen dürfen, ein nachträglicher Port ist aber nicht ohne.
Aber ein WLAN in der EMV Kammer hat noch mal eine andere Dimension ;P
Edit: Gabe es nicht sogar schon eine Erweiterung mit direktem Ethernet und PoE? Da hatte ich auch mal was gesehen, da hab ich aber den Faden verloren, auf welchem Stand das Projekt war und ob es je weiter gegangen ist. PoE dürfte am Ende aber EMV Technisch fast bei WiFi liegen, wenn es in die EMV Kammer geht?
:
Bearbeitet durch User
Das ist ja eine nette Überraschung, mit so einer Reaktion hatte ich nicht gerechnet. Ich würde zwei nehmen. Die Variante mit Ethernet fände ich auch klasse.
Es gibt da einen Fork vom AR488: https://github.com/Kofen/PoE_Ethernet_GPIB_Adapter
Ich muss gestehen, dass ich den nur von Hackaday, und vom EEVBlog Forum kenne. PoE kann der. Wenn man das braucht/will, würde ich dann direkt den nehmen.
Der readme nach ist der dann aber in Bauteilen auch min 2x so teuer.
Für eine Lösung dazwischen könnte ich mir vorstellen, eine 2. USB-C Buchse rein für Power vorzusehen. Es gibt nämlich folgende interessante entwicklung: https://github.com/hathach/tinyusb/issues/3810
Dann hätte man bei bedarf grundsätzlich über den USB-Host auch die möglichkeit einen 20€ usb-ethernet adapter zu verwenden.
Ich muss aber gestehen, dass ich 0 bock habe so tief in den arduino-build-wahnsinn einzusteigen nur um das schnell mal zu testen...
Viel wichtiger erscheint mir aber, dass man irgendwie die software so umbiegt, dass sie einen UART, den USB-UART und wifi "parallel" akzeptiert. Wie man vernünftig die interfaces umschaltet bzw da irgend eine art mutex einbaut, müsste man sich überlegen.
Es ist nämlich so, dass ich schon gerne z.B. SERCOS über eine PoF Faser hätte... Oder UART-Über-toslink kabel...
Aber gut, das sind hald so hirngespinnste die man so hat :)
73
SERCOS ist nun gleich mächtig oben drauf. Grob überschlägig ne Neuentwicklung der ESP/AR488 Hardware auf Basis eines STM32 und FreeRTOS und dann ein Hilscher Modul für ca 45€ drauf. Oder den Arduino-Teil raus operieren und den Hilscher Stack auf ESP32 portieren.
Trotzdem: Was mich bei IEEE488 nervt ist, dass die Kabel so fett sind und in guter Qualität leicht das Doppelte eines AR488 kosten. Aber dafür brauche ich nur einen Adapter und habe eine ganze Kette von Geräten am PC oder Netz. Was mich an IEEE/Ethernet nervt ist, dass ich überall freie Netzwerkports oder Switches haben muss.
Spinnen wir mal rum: Wenn man Master/Slave AR488 bauen würde, die man per TOSLINK verbindet und nur einer muss an Ethernet / USB sein? UART ist beim ESP32 kein Akt, seine UARTs können fast Mbit/s sind also für eine schnelle Kommunikation gut geeignet. Und wenn man das als Ring aufbaut, sollte es kein großer Aufwand sein. Ich bin aber nicht sicher, ob man einen UART mit RX und TX gleich an ein TOTX und TORX löten kann, oder ob es da noch eine Modulation braucht. Stromversorgung bleibt aber immer noch ein Thema.
SERCOS ist nun gleich mächtig oben drauf.
Ich hab mich da falsch ausgedrückt... ich hätte den UART einfach an SERCOS RX/TX Wandler drangehängt wie das "früher" bei EMV Equipment nicht unüblich war... also z.B. bei den Amplifier Research Feldsonden und Verstärkern oder den Maturo Masten und Drehscheiben.
Also z.B HFBR-1505/2505...
Wobei die dinger 1. overkill sind und 2. vergleichsweise teuer sind.
Toslink könnte man auch dafür vergewaltigen... mir das auch irgendwie "dumm" vorkommt.
Wie man es dreht und wendet, komme ich immer wieder auf die 2. USB-Buchse für "Power-In" zurück. Wenn man etwas das Netz durchforstet, dann gibt es anscheinend funktionsfähige libraries für usb-ethernet adapter. usb-serial geht auch.
Damit wäre vom billigen USB-RS485 bis zum USB-Ethernet adapter eigentlich alles möglich. Wenn man mutig ist, könnte man sogar sowas anhängen: https://shop.poetexas.com/products/gat-usbc-pd-r2v3-usbc
Das wären dann nur ein paar cent mehr für die 2. Buchse und man gewinnt dadurch tatsächlich einiges an flexibilität.
Es gibt ja schon eine plotter-emulation... mit so einer buchse könnte man dann tatsächlich was auf nem postscript drucker ausgeben :) Oder die storage-emulation, die dann tatsächlich auf einen USB-Stick zugreifen könne.
Alles andere geht irgendwie am Sinn eines billigen adapters vorbei. Ich muss mir nur ansehen, wo ich die Buchse vernünftig platzieren kann.
73
USB-Over-Ethernet geht natürlich auch. Also sowas: https://www.reichelt.at/at/de/shop/produkt/4x_usb_over_gigabit_lan_metallgehaeuse-106638
Aber ich würde mich auch erst einmal auf eine Sammelbestellung freuen und mich dann etwas hineinarbeiten in die Materie.
Dann kann man ja immer noch einen drauf legen.
Bei einer neuen Sammelbestellung wäre ich mit 4 Stück dabei.
VG
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.