|
DEUTSCHE VERSION |
|
 |
| Links | | | Forums | | | Comments | | | Report news |
|
| Chat | | | Polls | | | Newsticker | | | Archive |
|
| amiga-news.de Forum > Programmierung > Tonerkennung | [ - Search - New posts - Register - Login - ] |
| First 5 6 7 8 9 -10- 11 | [ - Post reply - ] |
|
2006-09-22, 15:06 h whose Posts: 2156 User |
Zitat: Öhm, nicht? Beherrscht MB keine verschachtelten Schleifen?? Ansonsten: BASIC code:WHILE Repeat1% < (intervall% * seconds%) . . . WEND wäre z.B. ein gangbarer Weg. Abgesehen davon: 1.648439 ist eindeutig zu lang. Also scheint der Goertzel in BASIC etwas zu langsam zu sein. Da wäre es evtl. sinnvoller, den Telefon-Sound in einen Puffer zu samplen und dann auszuwerten Grüße -- ---  µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2006-09-22, 15:41 h MaikG Posts: 5172 User |
>Öhm, nicht? Beherrscht MB keine verschachtelten Schleifen?? Doch, aber wenn ich das mache passiert gar nichts mehr. >Abgesehen davon: 1.648439 ist eindeutig zu lang. Also scheint der >Goertzel in BASIC etwas zu langsam zu sein. Nein, nicht langsamer als C. Ohne goertzen ists 1.164063 ergo läuft der Code genausowenig wie die anderen... >Da wäre es evtl. sinnvoller, den Telefon-Sound in einen Puffer >zu samplen und dann auszuwerten Das geht nicht wirklich gut, es soll z.B. ein Zuganscode bearbeitet werden, da ist die erste Ziffer noch nicht fertig wenn ich die letzte eingegeben habe. Ich müsste versuchen das vorauszuwerten, aber das geht nicht, weil wir dann wieder bei störgeräuschen sind. Wind/Autos/Züge/Wasser kann ich nur genauso wie DTMF als Amplitude sehen... > WHILE Repeat1% < (intervall% * seconds%) > WEND Bei seconds%=20 bekomme ich so 4.78125 Sekunden realtime??? [ Dieser Beitrag wurde von MaikG am 22.09.2006 um 15:44 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2006-09-22, 16:23 h whose Posts: 2156 User |
Zitat: Doch, ist er (Einschränkung kommt gleich). Der Code tut nichts anderes, als 125µs zu warten bzw. in dieser Zeit seinen Job zu erledigen. Wenn deutlich mehr als eine Sekunde dabei herauskommt, stimmt entweder die Zeitmessung nicht (die Einschränkung) oder der Code ist zu langsam und Dein Programm rennt der EClock hinterher. Zitat: Da der C-Code hier bis auf die Ungenauigkeiten von GetSysTime() immer brav Zeiträume von 1 Sekunde ausspuckt (sogar inzwischen MIT Goertzel), liegt der Haken vermutlich bei MB. Allerdings weiß ich nicht, wie flott Dein Amiga ist. Aber ein 030er/50MHz sollte das eigentlich eben gerade schaffen... Zitat: Ich sags mal so: Wenn das System ausschließlich für Deinen Gebrauch bestimmt ist, kannst Du Dir ja (wissentlich) beim Eingeben der Ziffern Zeit lassen. Also so: 1. Ziffer, 1 Sekunde warten, 2. Ziffer... Das sollte eigentlich tun. Zitat: Der Goertzel erkennt die Störgeräusche aber normal doch nicht als DTMF-Töne? Zitat: Irgendwie lustig, da ist es auf einmal VIEL schneller... intervall% bezeichnet doch das Warte-Intervall in Hz (Takte/s). Wenn man dann das Intervall (z.B. 8000) mit 20 multipliziert, ergeben sich 160000 Durchläufe der Schleife. Die Schleife wird also erst dann verlassen, wenn repeat% den Wert 160000 erreicht. Ach, warte: % bezeichnet nicht zufällig ein 16Bit-Integer?? Wenn ja, hast Du da wieder ein Überlauf-Problem (-32768 bis 32767). Mach daraus dann mal ein &. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2006-09-22, 17:54 h MaikG Posts: 5172 User |
>Da der C-Code hier bis auf die Ungenauigkeiten von GetSysTime() immer >brav Zeiträume von 1 Sekunde ausspuckt (sogar inzwischen MIT >Goertzel), liegt der Haken vermutlich bei MB. Ich nehme die Timer funktion von MB zur kontrolle, die stimmt mit meiner Armbanduhr überein. >Allerdings weiß ich nicht, wie flott Dein Amiga ist. Aber ein 030er/50MHz >sollte das eigentlich eben gerade schaffen... An dem ich Progge ist ein 060@60MHZ drin, später soll es mal auf 030er/50MHZ laufen. >Ich sags mal so: Wenn das System ausschließlich für Deinen Gebrauch >bestimmt ist, kannst Du Dir ja (wissentlich) beim Eingeben der >Ziffern Zeit lassen. Also so: 1. Ziffer, 1 Sekunde warten, >2. Ziffer... Und woher weiss der Computer das grade die erste Ziffe angekommen ist und nicht nur ein Umweltgeräusch? Das ist ja das Problem mit der Spracherkennung, innen kein Problem aber aussen ist es niemal still. >Der Goertzel erkennt die Störgeräusche aber normal doch nicht als >DTMF-Töne? Nein, Goertzel nicht aber ich kann ja nicht 1 sekunde Samplen 2 sekunden auf Goertzel warten, wieder 1 sekunde Samplen usw. Wenns nicht in Realtime geht müsste ich das vorauswerten. Zitat: > WHILE Repeat1% < (intervall% * seconds%) > WEND Bei seconds%=20 bekomme ich so 4.78125 Sekunden realtime??? >Irgendwie lustig, da ist es auf einmal VIEL schneller... intervall% >bezeichnet doch das Warte-Intervall in Hz (Takte/s). Wenn man dann >das Intervall (z.B. 8000) mit 20 multipliziert, ergeben sich 160000 >Durchläufe der Schleife. Die Schleife wird also erst dann verlassen, wenn repeat% den Wert 160000 erreicht. Aber es kann doch nicht schneller als Echtzeit sein wenn es über einen Timer läuft! >Ach, warte: % bezeichnet nicht zufällig ein 16Bit-Integer?? Wenn >ja, hast Du da wieder ein Überlauf-Problem (-32768 bis 32767). >Mach daraus dann mal ein &. Oh, stimmt Repeat wird ja immer erhöht und muss ja irgendwann 160000 sein. Hängt sich auf wenn man Repeat1& und 20sek nimmt. [ Dieser Beitrag wurde von MaikG am 22.09.2006 um 18:09 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2006-09-22, 18:26 h whose Posts: 2156 User |
Zitat: Das mag durchaus sein. Nichts desto trotz arbeitet der C-Code so, wie gewünscht. Bis auf die Abweichungen, die offensichtlich von GetSysTime() und der von mir etwas ungeschickt angelegten Reihenfolge stammen. Da kommt ziemlich häufig eine Differenz von exakt 1 Sekunde bei heraus (bei relativ beliebiger Frequenz, bis etwas über 12000Hz), die Abweichungen bewegen sich im Rahmen von 60000µs, sehr selten 80000µs, meist 20000µs. Aber keine 600000. Eine so hohe Abweichung wäre für mich ein Zeichen, daß der Code langsamer läuft als der Timer. Bei dem C-Code geht das bei 12500Hz los, bei 13000Hz z.B. bekomme ich eine Abweichung von 120000µs, immer "nach oben". Zitat: Ein 060er sollte das auf jeden Fall hinbekommen. Meiner schaffts problemlos bis 12000 Hz. Zitat: Wenn er DTMF-Töne erkennt, weiß er in dem Moment, wo ein solcher Ton erkannt wurde, daß die erste Ziffer ankam. Wenn nicht, von vorn anfangen. Zitat: Genau dafür wurden die DTMF-Töne doch entwickelt. Sie sind relativ unempfindlich gegen Störgeräusche, was die Auswertung angeht. Zitat: Nein, Du wertest es nachlaufend aus. Erst samplen, dann goertzeln, dann wieder sampeln... Zitat: Was, wenn es bei Dir aus irgendeinem Grund eben nicht synchron mit dem Timer läuft? Leider kenne ich den Grund nicht, kann Dir also momentan nicht sagen, was da schiefgeht. Eventuell findet Holger ja noch etwas. Zitat: Umso schlimmer. Schau doch auch mal nach, wie MB die Datentypen wandelt, wenn das Ergebnis nicht mehr "reinpaßt". Eventuell müßtest Du auch die anderen Variablen, die an dieser Rechnung beteiligt sind, als 32Bit-Integer wählen. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2006-09-22, 23:40 h MaikG Posts: 5172 User |
>Ein 060er sollte das auf jeden Fall hinbekommen. >Meiner schaffts problemlos bis 12000 Hz. Meine ich doch. >Nein, Du wertest es nachlaufend aus. Erst samplen, dann goertzeln, >dann wieder sampeln... Sagen wir 1 Sekunde Samplen, 2 sekunde Samplen 23:35:01 Samplen 23:35:02 Auswerten 23:35:03 Auswerten 23:35:04 Samplen 23:35:05 Auswerten 23:35:06 Auswerten Du siehst jeweils immer 2 sekunden indenen nichts erkannt werden kann. Ich als Mensch habe leider keine Clock leitung so dass ich micht damit Syncronisieren könnte... >Was, wenn es bei Dir aus irgendeinem Grund eben nicht synchron mit >dem Timer läuft? Das Prog besteht wenn ich den Rest ausklammere nur aus der Taktung, selbst diese schaft es nicht bei 8000HZ eine Sekunde zu erreichen. >Umso schlimmer. Schau doch auch mal nach, wie MB die Datentypen >wandelt, wenn das Ergebnis nicht mehr "reinpaßt". Eventuell müßtest >Du auch die anderen Variablen, die an dieser Rechnung beteiligt >sind, als 32Bit-Integer wählen. Ich guck. [ - Answer - Quote - Direct link - ] |
|
2006-09-23, 11:05 h MaikG Posts: 5172 User |
So, ich hab einen Fehler im Programm entdekt, WaitIO& muss hinter den 3 "newlow" berechnungszeilen. Weil so entsteht die abweichung. Jetzt hab ich ohne goertzel 20.07422, auch wenn ich zwischendurch etwas mache z.B. kann ich auch die Zeit ausgeben ohne das dieser Wert abweicht. Also endlich eine Timer Funktion die zu Funktionieren scheint. Schlechte Nachricht: Mit goertel sinds immernoch 26,56641 also 6,56641 sekunden zuviel auf 20 sekunden. code: [ - Answer - Quote - Direct link - ] |
|
2006-09-23, 14:24 h Holger Posts: 8116 User |
Zitat: Das kannst Du natürlich nicht. Aber der Algorithmus, so wie er hier implementiert ist, benötigt nur 92 Samples, um einen Ton zu erkennen (oder keinen Ton zu erkennen). Das sind 11,5 ms. Du kannst also problemlos 11,5ms samplen, dann 18 ms zur Auswertung benötigen, und solange ein DTMF-Ton länger als 30 ms dauert, wird Dir keiner entgehen. Aber, wie schon mehrfach gesagt, erstmal solltest Du ein funktionierendes Programm haben (dem nähern wir uns ja jetzt), und dann können wir uns um die Geschwindigkeit kümmern. Denn bislang haben wir noch nicht wirklich optimiert (was ja auch richtig so ist). Realtime könnte also immer noch möglich sein. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2006-09-23, 15:05 h MaikG Posts: 5172 User |
>Das kannst Du natürlich nicht. Aber der Algorithmus, so wie er hier >implementiert ist, benötigt nur 92 Samples, um einen Ton zu erkennen >(oder keinen Ton zu erkennen). >Das sind 11,5 ms. Du kannst also problemlos 11,5ms samplen, >dann 18 ms zur Auswertung benötigen, und solange ein DTMF-Ton >länger als 30 ms dauert, wird Dir keiner entgehen. Mh, interesant. >Aber, wie schon mehrfach gesagt, erstmal solltest Du ein >funktionierendes Programm haben (dem nähern wir uns ja jetzt), >und dann können wir uns um die Geschwindigkeit kümmern. Denn >bislang haben wir noch nicht wirklich optimiert (was ja auch >richtig so ist). Ich hab doch jetzt ein Programm was ein Timing liefert, auch wenn das Timen doch noch recht lang dauert scheint es zu Funktionieren. Besser währe natürlich ein Timing über den CIA. Also Timing+goertzel=26,6 sekunden, Timing ohne goertzel=20.07422, görtzel incl. 16Bit->8Bit ohne Timing=9.46 Sekunden. Jeweils bei 20 Sekunden echtzeit. [ - Answer - Quote - Direct link - ] |
|
2006-09-23, 23:54 h whose Posts: 2156 User |
Zitat: Also, das "Timen" dauert nicht lang. Es funktioniert in weiten Grenzen sehr gut, das Problem ist bisher nur die Laufzeit der Auswertung. Da kann man noch optimieren, wie Holger schon sagte. Zitat: Hm, bei dem Text kann ich mich des Eindrucks nicht erwehren, daß Du nicht verstanden hast, wozu das Timing eigentlich dient. Es nützt Dir rein gar nichts, wenn Du ungesteuert sampelst. Sicher liest Du dann auch 8000 Werte vom Parallelport, aber die so gelesenen Werte sind nutzlos. Du hast dann keinen Schimmer (bzw. der Algorithmus), welche Frequenz die vorliegende Wellenform besitzt, weil Dir die Zeitbasis fehlt, Du bekommst nur verzerrte Amplituden (manche Werte tauchen doppelt auf, manche gar nicht, völlig ungesteuert halt). Das Timing mit 125µs dient dazu, die Zeitbasis zu erhalten, die Dir eine Frequenzermittlung mittels Goertzel überhaupt erst ermöglicht. Angenommen, Du hast bei einer gesteuerten Sample-Frequenz von 8000Hz alle 2 Sample-Werte einen Wechsel der Amplitude (positiv nach negativ und umgekehrt). Dank der Tatsache, daß Du 8000Hz Samplefrequenz gewählt hast, weißt Du somit, daß die gesamplete Wellenform eine Frequenz von 4000Hz besitzt (ein primitives Beispiel, gebe ich zu). Schlußfolgerung: Wir müssen es hinbekommen, daß Sampling und Auswertung der Sample-Werte im notwendigen Zeitrahmen abgewickelt werden können. Deine Versuche mit und ohne Timing sowie die Erkenntnis, daß das ohne Goertzel zeitmäßig hinhaut, mit Goertzel aber nicht, bringen Dir überhaupt nichts. Der C-Code packt es auf schnellen Maschinen mit Goertzel ziemlich problemlos, also mußt Du Dich evtl. mit Holgers Hilfe (ich kann da, mangels MB, wohl nicht allzu viel helfen) hinsetzen und das Programm optimieren, bis alles im gewählten Zeitrahmen abgearbeitet werden kann und Dein Ziel somit erreicht ist. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2006-09-24, 10:11 h MaikG Posts: 5172 User |
> Zitat: > Also Timing+goertzel=26,6 sekunden, Timing ohne goertzel=20.07422, > görtzel incl. 16Bit->8Bit ohne Timing=9.46 Sekunden. > Jeweils bei 20 Sekunden echtzeit. > >Hm, bei dem Text kann ich mich des Eindrucks nicht erwehren, daß Du nicht verstanden hast, wozu das Timing eigentlich dient. Doch das habe ich zu 100% verstanden. Aber warum benötigt görtzel ohne Timing nur 9.46 Sekunden aber mit Timing 26,6 sekunden? Das heisst alleine das Timing benötigt mindestens 17 sekunden. Jeweils liegt gar kein Einganssignal an also die Einganswerte sind trotz unterschiedlicher Rate die selben. Das goertzel findet ja zwischen den Timing statt und nicht danach... [ - Answer - Quote - Direct link - ] |
|
2006-09-24, 10:30 h Ralf27 Posts: 2779 User |
Zitat: MaxonBasic ist wirklich *bedeutend* langsamer als C. Ich hab damals mal Spaßhalber ein paar kleine Programme von MaxonBasic nach BlitzBasic konvertiert und war erstaunt, wie schnell es mit Blitz geht. Amiblitz läuft ja leider hier nicht auf meinem Amiga, sonst würde ich es gerne auch da testen. Ich will einfach damit tippen das der Geschwindigkeitsunterschied zwischen MaxonBasic und C enorm ist. Deswegen versuch ich auch möglichst viel mit Betriebssystemroutinen und externen Libs zu machen... -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
|
2006-09-24, 15:26 h MaikG Posts: 5172 User |
>MaxonBasic ist wirklich *bedeutend* langsamer als C. In dem Fall ist es jedoch mit C vergleichbar. >Ich hab damals mal Spaßhalber ein paar kleine Programme von >MaxonBasic nach BlitzBasic konvertiert und war erstaunt, wie >schnell es mit Blitz geht. Amiblitz läuft ja leider hier nicht auf >meinem Amiga, sonst würde ich es gerne auch da testen. Tja, BB ist nicht grade Systemkonform... >Ich will einfach damit tippen das der Geschwindigkeitsunterschied >zwischen MaxonBasic und C enorm ist. Achso, ein C Programm hast du also noch nicht direkt mit MB verglichen? Ich hab schon in C und Basic ein und das selbe Programm geschrieben und es gab nur einen minimalen unterschied. >Deswegen versuch ich auch möglichst viel mit Betriebssystemroutinen >und externen Libs zu machen... Das ist immer gut, weil MB wird nicht weiterentwickelt, das Betriebssystem schon. [ - Answer - Quote - Direct link - ] |
|
2006-09-24, 16:29 h Ralf27 Posts: 2779 User |
Zitat:Das kann ich kaum glauben, da ich z.b. beim alten BMP-Readerprojekt versucht habe mit MB z.b. BGR nach RGB zu wandeln und selbst das dauert schon relativ lang, schlimmer noch bei Zoomberechnungen. Gerade das ist verdammt langsam, bzw. sieht man gerade da, das MB nicht gerade schnell ist. Sogar ACE ist bei Integer schneller! Zitat:Man kann in BB vermutlich genau so Systemkonform programmieren wie mit MB oder C. Hat damit nichts zu tun. Zitat:Bei einem anderen Versuch anfang des Jahres habe ich mal ein Mandelbrottprogramm auf meinem Rechner compiliert und zwar extra für einen 060er und das war schon ein riesiger unterschied zu MB, das kann ich dir tippen. Und dabei war das C-Programm nicht mal vom Code her optimiert... Glaub mir, MBasic ist wirklich nicht schnell. Zitat: Noch ein Grund ist halt auch, das das Programm auch bei OttoNormal-User schneller werden kann, wenn das Betriebssystem entweder durch Patchs oder neuere Versionen besser wird. -- http://www.alternativercomputerclub.de.vu [ - Answer - Quote - Direct link - ] |
|
2006-09-24, 21:42 h whose Posts: 2156 User |
Zitat: Eben. Rechne doch mal nach. [über den Daumen peil] 55µs benötigt der Goertzel bei Dir (9.46 / 8000 / 20) [/über den Daumen peil]. Das bedeutet, für WaitIO() (inkl. Message-Handling) und die Neuberechnung der EclockVal bleiben 70µs (da sind die Sprünge sowie SendIO() noch nicht drin). Das langt locker. Das sieht für mich eher so aus, als würde die Zeitmessung via MB-Funktion nicht ganz hasenrein laufen, vermutlich ähnlich wie mit GetSysTime(), nur noch ungenauer, je nach Last. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ Dieser Beitrag wurde von whose am 24.09.2006 um 21:50 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2006-09-24, 22:16 h MaikG Posts: 5172 User |
>Eben. Rechne doch mal nach. >[über den Daumen peil] >55µs benötigt der Goertzel bei Dir (9.46 / 8000 / 20) >[/über den Daumen peil]. >Das bedeutet, für WaitIO() (inkl. Message-Handling) und die >Neuberechnung der EclockVal bleiben 70µs (da sind die Sprünge >sowie SendIO() noch nicht drin). Das langt locker. Anscheinend aber nicht. >Das sieht für mich eher so aus, als würde die Zeitmessung via >MB-Funktion nicht ganz hasenrein laufen, vermutlich ähnlich wie >mit GetSysTime(), nur noch ungenauer, je nach Last. Nein das ist nicht so, einmal merke ich den Unterschied von 20 auf 27 sekunden und ausserdem habe ich ebend nochmal mit der Stoppuhr geguckt, die MB Zeit stimmt mit der auf der Stoppuhr überein. [ - Answer - Quote - Direct link - ] |
|
2006-09-24, 23:55 h whose Posts: 2156 User |
Zitat: Also, wenn das nicht reicht, stimmt die Zeitangabe für den Goertzel-Lauf nicht. Definitiv. Der Goertzel ist zwar nicht besonders aufwändig, benötigt aber sicherlich etwas mehr Zeit als die Kombination WaitPort()/GetMsg()/EClockVal-Berechnung und SendIO(). Selbst, wenn das nicht der Fall sein sollte, ist wohl noch ausreichend Reserve für diese Folge vorhanden. Im C-Code haut das auch einwandfrei hin, MIT Goertzel. Auf einem 060er. Bis 12000Hz. Zitat: Wir können jetzt noch eine halbe Ewigkeit weiter raten. Der C-Code funktioniert. Er ist ausreichend schnell, liefert Zeitwerte, die sich von Deinen dahingehend unterscheiden, daß sie immer rund um eine Sekunde ergeben (ziemlich oft sogar exakt eine Sekunde, mit maximalen Abweichungen von 80000µs/Durchlauf statt 600000), der selbiges 20 mal problemlos wiederholt (und das sicherlich auch bei 1000 Wiederholungen problemlos erledigt) und wahlweise auch den Goertzel-Algorithmus beinhalten darf, ohne daß sich am Verhalten etwas groß verändert (nur die maximal erreichbare Frequenz sinkt etwas ab). Frage: Welcher Code liefert ein anderes als das gewünschte Ergebnis? Offensichtlich der BASIC-Code. Also müssen wir jetzt schauen, woran es bei Deinem Code genau hapert. Da die Benutzung des timer.device (soweit ich das überblicken kann) identisch mit der C-Variante ist, klemmt es wohl an einem anderen Punkt des Programms. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2006-09-25, 09:57 h MaikG Posts: 5172 User |
>Also, wenn das nicht reicht, stimmt die Zeitangabe für den >Goertzel-Lauf nicht. Definitiv. Definitiv funktioniert meine Stoppuhr korrekt!!! Die hat nix mit Basic oder Computern zu tun. >Der Goertzel ist zwar nicht besonders aufwändig, benötigt aber >sicherlich etwas mehr Zeit als die Kombination WaitPort()/GetMsg()/EClockVal-Berechnung >und SendIO(). Tja so sollte es sein, aber wenn ich ebend diese sachen ausklammere rennt das Programm. >Im C-Code haut das auch einwandfrei hin, MIT Goertzel. Auf einem >060er. Bis 12000Hz. Alternativ könnte man ein C Programm in betracht ziehen, so das das Basic Programm irgendwie mit dem C Programm kommuniziert oder auch als Maschienencode in Basic einbinden. Mich wurmt das aber das bei dem MB Prog was nicht stimmt. >Der C-Code funktioniert. Ist der wirklich Identisch mit dem Basic code? Da wurden einige änderungen vorgenommen z.B. wo ReadEclock abgestürzt ist. >Offensichtlich der BASIC-Code. Also müssen wir jetzt schauen, >woran es bei Deinem Code genau hapert. Ja. >Da die Benutzung des timer.device (soweit ich das überblicken kann) >identisch mit der C-Variante ist, klemmt es wohl an einem anderen >Punkt des Programms. Das glaub ich nicht. Es kann sein das es bei der C->Basic umwandlung zu fehlern gekommen ist aber wenn dann irgendwo im Time Code. Holger hat den goertzel teil auch schon in Basic mit einer Datei gemacht und das Funktioniert und entspricht der C geschwindigkeit. [ - Answer - Quote - Direct link - ] |
|
2006-09-25, 13:46 h Holger Posts: 8116 User |
Zitat: Daran hatte ich auch schon am Anfang gedacht. Man könnte z.B. aus dem C Programm ein Commodity machen, das aus erkannten Tastendrücken künstliche Tastatureingaben macht. Dann funktioniert es mit jedem beliebigen Programm. Andererseits finde ich es eben genauso interessant, das Basic-Programm zu vollenden, jetzt, wo es schon so weit gediehen ist. Das ist eben die Sache mit dem Hobby... Mal ne andere Frage. Was für Optionen zur Ziel CPU/FPU besitzt die Vollversion von MaxonBasic eigentlich? Die Demoversion besitzt da irgendwie gar nichts. Und kannst Du mir mal sowohl Quellcode, als auch ne mit Deinen Optionen übersetzte Version des Programms schicken, damit ich die testweise in nen Debugger stecken kann? (Die NoLines Option vor dem Übersetzen natürlich ausschalten) mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2006-09-25, 18:00 h MaikG Posts: 5172 User |
>Mal ne andere Frage. Was für Optionen zur Ziel CPU/FPU besitzt die >Vollversion von MaxonBasic eigentlich? Keine... Aber erzeugte Programme lauffähig auf allen Prozessoren(68000-68040), steht auf diesem Hefter dingels. Abgesehen von einschränkungen von Peek bei 000 auf ungraden adressen. >Und kannst Du mir mal sowohl Quellcode, als auch ne mit Deinen >Optionen übersetzte Version des Programms schicken, >damit ich die testweise in nen Debugger stecken kann? >(Die NoLines Option vor dem Übersetzen natürlich ausschalten) Klar, aber ich hab deine Email adresse nicht... Aber nicht mit diesem mitgelieferten Debugger, der crash auf 060. [ - Answer - Quote - Direct link - ] |
|
2006-09-25, 20:59 h whose Posts: 2156 User |
Zitat: Das habe ich ja auch nicht angezweifelt. Andererseits wäre es natürlich denkbar, daß Dir bei dem Goertzel-only-Programm was daneben gelaufen ist... Zitat: Und eben das kommt mir etwas seltsam vor. Das Timing ist lange nicht so aufwändig, wie es vielleicht auf einen nicht daran gewöhnten BASIC-Programmierer wirkt. Zitat: Das sehe ich ähnlich. Falls es ums Verrecken nicht mit BASIC hinzubekommen sein sollte, kann man immer noch z.B. einen externen Task, der die Erkennung der DTMF-Töne erledigt, in C vorsehen. Eventuell findet Holger ja etwas heraus, wenn er Dein Executable durch den Debugger scheucht. Zitat: Diese "Änderungen" haben wir im C-Code ja auch drin. Da gings darum, auf die Library-Funktionen des timer.device zuzugreifen. Da mußten wir genauso eine Library-Base anlegen und mit einem Wert füllen, wie Du es dann (mit Holgers Hilfe) in BASIC gemacht hast. Ich glaube nicht, daß ausgerechnet dieses Vorgehen was mit dem Zeitproblem zu tun hat. Im Gegenteil, dieses Vorgehen ist zwingend notwendig. Hast Du ja an den Abstürzen merken können. Zitat: Vergleiche die beiden mal. Die eigentliche Benutzung des timer.device gleicht Punkt für Punkt der C-Variante. Es ist ja auch wirklich nichts Wildes oder Magisches. Werte berechnen, in die timerequest-Struktur eintragen, TR_ADDREQUEST dazu, mittels SendIO() ans timer.device senden, warten. Das wars schon. Das Gleiche macht Dein BASIC-Programm ja auch. Der einzige mögliche Fehler, der sich dabei noch aufdrängen könnte, wäre einer in den OS-Includes von MB. Wäre aber sehr seltsam, wenn es so wäre. Also, die Zeilen, die wirklich nur mit dem timer.device zu tun haben, sind nahezu identisch in BASIC und in C. Möglich wäre noch ein Problem im "Drumherum" um die Mimik für das timer.device. Mich macht es halt nervös, daß die Sache in C problemlos läuft, aber ein beinahe identisches Programm in BASIC nicht. Zitat: Hattest DU den dann auch mal getestet? Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2006-09-25, 22:49 h MaikG Posts: 5172 User |
>Das habe ich ja auch nicht angezweifelt. Andererseits wäre es >natürlich denkbar, daß Dir bei dem Goertzel-only-Programm was >daneben gelaufen ist... Bei MB kann man befehle komplett eleminieren indem man REM davorsetzt. Genau das hab ich mit den Timing Funktionen gemacht. Es gibt also kein Goertzel-only-Programm. Eventuell findet Holger ja etwas heraus, wenn er Dein Executable durch den Debugger scheucht. >Ich glaube nicht, daß ausgerechnet dieses Vorgehen was mit dem Zeitproblem zu >tun hat. Im Gegenteil, dieses Vorgehen ist zwingend notwendig. >Hast Du ja an den Abstürzen merken können. Da war noch so ein Extra While Wend das rausgenommen wurde. >Hattest DU den dann auch mal getestet? Nein, ich hab mein C-Compiler auf PPC eingestellt und weiss überhaupt nicht mehr wie also kann ich das nicht rückgängig machen (den 603e hab ich wegen fehlfunktion von der BPPC gelötet und bis heute kein Ersatzprozi in QCF gefunden) [ - Answer - Quote - Direct link - ] |
|
2006-09-26, 13:11 h Holger Posts: 8116 User |
Zitat:Das heißt, es gibt keine FPU-Unterstützung. Das macht einen gewaltigen Unterschied beim Vergleich mit dem C-Programm. Denn da braucht man nur eine compiler-option, um deutlich höhere Geschwindigkeiten zu erzeugen. Dein Zielsystem war allerdings 68030, wenn ich mich richtig erinnere. Mit FPU oder ohne? Zitat:Schick mir ne mail über's Forum... Dann bekomms Du meine Adresse mit der Antwort. Der Debugger von HiSoft ist der gleiche wie beim DevPac-Assembler. Davon habe ich verschiedene Versionen und auch ein bisschen Erfahrung mit gemacht (muss mich nur wieder erinnern)... Das geht schon. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2006-09-26, 18:12 h MaikG Posts: 5172 User |
>Das heißt, es gibt keine FPU-Unterstützung. Das macht einen >gewaltigen Unterschied beim Vergleich mit dem C-Programm. >Denn da braucht man nur eine compiler-option, um deutlich >höhere Geschwindigkeiten zu erzeugen. Ich möchte sagen die FPU wird durch die Math librarys unterstützt. Aber wie schon gesagt goertzel währe zumindest auf 060 noch nicht das Problem. >Dein Zielsystem war allerdings 68030, wenn ich mich richtig >erinnere. Mit FPU oder ohne? Zufällig mit... >Schick mir ne mail über's Forum... Dann bekomms Du meine Adresse mit >der Antwort. Okay, hab ich gemacht. [ - Answer - Quote - Direct link - ] |
|
2006-09-27, 21:09 h Holger Posts: 8116 User |
Zitat:Also für simple Operationen wie Addition und Multiplikation extra Library-Funktionen aufzurufen, ist keine wirkliche Unterstützung. Außerdem benutzen diese Bibliotheken nur dann ne FPU, wenn es sich um entsprechende Versionen handelt. Aber wenn man sich so anguckt, was in den Binaries alles so enthalten ist, scheinbar der ganze Basic-Compiler und dann noch irgendein Floating-Point Code von Motorola von 1981, da kommt man schon in's grübeln. Das einzige, was nicht enthalten ist, sind die Debugging-Informationen. Kannst Du noch mal die Compiler-Optionen überprüfen? mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2006-09-27, 23:31 h MaikG Posts: 5172 User |
>Aber wenn man sich so anguckt, was in den Binaries alles so >enthalten ist, scheinbar der ganze Basic-Compiler und dann noch >irgendein Floating-Point Code von Motorola von 1981, da kommt man >schon in's grübeln. Ja, aber goertzel machts in 9,x sekunden ohne Timing. Also wie schlecht der code auch immer sei auf 060 wäre das ausreichend. >Das einzige, was nicht enthalten ist, sind die Debugging-Informationen. >Kannst Du noch mal die Compiler-Optionen überprüfen? In der DTMF1.debug ist nichts drin? Die hat doch 5kB mehr als die DTMF1 und muss ja demnach sowas enthalten... [ - Answer - Quote - Direct link - ] |
|
2006-09-28, 12:55 h Holger Posts: 8116 User |
Zitat:Symbole sind drin, aber keine Line-Debug Informationen. Aber in der neuen Datei sind sie drin, soweit ich das auf den ersten Blick erkennen kann. Werd sie heut abend mal in den Debugger stecken. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2006-09-29, 09:50 h MaikG Posts: 5172 User |
>Symbole sind drin, aber keine Line-Debug Informationen. Aber >in der neuen Datei sind sie drin, soweit ich das auf den ersten >Blick erkennen kann. Ja, wie gesagt manche Einstellungen aus dem Programm werden nicht immer an den Compiler weitergegeben. Deswegen schreibe ich die Optionen meinstens Inline, aber die Option für Debug kannte ich noch nicht. >Werd sie heut abend mal in den Debugger stecken. Da bin ich mal gespannt was dabei rausgekommen ist... [ - Answer - Quote - Direct link - ] |
|
2006-09-30, 22:24 h MaikG Posts: 5172 User |
Holger? [ - Answer - Quote - Direct link - ] |
|
2006-10-02, 00:24 h Holger Posts: 8116 User |
Bisherige Erkenntnis ist nur, dass das von MaxonBasic erzeugte Programm der grauenhafteste code ist, der mir seit langem (bzw. überhaupt?) untergekommen ist. Debuggen ist schwierig, weil selbst der debugger aus dem gleichen Haus seine Probleme mit dem code hat. Ganz abgesehen von der MaxonBasic-Eigenart, falsche Zeilennummern zu erzeugen. Was für Fehlermeldungen gilt, gilt halt auch für die Line-Debug Informationen. Da ist der Compiler konsequent. Und es ist eigentlich ein Wunder, dass überhaupt eine benutzbare Geschwindigkeit herauskommt. Aber das timing-Problem erklärt es leider trotzdem nicht. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
| First 5 6 7 8 9 -10- 11 | [ - Post reply - ] |
| amiga-news.de Forum > Programmierung > Tonerkennung | [ - Search - New posts - Register - Login - ] |
|
|
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |
|