Hier im Markt wurde nach einem GPIB Adapter gefragt.
Neben dem USBTMC Adapter (anderer Thread hier im Markt) war auch etwas Interesse an meinem AR488 kompatiblem USB-GPIB Adapter zu vernehmen.
Im Vergleich zum USBTMC Adapter habe ich da einen ESP32-S2 verbaut. Der ist einfach wesentlich billiger als der Mega32U4. Dazu gibts auf allen Pins ESD Dioden und das Programmieren ist einfach über USB möglich (Taste gedrückt halten beim anstecken => der ESP32 startet mit dem internen bootloader).
Preislich sollten wir hier bei 15 Adaptern auf ca. 16€/Stück kommen.
Das ganze kommt als unprogrammierte (dafür braucht man keine zusätzliche Hardware!), teilbestückte Platine.
SMD ist drauf - der GPIB Stecker muss noch verlötet werden.
Der Stecker kann ggf. noch mit 2 Schrauben zusätzlich befestigt werden.
Post macht 8,20 nach DE (3,- AT) in der Versandtasche (ich habe noch
nicht geschaut, wieviele davon in eine reinpassen würden). Falls einer
günstigere Wege kennt... nur her damit!
Also incl. Verpackungsmaterial werden das ca 10.- Versand nach DE bzw
5.- nach AT.
Wie gesagt, das sind alles Richtpreise...
Meine Intention wäre, dass man sich bei Interesse die aktuellste Tabelle
runter kopiert (zitat-funktion!) und sich einträgt.
Nächste Woche ( 5.1.2025 ) würde ich dann mal schauen, wieviele es
tatsächlich sind und auf welchen Preis wir schlussendlich tatsächlich
kommen.
Fall jemand das 3d gedruckte Gehäuse auch will... könnte ich ggf. um 1-2€
auch machen.
Übrigens: Das ist hier rein privates Vergnügen von mir!
1
| Name | Stück | Land | Anmerkung (z.B. "Brache 3d-Druck Gehäuse!") |
2
----------------------
3
| Hans- | 5 | AT | |
4
----------------------
[Edit: Die Sammelbestellung ist abeschlossen, aber der Thread diskutiert im weiteren Verlauf den Umgang mit dem Adapter selbst sowie Modifikationen.]
Post macht 8,20 nach DE (3,- AT) in der Versandtasche
Ich hätte Interesse an so einem Teil, und ich könnte auch einen Versand innerhalb von DE übernehmen. Dürfte deutlich billiger werden, sofern es in eine BüWa (Warensendung der Deutschen Post) passt.
Post macht 8,20 nach DE (3,- AT) in der Versandtasche
Ich hätte Interesse an so einem Teil, und ich könnte auch einen Versand
innerhalb von DE übernehmen. Dürfte deutlich billiger werden, sofern es
in eine BüWa (Warensendung der Deutschen Post) passt.
Hi!
Ja, das klingt gut!
Eigentlich müssten da einige (ich würde mal sagen vllt. 6) in so ein Luftpolster Kuvert (Maxi Brief) reinpassen.
Schauen wir mal, wieviele das tatsächlich werden... es gibt ja einige Möglichkeiten.
1
| Name | Stück | Land | Anmerkung (z.B. "Brauche 3d-Druck Gehäuse!") |
Du kannst es ja zu mir mit einem versicherten Paket senden, und ich verschicke es dann hier auf dem Weg, den die jeweiligen Kandidat:innen es haben möchten. Wer es mit Versicherung haben will, bekommt es als DHL-Paket, alle anderen als BüWa.
Die Kosten für dein Paket zu mir müssten wir dann irgendwie auf alle deutschen Abnehmer aufteilen.
Im Vergleich zum USBTMC Adapter habe ich da einen ESP32-S2 verbaut. Der
ist einfach wesentlich billiger als der Mega32U4.
Der Grund warum Kai bei seinem Teil den (IMHO krass nervigen) AVR verwendet hat und nicht einen coolen ARM-cortex wie wir den sonst immer verwenden, war die 5V Festigkeit weil HPIB mit 5V laeuft. Kann der ESP das ab? Haette ich jetzt nicht gedacht. Ich geb aber zu das ich von den ESPs auch das Datenblatt noch nicht gelesen habe. :-D
Ich selbst hab vor 20Jahren schon mal so einen Adapter entwickelt und damals einen PCF8574 zum Bus verwendet weil der ja auch dieses schroedelige halbweiche Buskonzept aus der MCS51 Zeit verwendet, das hat gut funktioniert, war aber natuerlich lahm.
Dann will es mir so scheinen als wenn deine Loesung ganz schoen lang ist. Damit stehen die ohnehin schon fetten alten Bootsanker noch weiter aus dem Regal als sie es ohnehin schon tun. Sollte man bedenken.
Der Grund warum Kai bei seinem Teil den (IMHO krass nervigen) AVR
verwendet hat und nicht einen coolen ARM-cortex wie wir den sonst immer
verwenden, war die 5V Festigkeit weil HPIB mit 5V laeuft. Kann der ESP
das ab? Haette ich jetzt nicht gedacht.
Schon mal die ieee488 spec gelesen?
Da steht nur >=2.4V bei -5.2mA für Output high und >=2V für Input high.
Also 3.4V typ. für Output high.
Das geht mit 3.3V ICs.
Ich würde mir aber einreden lassen da zb 390R + eine bav99 oä für nicht typische Driver noch einzubauen dazu müsste ich aber nochmal die specs durchwühlen... Das Design ist schon ein paar Jahre alt). Platz hätte ich jetzt durch den Umstieg auf das S2-mini Modul.
Wie dem auch sei, das ist nicht nur meine Meinung. Das "Problem" mit 3V3 ICs wurde im eevblog Form auch diskutiert und für nicht gravierend befunden.
Normalerweise steckt der Adapter direkt am Messgerät und es gibt keine Kabel. Das entschärft die Situation schon etwas. Ich habe aber auch schon 4 Geräte mit einem Adapter und ein paar 1m Kabel betrieben. Ging absolut störungsfrei.
Dann will es mir so scheinen als wenn deine Loesung ganz schoen lang
ist. Damit stehen die ohnehin schon fetten alten Bootsanker noch weiter
aus dem Regal als sie es ohnehin schon tun. Sollte man bedenken.
Ja, das stimmt schon. Im Gegensatz zum Usbtmc Adapter ist dafür das USB Kabel kein Problem. Das steht bei mir nämlich nicht seitlich raus und kann mit einem Kabelbinder fixiert werden.
2 gestackte Stecker sind auch nicht wiklich kürzer...
Hat schon mal jemand diesen Adapter erfolgreich mit einem etwas komplexeren Protokoll betrieben? Ich frage, weil ich mit einem Adapter gleicher Bauart (nur mit ATMega) an einem Plotter gescheitert bin (mit SN75160 / SN75161) ... :-(
Das entschärft die Situation schon etwas. Ich habe aber auch
schon 4 Geräte mit einem Adapter und ein paar 1m Kabel betrieben.
Das ist dann IMHO eine wichtige Besonderheit deines Adapters! Das Teil von Kai kann immer nur ein Geraet und es meldet sich auch vom USB-Bus ab wenn das Geraet nicht eingeschaltet ist. Allerdings bei den Preisen steckt man einfach an jedes seiner Kisten einen Adapter. Wer moechte sich schon freiwillig diese fetten HPIB Kabel antun. Die sind ja teurer wie so ein Adapter.
Aber es mag Anwendungen geben wo einem das wichtig ist.
Das ist dann IMHO eine wichtige Besonderheit deines Adapters!
Nochmal: das Original ist dieser hier: https://prologix.biz/product/gpib-usb-controller/
AR488 und auch die hier angebotene ESP32-Variante sind vom Protokoll her kompatibel zum Prologix. Das Wort "clone" (Plagiat) verwende ich nicht, da die Hardware-Implementierung unterschiedlich ist und somit auch eigene Leistung drinsteckt.
Wer sich einen GPIB-Adapter bauen will, der sollte erstmal prüfen, was er braucht. Prologix oder VISA. Software, die einen VISA-Stack erwartet, kann mit dem virtuellen COM-Port eines Prologix nichts anfangen (egal ob über USB, WLAN oder Ethernet), und was für den COM-Port geschrieben wurde läuft nicht mit VISA-Treibern.
Wer sich einen GPIB-Adapter bauen will, der sollte erstmal prüfen,
was er braucht.
Ich nahm automatisch an das jemand der sowas braucht sich seine
Software selber schreibt. :)
Aber Kollege sagte mir das das VISA Zeugs wohl auch mit Matlab
laufen soll. Hab ich selber aber nicht getestet.
BTW: Das Optimum waere natuerlich eine direkte Umsetzung von HPIB auf
Wlan. Technisch auch kein Problem. Allerdings gibt es wohl keine
Moeglichkeit aus dem Bus genug Energie zu schmarotzen und wenn man
da jedesmal ein Netzteil dran stecken muss dann kann man auch gleich
USB nehmen.
BTW: Das Optimum waere natuerlich eine direkte Umsetzung von HPIB auf
Wlan.
Auch da musst Du Dir überlegen, welches Protokoll Du nutzen willst, also welche Sprache der Adapter sprechen soll. Sowohl VISA als auch virtueller COM-Port (Prologix) laufen auch über Netzwerk.
Bisher hat der ESP32S2 das direkt am GPIO gut vertragen... ganz sauber ist das aber tatsächlich nicht...
Natürlich wäre es Gift, den USBTMC-Adapter aus dem anderen Thread mit meinem AR488 zu verbinden. Echte Hardware sollte die 5V aushalten - wirklich sauber ist das auch nicht... solang's funktioniert solls mir recht sein :D
Darum habe ich mal den Weihnachtsfrieden genutzt und etwas herumgerechnet.
Herausgekommen ist eine Schnutzschaltung, mit der das jetzt besser gelöst ist.
Ich möchte aber über den Schaltplan nochmal schlafen, bevor er "zum Review online geht".
Einzig der Receiver Pegel ist grenzwertig.
Im PDF oben steht Vih>2.0V.
Der ESP erkennt 0,75xVCC als high. Bei 3V3 also 2,475.
In der Realität habe ich mit 4 Geräten am ESP32S2 aber noch nie Probleme gehabt. Bei einem vollen Bus mit 20m Kabel und 15 Geräten wird's aber sicher grenzwertig.
Hat schon mal jemand diesen Adapter erfolgreich mit einem etwas
komplexeren Protokoll betrieben?
Was ist bei dir komplex?
Ich habe einen alten Advantest Messempfänger, 2 R&S Signalgeneratoren und zumindest ein URV4 verbunden mit einer Adruino-Nano Version vom AR488. Die ESP32S2 Boards sind meistens nur mit 1-2 Geräten verbunden, wenn ich mit dem Laptop etwas abseits vom "Turm" aufbaue.
Das rennt über Stunden ohne Aussetzer.
Bei vielen Geräten am Bus gibt es aber etwas zu bedenken.. siehe unten.
Das entschärft die Situation schon etwas. Ich habe aber auch
schon 4 Geräte mit einem Adapter und ein paar 1m Kabel betrieben.
Das ist dann IMHO eine wichtige Besonderheit deines Adapters! Das Teil
von Kai kann immer nur ein Geraet und es meldet sich auch vom USB-Bus ab
wenn das Geraet nicht eingeschaltet ist.
Hmm... das ist sicher ein Implementierungsdetail von seiner Firmware. Die AR488 Firmware sollte eigentlich auch auf seinem Board rennen. Ich verstehe aber durchaus warum man USBTMC so implementiert.
Ich hab hier auch einiges an Quirks rennen.
In dummen Kombinationen ist 90% der Kommunikation zum AR488 nur für das Umkonfigurieren zwischen den Geräten zuständig.
Wenn du einiges an Museumsstücken hast, dann wirst du zwangsweise mehr als nur die Adresse umkonfigurieren, wenn du zwischen Geräten umschaltest.
Direkte Verbindungen sind wesentlich performanter.
Daher versuche ich soweit möglich immer nur 1 Gerät am Adapter zu haben.
BTW: Das Optimum waere natuerlich eine direkte Umsetzung von HPIB auf
Wlan.
Auch da musst Du Dir überlegen, welches Protokoll Du nutzen willst, also
welche Sprache der Adapter sprechen soll. Sowohl VISA als auch
virtueller COM-Port (Prologix) laufen auch über Netzwerk.
Hmm.. man sollte eigentlich recht einfach einen wrapper dafür bauen können.
Ich habe in meiner Software das über einen einfachen OOP Ansatz erledigt. Das Interface spricht SCPI und die werden dann entweder be USBTMC oder eben AR488 abgesetz. Würde mich wundern, wenn da noch niemand etwas VISA kompatibles gebastelt hat.. also SCPI via TCP (LXI heißt das glaube ich) => USB.
Komplex für mich ist die Kommunikation mit einem Plotter, welcher Rückmeldungen zu Pufferüberlauf etc. gibt. Z.B. eine Messung starten und dann die Messergebnisse abwarten und laufend verarbeiten ist aus meiner Sicht nicht so komplex.
Kurz das Wechselspiel mit interaktiv vertauschten Rollen als Talker / Listener.
Aber dafür ist der Adapter wohl auch nicht gedacht bzw. dafür muss man sich wohl eine eigene Version entwickeln.
Mir scheinen manche Signalpegel auch recht zeitkritisch zu sein - die IEEE-488 Spezifikation ist sehr umfangreich und nicht unbedingt leicht verständlich :-( (zumindest für mich).
Komplex für mich ist die Kommunikation mit einem Plotter, welcher
Rückmeldungen zu Pufferüberlauf etc. gibt. Z.B. eine Messung starten und
dann die Messergebnisse abwarten und laufend verarbeiten ist aus meiner
Sicht nicht so komplex.
Kurz das Wechselspiel mit interaktiv vertauschten Rollen als Talker /
Listener.
Ich würde an deiner Stelle da mal im eevblog-form-thread zum ar488 zu dem Problem nachfragen. Entweder hattest du Pech mit einem Bug, oder gerät/Adapter müssen schlicht anders konfiguriert werden. Ich hatte auch schon mit widerspenstigen Geräten zu tun, bei denen die Dokus von beiden Parteien "etwas" irreführend war.
Wenn ich das richtig verstehe nutzen manche einen ar488 Adapter als Plotter Emulator... Es sollte also auch anders rum klappen...
Mir scheinen manche Signalpegel auch recht zeitkritisch zu sein - die
IEEE-488 Spezifikation ist sehr umfangreich und nicht unbedingt leicht
verständlich
Kann ich nur zustimmen! Daher bin ich auch froh, dass beim AR488 doch viele Leute mitwirken. Wenn man sich den Log vom repo ansieht, kommen da regelmäßig neue Besonderheiten hinzu.
Bei der Hardware hier ging es mir eigentlich nur um die Kosten.
Der esp32s2 ist etwas billiger als ein mega328+ch340 und wesentlich günstiger als ein mega32u4. Nebenbei braucht's zum Programmieren keine Hardware...das geht auch über USB.
Ich hatte auch einen gd32f350 am Schirm. Für den Port hatte ich aber zu wenig Zeit. Zusätzlich war da dann noch das Fiasko mit der Verfügbarkeit.
Eines ESP32 Port gab's schon... Ein paar defines zu ändern um den internen USB Port vom S2 zu nutzen erschien mir logisch und mit geringen Aufwand möglich.
AR488 nutze ich schon viele Jahre recht problemlos.
Kurzes Kabel zerschnitten und beide Seiten mit einem Arduino nano versehen - das waren meine ersten. Beide sind dann irgendwann gestorben. Eigentlich kein Wunder ohne jegliche Schutzbeschaltung.
Daher habe ich auf dem PCB ESD Dioden am USB und am gpib.
Bisher gab's keinen Ausfall.
Ein paar Kleinigkeiten möchte ich aber bei der Gelegenheit noch gerade ziehen... USB inrush current und eine saubere reset Schaltung werde ich dem ganzen glaube ich noch gönnen.
Sicher sind die Adapter im Format eines gpib Steckers auch sexy - aus platzgründen sind die aber entsprechend minimalistisch.
Wenn er schon über ein "redesign" nachgedacht wird und mechanischer Minimalismus keine Rolle spielt, weshalb dann nicht auch die GPIB Bustreiber mit einbauen (75160 + 75161)? Der Preis ist doch recht uninteressant wenn man nicht gleich 100 Stück oder mehr bauen möchte.
Die Treiber gibt es bei Mouser, kosten Stück ca. 5€.
Dann kann man sich sicher ein dass der Bus elektrisch auch richtig bedient wird.
Finde ich sauber :)
Allerdings muss Hans das ja entscheiden. Am Ende ist es "sein" Interface was er hier netter Weise angeboten hat. Und deshalb tu ich mich eigentlich etwas schwer, ihm da reinzureden.
Bei der Hardware hier ging es mir eigentlich nur um die Kosten.
Wieso eigentlich? Mich interessieren bei meinen privaten Bastelsachen die Kosten nicht die Bohne. Ist mir doch Piepegal ob der Controller 1Euro oder 5Euro kostet. Vor allem wenn man die Preise der Originaladapter kennt.
Ausserdem kostet doch der HPIB-Stecker mehr wie der Controller. :)
Bei der Hardware hier ging es mir eigentlich nur um die Kosten.
Wieso eigentlich? Mich interessieren bei meinen privaten Bastelsachen
die Kosten nicht die Bohne. Ist mir doch Piepegal ob der Controller
1Euro oder 5Euro kostet. Vor allem wenn man die Preise der
Originaladapter kennt.
Ausserdem kostet doch der HPIB-Stecker mehr wie der Controller. :)
Vanye
Das ist jetzt der Fall... geh mal ein paar Jahre zurück, als man die Controller um die 20.- vom Abzocker seines geringsten Misstrauens beziehen durfte.
Texas-Instruments SN75160BN 914 in stock
Texas Instruments SN75161BN 589 in stock
hmmm... dort habe ich natürlich nicht geschaut.
Bleibt das "Problem" mit der USB Spannung...
The USB 3.x specifications require that all devices must operate down to 4.00 V at the device port.
Das geht sich mit dem verbauten 1117 ohnehin nicht aus. Die 4.5V bei USB-2.0 aber schon.
Sagen spricht was dagegen das hier zu ignorieren und 4,75 für die Transceiver vorauszusetzen? Soweit ich das verstanden habe, sollte das nur bei unpowered us-hubs unterschritten werden.
In der Vergangenheit hatte ich Probleme mit Kunden, die ein Gerät mit älteren USB Ladegeräten versorgt haben. Da hatten Kunden welche, die grundsätzlich eine Spannung am absoluten Minimum ausgegeben haben. Das führte dann zu sporadischen Fehlfunktionen.
Bin da also ein "gebranntes Kind"..
Auf der Rückseite würden sich die 75160/75161 sicher ausgehen.
V_OH von den chips ist 3.5V. Also würde das ohne Pegelwandler mit dem ESP32 funktionieren.
Wenn niemand was gegen die 4-5€ mehr hat, baue ich das gerne ein.
Saubere Reset-Schaltung mit MAX809 und ein limit auf 100mA beim Einstecken geht sich übrigens auch aus.
Hallo! Wie bereits im anderen Thread angemerkt, würde ich auch von beiden Adaptern ein Exemplar nehmen. Gerne mit dem extra GPIB-Treiber bei dieser Variante, die paar Euro Mehrkosten stören mich nicht.
| Name | Stück | Land | Anmerkung (z.B. "Brauche 3d-Druck Gehäuse!") |
| Hans- | 5 | AT | |
| Jörg W | 1 | DE | |
| 900ss | 2 | DE | wenn möglich 2x Gehäuse bitte |
| Oliver (leromarinvit) |1 | AT | mit Gehäuse wenn möglich |
Die Treiber sind nun auf der Unterseite hinzugekommen.
Die ESD Dioden sind natürlich geblieben.
Ich tendiere fast dazu das als 4-Lagen PCB zu bestellen, auch wenn es sich in 2 Lagen noch ausgeht. Bei 10Stück macht das eigentlich fast keinen Unterschied im Preis - die Fertigung dauert halt etwas länger... mal sehen...
In Summe rechne ich mit ca. 22.- für die Teilbestückte Platine + Treiber + Stecker. Die 3 Komponenten wären dann selbst zu bestücken.
Ich habe mal den Schaltplan und ein paar Renderings angehängt... vllt. überzeugt das den einen oder anderen noch mitzubestellen.
| Name | Stück | Land | Anmerkung (z.B. "Brauche 3d-Druck Gehäuse!") |
| Hans- | 5 | AT |
| Jörg W | 1 | DE |
| 900ss | 2 | DE | wenn möglich 2x Gehäuse bitte
| Oliver (leromarinvit) | 1 | AT | mit Gehäuse wenn möglich
| Christoph H. (dd5sv) | 2 | DE | germe mit Gehäuse
| NormalZeit | 1 | DE | Gehäuse oder 3D-Files
| Dieter S. (ds1) | 1 | DE | mit Gehäuse
| Jürgen (oj_k) | 1 | DE | mit Gehäuse
| Thomas F. (tommf) | 2 | DE | gern mit Gehäuse
| Haydar B. (haydar) | 2 | DE | mit Gehäuse
| Name | Stück | Land | Anmerkung (z.B. "Brauche 3d-Druck Gehäuse!") |
| Hans- | 5 | AT |
| Jörg W | 1 | DE |
| 900ss | 2 | DE | wenn möglich 2x Gehäuse bitte
| Oliver (leromarinvit) | 1 | AT | mit Gehäuse wenn möglich
| Christoph H. (dd5sv) | 2 | DE | germe mit Gehäuse
| NormalZeit | 1 | DE | Gehäuse oder 3D-Files
| Dieter S. (ds1) | 1 | DE | mit Gehäuse
| Jürgen (oj_k) | 1 | DE | mit Gehäuse
| Thomas F. (tommf) | 2 | DE | gern mit Gehäuse
| Haydar B. (haydar) | 2 | DE | mit Gehäuse
| Sascha S. (dec) | 2 | DE |
| Paul B. (97paul) | 1 | DE | mit Gehäuse
| Name | Stück | Land | Anmerkung (z.B. "Brauche 3d-Druck Gehäuse!") |
| Hans- | 5 | AT |
| Jörg W | 1 | DE |
| 900ss | 2 | DE | wenn möglich 2x Gehäuse bitte
| Oliver (leromarinvit) | 1 | AT | mit Gehäuse wenn möglich
| Christoph H. (dd5sv) | 2 | DE | germe mit Gehäuse
| NormalZeit | 1 | DE | Gehäuse oder 3D-Files
| Dieter S. (ds1) | 1 | DE | mit Gehäuse
| Jürgen (oj_k) | 1 | DE | mit Gehäuse
| Thomas F. (tommf) | 2 | DE | gern mit Gehäuse
| Haydar B. (haydar) | 2 | DE | mit Gehäuse
| Sascha S. (dec) | 2 | DE |
| Paul B. (97paul) | 1 | DE | mit Gehäuse
| 🍅🍅 🍅. (tomate) | 5 | DE | mit Gehäuse, wenns drinliegt
| Name | Stück | Land | Anmerkung (z.B. "Brauche 3d-Druck Gehäuse!") |
| Hans- | 5 | AT |
| Jörg W | 1 | DE |
| 900ss | 3 | DE | wenn möglich 2x Gehäuse bitte
| Oliver (leromarinvit) | 1 | AT | mit Gehäuse wenn möglich
| Christoph H. (dd5sv) | 2 | DE | germe mit Gehäuse
| NormalZeit | 1 | DE | Gehäuse oder 3D-Files
| Dieter S. (ds1) | 1 | DE | mit Gehäuse
| Jürgen (oj_k) | 1 | DE | mit Gehäuse
| Thomas F. (tommf) | 2 | DE | gern mit Gehäuse
| Haydar B. (haydar) | 2 | DE | mit Gehäuse
| Sascha S. (dec) | 2 | DE |
| Paul B. (97paul) | 1 | DE | mit Gehäuse
| 🍅🍅 🍅. (tomate) | 5 | DE | mit Gehäuse, wenns drinliegt
| Name | Stück | Land | Anmerkung (z.B. "Brauche 3d-Druck Gehäuse!") |
| Hans- | 5 | AT |
| Jörg W | 1 | DE |
| 900ss | 3 | DE | wenn möglich 2x Gehäuse bitte
| Oliver (leromarinvit) | 1 | AT | mit Gehäuse wenn möglich
| Christoph H. (dd5sv) | 2 | DE | germe mit Gehäuse
| NormalZeit | 1 | DE | Gehäuse oder 3D-Files
| Dieter S. (ds1) | 1 | DE | mit Gehäuse
| Jürgen (oj_k) | 1 | DE | mit Gehäuse
| Thomas F. (tommf) | 2 | DE | gern mit Gehäuse
| Haydar B. (haydar) | 2 | DE | mit Gehäuse
| Sascha S. (dec) | 2 | DE |
| Paul B. (97paul) | 1 | DE | mit Gehäuse
| 🍅🍅 🍅. (tomate) | 5 | DE | mit Gehäuse, wenns drinliegt
| Pat A. (patamat) | 1 | DE | gerne mit Gehäuse
Hallo!
Ich würde auch gerne eins haben wollen.
Danke!
| Name | Stück | Land | Anmerkung (z.B. "Brauche 3d-Druck Gehäuse!") |
| Hans- | 5 | AT |
| Jörg W | 1 | DE |
| 900ss | 3 | DE | wenn möglich 2x Gehäuse bitte
| Oliver (leromarinvit) | 1 | AT | mit Gehäuse wenn möglich
| Christoph H. (dd5sv) | 2 | DE | germe mit Gehäuse
| NormalZeit | 1 | DE | Gehäuse oder 3D-Files
| Dieter S. (ds1) | 1 | DE | mit Gehäuse
| Jürgen (oj_k) | 1 | DE | mit Gehäuse
| Thomas F. (tommf) | 2 | DE | gern mit Gehäuse
| Haydar B. (haydar) | 2 | DE | mit Gehäuse
| Sascha S. (dec) | 2 | DE |
| Paul B. (97paul) | 1 | DE | mit Gehäuse
| 🍅🍅 🍅. (tomate) | 5 | DE | mit Gehäuse, wenns drinliegt
| Pat A. (patamat) | 1 | DE | gerne mit Gehäuse
| Josef G. | 1 | AT | mit Gehäuse
Hi, ich würde auch gerne eins haben wollen (ebenso wie von der anderen Version), danke!
| Name | Stück | Land | Anmerkung (z.B. "Brauche 3d-Druck Gehäuse!") |
| Hans- | 5 | AT |
| Jörg W | 1 | DE |
| 900ss | 3 | DE | wenn möglich 2x Gehäuse bitte
| Oliver (leromarinvit) | 1 | AT | mit Gehäuse wenn möglich
| Christoph H. (dd5sv) | 2 | DE | germe mit Gehäuse
| NormalZeit | 1 | DE | Gehäuse oder 3D-Files
| Dieter S. (ds1) | 1 | DE | mit Gehäuse
| Jürgen (oj_k) | 1 | DE | mit Gehäuse
| Thomas F. (tommf) | 2 | DE | gern mit Gehäuse
| Haydar B. (haydar) | 2 | DE | mit Gehäuse
| Sascha S. (dec) | 2 | DE |
| Paul B. (97paul) | 1 | DE | mit Gehäuse
| 🍅🍅 🍅. (tomate) | 5 | DE | mit Gehäuse, wenns drinliegt
| Pat A. (patamat) | 1 | DE | gerne mit Gehäuse
| Josef G. | 1 | AT | mit Gehäuse
| Harry R. (harry_r2) | 1 | DE | mit Gehäuse
Hi, falls noch möglich würde ich auch noch 2 mit Treiber nehmen. Wäre super!
Vielen Dank und viele Grüße,
Nick
| Name | Stück | Land | Anmerkung (z.B. "Brauche 3d-Druck Gehäuse!") |
| Hans- | 5 | AT |
| Jörg W | 1 | DE |
| 900ss | 3 | DE | wenn möglich 2x Gehäuse bitte
| Oliver (leromarinvit) | 1 | AT | mit Gehäuse wenn möglich
| Christoph H. (dd5sv) | 2 | DE | germe mit Gehäuse
| NormalZeit | 1 | DE | Gehäuse oder 3D-Files
| Dieter S. (ds1) | 1 | DE | mit Gehäuse
| Jürgen (oj_k) | 1 | DE | mit Gehäuse
| Thomas F. (tommf) | 2 | DE | gern mit Gehäuse
| Haydar B. (haydar) | 2 | DE | mit Gehäuse
| Sascha S. (dec) | 2 | DE |
| Paul B. (97paul) | 1 | DE | mit Gehäuse
| 🍅🍅 🍅. (tomate) | 5 | DE | mit Gehäuse, wenns drinliegt
| Pat A. (patamat) | 1 | DE | gerne mit Gehäuse
| Josef G. | 1 | AT | mit Gehäuse
| Harry R. (harry_r2) | 1 | DE | mit Gehäuse
| Nick (azetulan) | 2 | DE |
Ach deshalb sind vorher oben die Leerzeilen da drin gewesen? Dann klappt es auch auf dem mobilen Device hab ich gerade geprüft.
Pre-Tags sind natürlich sehr viel sinnvoller.
Sooo... bin endlich dazugekommen, das durchzurechnen.
Ich komme auf einen Gesamtpreis von 22.-
Enthalten in dem Preis ist
die Adapterplatine
die beiden SMD Treiber ICs
Verpackungsmaterial
Gehäuse gedruckt in PETG
Mit der ursprünglichen Schätzung, 16€ + 1-2€ (Gehäuse) + 4-5€ (Treiber), war ich also nicht weit daneben. :)
Versandmaterial (ESD tüte, Luftpolstertasche,...) ist im Preis jetzt schon drinnen.
Ich muss mich aber mit Jörg W. noch absprechen, wie wir den Versand nach DE am besten organisieren. Meine Idee wäre, dass ich alles schon versandfertig eintüte, beschrifte und gesammelt als Paket ihm zukommen lasse. Den administrativen "Rest" .... wir werden sehen.
Übrigens gibt's eine kleine Überproduktion von 4-Stück, die ich einmal auf meine Kappe nehme und "bevorrate"...
Meine Idee wäre, dass ich alles schon versandfertig eintüte, beschrifte
und gesammelt als Paket ihm zukommen lasse.
Das klingt gut für mich. Adressen musst du noch nicht unbedingt komplett drauf schreiben, die könnte ich auch online gleich eingeben. Ich gehe mal davon aus, dass alles zusammen in 5 cm Dicke passt – dann wäre noch die Frage an die Abnehmer in DE, ob der Versand preiswert als Maxibrief (nur Basis-Sendungsverfolgung d. h. nur in den Briefverteilzentren getrackt) oder etwas teurer als kleines Paket erfolgen soll. Kann von mir aus auch jeder individuell entscheiden.
Wenn es passt, könnte ich auch die andere Sammelbestellung nach DE übernehmen, aber da hatte sich auch schon jemand anders angeboten.
Ich vermute mal, angesichts des Gesamtpreises werden möglicherweise auch die, die in der Tabelle kein Gehäuse gewählt haben (wie ich) durchaus eins nehmen wollen – das würde die Sache logistisch ja etwas einfacher machen.
Theoretisch könnte ich gleich die Marken für die Maxi Briefe drucken und dir das nur mehr zum Einwerfen schicken... 4€ sollten dann passen.
Wobei mir das mit dem Tracking bis zum Verteilzentrum nicht klar war.
Ich habe jetzt erst diese zweite Variante bemerkt. Finde beides gut, den USB-AVR weil klein und 5V-kompatibel, den ESP32 weil der leistungsfähig genug wäre, einen Prüfablauf und/oder eine Web-Visualisierung unterzubringen. Das nächste Softwareprojekt...
Vermutlich ist die Überproduktion längst aufgebraucht, für den Fall dass nicht verhunze ich auch mal die Tabelle. Keine Ahnung, wie pre-Tags gehen, sehe ich hier nicht stehen...
Vielen Dank an Hans und die Weiterleiter!
1
| Name | Stück | Land | Anmerkung (z.B. "Brauche 3d-Druck Gehäuse!") |
2
| Hans- | 5 | AT |
3
| Jörg W | 1 | DE |
4
| 900ss | 3 | DE | wenn möglich mit Gehäuse bitte
5
| Oliver (leromarinvit) | 1 | AT | mit Gehäuse wenn möglich
6
| Christoph H. (dd5sv) | 2 | DE | germe mit Gehäuse
7
| NormalZeit | 1 | DE | Gehäuse oder 3D-Files
8
| Dieter S. (ds1) | 1 | DE | mit Gehäuse
9
| Jürgen (oj_k) | 1 | DE | mit Gehäuse
10
| Thomas F. (tommf) | 2 | DE | gern mit Gehäuse
11
| Haydar B. (haydar) | 2 | DE | mit Gehäuse
12
| Sascha S. (dec) | 2 | DE |
13
| Paul B. (97paul) | 1 | DE | mit Gehäuse
14
| 🍅🍅 🍅. (tomate) | 5 | DE | mit Gehäuse, wenns drinliegt
15
| Pat A. (patamat) | 1 | DE | gerne mit Gehäuse
16
| Josef G. | 1 | AT | mit Gehäuse
17
| Harry R. (harry_r2) | 1 | DE | mit Gehäuse
18
| Nick (azetulan) | 2 | DE |
19
| HansH (hanshein) | 2 | DE | mit Gehäuse
20
| Ludwig (hellas) | 2 | DE | mit Gehäuse
21
| Thomas Horn (flaretom)| 2 | DE | mit Gehäuse
22
| Dieter J. (djac) | 3 | DE | mit Gehäuse
23
| Jörg H. (idc-dragon) | 1 | DE | Gehäuse kann, muss nicht
FYI: für den USBTMC wurde letzter Druckjob gerade gestartet. Damit sollte ich dann auch für den AR488 am Montag mit allen Teilen fertig sein. Für beide Sammelbestellungen zusammen sind das ca. 240 Teile + etwas Reserve für unsaubere Drucke. Nächste Woche sollte alles eingetütet und versendet sein.
Nächste Woche sollte alles
eingetütet und versendet sein.
73
bist du so nett und schickst mir dann die DHL Paketnummer damit ich den Boten empfangen kann, sonst landet das Paket wieder jwd weil ich nicht in 1s an der Tür bin und öffne. Die sind hier sehr ungeduldig.
bist du so nett und schickst mir dann die DHL Paketnummer
Ja, darum möchte ich auch bitten!
Wie ich gerade bei einer anderen Lieferung hier aus dem Forum erleben "durfte" ist es DHL wider Erwarten gelungen, eine neue Packstation mit gleich schlechter Bedienbarkeit (App) aber noch eingeschränkteren Zugangszeiten zu errichten und Sendungen ungefragt dorthin umzuleiten. Mit Sendungsnummer kann ich aktiv ein kleiners Übel wählen.
Der Witz ist ja, dass ich meine Sendung auch früh um 3 Uhr aus der
Station holen kann
nicht an jeder Packstation gibt es Terminals für Eingaben, daran ist mein Nachbar letztens gescheitert, die Ausgabe klappt nur mit bluetooth Zugang aus einer vorher installierten App und wer das nicht weiß steht dumm davor!
Ich kämpfe noch mit Farnell, dass die mir die Stecker liefern...
Ursprünglich habe ich mir nichts dabei gedacht, dass die Lieferung etwas länger dauert als üblich... könnte ja mal wieder in UK was daneben gegangen sein.
Nun habe ich herausgefunden, dass die meine Lieferung zurückhalten, da ich meine Mailadresse für die Rechnungen noch nicht bekannt gegeben hätte... warum auch immer das jetzt auf einmal ein Problem ist... Die Auftragsbestätigung ist ja auch durchgekommen...
Wie dem auch sei - das wird sich hoffentlich demnächst erledigen.
Nun habe ich aber noch bad-news:
Ich hatte noch ein paar Stecker herumliegen für das ursprüngliche Design ohne SN7616x Treiber. Daher wollte ich die Zeit nutzen und die Änderungen zu verifizieren.
Dabei habe ich leider feststellen müssen, dass bei den Änderungen ein paar Fehler passiert sind.
Offensichtlich habe ich ein falsches Symbol für das Modul verwendet.
Um das zu beheben, sind 4 Signale zu trennt und 4 Brücken zu setzt.
Außerdem habe ich bei der "soft-start-schaltung", um beim Anstecken die 100mA am USB einzuhalten, die GPIB Treiber nicht berücksichtigt. Die ziehen alleine in der Größenordnung von 200mA.
Das wäre dann Brücke Nr.5.
Dazu kommen noch 4 0402 Widerstände, die man runternehmen muss (das geht super easy mit einer nicht zu feinen spitze und etwas mehr lot... dann schwimmen die Widerstände bei Kontakt regelrecht davon).
Die Änderungen sind nicht weiter schwierig (siehe Bild im Anhang) - ich kann aber verstehen, wenn man die nicht machen will.
Leider ist gerade CNY. Daher schaffe ich es nicht rechtzeitig vor meinem Urlaub eine neue Revision zu ordern.
Denjenigen, die sich die Änderung zutrauen, kann ich die Adapter schicken, sobald mir Farnell (oder Mouser, wenn das so weiter geht) die Stecker schickt.
Allen anderen kann ich anbieten nach meinem Urlaub das rauszuschicken oder das Geld zurückzuüberweisen. Ob das dann eine neue PCB Revision wird, oder ich das händisch anpasse, weiß ich noch nicht... ist eine Zeitfrage.
Denjenigen, die sich die Änderung zutrauen, kann ich die Adapter
schicken, sobald mir Farnell (oder Mouser, wenn das so weiter geht) die
Stecker schickt.
Allen anderen kann ich anbieten nach meinem Urlaub das rauszuschicken
ich wünsche die ANDERE, ich habe Zeit ich kann besser warten als löten mittlerweile.
Mail kam noch nicht.
Oben deine Fotos lassen sich bis auf das erste nicht vergrößern in 3 Browsern. Android Chrome, Android Opera und Linux Firefox. Ich sehe nur ein großes weißes Feld.
Wenn ich sie hingegen auf meinen Rechner (Linux) lade, dann kann ich sie anzeigen mit einem Bildbetrachtungsprogramm.
Scheint ein Foren-SW Problem zu sein?
Also Bild runterladen und dann anzeigen klappt. Falls da jemand noch drüber stolpert.
Also ich habe persönlich gar kein Problem mit so einer Modifikation.
Ist jetzt die Frage, wie viele sie sich nicht zutrauen. Da ich ja auch den Weiterversand in DE zugesagt habe, wäre es eventuell ja sinnvoll, dass alles in einem Paket zu mir kommt. Wenn das jetzt um die 5 oder so Leute sind, die das hier nicht selbst machen wollen, könnte ich das übernehmen. Bei 30 Exemplaren würde ich aber auch an meine Kapazitätsgrenze kommen. ;-)
Sind das Null Ohm Brücken? Sonst verstehe ich das nicht, also dass die
plötzlich übrig sind :)
1 pull-up, 1 pull-down und 2 zur Strombegrenzung.
Nachdem doch ein paar die änderung selbst umsetzten wollen, sollte ich das etwas beschreiben, was ich mir dabei gedacht habe.
Ich hätte mir überlegt das pull-up-enable Signal auch auf Controller zu legen. Das hatte ich bei einem Commodore projekt gesehen... Der ar488 unterstützt das noch nicht daher der pull up. Für GPIB reicht es das fix zu verdrahten.
Ich vermute, das hat mit dem parallel Poll zu tun. Soweit ich das verstanden habe kann, erreicht man den open-collector Zustand aber auch über eine andere Kombination der Steuersignale... So macht das die Firmware anscheinend.
Der pull-down war ein Signal, (REN oder DC... Bin Grad nicht beim PC), das man sich für GPIB sparen kann, wenn man die 2 Pins am IC verbindet steht so in der ar488 Doku).
Beide ursprünglichen Verbindungen müssen oben getrennt werden.
Das sind jetzt die beiden Brücken/Unterbrechungen auf der Oberseite. (Pull-up enable direkt auf +5V und Ren/DC verbinden)
Unten werden die beiden falschen Leitungen getrennt und die 2 freigeworden verbunden. Da hier schon die pull-downs (in form der 4x0603 arrays) vorhanden sind, braucht's die 2 einzelnen nicht mehr.
Die beiden 100R Widerstände zur Strombegrenzung funktionieren solange man die Treiber nicht verlötet hat.
Damit hat man beim einstecken nur 100mA und die großen Cs sind dank reset-baustein kein Problem mehr.
Nachdem 200mA von den Treibern höher ist als das Limit, kommt die Spannung nicht hoch.
Mit 2x 10R funktioniert das bei mir auch... Das entstehende 1A Limit macht aber der längsregler genauso.
Daher am einfachsten brücken.
ich kann die Änderung wohl selber machen (das gibt mir dann auch das gute Gefühl, es selber gebaut zu haben), aber kannst du bitte noch bessere Fotos machen, vor allem der Bereich R14/15 ist schwer zu erkennen. Da steht noch was hoch?
Nachdem ihr überhaupt schon so nett seid, das ganze zu organisieren, solltet ihr nicht auch unnötigen Aufwand haben.
Ich brauche es (beide Versionen) nicht dringend. Wenn die meisten auf eine Änderung warten wollen und(!) dies für euch einfacher/billiger/... ist, dann warte ich halt auch darauf, es ist mir gleich.
So, wenn ich jetzt noch wüsste, ob/wie man das in eine hilfreiche Tabelle packen kann....
KannSelber/BraucheÄnderung/KannWarten/braucheSchnell ??
Ich bin bei der Bestellung auch mit 2 Stück dabei, (obwohl ich noch nicht in der Liste stehe).
Ich habe kein Problem, den Umbau selbst zu löten (obwohl ich ihn noch nicht ganz verstanden hab).
Ich habe aber auch kein Problem zu warten.
Hat keine Eile bei mir.
Ihr könnt das so machen, wie es am wenigsten Aufwand macht, auch zum Weiterverschicken.
Wie viele Leute sind es denn, die den Umbau nicht selbst machen möchten / können? Bisher sehe ich nur eine Meldung von Joachim (jar).
Wie schon geschrieben, für Einzelfälle kann ich das auch mit machen. Dann kann Hans mir das Paket mit den unmodifizierten Boards hierher schicken. Für Joachim ändere ich das Board, alle anderen sende ich so weiter.
@ Wilhelm: Ich habe bisher noch keine Mail wie angekündigt bekommen. War
auch bei dem anderen Adapter mit dabei . . .
Das war ein Problem in meiner Liste... ich gehe gerade alle Mails nochmal durch zum gegenchecken. Dabei ist mir deine Nachricht untergekommen, dass du ja beide wolltest.
Ich hab die Mail jetzt noch an dich rausgeschickt.
@ Jörg W.: Deinen „Umbauservice“ würde ich gerne wahrnehmen.
Dann wären es aktuell zwei. Muss sich Hans mal äußern, ob er das damit
zu mir im Ganzen (und ungepatcht) versenden will vor seinem Urlaub.
Wenn du mir dein PCB und dann noch 6 (JAR+5 weiter von 2 Bestellern) abnehmen könntest, dann sollte ich die restlichen 17 schaffen.
Dankenswerter Weise haben doch einige auf meine Email geantwortet, dass sie das selbst schaffen... Danke nochmal!
Übrigens wär's cool, wenn das Forum hier einem für Sammelbestellungen ein paar kleine Tools bereitstellen würde... Adressen in ein DHL verträgliches CSV einzutragen ist schon eine lästige Aufgabe. ;)
Das Captcha zu deaktivieren wäre ggf. auch gut, wenn man 30 leuten schnell hintereinander PMs schicken muss... oder vllt. eine Art Gruppen-PM für den TO.
Wenn du mir dein PCB und dann noch 6 (JAR+5 weiter von 2 Bestellern)
abnehmen könntest, dann sollte ich die restlichen 17 schaffen.
Kann ich, aber es hatten ja auch einige noch hier geantwortet, dass sie das selbst können. Haben möglicherweise nicht alle eine Mail geschrieben.
Übrigens wär's cool, wenn das Forum hier einem für Sammelbestellungen
ein paar kleine Tools bereitstellen würde... Adressen in ein DHL
verträgliches CSV einzutragen ist schon eine lästige Aufgabe. ;)
So häufig sind solche Aktionen halt doch nicht. Aber fürs nächste Mal: bitte alle drum, dass sie dir in der PM eine Mailadresse zusenden, damit bist du die Captchas los. Dann möge doch noch jeder seine Versandadresse als korrekte CSV-Zeile mit in der Nachricht senden. Ich denke, dass mehr als 90 % der Leute das problemlos hinbekommen, damit musst du im Wesentlichen nur nocht die CSV-Zeilen zusammen kopieren.
Wenn du mir dein PCB und dann noch 6 (JAR+5 weiter von 2 Bestellern)
abnehmen könntest, dann sollte ich die restlichen 17 schaffen.
Kann ich, aber es hatten ja auch einige noch hier geantwortet, dass sie
das selbst können. Haben möglicherweise nicht alle eine Mail
geschrieben.
Habe ich gesehen.
Mit dir sind es 11 Leute, die das selber machen können.
Farnell hat sich jetzt doch dazu herabgelassen und meine Bestellung mit 2 Wochen Verzögerung ohne weiteren Kommentar bestätigt.
Mit etwas Glück müssten die restlichen Stecker morgen bei mir sein.
Ich würde dir dann ein Paket mit einem Berg frankierter Versandtaschen schicken.
Davon sind dann 3 offen (das wären die 6 Stück die zu adaptieren wären) + deine Bestellung.
Dazu melde ich mich aber noch per Mail bei dir bevor es soweit ist...
Ich würde dir dann ein Paket mit einem Berg frankierter Versandtaschen
schicken.
Davon sind dann 3 offen (das wären die 6 Stück die zu adaptieren wären) + deine Bestellung.
Alle Sendungen (bis auf 1ne, bei der ich noch auf eine Antwort zur Adresse warte) sind unterwegs.
Die nach AT und RO sollten automatisch von der Österreichsichen Post eine Mail bekommen. Die nach DE werden morgen oder übermorgen von mir noch eine Mail mit den Sendungsdaten erhalten... das konnte ich leider nicht der Deutschen Post "anschaffen"... dafür gibt's da einen CSV import für die Adressen, der mir viel Arbeit erspart hat.
@Jörg: Deine Bestellung ist in einer transparenten Tüte. Umzubauen ist für dich nichts... Nachdem 50% der Besteller das selber gemacht haben, sind die paar mehr bei mir zeitlich noch drinnen gewesen.
Freut mich, und, hat's durch den Briefkastenschlitz gepasst? War ja
wirklich nicht sehr dick.
ja, aber ich hatte gemessen und sollte nicht passen, aber wie heißt es doch wer mißt mißt Mist.
nun habe ich gerade das Fluke 8840a auf dem Tisch, den Adapter angeschlossen hyperterm gestartet und nun frage ich mich wie ich die Kommandos rüberbekomme weil ich die Parameter und Baudrate nicht kenne vom Adapter
Mit den Angaben von Hans auf seiner Seite zum Build und Upload bin ich nicht zurecht gekommen, weil der Build-Prozess mit einer Fehlermeldung abbrach. Seine Angaben passten auch nicht zur platformio.ini.
Folgendes Vorgehen war jedoch erfolgreich:
make AR488-ESP32-Rev4
=====================
1, Download the platformio cli toolkit from https://platformio.org/
First download script get-platformio.py and then call it:
python get-platformio.py
If you need an access to platformio from other applications, please install Shell Commands:
either:
add PlatformIO Core binary directory /home/dj/.platformio/penv/bin to the system environment PATH variable
or (if ~/.local/bin is included in PATH, the normal case):
.. kommunikation geht über USB und die
serielle wird ja nur "emuliert".
und trotzdem, mit hterm Einstellung 115k und auto CRLF nach enter klappt die Fernbedienung schon ganz passabel am Fluke 8840a.
Es klemmt bei hyperterminal mit \r\n um nichts in der Welt will das Fluke reagieren, ausser mit einer 71 auf dem Display was so viel heißt wie "gib mir richtige Kommandos!"
Ist ja letztlich irrelevant. Hauptsache du hast es einmal geschafft mit irgendeinem Tool einmal Funktionalitaet zu beweisen. Danach musst du es ja mit der Sprache deiner Wahl machen um es fuer deine Projekte nutzen zu koennen.
Der Grund warum es mit Hterm geht und Hypterminal nicht kann im uebrigen darin bestehen das du einmal alles auf einmal mit send gesendet hast und einmal alles getippt hast mit irren Timings dazwischen. .-)
Aber wie ich schonmal sagte, diese ollen Bootsanker sind eine quelle steter Freude was Abweichungen in kleinen Details angeht.
Du musst Dich halt auch mal mit
den Geräte-Adressen etc. beschäftigen.
habe ich zu wenig geschrieben?
Mit den Adressen kenne ich mich ja aus, mit hterm bin ich weitr als mit hyperterminal, mit hterm klappen 2-stellige Adressen nicht
weder mit addr 09 \r\n noch mit addr 0\r\n 9\r\n mit addr9\r\n klappt es ja sofort mit allen anderen sofort error 71 auf dem Flukedisplay
In allen Fällen geht es aber sofort in den remote Modus.
Ist noch ein Rätsel.
Wir hatten damals alle IEEE Adressen durchgescannt und jedem Gerät eine enum zugewiesen, somit konnten wir gleiche Befehle allen DVM zuweisen AC read, DC read, es war egal ob ein Fluke 8840a oder ein Fluke 8860a am Bus hing.
Wir sprachen alle Geräte über Union oder Enum an, müsste noch mal nachschauen und bekamen sofort Antwort welches Gerät die falsche Busadresse eingestellt hat oder welches Gerät nicht vorhanden ist.
Aber antworten mußte es, bis jetzt fehlen mir alle Antworten. Wenn ich erst einmal Werte lesen könnte wäre ich weiter, aber es gilt immer noch:
Mit den Adressen kenne ich mich ja aus, mit hterm bin ich weitr als mit
hyperterminal, mit hterm klappen 2-stellige Adressen nicht
weder mit addr 09 \r\n noch mit addr 0\r\n 9\r\n mit addr9\r\n klappt es
Dir ist aber schon klar, dass "\r\n" das Betätigen der <Enter>-Taste rechts an der Tastatur bedeutet und Du diese Zeichen nicht einzutippen hast? Ob Hyperterminal auf Enter jetzt CR oder CR+LF sendet stellt man in der Konfiguration ein.
Dem Prologix ist das aber egal, denn "When data from host is received over USB, all non-escaped LF, CR and ESC characters are removed and GPIB terminators, as specified by this (++eos) command, are appended before sending the data to instruments."
Wenn Dein Gerät CR+LF will, einmal "++eos 0" an den Adapter senden. "++eoi 1" schadet auch nicht. Geräte die EOI nicht auswerten, ignorieren es einfach.
Aber antworten mußte es, bis jetzt fehlen mir alle Antworten.
Das tut es erst wenn Du es ihm erlaubst: "++read"
Also z.B.
++addr 9
*IDN?
++read
Alternativ geht auch "++auto 1". Damit wird nach jedem Geräte-Kommando automatisch die Antwort abgeholt.
Alternativ geht auch "++auto 1". Damit wird nach jedem Geräte-Kommando
automatisch die Antwort abgeholt.
unter hterm schon mal nicht
aber unter hyperterminal hat das Fluke Werte ausgespuckt, ich bin echt froh.
Warte aber noch auf die LED replacements wenn das mal kein Fake ist, soll im Versand sein tracking ist momentan aus -> 404 und es soll aus der Ukraine kommen, alles sehr merkwürdig, hoffen wir mal das der Käuferschutz greift, soll bis zum 14.3. kommen.
Der Sourcecode des Controllerprogramms enthält noch folgenden Fehler:
Jedes Commando an den Controller muss ja mit "\r\n", "\r" oder "\n" abgeschlossen werden. "\n" funktioniert aber nicht. Das folgende Testprogramm
"getver.c" hängt dann im read. Aufzurufen mit strace ./getver /dev/ttyACM0, dann sieht man das genau (auf anderen Linuxversionen kann das Device auch /dev/ttyUSB0 heißen, Adapter einstecken und ls /dev/tty*).
1
#include<stdio.h>
2
#include<stdlib.h>
3
#include<unistd.h>
4
#include<string.h>
5
#include<fcntl.h>
6
7
#define maxbuf 50
8
9
intmain(intargc,char**argv)
10
{charbuf[maxbuf];
11
intn;
12
intfd;
13
14
fd=open(argv[1],O_RDWR);
15
write(fd,"++ver\n",6);
16
n=read(fd,buf,maxbuf-1);
17
buf[n]=0;
18
n=strcspn(buf,"\r\n");
19
buf[n]=0;
20
printf("%s\n",buf);
21
return0;
22
}
Der Fehler ist in der Methode "parseInput" (Zeile 120) in controller.cpp. Das "break;" muss auskommentiert werden:
1
uint8_tController::parseInput(charc){
2
3
uint8_tr=0;
4
5
// Read until buffer full (buffer-size - 2 characters)
6
if(pbPtr<PBSIZE){
7
// Actions on specific characters
8
switch(c){
9
// Carriage return or newline? Then process the line
10
caseLF:
11
// just ignore LF for now...
12
// break; uncommented in the original source
13
caseCR:
14
// If escaped just add to buffer
Das ist weder kompatibel zum Prologix Adapter noch entspricht es den Ausführungen im Manual und ist von Bedeutung wenn man jede Menge Messsoftware hat, wo entsprechend des Unixstandards die Kommandos mit "\n" abgeschlossen sind.
Weiterer Hinweis:
Wenn die Adapter noch jungfräulich sind, dann werden sie vom Betriebssystem nicht erkannt, lsusb zeigt nichts an. Man muss erst den Bootloader mit den zwei Tastern auf der Platine aktivieren. Ein direkter Download der Software danach führt jedoch zu einer Fehlermeldung, sinngemäß wird gemeldet, dass man einen Reset durchführen muss, damit das Programm aktiv wird. Das stimmt auch, aber das Programm ist bereits erfolgreich geladen und ein Strom aus/an aktiviert es.
Wenn die Adapter noch jungfräulich sind, dann werden sie vom
Betriebssystem nicht erkannt, lsusb zeigt nichts an. Man muss erst den
Bootloader mit den zwei Tastern auf der Platine aktivieren.
hmmm erinnert mich an die ESP32 die ich mal geliefert bekam:
Jedes Commando an den Controller muss ja mit "\r\n", "\r" oder "\n"
abgeschlossen werden. "\n" funktioniert aber nicht.
Mal aus der Anleitung meines Keithley 199
Y0 CR LF
Y1 LF CR
Y2 CR
Y3 LF
Wuerde mich nicht wundern wenn es auch noch Geraete gibt die garnichts davon verwenden. :-D Aber besonders LFCR ist natuerlich pervers.
Aber man muss da wohl in der Praxis mit allem rechnen und natuerlich ganz besonders wenn man irgendeine alte Kiste in Betrieb nimmt weil man nicht weiss was der Vorbesitzer da eingestellt hat.
Oh...und das Keithley fuehrt so uebergebene Kommando auch nicht aus! Erst wenn es ein R fuer Run bekommt. Je aelter ein Teil ist umso interessanter sind die Leichen die man im Keller finden kann.
hin zum Controller:
die Zeichen oder Zeichenkombination aus \r und \n dient dem Controller zur Endeerkennung eines Befehls oder einer Befehlserie, gleichgültig ob er nun für den Controller oder das Device bestimmt ist. Ein Kommando für den Controller
wird immer durch "++" eingeleitet. Zur Übertragung von Binärdaten muss deshalb den Bytes, die ein \r, \n, ESC oder + codieren ein ESC vorangestellt werden, damit sie in der Message an das Device erhalten bleiben und nicht vom Controller interpretiert/entfernt werden.
vom Controller zum Device
Ist das Kommando für das Device werden die \r und \n entfernt und an ihre Stelle wird als Endeerkennung die Zeichenkette angehängt, die über ++eos definiert ist.
Eine Bedeutung hat das für neuere Geräte kaum, weil die meist alle Kombinationen von /r und /n gutmütig hinnehmen, nicht unbedingt aber die von Vanye erwähnten alten Dinosaurier. Als weitere Besonderheit soll es wohl Geräte geben, die zur Endeerkennung einer Message das EOI Signal benötigen. In diesem Fall ist ++eoi 1 zu setzen. Am besten fährt man mit ++eos 2 (\n) und ++eoi 1. Damit dürften 99% der Geräte zurechtkommen.
also würde ein Gerät ansprechen so aussehen?
(...)
Damit das so funktioniert, muss "++auto 1" sein. Ich glaube, das ist die Default-Einstellung. Ansonsten musst Du nach jedem Befehl ans Gerät einmal "++read" senden, damit der Adapter die Daten abholt. Mit "++auto 1" schickt er das read ohne explizite Aufforderung.
Hat jemand eine Kurzanleitung für Dummies, wie man damit einen Plotter realisiert? Ich habe hier einen Advantest-Spekki, den ich nicht zu großartiger Kommunikation bekomme. Der Vorbesitzer hat mir aber versichert, dass er über GPIB die Messdiagramme auf einen (virtuellen) Plotter ausgeben konnte.
Das hier sollte es können ("An Intelligent Plotter Emulator for
HP-GL/2-Compatible Instruments"):
Danke, mal gucken. Damit hatte es wohl der Vorbesitzer des Spekkis gemacht, aber ist halt Windows-only, daher hatte ich mir das nie ernsthaft angesehen.
Danke, mal gucken. Damit hatte es wohl der Vorbesitzer des Spekkis
gemacht, aber ist halt Windows-only, daher hatte ich mir das nie
ernsthaft angesehen.
Die Anforderungen an das Windows API sind minimal, das sollte Wine oder Ahnliches hinbekommen. Und aus dem Source Code ist vermutlich auch schnell eine Variante gebaut die ohne GUI auskommt und nur das Bild in eine Datei abspeichert (was das GUI bereits kann).
Ja, hat geklappt. Die .exe startet auch unter Wine, aber ich muss erstmal gucken, wie ich den so konfiguriere, dass er den AR488 an (fiktiver) COM2 findet.
Ja, hat geklappt. Die .exe startet auch unter Wine, aber ich muss
erstmal gucken, wie ich den so konfiguriere, dass er den AR488 an
(fiktiver) COM2 findet.
Irgendwie bekomme ich das nicht hin. Habe aber mal einen neuen Thread aufgemacht:
Da scheint es Probleme zu geben, wenn die serielle Schnittstelle kein CTS anlegt nach dem Öffnen. Das scheint aber hier bei der CDC tatsächlich nicht zu passieren. Wenn ich den AR488 im Kermit öffne und mir den Status ansehe, bekomme ich:
1
Carrier Detect (CD): Off
2
Dataset Ready (DSR): Off
3
Clear To Send (CTS): Off
4
Ring Indicator (RI): Off
5
Data Terminal Ready (DTR): On
6
Request To Send (RTS): On
Lässt sich das eventuell in der Firmware korrigieren, dass nach dem Öffnen der Schnittstelle durch den Host CTS aktiviert wird?
Ich bin mir sicher, dass man das machen könnte... Aber von der Arduino-CDC Implementierung habe ich zu wenig Ahnung.
Kannst du nicht die flow control komplett abdrehen? Wenn nicht, müssten auch alle anderen Arduino/avr basierten Boards Probleme haben, da ja in den allerwenigsten fällen die entsprechenden Pins belegt sind oder usb-serial Bridges verwendet werden, die das zuverlässig können.
Kannst du nicht die flow control komplett abdrehen?
Dafür muss ich erstmal einen Crosscompiler für den Windows-Sourcecode bekommen. Früher hatte ich mal MinGW32 dafür, aber der wurde unter FreeBSD mittlerweile abgekündigt, da das Projekt schon lange aufgegeben worden ist.
Ist auch noch nicht ganz klar, ob es das ist. Im Parallelthread gab es noch den Hinweis, die Antwort auf die Versionsabfrage zu ändern. Schau ich mir auch an.
Btw., da wir ja gerade über die CDC reden, gibt es eine Möglichkeit, da eine USB-Seriennummer zu setzen? Der String-Descriptor für die Seriennummer ist implementiert (also nicht nur weggelassen worden), aber die Nummer ist 0.
1
# usbconfig -d 4.11 -v
2
ugen4.11: <Espressif Systems ESP32S2DEV> at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)
Der String-Descriptor für die
Seriennummer ist implementiert (also nicht nur weggelassen worden), aber
die Nummer ist 0.
Weglassen darf man die Nummer sowieso nicht, 0 steht für undefined. Es muss also GetDeskriptor (String) mit der ID 3 implementiert werden, dann kann man das Feld im Devicedescriptor auf 3 stellen.
wg CTS:
Das ist ein Setup Request (CLASS) mit Reciepient Interface
Sieht in etwa so aus (wenn CDC Control Interface 1 ist):
0x21 0x22 0x03 0x00 0x01 0x00 0x00 0x00
0x03 setzt RTS (Bit1) und DTR (Bit0)
Das ist aber nur wichtig wenn man mit CDC auch eine physikalische RS232 Schnittstelle anspricht
Sind die String Descriptoren bei CDC verpflichtend? War mir jetzt nicht
bewusst. (Bei MSC hatte ich das so in Erinnerung.)
SerialNo sind nur bei MSC mantory. Sie helfen aber bei CDC beim Comport Durcheinander. Ohne SN vergibt Win dem CDC Device beim Anstecken für jeden USB Port eine neue Comport Nummer. Auch bei Midi ist das sehr zu empfehlen.
Sie helfen aber bei CDC beim Comport Durcheinander.
Keine Frage. Daher möchte ich ja gern eine haben. ;-)
Keine Ahnung wie das Linux macht.
Wenn es eine Seriennummer gibt, wird ein Symlink angelegt, der dann jedesmal der gleiche ist, egal wo man es ansteckt. Unter FreeBSD habe ich einen Script gebaut, der das ähnlich macht, aber da kommt jetzt halt immer /dev/cu.0 raus, was ich nicht schick finde. :-) MacOS macht das vergleichbar, ein persistenter Namen, wenn die Seriennummer da ist, sonst wird mehr oder weniger einer erfunden.
Der ESP hat doch sicherlich eine UID. Diese würde ich in einen USB String wandeln und dann einfach beim entsprechenden String Request zurück liefern,
Ich mache sowas z.B. bei meinem usbAsp Clone so.
Es gibt eine einfachere Möglichkeit unter Linux ohne die Sourcen zu ändern:
interaktiv die id name setzen:
++id name tty-esp32-1
der String ist frei wählbar, wenn man mehrere AR488 betreibt, sollte er eine Gerätenummer enthalten, die man auch auf dem Adapter anbringt (Filzstift).
Den Pfadnamen /work/bin/getname entsprechend der lokalen Gegebenheiten anpassen.
Auf manchen Linux-Versionen heißen die ttyACM<x> auch ttyUSB<x>.
Das Ergebnis ist, dass in welcher Reihenfolge der Adapter auch angeschlossen wird und gleich an welchem USB-Input, es entsteht immer ein Symlink /dev/tty-esp32-<nr>.
Nach dem ++id name tty-esp32-<Nr> darf man ein ++savecfg nicht vergessen, sonst ist nach nächsten Hochlaufen des Adapters der zugewiesene Name wieder vergessen.
Ja, ein paar müssten noch da sein... Bin aber diese Woche noch im Urlaub einige 1000km weg vom büro.
Am besten schickst du mir eine PM mit Mail-Adresse, dann melde ich mich, wenn ich wieder einen Überblick habe (da waren noch ein paar andere Anfragen).
Durch den Rev4 Rework wird DC (Direction Control) des SN75161BDW nicht durch einen separaten Pin des ESP32 gesteuert sondern es wird das GPIB REN (Remote Enable) Signal vom ESP32 verwendet. Das ist als mögliche Option hier unter "SN7516x GPIB transceiver support" beschrieben:
DC (Direction Control) des SN75161BDW schaltet zwischen "Controller" (DC ist Low) und "Device" (DC ist High) um.
Wenn der Adapter als "Controller" konfiguriert ist gibt es nur eine kleine Einschränkung, REN des GPIB Bus kann nicht per "++ren" gesteuert werden, REN ist dauerhaft "asserted", also aktiv (Low).
Wenn der Adapter als "Device" konfiguriert wird dann wird das REN Signal des Adapters zum Eingang, das REN Signal vom Mikrocontroller wird als Input mit Pullup konfiguriert und sollte so eigentlich DC auf High Pegel bringen. Das funktioniert aber zumindest bei mir nicht, erst mit einem zusätzlichen 1 kOhm Pullup auf Vcc funktioniert es. Allerdings kann das REN Signal des GPIB Bus auch DC umschalten und dann gibt es sehr wahrscheinlich Probleme.
Für einen Test soll der Adapter als "Device" einen Plotter emulieren, dazu werden ihm dann vom Gerät die Plotter-Kommandos geschickt. Ohne den zusätzlichen Pullup geht das bei mir gar nicht, mit Pullup nur teilweise weil REN vom Gerät auch mal kurz "asserted" wird, also aktiv und damit Low wird, was DC auf den falschen Pegel für ein Device bringt.
Erst mit einer dauerhaften Verbindung von DC per Pullup nach Vcc klappt es dann problemlos, was allerdings keine Lösung ist da der Adapter nun dauerhaft "Device" ist. Die saubere Lösung wäre dass man DC von einem separaten Pin des ESP32 ansteuert, das habe ich aber noch nicht im Detail untersucht ob und wie einfach das möglich ist (es gab ja vermutlich einen Grund warum der Rework so gemacht wurde).
das habe ich aber noch nicht im Detail untersucht ob und wie einfach das
möglich ist (es gab ja vermutlich einen Grund warum der Rework so
gemacht wurde).
Ich glaube, die uart-pins sind auch auf Pads rausgelegt... Hat halt andere Nebeneffekte. Das mit dem device war mir zu dem Zeitpunkt nicht klar - die readme habe ich aber so gelesen, dass es keine Einschränkungen gibt
Erst mit DC dauerhaft auf high kann ich einen Plot vom Spektrumanalysator empfangen. Die UART-Pins habe ich gefunden, aber ich könnte mir sicher auch einen anderen GPIO anzapfen. Muss ich mir wohl mal PlatformIO antun, hatte ich vor ein paar Jahren das letzte Mal in den Fingern.
Mist, die Toolchain für den ESP gibt's im PlatformIO mal wieder nicht für FreeBSD. :(
Was mich am Sourcecode wundert:
1
//#define SN7516X
2
//#ifdef SN7516X
3
// #define SN7516X_TE 7
4
// #define SN7516X_DC 13
5
// #define SN7516X_SC 12
6
//#endif
So steht es im AR488_Config.h. T_TE geht laut Schaltplan an IO17. Wo wird das in der Firmware verdrahtet?
Ich würde ja dazu tendieren, GPIO0 als DC zu benutzen. Das ist zwar der Bootloader-Button, aber der sollte ja im normalen Betrieb keine Relevanz haben, oder?
Warum ist an IO45 und IO46 jeweils ein Pulldown? Könnte man nicht eventuell einen davon für DC verwenden?
Nachtrag: IO45 ist der "Strapping Pin" für "VDD_SPI voltage", IO46 ist der "Strapping Pin" für "ROM messages printing" und zusammen mit IO00 für "Chip boot mode". IO45 sollte sich ja eigentlich gut für DC eignen, SPI wird ja nicht verwendet und irgendwelche Auswirkungen auf "VDD_SPI voltage" daher nicht stören.
Ah! Man darf nicht wie beschrieben mit -e esp32dev compilieren, sondern einfach ohne Angabe eines Environment. Default ist dann AR488-ESP32-Rev4, und das lässt sich auch compilieren.
Ja, die könnte man grundsätzlich auch verwenden (post-boot). Hat alles vor und Nachteilen... Ich dachte mit der gewählten Variante wäre das am ausgewogensten...
Ja, die könnte man grundsätzlich auch verwenden (post-boot). Hat alles
vor und Nachteilen... Ich dachte mit der gewählten Variante wäre das am
ausgewogensten...
unter "SN7516x GPIB transceiver support" ist offensichtlich für die Variante "REN" zum Ansteuern von "DC" zu verwenden falsch. Das funktioniert nur für einen "Controller", beim "Device" bestenfalls dann wenn auf dem GPIB Bus "REN" nicht aktiviert wird (Low) und damit DC wieder für einen "Controller" umschaltet.
Vermutlich wird diese Schaltungsvariante kaum verwendet und hat beim Testen zufällig als "Device" funktioniert weil "REN" auf High blieb.
Die Beschreibung hier
https://sdfa3.org/david/ar488/configuration.html
unter "SN7516x GPIB transceiver support" ist offensichtlich für die
Variante "REN" zum Ansteuern von "DC" zu verwenden falsch. Das
funktioniert nur für einen "Controller", beim "Device" bestenfalls dann
wenn auf dem GPIB Bus "REN" nicht aktiviert wird (Low) und damit DC
wieder für einen "Controller" umschaltet.
Wenn ich zurück bin, werde ich das Mal upstream (also über den eevblog thread) Posten, damit das zumindest in der readme so steht.
Was mich aber wundert ist, dass er aus dem device mode oft nicht zurück
findet. Das sollte ja jetzt eher nicht an den 10 µF liegen.
Warum nicht? Im Device Mode ist der Kondensator aufgeladen, die Frage ist was passiert wenn er beim zurückschalten durch den IO Pin auf Masse gezogen wird. Eventuell dauert der Vorgang zu lange, dann könnten bereits fertig konfigurierte Ausgänge des ESP32 auf noch nicht nach Eingang umgeschaltene Pins des Treibers treffen.
Ich tendiere immer noch zu IO45, bin aber noch nicht dazu gekommen das zu testen.
Habe ich gemacht, funktioniert soweit, die Timeout-Meldungen sind aber
die gleichen wie schon mit GPIO0.
Könntest Du bitte das fertige ESP32 Binary für IO45 hier hochladen, dann muß ich nicht erst PlatformIO für den Build installieren? Damit könnte ich schneller testen weil ich nur das Binary in den ESP32 laden muß. Danke.
GPIO47 oder GPIO48 sollten sich ebenfalls benutzen lassen – die sind ja beim "rework" abgetrennt worden von ihren vormaligen Signalen am 75161 (im Schaltplan noch als T_IFC und T_DAV bezeichnet). Allerdings ist nach dem Durchtrennen nur noch ein schmaler Leiterzug übrig, auf den man dann einen Draht löten müsste, nicht so ein schönes Pad wie bei GPIO45.
Erster kurzer Test zu der Firmware von oben: kann es sein dass es die falsche Version ist und deshalb die Fehler auftreten? Die original Version aus dem Adapter ist im Anhang (aus dem Flash Dump ab 0x10000 extrahiert).
Zu GPIO47 oder GPIO48: die gibt es bei dieser ESP32 Variante nicht, daher der Rework (ich habe es so verstanden dass das falsche Symbol im Schaltplan verwendet wurde).
Ein Test mit dem HP8569B zeigt mit der Firmware von oben (firmware.bin) und DC an IO45 das selbe Verhalten (Adapter als "Device", "++mode 0"), sobald "++lon 1" (Listen Only) geschickt wird kommen immer wieder die folgenden Meldungen:
1
Bytes read: 1
2
Timeout waiting for sender!
3
gpibReadByte: timeout waiting for DAV to go LOW
Es werden aber dennoch weiterhin die Plotter-Kommandos vom HP8569B empfangen, auch wenn es nicht mehr möglich ist weitere "++" Kommandos im Terminal einzugeben.
Eventuell ist das ja noch ein Bug in dieser Variante des Source Code, da die "Arduino" Variante wohl neuer ist könnte er dort behoben sein.
Die Arduino Variante verhält sich auf den ersten Blick wie gewünscht, ich bekomme zumindest das selbe Verhalten mit dem HP8569B, das Binary ist im Anhang (DC gesteuert von IO45).
Wenn man dem hp2xx noch passende Kommandozeilenargumente mitgibt, dann bekommt man auch farbige Plots. ;-) Die sehen übrigens auch besser aus als die von 7470.exe, womit sich der Thread mit dem Compilieren der KE5FX-Software dann auch erledigt hätte. Da bau ich mir lieber meinen Python-Wrapper um das alles herum.
So viel anders sieht das jetzt auch nicht mit 7470.exe aus, die Farben kann man nach Bedarf einstellen. Und was der Plot dann darstellt bestimmt sowieso das jeweilige Gerät.
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. Gerade mal zwei Geräte habe ich jetzt am Bus, das dritte reagierte gar nicht, aber dort habe ich jetzt den USB-TMC-Adapter genommen.
Mit der PCI-GPIB-Karte konnte man einfach irgendein Kabel benutzen und die haben alle funktioniert. Aber ich brauchte eben immer noch einen extra Computer dafür … irgendwie scheinen die Bustreiber dort aber besser funktioniert zu haben als hier beim AR488.
irgendwie scheinen die Bustreiber dort aber
besser funktioniert zu haben als hier beim AR488.
Hans sein AR488 arbeitet mit den ESP32 Ports und Serienterminierung oder nennen wir es Schutzbeschaltung.
Diese scheint mir schwächer zu sein als die ursprünglichen SN75160/161/162 wie sie im Commodore oder auf HP IEEE Karten verbaut waren, von daher wundert mich die Einschränkung von 2 Geräte nicht.
Da es die SN75160/161/162 zumindest noch als SMD gibt und DIL Adapter Platinen wäre sowas vielleicht schöner, ich weiß ist nicht die Minimalpreislösung aber vielleicht stabiler für Menschen mit mehr Messgeräte.
Ich bin leider noch nicht soweit und wenn überhaupt reicht mir 2 Geräte Betrieb Spannung/Strom oder Generator/AC-DVM, aber auch alle Geräte am Bus, 3 DVM + Generator wäre schick.
Joachim, sorry, bitte schau dir erstmal die Schaltung an.
sorry hatte ich doch, jedenfalls auf dem Adapter den ich von Hans bekam, aber vielleicht habe ich das verwechselt mit dem Schaltplan den ich gefunden hatte, ich recherschierte auch diese Terminierung/Schutzbeschalting
Ich bin vielleicht etwas durcheinander?
Ich sehe halt nur was ich an Infos bekomme!
https://www.diyemc.com/Products/Esp32s2Ar488/Esp32Ar488.pdf
kein U1, kein U12
aber offensichtlich etliche H5VU25U
sorry wie auch das mit den 404er Webseiten (was du dann bestätigt hast) ich kann nur sehen was mir bekannt ist.
wenn die SN75er chips bei mir auf dem Board sind (schlecht lesbar) weiß ich ja nicht wie es bei dir aussieht, ausserdem stehe ich dazu im Fehlerfall die SN75er tauschbar auf DIL Adapter im DIL Sockel wäre wartungsfreundlicher.
Was ist nun bei dir bestückt mit oder ohne SN75?
wir sollten an besserer Kommunikation arbeiten ;-)
Daher wundert mich auch etwas, dass der Aufbau eines größeren Busses
damit doch etwas problematisch ist.
Ich vermute, es ist das Timing wie die SW die Bussignale ansteuert/verarbeitet. Da ist evtl. etwas ganz auf Kante oder gar aüßerhalb der Spezifikation und wenn jetzt zuviele Geräte daran hängen, dann gibt's Ärger mit dieser "Kante".
An den Treibern wird es wohl eher nicht liegen.
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. Ich glaube es hing aber mit dem Devicemode zusammen. Konkretes hab ich vergessen (*). Ich habe mir damals einen der ersten überhaupt entwickelten Adapter gebaut. Da werkelte auch ein AVR mit diesen Bustreibern.
Das Bild weiter oben ist "Rev 3", dazu steht auf der Webseite:
"This was never built... I opted to go directly to Rev 4 after someone on the mikrocontroller.net forum mentioned to me that the SN7516x drivers are available again..."
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.
Sind natürlich drauf genauso wie bei dir. Und nein, programmierte Wackelkontakte (also ICs in Fassungen) muss ich auch nicht haben. Welche der früheren GPIB-Karten aus den PCs hatte denn die Treiber-ICs in Fassungen? Ich kenne keine. Sind da jemals welche bei jemandem durch normalen Betrieb kaputt gegangen?
