Ich brauch mal die gesammelte Lebenserfahrung der WinXP Programmierer... Derzeit programmiere ich an einer Anwendung die mit einem WinXP Rechner ueber einen BUS auf RS422 Basis redet. Dabei wird immer ein Byte von WinXP gesendet und dann von meinem Controller zurueckgeschickt. Also Ping-Pong :-) Das ist natuerlich Mist, aber der Bus stammt noch aus den 70ern, aechz. Das Problem, wenn ich das erste Byte fuer mich empfangen habe dann kann ich meinen Bustreiber einschalten und sende halt. Sollte es aber zu Problemen kommen, egal wie die nun aussehen, dann muss sich die Uebertragung wieder zuruecksetzen. Zum einen weil ich meinen Bustreiber deaktivieren muss falls andere Geraete an den Bus wollen, zum anderen um meine Statemachine zurueckzusetzen. Das heisst nachdem ich das erste Byte an Windows zurueckgeschickt habe, hat WinXP eine bestimmte Zeit zur Verfuegung um mir das naechste zu schicken. Das hatte ich gerade auf 0.1s. Das klappt dann in 60% der Faelle. Mit 0.5s sieht es deutlich besser aus. Gibt es eine Zeit auf die ich mich verlassen kann? Mir ist natuerlich klar das Windows kein Echtzeitsystem ist, aber was sind denn so in der Praxis vernuenftige Annahmen? Olaf
Im von Dir genannten Zeitrahmen kann XP das schon hinbekommen, auch zuverlässig. Du musst allerdings ein paar Rahmenbedingungen schaffen. Keine USB-Seriell-Adapter verwenden, und bei den Onboard-Schnittstellen (oder auf einer PCI-Karte befindlichen) den Sende- und den Empfangsfifo deaktivieren. Sofern Du keine allzu rechenlastigen Programme verwendest, sollte das ganze funktionieren. [Edit] Hatte hier ein paar Anmerkungen zu RS485 hingeschrieben ... Schusselkopp, geht ja um RS422.
Kommt halt drauf an, was du steuerst. Wenn etwas wichtiges von der Reaktionszeit abhängt, wirds haarig. Denn garantieren kann man nicht mal 10 Jahre Reaktionszeit bei Standard-Windows. (Bei Standard-Linux genausowenig). Vielleicht solltest du dir mal die Echtzeit-erweiterungen anschauen...falls was passieren kann, wenn Windows gerade mal nach Updates sucht oder sonstwas rödelt.
außer man setzt auf sogenannte Kerneltreiber. Sind aber sehr teuer. Bsp Kithara
Ebc Ebc wrote: > außer man setzt auf sogenannte Kerneltreiber. Sind aber sehr teuer. > Bsp Kithara Kann man auch selber schreiben - dann machen sie eine Menge Arbeit...
Hatte vor einiger Zeit mal mit dem Problem zu kämpfen, dass mir die "embedded" Seite nicht immer geantwortet hat. Habe dann irgendwo im MSDN etwas von 300ms Reaktionszeit auf Windowsseite für die RS232 gelesen. Ich glaube aber, dass dies noch unter Win2k war :-)
... war zu schnell mit Posten ... Machst Du die Schnittstelle im PC bei einem Problem komplett zu ? Sprich, gibts Du das Handle an Windows wieder zurück ?
Das Einfachste waere die Echtzeit in einen kleinen Controller grad neben dem PC auszulagern.
> Machst Du die Schnittstelle im PC bei einem Problem komplett zu ? > Sprich, gibts Du das Handle an Windows wieder zurück ? Ich hab mit der Programmierung auf der Windowsseite zum Glueck nichts zutun. Mir ist auch klar das man da was verbessern koennte wenn man tief im Kernel rummacht, oder zeitkritische Sachen in externe Hardware auslagert. Aber all das ist nicht noetig, da die Uebertragung so wie sie ist problemlos funktioniert. Es geht mehr daraum was passiert wenn sie aus nicht vorhersehbaren Gruenden mitten in einer Uebertragung stehenbleibt. Also von mir aus weil Windows abstuerzt, oder was auch immer. Dann sollte ich nach einer gewissen Zeit mein Geraet zuruecksetzen damit es wieder vernuenftig reagieren kann. Vor allem aber nicht andere Geraete behindert. Ich denke mal ich werde das so auf 5s setzen. Wenn Windows selbst dazu nicht in der Lage ist dann wird dem Anwender wohl was an seinem Rechner komisch vorkommen. Und es ist gleichzeitig kurz genug das man keinen Fehler vermuten wird wenn etwas schief laeuft und man es erneut probiert. Olaf
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.