ANDROID/JAVA sehr genauer Timer benötigt

Gast #3045270
Lesenswert?

Hallo an alle,

gibt es in Java /Android einen sehr genauen TimerTask?

Ziel:
Ich erhalte meine Daten per MC und will sie GENAU alle 20 ms auf dem
Bildschirm darstellen/aktualisieren.

mit dem normalen TimerTask funktioniert es nicht, da der nicht
gewährleistet, dass er GENAU alle 20 ms die Aktualisierung durchführt 
(wurde mit Oszi geprüft).

Gibt es hier ein paar Ideen, wie man das Problem lösen könnte?


Viele Grüße,

Banause
Gast #3045287
Lesenswert?

Erzähl erstmal was du genau vorhast..das klingt nach einem massiven 
Design Fehler...
Alleine das scheduling, framebuffering etc machen es ohne tiefen 
Eingriff unmöglich sowas zu realisieren...dafür sind Tablets auch nicht 
gedacht..
Gast #3045311
Lesenswert?

Naja ich möchte Daten von einem MC lesen, diese schickt er ständig.

Genau alle 20 ms möchte ich schauen ob neue Daten angekommen sind.

Die Daten lese ich mit einen InputStream ein.

Bisher habe ich es so realisiert:
Thread1 empfängt etwas --> Flag wird gesetzt
TimerTask (auf 20 ms gesetzt) schaut on das Flag gesetzt ist oder nicht 
und aktualisiert je nach dem ob das Flag true oder false ist die 
grafische Oberfläche.

Ich hoffe dass diese Erklärung hilft.

Und wenn Systemnähere EIngriffe notwendig sind, würde ich mich über 
Hilfe dazu freuen.

Viele Grüße,
Banause
Gast #3045320
Lesenswert?

Systemnaher Eingriff bedeutet neuer Kernel ...ggf kein android.. Eigene 
Firmware für die GPU+ Display Controller etc etc etc
Also nochmal..hat es einen Grund mit den 20ms ? Ohne Infos kann dir hier 
nicht geholfen werden. Das was du machen willst geht so definitiv nicht
Gast #3045328
Lesenswert?

banause schrieb:
> Bisher habe ich es so realisiert:
> Thread1 empfängt etwas --> Flag wird gesetzt
> TimerTask (auf 20 ms gesetzt) schaut on das Flag gesetzt ist oder nicht
> und aktualisiert je nach dem ob das Flag true oder false ist die
> grafische Oberfläche.

Absoluter Unsinn den du da baust.

Hier setzt man auf ein Event-basiertes System.


Task 1 besteht aus der RS232-Routine welche das Zeichen bzw. den Wert 
entgegen nimmt und in einen Buffer schiebt. Dies wird durch das 
jeweilige RS232 Framework aufgerufen (so wie ein Interrupt auf einem 
uC). Nix mit Polling oder so einem Müll.

Task 2 berechnet entkoppelt von der zeitkritischen Routine die 
jeweiligen Daten. Kann ja per Busy-Waiting dem Buffer schnuppern oder 
wie auch immer. Ist ja egal.
Gast #3045345
Lesenswert?

Es geht um eine grafische Protokollanalyse.

Alle 20 ms soll sich ein Balkendiagramm "weiter nach rechts" animieren.
Es müssen sehr genau 20 ms sein, da es verschiedene Sender gibt und die 
alle untereinander anhand von Balkendiagrammen die Anfagre und Antwort 
darstellen sollen:

BSP:
  _
__||_______  Das ist ein Balkendiagramm. es Zeigt, dass ein Protokoll 
empfangen wurde
     
__||__||___
  <--->
   20 ms
Gast #3045379
Lesenswert?

Mehrere Kanäle aufzeichnen und hoffen das die auf dem Bildschirm 
synchron zusammenlaufen? Das geht nicht. Du brauchst einen Thread der 
alle 20ms oder schneller drankommt und dann alle Kanäle einliest und die 
Daten in ein Array packt. Ein zweiter Thread kann dann die Daten für die 
Darstellung aufbereiten (Redern).
Gast #3045388
Lesenswert?

Ein Thread liest ca. voller Tablet-Perfomance die Daten ein und verpackt 
sie in ein Arrays.

Nur eben das Problem mit Thread2 oder Timer oder Interrupt oder oder 
oder bekomme ich es nicht in den Griff alle 20 ms die GUI zu 
aktualisieren...
Persönliche Seite #3045751
Lesenswert?

banause schrieb:
> und wie bekomme ich eine genaue 20 ms Zeitdifferenz hin?

Der uC muss alle Kanäle "syncron" (z.B. alle liegen auf einem Port und 
dann ein in auf diesem port) einlesen und mit einem Zeitstempel versehen 
(z.B. aktueller Timerwert eine 8 bit Timers).

Dies werte werden dann an das Tablet gesendet, der empfängt sie im RS232 
Handler und packt sie in eine passende Datenstruktur.

Alle 200..500 ms aktualisierst du dann das "Bild" in einem eigenem Task 
indem du die letzen X Werte nutzt, die Abstände der Datenpunkte ergeben 
sich dann aus den Zeitstempeln (Wraparound berücksichtigen!) und du hast 
überhaupt keine Probleme, kannst sogar scrollen und ggf. eine 
Protokollanalyse darüber fahren und sogar die exakte Samplerate auf dem 
uC ist nicht mehr so kritisch solange sie hoch geug ist das Signal 
passend abzutasten. Mit einem kleinen Puffer auf uC Seite kann sogar 
eine höhere Datenrate als die RS232 hergibt genutzt werden wenn immer 
mal wieder kurze Abschnitte gesampelt werden sollen.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren