| |
| |
|
Ulrich
Milde | Von einer Lüftersteuerung mit Microcontroller lese ich über die serielle Schnittstelle die Temperatur aus und zeige diese an. Ich habe dazu lediglich das Beispielprogramm für die serielle Schnittstelle an das gelieferte Datenformat angepasst. Funktioniert gut, das ist nicht das Problem. Die CPU Last liegt permanent bei 100% und dabei ist es egal, ob ich das Programm im Interpretermodus oder compiliert als eigenständige Anwendung laufen lasse. So eine heftige Auslastung ist leider inakzeptabel, gerade weil es sich um den ersten Schritt zu einer Anwendung handelt, die die Temperatur überwachen soll.
Ich benutze Profan 7.6a unter Windows XP und der Einfachheit halber zeige ich die Daten erstmal im Profan "DOS" Fenster an . Upgrade auf XProfan10, daran hatte ich schon gedacht, aber ist die CPU Auslastung dort geringer? Vielleicht gibt es auch eine andere Lösung des Lastproblems? Ich bin dankbar für jeden Tipp!
Danke und Tschüss! |
|
| |
| |
| |
|
|
| @Ulrich
Ein bischen Programm-Code wäre hilfreich...  |
|
| |
| |
| |
|
|
RGH | Hallo Ulrich,
natürlich halte ich die Anschaffung eines Updates auf XProfan 10 für eine sehr gute Lösung ;) , aber ich befürchte, das würde an Deinem Problem nichts ändern. Da dürfte vermutlich ein "Sleep 1" in der Hauptschleife Wunder wirken. Das sorgt dafür, daß auch bei einer While-Schleife ohne Wait-Befehle andere Prozesse eine Chance bekommen. Eine While-Schleife ohne Wait- und Sleep-Befehle führt in der Regel zu 100% Systemauslastung. Wichtig: 100 % Systemauslastung bedeutet nicht, dass außer dem Programm niuchts mehr geht und das restliche System zum Stillstand kommt. Für eine Verteilung der Prozessorzeit auf die verschiedenen Prozesse sorgt sich schon Windows selbst. Es bedeutet nur, daß das Programm dann jede freie Prozessorzeit für sich nutzt.
Gruß
Roland |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 15.02.2007 ▲ |
|
| |
|
|
 | Erstmal willkommen Ulrich. 
Dein Problem ist damit zu beheben das Du ebend nicht den Temparaturstand hunderte Male pro Sekunde abrufst - sondern viel seltener.
Ich würde Dir folgenden Bauplan empfehlen:
KompilierenMarkierenSeparieren |
|
| |
| |
| |
|
|
Ulrich
Milde | CPU Last von 100% um ca. 100% gesenkt, das nenn ich mal einen wirklich 100%tigen Erfolg! Das Programm hier zu posten wird übrigens nichts bringen denn ohne den Microcontroller wird sich nichts tun. Dabei hat das Programm eh jeder, der Profan hat.
Hilfe starten und dann - Einführung - Verbindung mit der Aussenwelt - Serielle Schnittstelle - Hinter jedem der beiden ReadCom$ Befehle des Beispielprogramms einmal Sleep1 einfügen, und das brachte schon das Performancewunder 
Das wird übrigens eine Anwendung, die bei Fertigstellung zusammen mit dem Projekt auf derOpenMicro Website [...]  stehen wird. Vielleicht darf ich noch eine Frage stellen, denn dazu habe ich nichts gefunden, weder in der Profanhilfe noch hier. Ganz rechts in der Taskleiste sind Icons von Programmen, die nicht einfach nur minimiert laufen, sondern im Hintergrund auf ihren Einsatz warten. Mir kommt das fast so vor wie die Windows Analogie zu einem DOS TSR Programm. Wie kann ich es erreichen, dass sich das Programm dort versteckt, aber aktiv bleibt? Temperaturanzeige im Icon selbst, so wie bei SpeedFan oder dem MBM5 (Motherboard Monitor) wäre natürlich noch besser, aber ich befürchte das könnte zuviel Aufwand werden.
Ich bedanke mich schon mal, nicht zuletzt mit dem Hinweis dass ich mir XProfan10 wahrscheinlich kaufen werde. Mit SetComExtended kann ich nämlich mein DOS Programm zum auslesen meines Multimeters endlich auf Windows umstellen.
Danke und Tschüss! |
|
| |
| |
| |
|
|
Jörg
Sellmeyer | Hallo Ulrich,
Sieh Dir das mal an: [...]
und such auch mal auf xprofan.de mal nach "systray"
Gruß
Jörg |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 15.02.2007 ▲ |
|
| |
|
|
Ulrich
Milde | SysTray, richtig, danach hätte ich suchen sollen! Aber das ist viiiel zu früh denn das Lesen von der seriellen machte Probleme. Ich konnte das Problem zurückverfolgen bis auf die Leseroutine, die ich unverändert aus dem funtionirenden Beispielprogramm übernommen habe.,
Fakt ist: Serielle Daten werden gesendet, aber nicht empfangen. ComError ist 0 und weil keine Daten empfangen werden, wird die Leseschleife niemals verlassen. Dieselbe Leseschleife unter der Quasi DOS Umgebung vom veränderten Beispielprogramm läuft problemlos und liefert Daten. Sehr seltsam!
Ich konnte das Problem bei WaitKey und Co. in der äusseren Windowstypischen Schleife festmachen. Nur Inkey$() liess die Schnittstelle so arbeiten wie es sein soll. Offensichtlich stören Profan-interne Prozesse bei WaitKey das Handling der seriellen Schnittstelle, obwohl das Programm sich dann in der seriellen Prozedur befindet. Jetzt, wo ich das weiss ist das Problem nicht so schlimm, aber die Fehlersuche hat mich teilweise an mir selbst zweifeln lassen.
Die Frage ist jetzt ob und wie ich nur mit InKey$() eine Windows typische Benutzeroberfläche bauen kann? Mausaktionen abfragen, das muss ich erst noch ausprobieren, aber ich befürchte fast dass es auch da seriell haken könnte. Ich werde ich mich grösstenteils alleine durchbeissen müssen, denn der Microcontroller an der seriellen Schnittstelle gehört dazu. Ohne den gibt es keine Daten, um die es eigentlich geht.
Ich habe das jetzt eher als Bericht geschrieben, wie es mir mit meinem Projekt ergangen ist. Ich weiss nicht ob es in dieses Forum passt, wenn ich von Zeit zu Zeit erneut poste wie es dem Programm (und somit auch mir...) geht.
Grüsse und Tschüss! |
|
| |
| |
| |
|
|
Jörg
Sellmeyer | "WaitKey" läßt tatsächlich nur Keyboardeingaben durch. Versuchs doch mal mit "WaitInput". Am besten Du postest einfach mal ein bischen Code. Sonst ist das hier nur gerate. Auch wenns aus den Beispielen ist. Wir wissen ja nicht, was Du schon evtl. geändert hast.
iF hat ja im Prinzip auch schon ein Grundgerüst gezeigt. Du mußt nur vor der Schleife Buttons und sonstige Fensterelemente erzeugen und die dann innerhalb der Schleife mit einer If-Struktur abfragen:
KompilierenMarkierenSeparieren
Gruß
Jörg |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 16.02.2007 ▲ |
|
| |
|
|
Ulrich
Milde | Danke für den Code, der wird das Grundgerüst werden. Code posten, das reicht noch nicht weil ich zur Zeit noch in dem Stadium bin, in dem erstens alles ständig umgeworfen wird. und ich zweitens hauptsächlich am seriellen Empfang rumgebastelt habe. Das schliesst das Datenformat mit ein und somit auch das Programm vom Microcontroller. Sowie ich die seriellen Daten sauber im Grundgerüst "sehen" kann, dann wirds anders werden und das wird hoffentlich recht bald sein!
Nochmal zu WaitKey: Ich finde es bemerkenswert dass WaitKey die stoppende Hand auf fast alles legt, inkl. der seriellen Schnittstelle. Ein geradezu gefährlicher Befehl
Danke und Tschüss! |
|
| |
| |
| |
|
|
| Hm kann es sein das da eigendlich garnix gestoppt wird - sondern eher ebend nur nicht ausgelesen wird wenn z.B. Waitkey oder Waitinput am Zuge ist?
Solltest Du also doch vielleicht ohne "Warten" permanent den Port auslesen? Wenn "Ja" - dann solltest Du eine 2-Prozess-Anwendung programmieren. Zum Einen ne art ServerAnwendung welche Fensterlos permanent aus dem Port liest - und zum Zweiten das Programm was die Benutzeroberfläche darstellt. Normalerweise könnte man dies über Threads tun - xprofan ist aber nicht Thread-Sicher, also müssen 2 Prozesse statt Threads her - nimmt sich aber eigendlich kaum was.
Die Prozesse müssen nun aber irgendwie auch miteinander kommunizieren können - sodass die Fensteranwendung der Serveranwendung Befehle geben kann. Hierfür empfehle ich die Pipe-Unit.
Kann es aber vielleicht auch sein das es einfacher geht? GDL macht doch auch sowas!? Er schwärmt von der Thread.Pcu (die tut so als ob nen Thread erzeugt wird nutzt aber nen Timerkonstrukt) und meinte doch immer das es ohne diese kaum möglich wäre?! Geeeooooorrrg???? |
|
| |
| |
| |
|
|
Ulrich
Milde | Uuups, das geht so ein klein wenig über meinen Horizont! Ich bin zwar kein Neuling was programmieren angeht; auch kein Profan Neuling, aber Profan stand zu lange in der Ecke und staubte vor sich hin. Erschwerend hinzu kommt noch das ich im Prinzip ein DOS-QBasic Dinosaurier bin, für den das OOP Konzept schwer verständlich ist. Solange ich in Gedanken bei Datenstruktiuren, Prozeduren, Funktionen und Parameterübergaben bleiben kann, die meinen Verständnisrahmen nicht übersteigen, geht alles noch. Auch in Profan hab ich schon was nettes hinbekommen. Leider steckt da irgenwo ein Fehler drinnen, der nur zeitweilig auftritt so dass Train-Sim.com auf mein Programm verzichten musste 
Hier und jetzt fürchte allerdings dass, dass Windows und (X)Profanspezialitäten angesprochen werden, die meinen Horizont übersteigen. XProfan habe ich noch nicht und das wird auch noch etwas dauern, denn am Mittwoch werden bei mir einige zugewachsene Zahnwurzeln ausgegraben. Es ist zu befürchten dass ich dann einige Tage keine grosse Lust haben werde mir den Kopf über Programme und Profan zu zerbrechen.....
Ich finde es toll dass meine profanen Schwierigkeiten gleich aufgegriffen worden sind und ich hoffe sehr, dass ich in der Lage sein werde die Tipps und Infos auch umzusetzen. Ich werde erstmal damit weitermachen, überhaupt was serielles mit einem eingermassen lesbarem Progamm ohne den Profan DOS Screen windowsähnlich auf den Monitor zu bringen. Das wede ich (hoffentlich) dieses Wochenende noch hinbekommen. Dann werde ich sehen wie es weitergeht.
Vielen Dank und Tschüss! |
|
| |
| |
| |
|
|
GDL | Hi,
das Problem bei zwei freilaufenden RS232 Schnittstellen ist immer "WANN DARF ICH AUSLESEN.Es darf keinesfalls ausgelesen werden ,wenn der der MControler gerade sendet.Wenn auch noch Fehlerbytes ausgewertet werden wirds extrem schwierig.
Entweder du nutzt die Handshakingleitungen oder sendest vorher eine Präambel.
Ich nutze immer die 255.
Servus
Georg |
|
| |
| |
| |
|
(543)
Deutsch
English
Français
Español
Italia