> @Kai >> - Mein Multimeter (Keithley 2700) bleibt beim Start hängen, wenn der >> Adapter schon dran ist. Dessen Polling o.Ä. scheint zu stören? > > Ich kann die Beobachtung von Jörg H. (idc-dragon) bestätigen. Das > passiert immer, wenn das USB Kabel am Rechner schon angesteckt ist beim > Einschalten 2700. Probier autoid mal auf slow oder off zu stellen, das sollte helfen. Wenn du windows hast, gibt es ne GUI dazu im SW folder.
Übrigens hielt ich dieses autoid feature mal für ganz toll, danit man einen visa ressource string mit dem echten instrumentennamen hat... Da aber viele alte Geräte kein *IDN? Unterstützen stört es oft. Daher würd ich jedem erstmal blind empfehlen es abzuschalten, d.h. autoid auf off zu setzen. Die Read terminierung muss man in der Praxis selten auf was anderes als EOI stellen. Bei HP Geräten die kein EOI nutzen kann man es meist einschalten durch senden von END ALWAYS\r\n
:
Bearbeitet durch User
> Daher würd ich jedem erstmal blind empfehlen es abzuschalten, d.h. > autoid auf off zu setzen. Waere es nicht sinnvoller es per Default auszuschalten? Oder in der Firmware einen Filter fuer bestimmte Kommandos einzurichten die dann Sonderfunktionen umstellen? Vanye
Aus Backwardskompatibilitätsgründen hab ich das erstmal gelassen. Hmm, ich könnte aber evtl. am EEprom inhalt erkennen obs nen flatschneues oder bereits genutztes Gerät ist.
Achja, das geht auch mit visa kommandos. Die GUI macht nix anderes. Aber es NUR über speziel codierte visa ASCII Nachrichten zu machen war mir zu heikel, darum muss man erstmal nen pulse indicator Kommando schicken. Das ist eigentlich im USBTMC standard dafür gedacht eine LED blinken zu lassen um ein Gerät identifizieren zu können. Nur für den Fall, dass jemand kein Windows nutzt: In dem readme.md steht drin wie man das mit Visa Kommandos triggern kann auf Basis von Python code. Es gibt auch ne Linux GUI, die python basiert ist im SW Ordner. Und der windows GUI Sourcecode zeigt wie man das mit visa32.dll Kommandos machen kann.
:
Bearbeitet durch User
Sorry für die ganzen rechtschreibfehler - spreche 3 Sprachen jeden Tag und da leidet die eigene drunter + tippe oft am Handy :-)
so, ich hab noch einen AVRISP mkII hier und konnte den bootloader flashen. Dann ging ein Laufwerk auf und ich hab das testandmeasurement.bin über das flash.bin kopiert. Nach einem Neustart blinkt jetzt eine LED dauerhaft. Ist das jetzt so richtig ? Ich hab noch kein Messgerät dran. Bei 3 Sekunden auf den Taster passiert garnix. Da kommt kein Laufwerk mehr hoch.. oder geht das auch nur noch wenn es am Messgerät angeschlossen ist ? Grüße Marc
Marc G. schrieb: > Nach einem Neustart blinkt jetzt eine LED dauerhaft. Ist das jetzt so > richtig ? Ich hab noch kein Messgerät dran. Bei 3 Sekunden auf den > Taster passiert garnix. Bei mir hat es nach Anschluss an ein Messgerät auf Anhieb funktioniert. Das Fummeligste war, die Programmierpins alle gleichzeitig zu kontaktieren. Danke übrigens sowohl an den Erfinder des Adapters (Kai G. "xyphro") als auch an den Hersteller (Hans W.)!
:
Bearbeitet durch User
Marc G. schrieb: > Nach einem Neustart blinkt jetzt eine LED dauerhaft. Ist das jetzt so > richtig ? Ja. Messgerät anschließen und einschalten. Dann sollte die LED dauernd leuchten.
Max G. schrieb: > Das Fummeligste war, die Programmierpins alle gleichzeitig zu > kontaktieren. Ich hab einfach einen 2x3 Pfostenstecker genommen und die Pins ein bisschen zusammengedrückt - kein Fummeln, Kontakt perfekt... Gruss Chregu
Das ist natürlich elegant :-) Ich hatte mir für die 50 stück die ich mal gebaut hab aus USB B Buchsenkontakten, Sekundenkleber und alten Platinen schnell nen Adapter zurechtgedengelt. Für nen Einzelstück lohnt sich der 30 minütige extra Bastelaufwand nicht. Es war halt nicht mehr viel Platz übrig und der 45 grad Eckkontakt mit ISP pinout kam dem standard Wannenstecker am nächsten :-)
Kai G. schrieb: > ISP pinout Perfekt! Der Christian M. schrieb: > Pfostenstecker passt so genau auf die Buchse! Gruss Chregu
Kai G. schrieb: > Es war halt nicht mehr viel Platz übrig und der 45 grad Eckkontakt mit > ISP pinout kam dem standard Wannenstecker am nächsten :-) Ist ja auch 'ne nette Idee. Ich hatte sowas ähnliches mal in der Vergangenheit gemacht (für einen Workshop bei den Chemnitzer Linuxtagen), allerdings dann einen Adapter mit einer Pfostenleiste mit 2 mm Raster gebaut. Die passt ziemlich saugend auf eine Platine mit 1,5 mm Stärke.
Vanye R. schrieb: > avrdude -c usbasp -p m32u4 -e -Ulock:w:0xFF:m -Uefuse:w:0xcb:m > -Uhfuse:w:0xd8:m -Ulfuse:w:0xde:m Wobei das "-Ulock:w:0xFF:m" Spaß ist. Lockbits kann man nicht auf diese Weise auf '1' setzen, sondern nur durch das chip erase selbst. Sonst wären es ja keine lock bits …
Angehängte Dateien:
-
2025-02-26-21-48-45-194.jpg
210 KB
Jörg W. schrieb: > Ich hatte sowas ähnliches mal in der Vergangenheit gemacht (für einen > Workshop bei den Chemnitzer Linuxtagen), allerdings dann einen Adapter > mit einer Pfostenleiste mit 2 mm Raster gebaut. Die passt ziemlich > saugend auf eine Platine mit 1,5 mm Stärke. Der alte Adapter funktioniert natürlich auch noch :), allerdings habe ich damals offenbar die Pins versehentlich gespiegelt (1 <-> 2 etc.), daher ging es nur mit dem "squid cable". Allerdings bekomme ich beim Versuch, das bin-File in den Bootloader zu kopieren, immer ein "No space left on device" und einen abgebrochenen letzten Block. Am Ende habe ich einfach auch das binary noch mit AVRDUDE drauf geschrieben (und -D, damit der Bootloader nicht gelöscht wird). Jetzt blinkt zumindest ordnungsgemäß die LED.
> Ich hatte sowas ähnliches mal in der Vergangenheit gemacht (für einen > Workshop bei den Chemnitzer Linuxtagen), allerdings dann einen Adapter > mit einer Pfostenleiste mit 2 mm Raster gebaut. Die passt ziemlich > saugend auf eine Platine mit 1,5 mm Stärke. Das muss ich mir merken, so nen Adapter könnte ja direkt zum Abbrechen an der Platine dranhängen und lässt sich zur Not mehrfach nutzen. In der 1. Hw revision waren die programmierleitungen zu einem echten 2x3 pinheader geroutet, den man abbrechen konnte. Fand ich dann aber doof, weil man danach nie wieder ohne Fädelaktion an die spi leitungen drankommt.
Unter linux schiebt man die bin Datei am besten mit DD drauf, der bootloader hat da nen Problem - unter windos klappts mit copy. In der readme im ordner zur rev2 steht was dazu drin. Mit avdrdude direkt mitprogrammieren ist natürlich noch eleganter.
Kai G. schrieb: > Unter linux schiebt man die bin Datei am besten mit DD drauf, Hab ich gemacht, wie geschrieben, unter FreeBSD bricht der ab mit:
1 | # dd if=/tmp/TestAndMeasurement.bin of=/mnt/TestAndMeasurement.bin bs=512 |
2 | dd: /mnt/TestAndMeasurement.bin: No space left on device |
3 | 21+0 records in |
4 | 20+0 records out |
5 | 10240 bytes transferred in 0.001884 secs (5434938 bytes/sec) |
Irgendwas ist in diesem Bootloader seltsam (irgendwelche weiteren Optionen zu dd haben daran auch nichts geändert).
Probier mal: dd if=tmp/TestAndMeasurement.bin of=/mnt/FLASH.BIN bs=512 conv=notrunc oflag=direct,sync Der bootloader mapt FLASH.BIN aufs flash der MCU. Mit Testandmeasurement.bin kann er nix anfangen.
Kai G. schrieb: > Der bootloader mapt FLASH.BIN aufs flash der MCU. Mit > Testandmeasurement.bin kann er nix anfangen. Bingo! Das war's. (Die anderen Flags konnte ich mir sparen, weil ich mittlerweile eh ein paar 0xFFs an die Datei angehängt hatte.)
So nen rp2040 uf2 bootloader ist doch was sehr feines gegenüber von dem bootloader den ich genutzt habe :-) Deine Idee mit dem pinheader würd ich gern auf github posten (mit credit) wenn du damit einverstanden bist. Passt ja wie Faust aufs Auge.
Kai G. schrieb: > Deine Idee mit dem pinheader würd ich gern auf github posten (mit > credit) wenn du damit einverstanden bist. Klar, ich habe kein Patent dafür eingereicht. :-)
Kai G. schrieb: > Mit avdrdude direkt mitprogrammieren ist natürlich noch eleganter. Ich habe das so gemacht wie im README.md beschrieben:
1 | avrdude -C avrdude.conf -c avrisp -p m32u4 -P COM32 -b 19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xcb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xde:m -U flash:w:TestAndMeasurement.hex -U flash:w:BootLoader.hex |
Gruss Chregu
Christian M. schrieb: > Ich habe das so gemacht wie im README.md beschrieben: Klappte mit mir auch so nachdem ich den Inhalt von git korrekt runtergeladen hatte (siehe oben). Ich hatte auch die beiden Teile in einem File bekommen von Kai (ein perfekter Service). Aber ich war dann neugierig, sollte ja auch laut readme funktionieren. Die dd Variante unter Linux hab ich auch probiert, funktionierte auch mit den Angaben im readme.
900ss schrieb: > Die dd Variante unter Linux hab ich auch probiert, funktionierte auch > mit den Angaben im readme. Ja, das Entscheidende ist halt, dass das Ding "flash.bin" im Ziel heißen muss.
Ja musste mir die beiden Dateien auch erst zusammensuchen und habe mir dann ein Verzeichnis gemacht mit dem .conf und den .hex, so hatte ich alles sauber zusammen. Gruss Chregu PS: Mein Script ist für einen "Arduino-as-ISP". COM muss angepasst werden!
Jörg W. schrieb: > 900ss schrieb: >> Die dd Variante unter Linux hab ich auch probiert, funktionierte auch >> mit den Angaben im readme. > > Ja, das Entscheidende ist halt, dass das Ding "flash.bin" im Ziel heißen > muss. Ja. Ich hab einfach c&p gemacht. :)
Und dass FLASH.BIN in grossbuchstaben geschrieben ist, also wie früher unter DOS. Sonst legt das OS noch extra einträge im directory an was der bootloader nicht versteht. Der bootloader ist halt sehr klein und die MCU hat wenig ram.
Angehängte Dateien:
Vielleicht kann mir jemand helfen: Ich habe den Adapter an mein Schlumberger/Solartron 7150 angeschlossen. https://www.holzleitner.com/el/solartron-7150/index-de.html http://bee.mif.pg.gda.pl/ciasteczkowypotwor/Solartron/Solartron_7150_Digital_Multimeter_User_Manual.pdf ab Seite 36. Mit dem RsVisaTester und auch mit den Scripts von Hannes Beitrag "Re: Sammelbestellung USBTMC Adapter. Interesse?" kann ich auf das Messgerät senden, es reagiert (wechselt z.B. den Modus) aber ich empfange nichts! Mache ich was falsch oder ist das Messgerät kaputt? Gruss Chregu
Ich check gleich mal das manual und meld mich. Gibt es mäuseklaviere mit einstellungen auf der rückseite? Falls ja, schick mal ein foto. Unter welchem namen wird es im visa tester gefunden?
Christian M. schrieb: > Mache ich was falsch oder ist das Messgerät kaputt? Wenn du magst und es dir hilft, kann ich dir leihweise einen getestet funktionierenden Adapter schicken. Grüße Max
Christian M. schrieb: > Vielleicht kann mir jemand helfen: Ich habe den Adapter an mein > Schlumberger/Solartron 7150 angeschlossen. Ich glaub erstmal nicht, dass da was kaputt ist. Bei jedem neuen Messgerät was man ansteuert muss man erstmal etwas "fummeln" bis man die Einstellungen passend hat. Das Gerät steht standardmaessig auf U0, das heisst terminiert seine generierten Antworten mit CR + LF, also ohne das EOI Signal zu erzeugen beim letzten Datenwert. Jetzt kann man entweder den GPIB Adapter auf LF Readterminierung umstellen (z.B. mit der GUI), aber einfacher wäre es hier das Messgerät einfach auf EOI Terminierung umzustellen - das haben die vorgesehen. Mach mal folgendes: Schreibe "U3" (Das schaltet EOI Generierung ein bei Antworten - siehe Seite 44) Und probier dann nochmal ein query mit M? aus. Viele Gruesse, Kai Achja: Erstmal mit dem R&S Tester zu arbeiten ist immer eine gute Idee am Anfang, dann weiss man schnell was geht und was nicht.
:
Bearbeitet durch User
Angehängte Dateien:
-
IMG20250227185327.jpg
240 KB
Kai G. schrieb: > mäuseklaviere mit einstellungen auf der rückseite? Falls ja, schick mal > ein foto. Gruss Chregu
Kai G. schrieb: > Schreibe "U3" (Das schaltet EOI Generierung ein bei Antworten - siehe > Seite 44) > Und probier dann nochmal ein query mit M? aus. Geht nicht. Umgekehrt: wie stelle ich den Adapter auf CR/LF? Edit: Habs gefunden => UsbGpibGUI, aber die Umstellung auf LF ist nicht non-volatile. Also beim nächsten Abfragen wieder EOI... Gruss Chregu
:
Bearbeitet durch User
Max G. schrieb: > Wenn du magst und es dir hilft, kann ich dir leihweise einen getestet > funktionierenden Adapter schicken. Vielen Dank! Aber ich denke auch nicht, Kai G. schrieb: > dass da was kaputt ist. Ausserdem habe ich ja zwei hier, und könnte die Gegentesten. Aber solange wir mit dem LF/EOI nicht weiterkommen, bringt das nichts! Gruss Chregu
Ich geh erstmal von windows aus. Lad dir die usbgpibui.ex hier runter: https://github.com/xyphro/UsbGpib/tree/master/SW%2FUsbGpibGUI Die Nutzung sollte denk ich selbsterklärend sein. Probier mal LF Terminierung aus. U3 sollte es eigebtlich auch tun, solange die Kommandos zur fw version deines Gerätes passen. Evtl. Braucht der Parser vom Messgeeät beim schreiben auch ein U3\r\n
Klasse! Jo, jedes Gerät bringt erstmal wieder seine eigenen Anforderungen an Terminierung mit sich und man muss experimentieren. Das Keithley 199 hat mir die meisten Haare geraubt :-)
Christian M. schrieb: > Kai G. schrieb: >> U3\r\n > > Bingo! Das wars! Vielen Dank! > > Gruss Chregu Wenn du python nutzt kannst du \r\n als write termination einstellen, dann musst du es nicht bei jedem kommando von Hand einbauen.
Anmerkung noch dazu, Zitat von Github: "This limited the microcontroller choice to e.g. AVR or PIC controllers." Nicht exakt, es gibt ja duchaus auch Cortex-M mit 5-V-Fähigkeit, ATSAMCxxx von AtMicrochip beispielsweise.
Ja gibt es. War damals nicht auf meinem Radar. Mittlerweile halt ich den ch307 für am geeignetsten. Edit: Der AVR ist denk ich auch immer noch ne nette Wahl. Gut verfügbar und gute integration. Die Applikation ist sehr klein (kein ldo, leveltranslator), trotzdem im Rahmen der Möglichkeiten hochperformant. Mit etwas mehr ram würd man das lesen auch nochmal deutlich beschleunigen können.
:
Bearbeitet durch User
> Mittlerweile halt ich den ch307 für am geeignetsten.
Genau, mach mal eben eine neue Version. Dafuer hab ich auch schon
den Debugger rumliegen. :-)
Vanye
Ganz alleine würd ich es im Moment nicht mehr stemmen wollen nur um dann den besten, schnellsten, billigsten Adapter gemacht zu haben wo mir der alte doch reicht - mir fehlt die Zeit :-) und wenn man pech hat darf man wenns fertig ist irgendwann plötzlich keine chinesischen MCUs mehr kaufen.
Kai G. schrieb: > Der AVR ist denk ich auch immer noch ne nette Wahl. Gut verfügbar und > gute integration. Ja, ich finde die insgesamt auch nicht so schlecht. Aber ich fand daher dazumals eben auch ATSAMC interessant, weil sich (zu der Zeit noch Atmel) wenigstens mal ein Hersteller um Cortex-M mit 5-V-Fähigkeit bemüht hat. Ist ja auch an anderen Stellen interessant, kann man beispielsweise ohne zusätzliche Mittel direkt an eine LiPo-Zelle klemmen. > Mittlerweile halt ich den ch307 für am geeignetsten. Ist das der gleiche Hersteller wie CH340? Dessen Dokumentation begeistert mich überhaupt nicht (und ich habe einen chinesischen Studenten mal schauen lassen, die chinesische Doku ist nicht besser als die englische).
:
Bearbeitet durch Moderator
Kai G. schrieb: > Wenn du python nutzt kannst du \r\n als write termination einstellen, > dann musst du es nicht bei jedem kommando von Hand einbauen. Scheint (bei mir) default zu sein, denn es geht ohne und wenn ich sie eingebe, kommt eine Warnung dass sie sowieso gesendet werden! Sonst geht jetzt auch folgender Python-Script:
1 | import pyvisa as visa |
2 | rm = visa.ResourceManager() |
3 | |
4 | print(rm.list_resources()) |
5 | |
6 | psu=rm.open_resource('USB0::0x03EB::0x2065::GPIB_01_1443531313035130F0C0::INSTR') |
7 | |
8 | psu.write('U3', encoding='ascii') # \r\n wird sowieso geschickt! |
9 | psu.query('M0') # Vdc |
10 | print(psu.query('G')) |
11 | |
12 | inst_error='' |
13 | while inst_error.strip() != 'ERROR 00': |
14 | inst_error=psu.query('!') |
15 | print(inst_error) |
16 | |
17 | psu.close() |
18 | rm.close() |
Gruss Chregu
Kai G. schrieb: > Edit: > Der AVR ist denk ich auch immer noch ne nette Wahl. Gut verfügbar und > gute integration Jörg W. schrieb: > Ja, ich finde die insgesamt auch nicht so schlecht und wer günstige Gehäuse braucht bedient sich hier: https://www.ebay.de/str/aholstore https://youtu.be/IHaDNVAOMYc?list=TLPQMjgwMjIwMjVmjn06mZZFAw&t=1117 die Originalen IEEE Bustranceiver gibt es zumindest neu als SMD SN75160B SN75161B https://www.ti.com/product/de-de/SN75161B aber es gibt ja Adapterplatinen auf DIL
Habe meinen Adapter nun auch endlich mal in Betrieb genommen. Funktioniert auch noch problemlos an ein paar Metern Kabel (die ich gerade eh am Bus dran hatte). Das NiceGUI habe ich dann auch zum Laufen bekommen. usbtmc brauchte unter FreeBSD noch einen kleinen Patch (es gibt kein "detach kernel driver", da die gesamte Architektur der USB-Treiber ganz anders ist als bei Linux).
Jörg W. schrieb: > Funktioniert auch noch problemlos an ein paar Metern Kabel ähm welche USB oder GPIB?
Joachim B. schrieb: > Jörg W. schrieb: >> Funktioniert auch noch problemlos an ein paar Metern Kabel > > ähm welche USB oder GPIB? Ich meinte vor allem jetzt GPIB. Da das Teil ja keinen Bustreiber enthält, war das nicht unbedingt garantiert. (Aber Joachim, soweit ich mich entsinne, hast du keinen TMC-Adapter sondern den AR488. Damit ist das für dich eh nicht relevant, den der AR488 von Hans hat Bustreiber.)
> Ich meinte vor allem jetzt GPIB. Da das Teil ja keinen Bustreiber > enthält, war das nicht unbedingt garantiert. So hatte ich das auch verstanden. Das lange USB Kabel gehen, sollte wohl normal sein. Ich hab hier auch so 3-4m USB-Kabel. Bei den GPIP-Kabeln ist das vermutlich schon etwas ausserhalb des Entwicklungsscope gewesen. Interessant ist dann noch die Frage ob es immer und ueberrall mit jedem USB-Hub geht! Ich hab es bei mir problemlos mit einem 5x hub, aber aktive(!) laufen. Vanye
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.