XProfan

Deutsch

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!

15.02.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

- Seite 1 -

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:
Kompilieren Markieren Separieren

cls
settimer 3000  alle 3 sekunden abrufen reicht?

while 1

    waitinput

    if %wmtimer

        hier temparatur abrufen und anzeige aktualisieren

    endif

endwhile

end

15.02.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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!

15.02.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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!

16.02.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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:
Kompilieren Markieren Separieren

If %wmtimer

    ...

EndIf

If GetFocus(Button1&)

    ...

ElseIf GetFocus(Button2&)

    ...

ElseIf ...

    ...

EndIf

Gruß
Jörg

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

16.02.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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!

16.02.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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????

16.02.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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!

16.02.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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

Windows7 Xprofan 8,9,10 [...]

[...]

16.02.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

- Seite 2 -

Ulrich
Milde

Heute lief es erheblich besser und ich bin soweit, dass sich mit dem Programm schon was anfangen liesse. Die seriellen Probleme sind gelöst, aber ich möchte da lieber kein mit Menüs volgestopftes Programm draus machen...
Das was jetzt fehlt ist, dass das Hauptfenster verschwindet, besser gesagt völlig unsichtbar wird. Teilweise hatte ich Erfolg, aber ein Rest bleibt sichtbar. Es wäre schön wenn der auch unsichtbar werden würde.
Fürs erste ist das Programm so ausreichend, die Sache mit dem noch ein bischen sichtbarem Hauptfenster mal ausgenommen. Mit Erweiterungen werde ich mir glücklicherweise etwas mehr Zeit lassen können. Ich bedanke mich nochmal für die wirksame Hilfe!

Grüsse und Tschüss!

PS. Ich habe das Listing hochgeladen, keine Ahnung wo das auftaucht... So wie es aussieht gibt es in diesem Forum anscheinend leider keine Vorschau

MinMicSer_01_02.prf	3 kB

Kurzbeschreibung:	Ohne serielle Schnittstelle lauffähig

Hochgeladen:	17.02.2007

Ladeanzahl:
		Herunterladen

17.02.2007 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Rolf
Koch

Hi Du hast ein Endif zuviel drin

Kompilieren Markieren Separieren

ELSEIF getFocus(EndIt&)

Ende%=1

Endif

ENDIF <--------- Dieses ist überflüssig

Hauptfenster nicht sichtbar:
showwindow %hwnd,0

Und nochwas:
Settimer kommt vor die Hauptschleife und dann fragt man per %wmtimer nach dem Waitinput ab, ob der Timer eingetroffen ist.
Kompilieren Markieren Separieren

settimer xxx

Whilenot ende%

    Waitinput

    If %wmtimer

        Hier passiert dann das was alle xxx milisek. passieren soll

    endif

Endwhile

Killtimer