Socke hat geschrieben:TThread.Synchronize() arbeitet ausschließlich mit einem einzigen Thread (dem Mainthread in Lazarus-Anwendungen). Da ich in eingebettenen Systemen viel eher eine N-zu-N-Kommunikation zwischen den Threads bevorzuge, hatte ich das noch nicht implementiert.
Synchronize ist sowieso schlecht, weil es den aufrufenden Thread blockiert, bis der GUI Thread irgendwann mal dazu kommt sich der Sache anzunehmen. Besser ist da TThread.Queue oder QueueAsyncCall. (AsyncPro verwendet Windows Mesasages.)
Aber auch das spricht alles nur einen (den Main-) Thread an. Im Worker-Thread kann man meist problemlos mit blocking Aufrufen arbeiten. Eine Implementierung von Event Queues für Worker Thread wurde für Lazarus diskutiert, aber nicht weiter verfolgt (Gibt es in Delphi ja auch nicht). (MSE-GUI hat das.)
-Michael
Zuletzt geändert von mschnell am Di 28. Okt 2014, 10:30, insgesamt 2-mal geändert.
Es ist vollbracht. Die Methode WaitForInterupt() funktioniert jetzt einwandfrei (aus meiner Sicht).
Zu den Hintergründen:
Zum einen war im Beispiel der falsche Timeout angegeben; dieser muss ungleich 0 sein, damit überhaupt gewartet wird. Zum Anderen ist der aktuelle Wert verfügbar; dieser muss zuerst gelesen werden, damit FpPoll() überhaupt auf neue Daten (und nicht auf die alten, vorhandenen) wartet.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein
Gut ! Aber ohne Threads ist das meiner Ansicht nach wenig sinnvoll und entspricht nicht dem Thema des Threads, das von "Interrupt" sprach (was im Userland natürlich nicht korrekt ist) und damit vermutlich ein "Main-Thread Event" meint.
mschnell hat geschrieben:Gut ! Aber ohne Threads ist das meiner Ansicht nach wenig sinnvoll und entspricht nicht dem Thema des Threads, das von "Interrupt" sprach (was im Userland natürlich nicht korrekt ist) und damit vermutlich ein "Main-Thread Event" meint.
Jetzt kann sich aber jeder einen eigenen Thread damit bauen. Eine GUI-Komponente mit Thread wird zurzeit von mir entwickelt; es fehlt vor allem noch das Entrellen in Software. Da habe ich mich schonmal ein wenig schlau gemacht, jedoch weiß ich noch nicht genau, wie ich das umsetzen kann/muss. Falls du einen Algorithmus hast, immer her damit
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein
Entprellen habe ich mit kleinen Prozessoren schon oft gemacht.
Im allgemeinen geht das so:
- ein "Maximum" Wert ist definiert.
- alle x milisekunden wird der zustand eingelesen
- bei "gedrückt" wird eine Variable inkrementiert (falls sie nicht auf Maximum steht) , bei "nicht gedrückt" wird sie dekrementiert (falls sie nicht auf 0 steht).
- bei Step Maximum-1 -> Maximum und von 1 -> 0 wird ein Callback aufgerufen, der dann die gewünschte Funktion auslöst.
Dafür braucht man aber keinen Hardware-Tasten-Interrupt, sondern einen Hardware-Timer-Interrupt.
Will man einen Hardware-Tasten-Interrupt verwenden, sollte die Entprellung in Hardware gemacht werden (Widerstand, Kondensator, Gatter mit Hysterese).
Vorerst möchte ich mich mal für die Arbeit von Simon ausdrücklich bedanken! Er hat mir fast das Gefühl gegeben, welches ich vor mehr als 6 Jahrzehnten gehabt habe, als ich zu Weihnachten ein Spielzeug bekommen habe...
Die Variante, wo man von der Kommandozeilen-Ebene das Programm aufruft, funktioniert bei mir am RaspberryPi so, wie ich es mir vorgestellt habe.
Nach dem Start sieht man durch einen Punkt (3 Sekunden-Takt) symbolisiert, das ein Programm läuft. Wird die Taste (liegt bei mir am GPIO Pin12) gedrückt, wird ein Interrupt ausgelöst und es erscheint eine Meldung im Terminal: poll() Gpio 18 interrupt occured value:TRUE.
Von Projekten mit Atmel - Mikrocontroller, wo ich in BASCOM mich schon mal mit Hardware-Interrupts beschäftigt habe, hätte ich mir eine Interruptbehandlung jedoch einfacher vorgestellt. Anscheinend ist der Thread- Mechanismus, Dämon (hat nichts mit dem heutigen Tag zu tun) und ähnliches dafür verantwortlich, dass es nicht ganz einfach ist, zu verstehen und nachzuvollziehen, was, wo und wann passiert! Zumindest für mich - eigentlich schade.
Als Halb-Wissender (ist bei mir wahrscheinlich noch zu hoch gegriffen) wünscht man sich, und stellt sich vor : Ein Gui-Programm mit verschiedenen Funktionen wird abgearbeitet und am Eingang eines µC wird durch einen Taster ein Hardware-Interrupt ausgelöst, bzw. angefordert (IRQ). Ich dachte (hab es mal so gelesen...), dass zuerst mal ein IRQ freigegeben oder gesperrt sein kann bzw.muß. Wenn er aber explizide freigegeben ist, dann müsste eine Unterbrechungsroutine ausgeführt werden. Nach deren Beendigung wird IRQ zurückgesetzt und die unterbrochene Aufgabe fortgesetzt. So einfach scheint es aber nicht zu sein....
Die göttliche Neugierde (Aussage von Albert Einstein)treibt aber auch mich, dass ich nach wie vor ebenfalls neugierig bin, inwieweit es möglich ist, von einer Lazarus -GUI-Anwendung aus, eine Unterbrechungroutine (ISR) auszuführen. Die Hardware ist jedenfalls Interruptfähig und ich glaube mal irgendwo gelesen zu haben, dass es eine besonder Eigenschaft des ARM-Prozessors ist, dass er 32 Hardware-Interrupts kennt.
Vielleicht findet dieses Thema hier noch eine Fortsetzung - ich bin gespannt und würde mich freuen (beim Spielzeug für große Buben).
Schönen Abend!
"Hardware-Interrupt" ist Betriebssystem-Angelegenheit. "GUI" ist User-Programmierung. Das geht überhaupt nicht zusammen, sondern muss separat behandelt werden und wenn man das braucht über entsprechende Betriebssystem-ASPIs (Threads, Signale, Device-Treiber, Timer, ...) mit einander verbunden werden.
Verein
Links
Suche