Hi, bei einem C# - Programm, das mit einem Atmega64 über die serielle Schnittstelle kommuniziert, tritt beim Powerdown des Laptops ein vollständiges Blockieren des Programmes auf. Powerdown wird eingeleitet durch Zuklappen des Laptops oder nach Ablauf der eingestellten Zeit. Danach verriegelt sich das C# - Programm total. Graues Fenster, keine Annahme von Maus oder Tastatur, selbst mit dem Task-Manager lässt es sich nicht entfernen. Die verwendeten Komponenten sind: Visual Studio 2010, Net 4, C#, SafeSerialPort. Die Fehlersuche wird erschwert durch die Tatsache, daß beim "Schlafengehen" (Hibernate) des Laptops auch kein Debuggen mehr möglich ist. Um den Fehler einzugrenzen habe ich 5 Eventhandler eingebaut: SystemEvents.EventsThreadShutdown SystemEvents.PowerModeChanged SystemEvents.SessionSwitch SystemEvents.SessionEnding SystemEvents.SessionEnded und Text in eine Datei ausgeben lassen. Beim Zuklappen wird OnPowerModeChanged ausgelöst mit PowerModeChangedEventArgs = PowerModes.Suspend. Mit diesem Ereignis versuche ich mit serialPort.Close(); serialPort.Dispose(); Application.Exit(); das Hängen des Programms durch Beenden desselben zu verhindern. Leider ohne Erfolg. Anzumerken ist noch, daß der Laptop keine echte Com - Schnittstelle mehr hat. Das V24 - Kabel hängt an einen V24/USB - Adapter. Bin für jede Anregung dankbar. mfg Nucor
> V24/USB - Adapter
Die Macke haben wohl alle Prolific-Adapter.
Vielleicht mal nen anderen nehmen?
Hmm. Klingt irgendwie nach einem Treiber Problem des USB Konverters. Passiert dies nur, wenn die Verbindung geöffnet ist? Passiert dies auch bei einem anderen Konverter (anderer USB/RS232 Chip Hersteller) oder bei einer fest eingebauten COM Schnittstelle? Kann das Programm eigentlich generell (also wenn es manuell gestart wird) nachdem der Laptop aufgeweckt wurde, auf die Schnittstelle zugreifen? Wie reagiert das Programm eigentlich, wenn im Betrieb der USB Konverter entfernt wird? Du könntest auch noch versuchen, im Gerätemanager beim entsprechenden USB-Root-Hub im Bereich Energieverwaltung den Punkt "Computer kann das Gerät ausschalten, um Energie zu sparen" zu deaktivieren. Eventuell zeigt das auch eine Auswirkung auf das Verhalten. lg. Michi
Ja. diesen Fehler habe ich auch schon festgestellt. Diesmal mit einem FTDI Chip, dem passenden Treiber, einem anderen Communication package, einer anderen Sprache. Das einzig Moegliche ist ein sauberer Reboot. Ist leider so.
Ich hatte auch schon einmal Probleme mit virtuellen COM Ports, wo danach nur noch ein Neustart des Rechners half. Vielleicht kommt das Problem irgendwo aus dieser Richtung. Falls es ein FDTI Chip ist, könnte es eventuell helfen, die Kommunikation über D2XX und nicht über den Virtual COM Port (VCP) aufzubauen. Auf der FDTI Homepage sind auch einige Beispiele für C# verfügbar: http://www.ftdichip.com/Projects/CodeExamples/CSharp.htm
Hibernate != Hibernation Hibernate: http://www.hibernate.org/ Hibernation: http://de.wikipedia.org/wiki/Hibernation
Läubi .. schrieb: > Hibernate != Hibernation > > Hibernate: http://www.hibernate.org/ > Hibernation: http://de.wikipedia.org/wiki/Hibernation das debian package "hibernate" haste noch vergessen ;) @topic habe atm das gleiche problem mit dem vcp driver..werde es mal mit dem d2xx java wrapper probieren. wahrscheinlich muss ich die verbindung vorm ruhezustand jedoch trennen
Hi, vielen Dank für die vielen Hinweise. Das Problem ist der Treiber des FTDI - USB-Adapters. Mit einem Prolific - USB-Adapter gehts problemlos. Klappe des Läppis schliessen, der Läppi stellt die Arbeit ein, das Programm beendet die Kommunikation mit dem ATMEG64, Klappe auf, der Läppi startet wieder, das Programm tauscht wieder Daten aus. Auch den USB-Adapter entfernen und wieder verbinden geht. Das Programm stellt ordnungsgemäß die Aktivität mit dem ATMEGA ein und setzt bei Wiederanschluss problemlos auf. Die naheliegende Vermutung, daß der Treiber für FTDI nicht aktuell ist, bin ich nachgegangen. Mit CDM20602 (=Version 206.02) ist er auf dem neuesten Stand. Der Prolific - Treiber hat die Version 3.20. Beide Treiber waren schon in Vista vorhanden. Den anderen Vorschlägen werde ich noch nachgehen. Jedenfalls bin ich froh, daß es jetzt geht. Als Programmierer ich bin es gewohnt den Fehler erst mal in den eigenen Sachen zu suchen. Dort liegt ja auch zumeist zu 99,9% die Ursache. Mit der Zeit wird man allerdings betriebsblind. Mit ein paar Denkanstößen von euch kommt leichter ans Ziel. mfg Nucor
Bitte 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.