amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Tonerkennung [ - Suche - Neue Beiträge - Registrieren - Login - ]

Erste 2 3 4 5 6 -7- 8 9 10 11 [ - Beitrag schreiben - ]

11.09.2006, 23:48 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Mad_Dog:
Zitat:
Original von whose:

testen kann ich das mangels Sampler leider nicht selbst :(


Naja... testen kannst Du's auch ohne Sampler - Du bekommst dann eben eine Flatline (Patient tot ;) ).


Naja, aber nen toten Patienten kitzeln bringt irgendwie wenig Spaß ;)

Ich werds auf jeden Fall mal laufen lassen und auch schauen, ob man da noch was dran verbessern kann. Für die Grafik-Geschwindigkeits-Frage wäre es aber schon besser, wenn ich einen Sampler zum Testen hätte *schnüff*

Hat vielleicht jemand der Mitlesenden einen über? Ein Billigheimer-Modell (von mir aus auch ein Mono-Sampler) würde es schon tun, für ernsthaftes Soundsampling habe ich eine Delfina bzw. Toccata bzw. µA1-onboard-Soundkarte.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 11.09.2006 um 23:58 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 13:57 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
Inzwischen konnte ich mich näher mit dem Testprogramm beschäftigen. Die "Drift" zwischen Systemzeit und WAITUNTIL-Zeit ist ganz einfach zu erklären: Du hast vergessen, nach dem ersten Holen der Systemzeit target entsprechend in der while-Schleife zu setzen (auch in dem Teil, wo auf checkTime geprüft wird. Mach einfach die Bedingung immer wahr, dann siehst Du es).

Um die korrekte WAITUNTIL-Zeit zu bekommen, muß man sich vorher mittels TR_GETSYSTIME die aktuelle Systemzeit holen und dann erst die Differenz aufaddieren. Das fehlt in der while-Schleife, da addierst Du immer nur die Differenz auf die zu Beginn von main() gelesene SysTime, nicht auf die aktuelle. Daher driftet das auseinander, weil ja trotz allem immer ein wenig Zeit "verplempert" wird. Je länger das läuft, desto größer die "Drift" (die in Wirklichkeit gar keine ist).

Um Himmels Willen, das wäre ja exakt das Gegenteil von dem, was es tun soll. Wenn ich will, dass das Programm 8000 Mal wartet und danach exakt einen Sekunde vergangen sein soll, muss das timer.device auch auf die korrekte Zeit warten, wenn ich sage dass es Zeitpunkt zum Programmstart plus 8000 * 125 µs warten soll. Würde ich zu diesem Zeitpunkt die Systemzeit erneut holen, obwohl ich ja weiß, dass bis zur Ausführung von TR_GETSYSTIME schon wieder Zeit vergangen ist, dann wäre vollkommen klar, dass die Gesamtwartezeit größer als 125µs ist. Genau das will ich aber nicht. Wenn ich sage "warte bis zum letzten Meßzeitzeitpunkt plus 125µs", dann ist klar, dass zu diesem Zeitpunkt schon etwas Zeit vergangen ist und deshalb die eigentliche Wartezeit kleiner als 125µs sein wird. Aber genau das will ich ja, jetzt klar?
Zitat:
Allein das end_timer() sorgt schon für kleinere Differenzen, der Goertzel für noch größere. Vor allem unterscheiden sich die Differenzen immer etwas, weil end_timer() nie ganz exakt gleich "wartet", bis der Request erledigt wurde.
end_timer() warte auf das Erreichen eines Zeitpunkts, genau das ist der Sinn von WAIT_UNTIL. Bei größeren Intervallen funktioniert das auch. Natürlich ist die Systemzeit nach end_timer() etwas größer als die Zielzeit, und die Differenz schwankt. Aber sie bleibt in der gleichen Größenordung.
Zitat:
Das erklärt übrigens auch, weshalb das auch ohne Goertzel und Textausgabe irgendwann einfach "durchrauscht". Die WAITUNTIL-Zeit ist ja, dank der "Drift" immer schon überschritten, wenn der Request gesendet wird. In der Folge kehrt das sofort zurück, statt 125µs zu warten.
Und genau das nicht nicht verständlich. Auf meinem System brauchen Goertzelberechnung und Textausgabe zusammen weniger als 125µs, genauer gesagt, weniger als 50µs. Erst die Verwendung des timer.devices sorgt für diese Drift. Das heißt, der Overhead des timer.device scheint zu hoch zu sein.
Zitat:
2. braucht printf() (nicht Printf(), die läuft etwas schneller) auf meinem WinUAE-System ca. 20 tausendstel, um Text auszugeben. Das läßt sich dann prima ablesen. Sogar die Differenzen passen bis auf 2µs genau bei jedem Durchlauf.
Da ich ja nur zur vollen Sekunde eine Ausgabe mache (oder gar keine, wenn ich sie deaktiviere), ist das irrelevant.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 14:00 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
@Holger:

Also, ich hab den GCC auf Standardeinstellungen laufen, der übersetzt das nicht. Wäre mir irgendwo auch neu, daß Definitionen/Deklarationen "irgendwo im Code" unterstützt würden. Aber seis drum.

Das unterstützt gcc sowieso, genauso wie die Doppelslash-Kommentare. Aber wenn Du es richtig haben willst, gibst Du als Option -std=c99 an, und dann hast Du das ganze Paket. Zumindest soweit, wie gcc das unterstützt. Aber ich kann mir auch nicht vorstellen, dass vbcc wesentlich weiter als gcc sein sollte.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 14:05 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
Abgesehen davon hängt es sich auf dem WinUAE weg, nachdem der Timer gestartet wurde und das Signal eintrifft (im Storm-Debugger sieht man aber sehr gut, daß das Signal wie gewünscht noch eintrudelt und auch noch registriert wird).


Was hängt sich weg, und was für ein Signal meinst Du?
Ctrl+C?
Dann hast Du bestimmt diese Clipboard-Tool zu laufen. Das hat das "tolle" Feature, dass Ctrl+C als "Copy" abgefangen wird. Wenn Du aus 'ner andern Shell mittel break das Ctrl+C schickst, bricht es problemlos ab.

Oder Du meinst irgendetwas anderes?

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 14:12 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
@MaikG:

Zu dem BASIC-Code kann ich Dir relativ wenig sagen, weil ich MB nicht besitze. Eine Anmerkung habe ich aber:
code:
target&=PEEKL(tr& + tr_time%)


Das funktioniert nicht. target& muß eine timeval-Strukur sein, keine einfache 32-Bit-Zahl. Im C-Code funktioniert das, weil der C-Compiler Strukturen komplett kopieren kann. MB kann das nicht.

Und die Übergabe bei AddTime muss die Pointer übergeben, nicht die Werte.
Also statt
code:
target&=PEEKL(tr& + tr_time%)
AddTime& target&, offset&(0)

dann
code:
DIM target&(2)
target&(0)=PEEKL(tr& + tr_time% + tv_secs%)
target&(1)=PEEKL(tr& + tr_time% + tv_micro%)
AddTime& VARPTR(target&(0)), VARPTR(offset&(0))

oder so ähnlich

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 15:03 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Inzwischen konnte ich mich näher mit dem Testprogramm beschäftigen. Die "Drift" zwischen Systemzeit und WAITUNTIL-Zeit ist ganz einfach zu erklären: Du hast vergessen, nach dem ersten Holen der Systemzeit target entsprechend in der while-Schleife zu setzen (auch in dem Teil, wo auf checkTime geprüft wird. Mach einfach die Bedingung immer wahr, dann siehst Du es).

Um die korrekte WAITUNTIL-Zeit zu bekommen, muß man sich vorher mittels TR_GETSYSTIME die aktuelle Systemzeit holen und dann erst die Differenz aufaddieren. Das fehlt in der while-Schleife, da addierst Du immer nur die Differenz auf die zu Beginn von main() gelesene SysTime, nicht auf die aktuelle. Daher driftet das auseinander, weil ja trotz allem immer ein wenig Zeit "verplempert" wird. Je länger das läuft, desto größer die "Drift" (die in Wirklichkeit gar keine ist).

Um Himmels Willen, das wäre ja exakt das Gegenteil von dem, was es tun soll. Wenn ich will, dass das Programm 8000 Mal wartet und danach exakt einen Sekunde vergangen sein soll, muss das timer.device auch auf die korrekte Zeit warten, wenn ich sage dass es Zeitpunkt zum Programmstart plus 8000 * 125 µs warten soll. Würde ich zu diesem Zeitpunkt die Systemzeit erneut holen, obwohl ich ja weiß, dass bis zur Ausführung von TR_GETSYSTIME schon wieder Zeit vergangen ist, dann wäre vollkommen klar, dass die Gesamtwartezeit größer als 125µs ist. Genau das will ich aber nicht. Wenn ich sage "warte bis zum letzten Meßzeitzeitpunkt plus 125µs", dann ist klar, dass zu diesem Zeitpunkt schon etwas Zeit vergangen ist und deshalb die eigentliche Wartezeit kleiner als 125µs sein wird. Aber genau das will ich ja, jetzt klar?

Ja, klar ist mir das schon länger. Das Problem dabei ist, daß das "mit der Zeit" schiefgeht, eben genau weil die Wartezeit (bzw. die sich bildende Differenz zur aktuellen SysTime) immer kleiner wird.

Angenommen, pro Durchlauf gehen Dir (seit dem Initialmeßzeitpunkt) genau 5 µs für "andere Aufgaben" flöten (schließlich schaffst Du es nie, den neuen Request sofort nach Erhalt des Signals auf den Weg zu bringen).

Dann dauert es genau 25 Durchläufe, bis aktuelle SysTime und WAITUNTIL-Zeit genau gleich sind. Ab dem 26. Durchlauf hat sichs ausgeWAITUNTILt, weil Deine berechnete WAITUNTIL-Zeit kleiner als die tatsächliche SysTime geworden ist (durch den "Verlust", den die anderen Tätigkeiten im Programm halt mit sich bringen). Das ist der Zeitpunkt, wo die SysTime Deine Initial-SysTime zzgl. bisher addierte Wartezeiten "überholt".

Nicht der Timer ist zu langsam, Dein Programm ist es.

Jetzt klar?

Das Ganze würde nur dann wie von Dir gewünscht funktionieren, wenn sich der Timer zyklisch selbst auf die Differenz einstellen würde und quasi ein Taktsignal von sich gibt.

Programmtechnisch funktioniert das einerseits, wenn Du vor jedem Request an die WAITUNTIL-Unit die aktuelle Systemzeit als Basis holst. Je größer das gewählte Intervall, desto länger dauert es, bis die SysTime "zum Überholen ansetzt", wenn Du nur einmal zu Beginn die Systemzeit holst. Je kleiner das Intervall, desto früher wird "überholt" (bei gleich großen "Verlusten").

Andererseits, wenn Du ein Signal nach exakt einer Sekunde erhalten willst bei 8000 Zyklen, mußt Du die "Verluste" Deines Programms mit in die Wartezeit einkalkulieren (soll heißen: Messen und die Wartezeit um den entsprechenden Betrag verkleinern und hoffen, daß Dein Programm schnell genug ist, um in der Zeit zu schaffen, was es tun soll). Dein Programm "muß schneller laufen", um die Verluste zu kompensieren. Erst dann funktioniert das so, wie Du es gern hättest.

Um es klarer zu machen: Die 125µs bleiben, aber Du mußt z.B. die "weitergelaufenen" z.B. 50µs mit einkalkulieren. Das geht am einfachsten mit Kalibrierung (wie lange dauert ein Durchlauf?), ständiger Aktualisierung der Zeitbasis (GETSYSTIME) und Addition der 125µs abzüglich des Kalibrierungswerts. Ansonsten wäre finstere Rechnerei angesagt.

Oder Du arbeitest mit Unit_MICROHZ, dann funktioniert das auch mit der festen Basis und gleichbleibenden Differenzen, sofern der Request asynchron gesendet wird (und natürlich, sofern das Programm schnell genug läuft, um das Signal nicht zu verpennen).

Im Grunde funktioniert WAITUNTIL ja als einfacher Vergleich mit der aktuellen Systemzeit. Da wird dann nur ein Zähler heruntergezählt (Differenz von den Zeitwerten aus dem Request zur aktuellen Systemzeit), sobald der 0 erreicht hat, gibts ein Signal. Ergibt die Differenz der Zeitwerte aus dem Request zur aktuellen Systemzeit eine negative Differenz oder 0, gibt das timer.device "sofort" ein Signal (oder besser: sollte es. Ich weiß nicht, was bei einer negativen Differenz passiert).

Zitat:
Zitat:
Allein das end_timer() sorgt schon für kleinere Differenzen, der Goertzel für noch größere. Vor allem unterscheiden sich die Differenzen immer etwas, weil end_timer() nie ganz exakt gleich "wartet", bis der Request erledigt wurde.
end_timer() warte auf das Erreichen eines Zeitpunkts, genau das ist der Sinn von WAIT_UNTIL. Bei größeren Intervallen funktioniert das auch. Natürlich ist die Systemzeit nach end_timer() etwas größer als die Zielzeit, und die Differenz schwankt. Aber sie bleibt in der gleichen Größenordung.

Nein, bleibt sie nicht. Da können durchaus mehr als 2µs Differenz bei herumkommen, besonders auf WinUAE-Systemen im Fenstermodus. Meß das einfach mal.

Zitat:
Zitat:
Das erklärt übrigens auch, weshalb das auch ohne Goertzel und Textausgabe irgendwann einfach "durchrauscht". Die WAITUNTIL-Zeit ist ja, dank der "Drift" immer schon überschritten, wenn der Request gesendet wird. In der Folge kehrt das sofort zurück, statt 125µs zu warten.
Und genau das nicht nicht verständlich. Auf meinem System brauchen Goertzelberechnung und Textausgabe zusammen weniger als 125µs, genauer gesagt, weniger als 50µs. Erst die Verwendung des timer.devices sorgt für diese Drift. Das heißt, der Overhead des timer.device scheint zu hoch zu sein.

Nein. Mit den Ausführungen oben hast Du schon die Erklärung. Wenn der Goertzel vor dem Senden des neuen Requests ausgeführt wird, fehlen von den 125µs Differenz im Vergleich zur bereits weitergelaufenen SysTime schon 50µs. Das ist der "Overhead", den Du zu messen meinst. Immerhin gehst Du ja weiter von 125µs aus, statt von den tatsächlichen 75µs, die noch im Vergleich zur (weitergelaufenen!) SysTime übrig sind.

Das bedeutet, daß die von Dir dem timer.device übergebene Wartezeit im Endeffekt nur noch 75µs beträgt (weil Du ja nicht die zum Zeitpunkt des Request-Sendens aktuelle SysTime als Basis nimmst, sondern die, die Du einmal in main() zu Beginn besorgt hast). Ab dem dritten Durchlauf ist die aktuelle SysTime weit vor Deiner "Basis-SysTime plus 3 * 125", nämlich 25µs.

Zitat:
Zitat:
2. braucht printf() (nicht Printf(), die läuft etwas schneller) auf meinem WinUAE-System ca. 20 tausendstel, um Text auszugeben. Das läßt sich dann prima ablesen. Sogar die Differenzen passen bis auf 2µs genau bei jedem Durchlauf.
Da ich ja nur zur vollen Sekunde eine Ausgabe mache (oder gar keine, wenn ich sie deaktiviere), ist das irrelevant.

Ganz und gar nicht. 20tausendstel sind einiges mehr als unsere Differenz hier. Mit einem printf() sind wir dann schon weiiiiiit hinter der Systemzeit zurück, wenn wir die Basis unserer WAITUNTIL-Zeit nicht aktualisieren. Bei keiner Ausgabe zählen natürlich nur die "übrigen" Verluste.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 12.09.2006 um 15:13 Uhr geändert. ]

[ Dieser Beitrag wurde von whose am 12.09.2006 um 15:16 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 15:06 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Abgesehen davon hängt es sich auf dem WinUAE weg, nachdem der Timer gestartet wurde und das Signal eintrifft (im Storm-Debugger sieht man aber sehr gut, daß das Signal wie gewünscht noch eintrudelt und auch noch registriert wird).


Was hängt sich weg, und was für ein Signal meinst Du?
Ctrl+C?
Dann hast Du bestimmt diese Clipboard-Tool zu laufen. Das hat das "tolle" Feature, dass Ctrl+C als "Copy" abgefangen wird. Wenn Du aus 'ner andern Shell mittel break das Ctrl+C schickst, bricht es problemlos ab.

Oder Du meinst irgendetwas anderes?


Nein, ich meinte einen Absturz. Was es genau war, darfst Du mich nicht fragen, ich hab n paar kleine Umbauten gemacht, weiß aber nicht mehr, was ich da genau geändert habe. Aber es läuft ja nun.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 15:36 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
Angenommen, pro Durchlauf gehen Dir (seit dem Initialmeßzeitpunkt) genau 5 µs für "andere Aufgaben" flöten (schließlich schaffst Du es nie, den neuen Request sofort nach Erhalt des Signals auf den Weg zu bringen).

Tut mir leid, ich möchte nicht den gesamten Text quoten, er scheint insgesamt durchgängig das gleiche zu sagen, und es bleibt, ich kannst nicht anders sagen, Unsinn.

Noch mal: Wenn ich sage: "warte auf den Zeitpunkt x", dann heißt das, Zeitpunkt x, und nichts anderes. Dabei ist es vollkommen unwichtig, zu welcher Zeit ich diesen Auftrag erteile, ob das nun zum Zeitpunkt "x-125µs" oder "x-80µs" oder "x-10µs" ist. Solange der Zeitpunkt x noch nicht erreicht war. Wenn meine Goertzelberecnung also wider Erwarten nicht 20µs dauert, sondern 30µs, macht das keinen Unterschied.
Zitat:
Nicht der Timer ist zu langsam, Dein Programm ist es.
Jetzt klar?

NEIN
Verdammt noch mal, lies und versteh es: ich kann die Goertzelberechnung und sämtliche Ausgaben auskommentieren, das Programm tut dann nichts weiter als timer-Requests zu verschicken und zu empfangen und es funktioniert trotzdem nicht mit einem Intervall von 125µs.

Und das auf einem System, das ohne timer.device ein Sample im fünffachen der eigentlichen Länge analysieren kann, auch mit Debug-Output.

Zitat:
Nein, bleibt sie nicht. Da können durchaus mehr als 2µs Differenz bei herumkommen, besonders auf WinUAE-Systemen im Fenstermodus. Meß das einfach mal.
Und?!
Was interessieren mich 2µs?
Dan wartet der timer halt nicht 125-x µs, sondern 125-x-2 µs.
Zitat:
Nein. Mit den Ausführungen oben hast Du schon die Erklärung. Wenn der Goertzel vor dem Senden des neuen Requests ausgeführt wird, fehlen von den 125µs Differenz im Vergleich zur bereits weitergelaufenen SysTime schon 50µs.
Kann es sein, dass Du einfach nicht begreifst, was "wait until" heisst?! Es heisst "warte bis" zum Zeitpunkt. Und auch wenn es keine Rolle spielt, wann der Request abgeschickt wird, so hast Du offenbar auch noch nicht wirklich das Programm verstanden, es wird kein Goertzel "vor dem Senden des neuen Requests" ausgeführt, und kein Printf. Zuerst wird der Request verschickt, dann wird berechnet, dann wird auf die Anwort vom Request gewartet. Dazwischen findet lediglich die Überprüfung von CTRL+C statt.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 16:03 Uhr

Holger
Posts: 8090
Nutzer
Also für die, die mit der Komplexität des ursrünglichen Programms überfordert waren:
C code:
#include <proto/dos.h>
#include <proto/exec.h>
#define __NOLIBBASE__
#define TimerBase (tr->tr_node.io_Device)
#include <proto/timer.h>
#include <devices/timer.h>

struct timerequest *open_timer(long unit)
{
  struct MsgPort *port;
  struct timerequest *req;

  if(port = CreateMsgPort())
  {
    if(req=(struct timerequest*)CreateIORequest(port,sizeof(struct timerequest)))
    {
      if(0 == OpenDevice("timer.device", unit, (struct IORequest*)req, 0))
        return req;
      DeleteIORequest((struct IORequest*)req);
    }
    DeleteMsgPort(port);
  }
  return NULL;
}
void close_timer(struct timerequest *req)
{
  struct MsgPort *port;

  if (req)
  {
    CloseDevice((struct IORequest *)req);
    port = req->tr_node.io_Message.mn_ReplyPort;
    DeleteIORequest((struct IORequest *)req);
    DeleteMsgPort(port);
  }
}

int main(int x, char**y)
{
  struct timerequest *tr=open_timer(UNIT_WAITUNTIL);
  struct timeval target, offset={0, 10000};
  int ticksPerSecond=1000000/offset.tv_micro, i;

  if(!tr) { PrintFault(IoErr(), "Couldn't open timer.device"); return 10; }
  tr->tr_node.io_Command=TR_GETSYSTIME;
  DoIO(&tr->tr_node);
  target=tr->tr_time;
  tr->tr_node.io_Command = TR_ADDREQUEST;
  for(i=0; i<ticksPerSecond&&!(SetSignal(0L,0L)&SIGBREAKF_CTRL_C); i++)
  {
    AddTime(&target, &offset);
    tr->tr_time=target;
    DoIO((struct IORequest *)tr);
  }
  tr->tr_node.io_Command=TR_GETSYSTIME;
  DoIO(&tr->tr_node);
  VPrintf("processed %ld requests\n", (ULONG*)&i);
  VPrintf("target time { %ld, %ld }\n", (ULONG*)&target);
  VPrintf("sys time { %ld, %ld }\n", (ULONG*)&tr->tr_time);
  close_timer(tr);
  return 0;
}


Kann man auch ohne C99-Modus übersetzen, man braucht nix mehr auszukommentieren und man sieht auch deutlich, dass in der Schleife nichts, aber auch wirklich nichts passiert. Und ich habe schonmal das Intervall auf 10ms verlängert, damit man wirklich einsieht, dass der Amiga das normalerweise schaffen sollte und Abweichungen im Sekundenbereich nicht verständlich sind...

Falls es nicht doch am verwendeten System liegt. Aber hier hat sich ja noch niemand gemeldet, bei dem es funktioniert, wie es sollte.

Man kann auch gerne mit anderen Intervallen (wie wär's mit 125µs?) experimentieren.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 17:52 Uhr

MaikG
Posts: 5172
Nutzer
Ich Experimentiere grade mit Getsystime.
Wie bekommt man den Überschlag von den micros weg?

Ich meine jetzt mit normalen Rechenoperationen, ohne
das Addtime dingels.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 19:17 Uhr

whose
Posts: 2156
Nutzer
@Holger:

Tu mir einfach den Gefallen und kalibriere das Programm. Nimm die Latenzen raus, hol dir die Systemzeit bei jedem Durchlauf, rechne die Ungenauigkeit des Timers von ca. 2µs da raus und probiers nochmal.

Grüße

Edit: Schau doch auch nochmal ins RKM "Devices", was da zum Thema Genauigkeit im Sekundenbereich ohne besondere Maßnahmen bei UNIT_MICROHZ (das Gleiche für WAITUNTIL, weil gleiche Basis) gesagt wird.

Grüße


[ Dieser Beitrag wurde von whose am 12.09.2006 um 22:22 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 19:30 Uhr

whose
Posts: 2156
Nutzer
@MaikG:

Meinst Du den "Überlauf" bei 999999 micro?

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 22:22 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
Es ist eben nicht unwichtig, wann Du eine Differenz als Wartezeit ab einem fixen Zeitpunkt nach Systemzeit angibst, verdammt nochmal!

Ich übergebe keine Differenz, ich übergeben eine Zielzeit. Es heisst WAITUNIT, weil auf auf einen Zeitpunkt wartet.
Zitat:
Du gibst doch einen fixen Zeitraum von 125µs ab Zeitpunkt x an mit jedem Durchlauf.
Ich sage er soll Auf!(verdammt nochmal, was ist daran so schwer zu kapieren!) den Zeitpunkt target warten. target ist der Programmstartzeitpunkt plus 125µs, bzw. nach n Durchläufen der Programmzeitpunkt plus n * 125µs. Also nach 8000 Durchläufen sagt das Programm, "warte bis zu dem Zeitpunkt Programmstart + 8000 * 125µs, also Programmstart + 1 Sekunde. Das Beispielprogramm ist bereits so geschrieben, dass es egal ist, welches Intervall Du benutzt, es müsste exakt eine Sekunde warten, falls Du es nicht vorher mittels CTRL+C abbrichst.
Zitat:
Die Klamotten laufen parallel (Systemzeit und Deine WAITUNTIL-Berechnung, die auf der Systemzeit zu einem Zeitpunkt basiert), aber Dein Programm "verbraucht" immer ein paar µs. Wenn Du es nicht regelmäßig "kalibrierst", läuft Dir irgendwann die Systemzeit weg.
Wenn ich zu einem Mitmenschen sage (Dich vielleicht ausgenommen), wir treffen uns um 14:00 Uhr, dann ist es vollkommen unerheblich, ob ich ihm das um 10:00 Uhr, um 11:00 Uhr oder um 12:00 Uhr sage. Und wenn ich um 10:00 Uhr auf die Uhr schaue und dann 4 Stunden dazuaddiere, eine Nachricht schreibe, und der Empfänger diesen Brief aufgrund des Overheads erst um 13:00 liest, dann sind 14:00 immer noch 14:00, die Zeit läuft nicht davon.
Zitat:
Nochmal, WAITUNTIL wartet bis zu einem sehr spezifischen Zeitpunkt im Vergleich zur laufenden Systemzeit. Ist die Systemzeit erreicht, die Du mit Deinem Request vorgegeben hast, gibts das Signal. Bist Du zu langsam bei der Berechnung dieser Vorgabe (was Du immer bist, mal mehr, mal weniger), läuft das nicht lange synchron. Je kürzer das Intervall, je kürzer der Zeitraum, in dem das noch ziemlich synchron läuft.
Also, was Du mir zu sagen versuchst, wenn ich Dir sagen würde, wir treffen uns um 14:00, muss ich Dir das "sehr schnell" sagen, sonst gehst Du erst um 14:30 zum Treffpunkt.

Bzw. die Fernsehsender müssen ständig die Uhr neu kalibrieren, wenn sie zur vollen Stunde Nachrichten senden wollen, weil ihnen sonst die echte Zeit davonläuft. Anzunehmen, dass 10 Uhr plus 10 volle Stunden wieder eine volle Stunde ist, und somit Nachrichten gesendet werden müssten, wäre in diesem Fall wohl zu naiv.

Na ja, wenn das timer.device wirklich so funktioniert wie Deine Logik, dann kann man es wohl getrost in die Tonne treten.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 22:30 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Na ja, wenn das timer.device wirklich so funktioniert wie Deine Logik, dann kann man es wohl getrost in die Tonne treten.


Wenn Du verstehen würdest, wie genau WAITUNTIL funktioniert, dann hättest Du eventuell die selten dämlichen Vergleiche weggelassen.

Lies nochmal das RKM "Devices" und dann versuche zu verstehen, wie genau WAITUNTIL funktionieren könnte. Was Dein Programm gerne hätte und was UNIT_WAITUNTIL liefern kann, sind manchmal einfach zwei verschiedene Dinge (abhängig vom gewählten Intervall).

Das ist ungefähr so, als würden wir uns um 14:00 zum Kaff treffen wollen, ich brauche aber eine Stunde für die Fahrt und Du sagst es mir erst um 13:15.

Eventuell hätte ich es direkt technisch erklären sollen, nicht anhand Deines Programms.

UNIT_WAITUNTIL taugt, genausowenig wie UNIT_MICROHZ (auf der UNIT_WAITUNTIL basiert) nicht zum Messen größerer Zeiträume (dazu zählen bereits Sekunden). Ganz einfach. Steht auch so im RKM.

Wenn Du trotzdem über längere Zeiträume mit Deinem Programm synchron zur Systemzeit bleiben willst, kalibrier es und gleiche es mit der aktuellen Systemzeit ab. Auch ganz einfach. Und steht sogar auch im RKM, wenn auch etwas versteckt.

Nabend.

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 22:31 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
@Holger:
Tu mir einfach den Gefallen und kalibriere das Programm. Nimm die Latenzen raus, hol dir die Systemzeit bei jedem Durchlauf, rechne die Ungenauigkeit des Timers von ca. 2µs da raus und probiers nochmal.


Nein, das werde ich nicht tun. Denn das, um das Du bittest, läuft darauf hinaus, die Latenzen zu ignorieren (man kann den Overhead einer leeren Schleife nicht weiter reduzieren), und statt auf einen konkreten Zeitpunkt einfach 125µs (meinethalben abzügl 2µs) zu warten, ganz egal, wieviel reale Zeit bis dahin vergangen ist.

Dass das Abdriften muss, liegt bereits in der Natur der Sache. Und ist vor allem genau das, wie das Programm funktioniert hat, bevor es auf WAITUNTIL umgeschrieben wurde.

Wenn "warte auf 14:00 Uhr" beim timer.device bedeutet "warte auf irgendeinen Zeitpunkt, den Du Dir selbst ausgedacht hast" bedeutet, dann hat es keinen Sinn mehr, an dem Programm etwas zu ändern. Denn dann ist selbst (oder gerade) ein Poll-Loop sauberer, denn den kann man sauber kalibrieren, ohne noch auf einen zusätzliche, falsch laufende Entität Rücksicht nehmen zu müssen.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 22:40 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
Das ist ungefähr so, als würden wir uns um 14:00 zum Kaff treffen wollen, ich brauche aber eine Stunde für die Fahrt und Du sagst es mir erst um 13:15.

Verdammt noch mal, wir reden über eine leere Schleife, die nichts tut, außer WAIT_UNTIL-Request zu verschicken und ein Zeitintervall von 125µs, bzw. selbst bei >10 ms treten diese Fehler auf. Wieso braucht das timer.device über 10ms, um einen Request sauber zu bearbeiten?
Zitat:
UNIT_WAITUNTIL taugt, genausowenig wie UNIT_MICROHZ (auf der UNIT_WAITUNTIL basiert) nicht zum Messen größerer Zeiträume (dazu zählen bereits Sekunden). Ganz einfach. Steht auch so im RKM.

Das Problem ist, dass wir keine Sekunden warten wollen, sondern 1/8000 Sekunden. Und dass das timer.device bereits da versagt, weil es anscheinend, bleiben wir bei der Darstellung, über 10 ms für "die Fahrt zum Treffpunkt" braucht.

Wen interessiert da noch die Drift, die nach dem langen Zeitraum von 1 s auftritt? Ich habe die Ergebnisse nur erst nach einer Sekunde ausgegeben, um die Last gering zu halten. Ich hätte sie auch sofort ausgeben können.

Die Variante, "wir treffen uns nach 125µs" haben wir bereits zu Beginn ausprobiert.

Wenn das timer.device weder für kleine, noch für große Wartezeiten taugt, dann taugt es offenbar für gar nichts.

Allerdings funktioniert das Beispiel mit Wartezeiten von 1/2 Sekunde bis 1/10 Sekunde. Da spielt die Abweichung aufgrund der "großen Zeiten" keine Rolle.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 22:45 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
@Holger:
Tu mir einfach den Gefallen und kalibriere das Programm. Nimm die Latenzen raus, hol dir die Systemzeit bei jedem Durchlauf, rechne die Ungenauigkeit des Timers von ca. 2µs da raus und probiers nochmal.


Nein, das werde ich nicht tun. Denn das, um das Du bittest, läuft darauf hinaus, die Latenzen zu ignorieren (man kann den Overhead einer leeren Schleife nicht weiter reduzieren), und statt auf einen konkreten Zeitpunkt einfach 125µs (meinethalben abzügl 2µs) zu warten, ganz egal, wieviel reale Zeit bis dahin vergangen ist.

Dass das Abdriften muss, liegt bereits in der Natur der Sache. Und ist vor allem genau das, wie das Programm funktioniert hat, bevor es auf WAITUNTIL umgeschrieben wurde.

Wenn "warte auf 14:00 Uhr" beim timer.device bedeutet "warte auf irgendeinen Zeitpunkt, den Du Dir selbst ausgedacht hast" bedeutet, dann hat es keinen Sinn mehr, an dem Programm etwas zu ändern. Denn dann ist selbst (oder gerade) ein Poll-Loop sauberer, denn den kann man sauber kalibrieren, ohne noch auf einen zusätzliche, falsch laufende Entität Rücksicht nehmen zu müssen.


Nun ja, wenn Du meinst... also laufen alle Programme, die das timer.device mit UNIT_MICROHZ benutzen und kleinere Zeiträume damit abmessen alle falsch. Ist in Ordnung, so notiert und werde ich mir merken.

Was wohl die OS-Entwickler dazu sagen?

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 22:47 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
Wenn Du trotzdem über längere Zeiträume mit Deinem Programm synchron zur Systemzeit bleiben willst, kalibrier es und gleiche es mit der aktuellen Systemzeit ab. Auch ganz einfach. Und steht sogar auch im RKM, wenn auch etwas versteckt.

Ich bin doch nicht blöd. Ich schreibe doch keinen workaround um irgendeinen Mist, der mir keinerlei Nutzen bringt. Du bist gerne dazu eingeladen, diesen "total einfachen" Mist zu schreiben.

Die Aufgabe ist klar definiert, alle 1/8000 Sekunden soll ein Wert vom Parallelport gelesen werden. Das ist kein Overhead. Und nach 1 s soll auch tatsächlich ein Sample mit 8000 Werten (meinetwegen auch 7990 oder 8010, aber keinesfall 80000 oder 800) vorliegen.

Und wenn das Beispiel mit der "Kalibrierung" und dem restlichen Mist dann nur doppelt so kompliziert ist, wie eine direkte Programmierung der CIA-Chips, werden wir es zu Deiner Ehrung als Referenzcode für's timer.device im Netz verbreiten.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 22:50 Uhr

MaikG
Posts: 5172
Nutzer
>Meinst Du den "Überlauf" bei 999999 micro?

Ja, hab das inzwischen so gemacht:

WHILE myseconds%<20
POKEW tr& + IORequestio_Command%, TR_GETSYSTIME&
junk& = DoIO&(tr&)
old&=PEEKL(tr&+tr_time%+tv_micro%)
INCR mycount%:IF mycount%=8000 THEN mycount%=0:INCR myseconds%:move rpS&,20,25:Text rpS&, SADD(TIME$+CHR$(0)),8
REM bla%=goertzel%((PEEKB(&hBFE101) - 127)<<8)

2 POKEW tr& + IORequestio_Command%, TR_GETSYSTIME&
junk& = DoIO&(tr&)
tmp&=PEEKL(tr&+tr_time%+tv_micro%)-old&
IF tmp&<0& THEN
IF tmp&+1000000&<125 THEN GOTO 2
ELSE IF tmp&<125 THEN 2
END IF
WEND

Also Zeit holen, Programm, gucken ob 125 mics vergangen sind, wenn
ja nächste wenn nicht zu 2.
Aber das geht genauso bescheiden wie die andere Methode,
schlecher sogar braucht auf 20 Sekunden 8 Sekunden zu lange(ohne
goertzel)

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 22:50 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
Nun ja, wenn Du meinst... also laufen alle Programme, die das timer.device mit UNIT_MICROHZ benutzen und kleinere Zeiträume damit abmessen alle falsch. Ist in Ordnung, so notiert und werde ich mir merken.

Was wohl die OS-Entwickler dazu sagen?

Wieso fragst Du? Hast Du nicht eben behauptet, dass sie es im RKRM als "richtig" umdefiniert haben?

Oder meinst Du die jetzigen?

Ansonsten ist alles gesagt. Du hast die Einladung, den richtigen code zu posten, also unter der Maßgabe, das die beiden bisherigen Anwendungen/Ansätze falsch waren.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 22:59 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:

Das Problem ist, dass wir keine Sekunden warten wollen, sondern 1/8000 Sekunden. Und dass das timer.device bereits da versagt, weil es anscheinend, bleiben wir bei der Darstellung, über 10 ms für "die Fahrt zum Treffpunkt" braucht.


Nein, das timer.device macht nur 8000 mal einen kleinen Fehler, den Du akkumulierst, wenn auch unwissentlich *seufz*

Zitat:
Wen interessiert da noch die Drift, die nach dem langen Zeitraum von 1 s auftritt? Ich habe die Ergebnisse nur erst nach einer Sekunde ausgegeben, um die Last gering zu halten. Ich hätte sie auch sofort ausgeben können.

Dann wäre Dir auch aufgefallen, daß der Fehler pro Durchlauf gar nicht so groß ist...

Zitat:
Die Variante, "wir treffen uns nach 125µs" haben wir bereits zu Beginn ausprobiert.

Ja, ich weiß. Und ich hab mit Deinem Programm die Variante "Wir treffen uns in 125µs ab jetzt zzgl. 50ms wegen printf()" ausprobiert und sie paßt. Immer. Mit einer maximalen Abweichung von +-2-4µs, je nach Last.

Zitat:
Wenn das timer.device weder für kleine, noch für große Wartezeiten taugt, dann taugt es offenbar für gar nichts.

Sicher. Deswegen wird es auch andauernd verwendet.

Zitat:
Allerdings funktioniert das Beispiel mit Wartezeiten von 1/2 Sekunde bis 1/10 Sekunde. Da spielt die Abweichung aufgrund der "großen Zeiten" keine Rolle.

Spielt sie auch so nicht, wenn Du das timer.device so einsetzt, wie es vorgesehen ist.

Würdest Du das Intervall immer fein auf die tatsächlich vergangene Zeit (inkl. diverser kleiner Abweichungen) abgleichen, gäbs da gar kein Problem.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 23:01 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von MaikG:
Ja, hab das inzwischen so gemacht:
[...]

Also Du wartest überhaupt nicht mehr, sondern pollst, bist die 125µs überschritten wurden, zumindest laut Systemzeit?

Interessanter Ansatz.
Zitat:
Also Zeit holen, Programm, gucken ob 125 mics vergangen sind, wenn
ja nächste wenn nicht zu 2.
Aber das geht genauso bescheiden wie die andere Methode,
schlecher sogar braucht auf 20 Sekunden 8 Sekunden zu lange(ohne
goertzel)

Na ja, dieser Code berücksichtigt nicht den Overhead der Schleife und des zweimaligen Lesens der Systemzeit. Das zweite Lesen der alten Zeit wäre auch überflüssig, Du kannst einfach old&=tmp& schreiben, ich hoffe, Du verstehst, was ich meine, will jetzt nicht noch mehr tippen...

Aber 8 Sekunden auf 20, das klingt doch eigentlich schon ziemlich gut, verglichen mit dem, was ich bei den anderen Ansätzen hatte. Wenn Du dann noch Goertzel reinnimmst (hohe Last soll den timer ja angeblich schneller werden lassen), dann haut's vielleicht hin. Portabel soll's ja eh nicht sein.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 23:05 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Nun ja, wenn Du meinst... also laufen alle Programme, die das timer.device mit UNIT_MICROHZ benutzen und kleinere Zeiträume damit abmessen alle falsch. Ist in Ordnung, so notiert und werde ich mir merken.

Was wohl die OS-Entwickler dazu sagen?

Wieso fragst Du? Hast Du nicht eben behauptet, dass sie es im RKRM als "richtig" umdefiniert haben?

Oder meinst Du die jetzigen?


Beide. Und die vorherigen haben nichts "umdefiniert", sie haben nur geschrieben, daß UNIT_MICROHZ nicht für größere Zeiträume aufgrund der Drift taugt, und daß diese "größeren" Zeiträume kleiner als 1 Sekunde sind. Das gleiche gilt für UNIT_WAITUNTIL.

Und wieso ich frage? Weil das timer.device alle Nasen lang zum Einsatz kommt. bubblebobble verwendet es als Virtual VBlank, in AHI-Treibern kommt es dauernd zum Einsatz, Floppytreiber verwenden es. Und die funktionieren laut Dir ja alle nicht richtig.

Zitat:
Ansonsten ist alles gesagt. Du hast die Einladung, den richtigen code zu posten, also unter der Maßgabe, das die beiden bisherigen Anwendungen/Ansätze falsch waren.

Danke.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 23:06 Uhr

Holger
Posts: 8090
Nutzer
Zitat:
Original von whose:
Ja, ich weiß. Und ich hab mit Deinem Programm die Variante "Wir treffen uns in 125µs ab jetzt zzgl. 50ms wegen printf()" ausprobiert und sie paßt. Immer. Mit einer maximalen Abweichung von +-2-4µs, je nach Last.

Das interessiert mich nicht die Bohne. Auf den Ansatz "ich definiere die Aufgabenstellung so lange um, bis das Programm mit ihr übereinstimmt", kann ich verzichten.

Die Aufgabe ist seit fast 100 Posting klar umrissen, ich habe sie etwas weiter oben noch mal extra für Dich zusammengefasst. 8000 Samples in einer Sekunde. Das war jetzt noch kürzer.

Bring ein Programm, das zeigt, dass man diese Aufgabe mit dem timer.device lösen kann, als Bonus noch auf eine für Menschen verständliche Art und Weise, aber das muss nicht, und dann sind wir alle glücklich.

Oder hör auf zu labern.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

12.09.2006, 23:20 Uhr

whose
Posts: 2156
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von whose:
Ja, ich weiß. Und ich hab mit Deinem Programm die Variante "Wir treffen uns in 125µs ab jetzt zzgl. 50ms wegen printf()" ausprobiert und sie paßt. Immer. Mit einer maximalen Abweichung von +-2-4µs, je nach Last.

Das interessiert mich nicht die Bohne. Auf den Ansatz "ich definiere die Aufgabenstellung so lange um, bis das Programm mit ihr übereinstimmt", kann ich verzichten.

Die Aufgabe ist seit fast 100 Posting klar umrissen, ich habe sie etwas weiter oben noch mal extra für Dich zusammengefasst. 8000 Samples in einer Sekunde. Das war jetzt noch kürzer.

Bring ein Programm, das zeigt, dass man diese Aufgabe mit dem timer.device lösen kann, als Bonus noch auf eine für Menschen verständliche Art und Weise, aber das muss nicht, und dann sind wir alle glücklich.

Oder hör auf zu labern.


Verdammt nochmal, jetzt langts mir aber mit Deinem Großkotz-Gehabe!

Die 125µs sind mir bekannt und ich habe keine Aufgabenstellung umdefiniert, als ich die Tests gemacht habe. Mir ist dabei nur aufgefallen, daß es dabei so gut wie keine Drift gibt, wenn ich das Intervall periodisch gegen die Systemzeit abgleiche. Sogar ohne printf(), nur mit einer "leeren" Schleife!

Ist das jetzt klar??

Und ausgerechnet Du mußt mit "...auf eine für Menschen verständliche Art und Weise" kommen, mit einem Testprogramm, das übelst zusammengehackt ist und vor allem auf Anhieb abstürzt auf einem normalen Amiga, noch dazu mit Deklarationen und Definitionen "wie es uns gefällt", irgendwo mitten im Text.

Mir ist es Latte, ob das von C99 nun zugelassen wird oder nicht, ich finds zum Weinen und gnadenlos unleserlich.

Lies die RKMs, verstehe, was darin steht und dann schreib ein dazu passendes Programm. Oder halt einfach die Finger still, wenn jemand was in die Runde bringt, was Du nicht ausprobiert hast und was Dir einfach nur gegen Deine "innere Überzeugung" geht, aber möglicherweise die Lösung des Ganzen ist.

Manchmal benimmst Du Dich echt zum Kotzen.

Für heute langts mir erst einmal. Ein Programm mit funktionierendem Timing folgt die Tage.

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 12.09.2006 um 23:32 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.09.2006, 01:19 Uhr

whose
Posts: 2156
Nutzer
Ach Gottchen, nun konnte ich, endlich daheim, mal einen Blick ins RKM werfen und es ist alles noch viel Schlimmer:

Lieber Holger, UNIT_WAITUNTIL ist sogar nur mit UNIT_VBLANK vergleichbar, was die Genauigkeit angeht.

Da wundert es nicht, wenn das bei 125µs aus dem Ruder läuft. Allerdings hättest Du als Kenner der Materie das eigentlich wissen müssen :D

Nimm UNIT_WAITECLOCK, dann siehts besser aus.

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

13.09.2006, 09:45 Uhr

MaikG
Posts: 5172
Nutzer
>Also Du wartest überhaupt nicht mehr, sondern pollst, bist die 125µs
>überschritten wurden, zumindest laut Systemzeit?

Ja, das kann man so sagen.

>Interessanter Ansatz.

Geht aber auch nicht.

>Na ja, dieser Code berücksichtigt nicht den Overhead der Schleife
>und des zweimaligen Lesens der Systemzeit.

Nur wie sollte ich das berücksichtigen, wenn ich hier z.B. 120 mics
nehme läuft das auf den 030er doch wieder ganz anders weil er
langsamer ist.

>Das zweite Lesen der alten Zeit wäre auch überflüssig, Du kannst
>einfach old&=tmp& schreiben, ich hoffe, Du verstehst, was ich meine,
>will jetzt nicht noch mehr tippen...

Old wird mehrmals gelesen, weil ich ein neues alt brauche, man
könnte auch eine 2. Variable immer um 125 erhöhen. Vorrausgesetzt
das bleibt dann "genau".


>Aber 8 Sekunden auf 20, das klingt doch eigentlich schon ziemlich
>gut, verglichen mit dem, was ich bei den anderen Ansätzen hatte.
>Wenn Du dann noch Goertzel reinnimmst (hohe Last soll den timer ja
>angeblich schneller werden lassen), dann haut's vielleicht hin.
>Portabel soll's ja eh nicht sein.

Mit goertzel waren es glaube ich in den 30ern.
Es muss Portabel vom 060@50MHZ auf 030@50MHZ sein.

[ - Antworten - Zitieren - Direktlink - ]

13.09.2006, 10:10 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von Holger:
Und dass das timer.device bereits da versagt, weil es anscheinend, bleiben wir bei der Darstellung, über 10 ms für "die Fahrt zum Treffpunkt" braucht.


Dir ist aber schon bewußt, daß Du in Deinem Beispiel DoIO() genommen hast - was die Anfrage an das Device synchron versendet. D.h. nach DoIO geht's erst dann weiter, wenn der Request tatsächlich verarbeitet wurde. Im Gegesatz dazu arbeitet SendIO() asynchron, d.h. es geht sofort weiter, auch wenn das device den Request noch nicht ganz verdaut hat.


--
http://www.norman-interactive.com

[ Dieser Beitrag wurde von Mad_Dog am 13.09.2006 um 10:15 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.09.2006, 11:10 Uhr

whose
Posts: 2156
Nutzer
@Mad_Dog:

Wie oben schon erwähnt, die Diskussion ist brotlos, solange man von falschen Annahmen über das Auflösungsvermögen der gewählten timer.device-Unit ausgeht.

UNIT_WAITUNTIL hat im günstigsten Fall eine Samplerate von 60Hz (VBlank bei NTSC), das bedeutet, daß das Signal frühestens mit dem nächsten VBlank nach Absenden des Requests kommt, was natürlich fast immer viel zu langsam ist bei einem gewünschten Zeitraum von 125µs. Durch Zufall kann das eine oder andere Signal passend kommen, das wars dann aber auch.

UNIT_WAITECLOCK bietet die passende Auflösung, UNIT_MICROHZ auch. Wenn dann noch die Warte-Mechanik des Programms paßt, dann funktioniert das.

Ich muß mir doch mal die DevCD auf den Laptop werfen, glaube ich...

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233

[ - Antworten - Zitieren - Direktlink - ]

13.09.2006, 11:35 Uhr

MaikG
Posts: 5172
Nutzer
Mit der Getsystime methode kommen ich immerhin auf 9sekunden innerhalb
von 20sekunden.
Also habe ich goertzel mal reingenommen und 125 durch 83 ersetzt.
Sind jetzt etwa 19.4sekunden bei 20 sekunden. Genauer geht es
nicht, der DTMF Code gibt mir allerdings nach wie vor nichts
aus. Selbst wenn, beim Ausgeben hätte der Code ja wieder
mehr Zeit verbraucht als sonst und würde wieder abweichen.

Es kann einfach nicht sein das diese Zeitabfrage so lange dauert.

Ich hab ja

Getsystime

Programm

Getsystime
sind 125 sekunden Vergangen?

Bei der Abfrage ist das Programm an sich ja schon durchgelaufen
auch wenns bis zum Wend noch etwas hin ist, das ist Minimal.
Und darauf jetzt die mics von 125 auf 85 zu reduzieren leuchtet
mir nicht ein.
Das Programm ist in der Mitte, also sollten 20 Sekunden immer
20 Sekunden sein und nicht anders.

[ - Antworten - Zitieren - Direktlink - ]


Erste 2 3 4 5 6 -7- 8 9 10 11 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Tonerkennung [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2022 by amiga-news.de - alle Rechte vorbehalten.
.