[C/C++] Timercallback für LCD Anzeige.

[jgmischke]

Wäre es möglich, auch für den LCD Bricklet ein Timercallback wie bei vielen anderen Bausteinen zu ermöglichen. Die Idee wäre, etwa alle XX Sekunden nachzusehen, ob in einem Puffer Texte für die Darstellung auf dem LCD sind, diese könnten dann aktualisiert werden, ohne dass die Darstellungsfunktion aus anderen Funktionen heraus genutzt werden muss. So könnten mehrere Daten zusammen fliessen und dann dargestellt werden.

 

[Nic]

So ganz habe ich es nicht verstanden: Welcher Baustein/Objekt/Klasse soll den Callb. auslösen ?

Ich bin nicht der c++ Profi, aber es dürfte auch in dieser Progr.sprache möglich sein, eigene Timer festzulegen die periodisch etwas tun, also unabh. von der TF-API.

Andererseits ist es immer günstiger die Callb. der Bricks zu nutzen statt zu pollen, und z.B. die Stepper.ReachedPosition http://www.tinkerforge.com/de/doc/Software/Bricks/Stepper_Brick_C.html#STEPPER_CALLBACK_POSITION_REACHED zu nutzen wenn der Motor eine gewünschte Position erreicht, im Callb.-Handler des Steppers würde ich dann den Text in den LCD schreiben.

[jgmischke]

Ja, da hab ich mich ungeschickt ausgedrückt.

Ich habe das LCD Display eingeplant, um sämtliche Meldungen aller Sensoren auszugeben. Dies kann ich natürlich machen, indem ich bei jedem Sensor die Werte mit lcd24_write... wegschicke. Das wird aber bei einer Vielzahl von Sensoren unübersichtlich.

Einfacher wäre es, etwa die Werte in einen belibig grossen Puffer zu schreiben, der dann regelmässig via Timer vom LCD selber abgearbeitet wird. ( Dort könnte man auch noch Meldungen nach Prioritäten sortieren und was weiss ich. Über den direkten Aufruf ist das alles nicht möglich. )

 

Es ist ja kein Problem, unter C einen eigenen Timer zu bauen, aber dieser könnte mit der TI Software kollidieren und wäre eben nicht Bestandteil der TI Software. So wäre es halt einfacher und eleganter, zumal alle TI-Timer ja von der TI Software gesteuert werden.

 

[Nic]

Welche Sensoren ? ich dachte du baust eine Astro-Nachführung ? Soviele Sensoren braucht die nicht

 

Also du möchtest in einem zentralen Timerevent alle Werte der Sensoren getten ?

aber dieser könnte mit der TI Software kollidieren und wäre eben nicht Bestandteil der TI Software.

Nein wieso, muss es es auch nicht. Warum ist das ein Problem ?

[jgmischke]

Die Astronachführung ist nur ein(!) Projekt, welches relativ einfach von der Anwendung her ist. Ist ja im Prinzip  nur ein wenig Schrittmotorsteuerung und das hab ich soweit schon fertig. Nächsten Monat kommt eine Untersetzung 1:3900 und dann teste ich das ganze mal-.

 

Wie gesagt, ein Timer für die LCD Anzeige wäre halt in der TF Umgebung einfacher.  Etwa so: Alle Sensoren liefern ihre Werte in einen Puffer ( Zeile 1 -x ) und machen dann weiter mit der Arbeit. Alle X Sekunden schaut dann die Anzeige nach, was sie ausgeben muss. ( Also etwa ein Rasenmäherbot oder sowas in der Art, mal sehen, der braucht schon einiges an Sensorik. )

 

 

[jgmischke]

"Nein wieso, muss es es auch nicht. Warum ist das ein Problem ?"

 

Es ist auch kein richtiges Problem, aber ein einfacher Callbackaufruf nach TF Manier wäre eben nur "einfacher", bzw. passt halt.

[Nic]

Nächsten Monat kommt eine Untersetzung 1:3900

Wo gibt es denn sowas für Schrittmotoren ?

Du willst das also noch vor den Getriebemotor spannen ?

Wie gesagt, ein Timer für die LCD Anzeige wäre halt in der TF Umgebung einfacher.

Wie stellst du dir das vor ? Bzw. wo "lebt" dieses Object ? Das LCD ist erstmal dumm und kennt die anderen Bricklets gar nicht. Grundsätzlich sind die Callb. dafür da, veränderten Status oder Zustandswerte im Bricklet/Bricks an den HostPC zu liefern. Das was du möchtest ist ein Timer in deiner Anwendung, der periodisch die Werte ermittelt, puffert und in einer bestimmten Logik im LCD ausgibt.

 

Wenn ichs richtig verstehe sind mit Sensorik beliebige Bricklets gemeint, die hängen alle an Bricks, die wiederum mit dem HostPC kommunizieren. Welche Sensoren ermittelt werden, musst du aber in deiner Software selbst programmieren.

Ich kann mit nicht vorstellen, dass das sonst nur durch API Anpassung im LCD machbar wäre.

[jgmischke]

Da ich in nackten C programmiere, stell dir das gnaze so vor: Beispiel ist ein Rasenmäher, der anhand von GPS und anderen Sensordaten fröhlich durch die Gegend mäht. ( Die ganze Logik und Auswertung wird von einem Raspberry erledigt, der an den Bricks hängt ) Und jeder Sensor meldet nun ab und an oder wenn ein Ereignis eintrifft: Da steht was im Wege, es regnet oder ähnliches. Und dies soll halt die LCD anzeigen. Im einfachsten Fall etwa so:

 

GPS-Brick

sprintf(zeile[0],"Ko: 13.23.45 43.32.12");

 

wobei dann die Zeilenpuffer einfach für alle global erreichbar sind.

 

Dann sprint irgendwann der Callback des LCD an und die Meldung erscheint unabhängig von dem, was alle anderen Teile gerade machen. Deswegen braucht das LCD auch nichts von den andren Teilen wissen, es bekommt statt dessen seinen Puffer gefüllt und hat diesen dann abzuarbeiten.

 

Ich habe mir schon ein Grundgerüst gebaut, welches selbstständig alle Bricks erkennt, diesen Namen zuweist, alle Device initialisert, die UID speichert etc. Und da habe ich gemerkt, das so ein LCD Timer eben ganz nett wäre.

 

Aber das ist im Prinzip auch noch ganz am Anfang, das Grundgerüst jkann ich dann eben je nach Anwendung immer wieder nutzen, ob nun fürs Teleskop oder als Rasenmäher.

 

 

[remotecontrol]

Die Bricklets selber sind ja erstmal relativ "dumm" und die Bricks steuern weitestgehend die Callbacks. Aber viel Speicher haben die Bricks nicht, d.h. einen größeren Puffer kann man da gar nicht einbauen.

 

Eine machbare Funktion wäre wohl, alle X Millisekunden vom LCD einen Callback auszulösen der nur sagt "Timer abgelaufen". Aber das bringt nicht viel. Das kannst direkt in C/C++ machen. Das kommt auch nicht mit den TF Threads in Konflikt.

 

Ich mache das so, dass ich mehrere "virtuelle" Displays habe. Die Anwendung schreibt von beliebigen Stellen/Threads in die virtuellen Displays und ein anderer Thread kontrolliert wann welcher Inhalt auf dem LCD ausgegeben wird - geht wunderbar (nur muss man auf saubere Thread-Synchronisierung achten).

[Nic]

Die ganze Logik und Auswertung wird von einem Raspberry erledigt, der an den Bricks hängt

Damit ist eigentlich schon gesagt wo dieser Puffer oder Message Queue hingehört: Zum Raspi/RED oder den HostPC, denn nur dort kannst du die TF-Bausteine auch registrieren wie du es schon machst:

Grundgerüst gebaut, welches selbstständig alle Bricks erkennt, diesen Namen zuweist, alle Device initialisert, die UID speichert etc

Und dieser Vorgang ist nur in deiner Application möglich. Sowas kann der LCD bzw. alle Bricklets nicht.

 

Du möchtest dir den ganzen Aufwand der Timer-Implem. und Logik der Abarbeitung sparen durch einen Automatismus angesiedelt im LCD. Das wird es nicht geben bzw. die Hardware gibt das nicht her. Und genau für solche Zwecke wurde der RED konzipiert um quasi das "OnDevice-Programming" mittels beliebiger Sprache zu ermöglichen. Aber du machst das schon mit einem Raspi, der RED ist aber wesentlich kompakter.

 

Sei mir nicht böse wenn ich nochmal nachfrage aber die Astro-Nachführung interessiert mich schon sehr, darum nochmal die Frage um was für ein Getriebe mit 1:3900 handelt es sich ?

[jgmischke]

Hi Nic,

 

ja, ist schon klar, das der Puffer auf dem Host laufen muss, es ging und geht nur darum, dass es einfachen eine zusätzliche Funktion für das LCD Bricklet gibt, wo halt ein Timer vom Host gesetzt wird. Geht auch mit setitmer oder timercreate, aber manche Signale bringen das NCurses durcheinander, zumal wenn es multithreaded läuft. SIGALRM ist da völlig unbrauchbar.

 

Naja, prog ich mir halt einen Timer füs LCD zusammen, aber danke fürs mitdenken und helfen. 

[jgmischke]

@remotecontrol.

 

Genauso ist es ja auch geplant, die Puffer auf dem Host stellen quasi eine Art virtuelles Display dar und da wäre halt ein LCD Timer von TI bequemer, da ja alle Timerevents von dort gesteuert werden. Mach ich es jetzt eben selbst. Trotzdem DANKE!

[jgmischke]

@ NIC: " Wo gibt es denn sowas für Schrittmotoren ?

Du willst das also noch vor den Getriebemotor spannen ?"

 

Ja bei uns in der Hardwareentwicklung gibt es einen Freak, der kennt eine Firma, die Getriebe auch alleine verkaufen, also ohne jeden Motor. Die Preise sind human und selbst wenn mein Projekt "Erdrotation" nicht klappt, habe ich schon jetzt so viel gelernt, das sich das ganze auf jeden Fall lohnt. Und wenn es dann klappt, ein Weitwinkelbild vielleicht ein paar Minuten zu belichten OHNE Strichspuren .. mal sehen. Ich kann ja dann davon berichten, wenn du Interesse daran hast.

[Nic]

Aha, du möchtest den Timer zumindest im LCD Bricklet haben damit dieser von sich aus den Callb. auslöst. Das alleine wäre sicher noch möglich, und da du fit in C Programmierung bist könntest du die Firmware (openSource) auch gleich selber anpassen. Dann noch schnell die Bindings etc. Einige Pioniere haben das wohl schon geschafft, z.B. Status LED ein/ausschalten. Ich persönlich möchte meine Zeit und Nerven schonen, und mache solche Dinge dann lieber im RED.

 

Wenn es nicht Topsecret ist gib doch einfach mal einen Link vom Getriebehersteller an, wo wir Forenteilnehmer uns das auch mal genauer anschauen können. Du kannst davon ausgehen, dass nicht nur ich von einer DIY Astronachführung träumen

[jgmischke]

Ich stelle die Webadresse am Monatg hier rein, wenn ich wieder auf Arbeit bin.

[jgmischke]

Hier wie versprochen die Webadresse:

 

http://www.dc-getriebemotor.de/

 

 

[Nic]

Prima, danke. Aber welchen hast Du genommen ? Das sind alles DC-Motoren...

Und den Motor willst du an den Stepper-Brick anschließen ?

 

Gib mal so eine grobe Hausnummer für den Preis deines 1:3900 Getriebes an.

[jgmischke]

@NIC

 

Also es gibt auch die Getriebe OHNE Motor. Leider gibt es da noch keine PDF Datei für, aber das DSMP221 hat ein Getriebe mit 1:3968, das würde ich gerne mal ausprobieren. ( Ok, ist 5 stufig, aber einfach mal schaune ob das irgendwie passt )

 

Preise hab ich noch nicht, da wollte sich mein Kollege mal schlau machen, aber der verpennt das bestimmt.

 

[Nic]

Die Preise sind human

Wieso ich dachte die Preise sind bekannt ? Es reicht auch grob wohin der Preis geht, dann haben wir hier eine gewisse Vorstellung von den Gesamtkosten.

 

Ich habs später gesehen, dass die Getriebe einzeln gibt, allerdings werde ich aus den Angaben nicht schlau. Das muss natürlich auf dem Schrittmotor passen und adaptierbar sein. Schrittmotoren werden i.d.R. in der Bauform Nema 16,17,23 etc. gehandelt: https://de.wikipedia.org/wiki/Schrittmotor#Baugr.C3.B6.C3.9Fe

 

Vielleicht machst du den Thread im Projekt-Forum http://www.tinkerunity.org/forum/index.php/board,3.0.html neu auf und berichtest über deine Fortschritte quasi als Blog.

[jgmischke]

@NIC

 

Naja, da sitzen echt Profis. Ob das Teil auf eine NEMA 17 passt, konnte mir der Mensch am Telefon nicht sagen, das 5 stufige Getriebe mit fast 1:4000 liegt bei 64€ netto. Ist also noch finanzierbar. Mal sehen, ob ich auch jemanden von der Technik dran bekomme, dann gibt es mehr Info.

 

 

[jgmischke]

@NIC

Ups, das Teil ist wohl etwas klein geraten, wird auf ein NEMA 17 nicht passen. Aber ein anderes Teil in der gleichen Preisklasse mit 1:3600 Untersetzung gibt es auch noch.

 

Ich packe das mal in Zukunft unter den von dir gezeigten Forumspunkt.

[Nic]

Das wäre prima, welches Teil würde auf den Nema 17 Motor passen ?

Kauf den Schrittmotor OHNE aufgeflanschtes Getriebe, bei der Chinaware wäre ich mir nicht sicher, ob die sich so einfach auseinander nehmen lässt.

 

Verkauft diese Firma auch an Privatleute ?