Hallo, ich nutze seit vielen Jahren das Tool HTerm in WinXP und Win10 und hatte bisher keine Probleme. Im Lauf der Jahre hat das Win10 viele updates durchlaufen und auch damit hatte ich keine Probleme. Die letzte Version ist Win10Pro Version 2004 Build 19041.572. Nun muß aber bei einem der updates etwas geändert worden sein, was HTerm Probleme bereitet. Leider weiß ich auch nicht welches update es war, da ich HTerm nur hin und wieder brauche. Es gibt ja ein schönes UART Testprogrogramm das zuerst sendet und dann auf Antwort wartet. Dieses Programm nutze ich immer wenn etwas nicht richtig funktioniert. Das Problem: Der gesendete Text kommt ordnungsgemäß an, aber Antworten nur bei niedrigen Baudraten. Wenn sie ankommen, sind alle Zeichen doppelt und zwischendurch fehlen immer welche. Ich meine ich habe schon ziemlich viel probiert, d.h. Baudraten und Takt geändert, HTerm neu installiert (Version 0.8.5), RTS ein und ausgeschaltet, aber es ändert sich nichts. In WinXP funktioniert nach wie vor alles ohne Probleme. Hat jemand eine Erklärung?
Gast
#6452051
Mal einen anderen USB to Uart Chip ausprobiert an einem anderen USB Port? Ich greife immer zum FTDI wenn mir was merkwürdig erscheint das ich nicht klar verorten kann. Ich benutze auch Hterm in der aktuellen Version unter WIN10 und habe diese Problem derzeit nicht. (CH340 Wandler)
Gast
#6452070
Bruno M. schrieb: > Es gibt ja ein schönes UART Testprogrogramm das zuerst sendet und dann > auf Antwort wartet. Dieses Programm nutze ich immer wenn etwas nicht > richtig funktioniert. Welches ist das und wozu soll das deiner Meinung nach genau gut sein? Der normale und sinnvolle Test erfordert kein zusätzliches Programm, sondern nur ein (bis max. drei) Stücke Draht, um einen lokalen Loopback zu erzeugen. Dann kann man nämlich mit HTerm (oder auch irgendeinem beliebigen anderen Terminalprogramm) senden und in demselben Terminalprogramm die "Antwort" checken. > Hat jemand eine Erklärung? Ja: Du weißt nicht wirklich, was du da eigentlich tust. Ich kann nur sagen, dass HTerm auch mit Windows10, Build2004 und aktuellem Patchlevel dieses Builds in vollem Umfang funktionsfähig ist. Was wenig überraschend ist, da Microsoft schon seit ewigen Zeiten nichts mehr am Code des COMM-API geändert hat. Allerdings: es ist immer auch der Treiber für die benutzte COM-Schnittstelle involviert. Und diese Treiber können durchaus auch im Rahmen von Windows-Updates "aktualisiert" werden, wenn man das nicht in weiser Voraussicht explizit verbietet... Und dann kann natürlich beliebiger Scheiß passieren. Typisch sind Bemühungen von UART-Schnittstellenherstellern, den Einsatz "veralteter" (und vor allem: massenhaft billig geclonter) Hardware zu unterbinden als Ursache für plötzliche "unerklärliche" Probleme...
Ich habe einen zweiten Win10 Rechner, den ich selten nutze, daher ist dort noch Build 19041.450 drauf. Ich habe es soeben mit identischer Hard- und Software an diesem Rechner probiert und es geht ohne Probleme bis 250000 Baud.
Gast
#6452075
Bruno M. schrieb: > Ich habe einen zweiten Win10 Rechner, den ich selten nutze, daher ist > dort noch Build 19041.450 drauf. Ich habe es soeben mit identischer > Hard- und Software an diesem Rechner probiert und es geht ohne Probleme > bis 250000 Baud. Dann mach' doch einfach da auch mal ein Windows-Update... Das kann doch nicht so schwer zu begreifen sein...
c-hater schrieb: Natürlich c-hater! Die üblichen schlauen Sprüche, aber nichts was einem wirklich hilft!
Gast
#6452080
c-hater schrieb: > Dann mach' doch einfach da auch mal ein Windows-Update... > > Das kann doch nicht so schwer zu begreifen sein... Vergessen: natürlich notierst du vor den Update die Version des Treibers der verwendeten Schnittstelle und vergleichst mit der Version nach dem Update.
Gast
#6452081
Bruno M. schrieb: > es geht ohne Probleme > bis 250000 Baud. Haben die auch identische Treiberversionen für USB HUB und Uart Wandler? Du wirst das Problem einkeisen müssen, um es zu lösen, sonst landen wir nur wieder bei 'WIN10 ist blöd' Aussagen.
Gast
#6452085
Bruno M. schrieb: > Die üblichen schlauen Sprüche, aber nichts was einem > wirklich hilft! Nun mal langsam kleiner Wüterich. Wir können nix für Deinen Frust. Vergeliche die Treiberversionen und wenn gleich führe das Update durch wie c-hater gesagt hat. Wenn das Problem dann auftritt, liegt es am Update und wir könnne weitersuchen. Pöbeln führt nur dazu das Du das ganz alleine lösen darfst.
Gast
#6452089
Bruno M. schrieb: > Natürlich c-hater! Die üblichen schlauen Sprüche, aber nichts was einem > wirklich hilft! Doch, das hilft. Wenn du nämlich meinem Vorschlag folgst, weißt du gleich zwei Sachen: 1) Es liegt am Treiber. 2) Du kennst die Versionsnummer eines funktionierenden Treibers. Damit sind alle Bedingungen erfüllt, um die Sache zum Laufen zu bekommen. Das ist dann einfach: 1) nicht funktionierenden Treiber vollständig (also inklusive Treiberdateien) deinstallieren. 2) funktionierende Treiber installieren. 3) Windows-Update das Update von Treibern verbieten, um die Lösung dauerhaft zu machen.
Gast
#6452110
Bruno M. schrieb: > > Die üblichen schlauen Sprüche, ... Die sind nicht schlau. Die sind, wie bei Rindviechern üblich, hochgewürgt und wiedergekäut. Pfui Deifi!
Gast
#6452118
Semmel schrieb: > Die sind nicht schlau. Also das ich mal c-hater verteidigen würde hätte ich auch nie gedacht. Er hat trotzdem recht. Ausser hier Stück für Stück das funktionierende System in den gleichen Zustand wie das nicht funktionierende zu versetzen, wird nichts funktionieren um den Fehelr zu finden. Das verbale Aufstöhnen und Augenrollen das der TO nicht von alleine auf die Idee kommt, möge man ihm nachsehen. Typfrage ...
Hallo, habe hier die verschiedensten Kombinationen aus Win 10 Home, Pro, LTSC und ganz viele verschiedene Konverter. MOXA, CM340, FTDI, Texas usw. nur Prolific nicht. Alles läuft mit HTERM. Also an Win 10 sollte es nicht liegen. Gruß Holger
Gast
#6452193
M. K. schrieb: > Das verbale Aufstöhnen und Augenrollen das der TO nicht von alleine auf > die Idee kommt, möge man ihm nachsehen. Das dramatische Unwissen des TO war hier (zumindest anfangs) garnicht wirklich das Problem. Das Problem meines heftigen Mißvergnügens war, dass der TO sich (in offensichtlich völliger Absenz jeglichen einschlägigen Sachverstands) trotzdem schon dazu berufen fühlte, HTerm die Schuld zu geben. Siehe allein den gewählten Topic des Threads... Aber dann setzte sich die Arroganz des völlig Unwissenden weiter durch (woher zum Teufel nimmt der die nur?). Und da brachen natürlich alle Dämme. Fazit: Wenn einer unwissend ist und das weiss, sollte er einfach kleine Brötchen backen. Hilft natürlich nicht für die Leute, die sogar zu unwissend sind, um zu erkennen, wie wenig sie eigentlich wissen... So ein Fall dürfte hier vorliegen.
In der Zwischenzeit habe ich die relevanten Treiber der beiden Systeme verglichen. Sie sind völlig identisch einschließlich Versionsnummern. Dann habe ich bei dem nicht funktionierenden System die Treiber deinstalliert und neu gestartet -> keine Änderung. Das update beim funktionierenden System habe ich noch nicht gemacht, da ich vorher eine Sicherung laufen lasse, die etwas dauert. Wenn es nicht am System liegt, was gibt es sonst noch für Möglichkeiten?
c-hater schrieb: Dieser verbale Erguß (auf dessen Niveau ich mich nicht begeben werde) bestätigt nur meine ersten Kommkentar zur Person des Autors.
Gast
#6452213
Bruno M. schrieb: > In der Zwischenzeit habe ich die relevanten Treiber der beiden Systeme > verglichen. Als da im Detail wären? (Mir kommt schon die hier verwendete Mehrzahl ziemlich verdächtig vor) > Dann habe ich bei dem nicht funktionierenden System die Treiber > deinstalliert und neu gestartet -> keine Änderung. Wie sollte sich da auch eine Änderung ergeben? Wenn die Treiber unvollständig entfernt wurden, wird einfach eine neue Instanz davon installiert. Wenn sie vollständig entfernt wurden, werden sie per WindowsUpdate neu heruntergeladen und auch wieder eine neue Instanz davon installiert. Der zweite Teil passiert nur dann nicht, wenn man halt das TreiberUpdate per WindowsUpdate verbietet. > Wenn es nicht am System liegt, > was gibt es sonst noch für Möglichkeiten? Ziemlich viele, da sich die verwendeten System ja auch physisch unterscheiden. Das fängt bei unterschiedlichen verwendeten Kabeln an, endet da aber längst nicht. Die tatsächliche Fehlerursache kann man nur mit logisch durchdachter, strukturierter Fehlersuche ermitteln. Die allerdings größtenteils im Austauschverfahren stattfindet. Also logisch eigentlich ziemlich einfach zu beherrschen ist.
Gast
#6452237
Wenn das Kompetenzgerangel dann soweit ausgetragen ist könnte man in der Sache ja mal weitermachen... Bei mir hatte HTerm auch immer Probleme bei besonders hohen Baudraten, teilweise auch mit Absturz der Applikation. Dazu musste noch noch nicht einmal besonders viel übertragen werden. Da scheint sich im Programm etwas zu verheddern. Es ist halt Version 0.8.5 seit Ewigkeiten (gefühlt 10 Jahre?), der Autor macht da nichts mehr. Es gibt ja auch noch so manche andere Problematik, z.B. die fehlende automatische Neuanmeldung bei USB-Unterbrechung. Vielleicht solltest Du es mit einem anderen Tool versuchen. Richtig gut ist z.B. Docklight, allerdings nicht kostenlos.
Verehrter c-hater, ich möchte dich bitten, dich heute und in Zukunft bei der Kommentierung und Beantwortung meiner posts rauszuhalten. Danke!
Harald schrieb: > Bei mir hatte HTerm auch immer Probleme bei besonders hohen Baudraten, Das kann ich eigentlich so nicht bestätigen, ich war immer sehr zufrieden.
Zur Verdeutlichung des Problems noch die Ausgabe in HTerm: hast du was zu melden?<\n><\r>jjaa ssiicchhrr<\n><\n> Der Empfang ist klar und die Antwort sollte "ja sicher" heißen.
Bruno M. schrieb: > Der Empfang ist klar und die Antwort sollte "ja sicher" heißen. Für jemanden am anderen Ende des Internet sieht das aber schon so aus, als hättest du entweder ein lokales Echo aktiviert oder eine ungewollte Verbindung zwischen TXD und RXD. Ausserdem fehlt immer noch die Angabe deines UART-USB Chips. In letzter Zeit ist mir durch XModem Uploads jedenfalls aufgefallen, das bei 115,2 kBaud der CH340 Adapter hier Mist ist und der FTDI ziemlich gut funktioniert - jedenfalls mit Win10/32bit Home und Build 2004.
Matthias S. schrieb:
> Ausserdem fehlt immer noch die Angabe deines UART-USB Chips.
Sorry, ich nutze einen FTDI Chip.
Das Problem kann eigentlich nur im Inneren des PCs sein, da ich alles
Externe, inklusive USB- und Stromkabel von einem zum anderen PC
transportiere.
Gast
#6452279
Bruno M. schrieb: > Verehrter c-hater, ich möchte dich bitten, dich heute und in Zukunft bei > der Kommentierung und Beantwortung meiner posts rauszuhalten. Danke! Das werde ich nicht tun, solange sie offensichtlich andere insofern beeinflussen können, Fehler an der falschen Stelle zu suchen. Du bist nicht das Zentrum des Unversums und das Forum ist nicht dazu da, allein deine Probleme zu lösen. Und darüber hinaus: du vermeidest es mit beachtlicher Permanenz, jegliche zur Problemlösung hifreiche Informationen zu veröffentlichen, auch explizit angefragte und sehr leicht zu ermittelnde. Also vielleicht nicht wirklich dumm, aber Troll? Das ist etwas noch sehr viel Schlimmeres. Das ist völliger Abschaum.
Gast
#6452320
c-hater schrieb: > schon dazu berufen fühlte, HTerm die Schuld zu geben Du triggerts aber auch wirklich schnell auf sowas. Man muß auch ein wenig Verständniss für die menschliche Natur haben, sich aufzuregen und Schuld zuzuweisen, obwohl wir alle es eigentlich besser wissen sollten.
So, ich bin zwar einen Schritt weiter, aber nicht wirklich schlauer. Jetzt sind beide Rechner auf gleichem Stand, aber nach wie vor funktioniert es bei einem und beim anderen nicht.
Noch ein Nachtrag! HTerm kann ich auch ausschließen. Ich habe ein anderes Terminalprogramm ausprobiert und siehe da, der Fehler bleibt! Und nun???
Gast
#6452497
Bruno M. schrieb: > Noch ein Nachtrag! > HTerm kann ich auch ausschließen. Ich habe ein anderes Terminalprogramm > ausprobiert und siehe da, der Fehler bleibt! > Und nun??? Ich zitiere mich einfach mal selber: > du vermeidest es mit beachtlicher Permanenz, > jegliche zur Problemlösung hifreiche Informationen zu veröffentlichen, > auch explizit angefragte und sehr leicht zu ermittelnde. Da wäre also: -Hardware der verwendeten Schnittstelle -Treiber (und -version) -Reaktion auf den Primitivtest mit lokalem Loopback
Zur Info: Das Problem ist gelöst! Ich weiß zwar immer noch nicht woran es gelegen hat, aber es funktioniert wieder. Ich habe den PC einfach auf einen älteren Stand zurückgesetzt. Dank an alle die versucht haben mit vernünftigen Beiträgen zu helfen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.