Hallo, ich möchte mit Bascom die dauer eines Tastendrucks festhalten. Es
muß kein genauer Wert sein. Ich möchte eine zweite Funktion auf die
Taste legen, die ich durch längeres drücken aktivieren kann. Folgendes
Programm läuft nicht..........
Hatt jemand einen Tipp ?
Danke !!!
Do
Do
Taste = Getkbd(0)
If Taste <> 16 Then
Zeit = Zeit + 1
Tast = Taste
Loop Until Taste = 16
Select Case Tast
Case 0 To 9 :
If I < 9 Then
Frequenz = Frequenz + Str(tast)
I = I + 1
If Beep = 1 Then Sound Pinb.0 , 60 , 200
End If
End Select
End If
Locate 1 , 1
Lcd Frequenz
Locate 2 , 1
Lcd Zeit ; " "
Waitms 120
Loop
Wenn Du ne Zeit messen willst, brauchst Du erstmal nen Timer, um
definierte Intervalle zu erzeugen.
Idealer Weise nimmt man gleich nen Timerinterrupt (10ms) fürs Entprellen
und Langdruckerkennung zusammen.
In der Codesammlung ist ein Beispiel in C.
Peter
...
nicht nur das. Der Code, so wie er gepostet wurde kann
nicht korrekt eingerückt werden, da da ein Mischmasch
aus dem ersten if und einer do-loop-until Schleife
besteht.
Meiner Ansicht nach sind die so geschrieben
do
if ... then
loop until ...
end if
Paul Baumann wrote:
> Ein dreifach "Hoch" auf Bascom! :-))
Also wenn ich sowas hier sehe:
1
Waitms200
wird mir immer ganz schlecht ob der vergeudeten Performance.
Was hätte man in dieser langen Zeit nicht alles sinnvolles tun können.
Wenn man erstmal mit Monster-Delays anfängt, summieren die sich ganz fix
und dann ist eine Schnecke ein Düsenjet gegenüber Deinem Programm.
Peter
Einmal, wirklich nur einmal möchte ich erleben, daß Du an den
Programmvorschlägen anderer Leute nichts auszusetzen hast. Wenn Du Dir
den Zweck der Übung veranschaulichst, werden die 200ms Wartezeit nur
dann ausgeführt, wenn jemand die Taste drückt. Ansonsten wird sich im
Hauptprogramm "herumgesielt" und dort kann man dann nach Herzenslust mit
Interrupts arbeiten.
Ich habe absichtlich keinen Interrupt "vergeudet", da ich ja nicht
wissen
kann, was der Mr.400Volt in seinem Hauptprogramm noch an Timern
benötigt.
....und ab dafür. :-(
Paul
Abgesehen davon das grössere Projekte schnell die Zielhardware füllen
und der BASCOM-Programmierer so weit von dem Zielprozessor wegsitzt
(woher weiß BASCOM,wann 200ms um sind?Timer?Prescaler?CPU-Takt?Der
C/Assembler-Programmierer muss so etwas erstmal in Erfahrung bringen)
,dass er bei Problemen eventuell Schwierigkeiten bekommt,die Ursachen
der Probleme zu finden,kommt irgendwann der Punkt das die Anwendung
soviel Zeug zu tun hat,das man sich über extra Rechenzeit freut.Und dann
alle Stellen wo ein WaitMS steht so umzustricken,das man vernünftig
weiter arbeiten kann,ist dann eine Qual.
Peter hat lediglich einen Hinweis gegeben,wie es eleganter geht.Will man
die Vorlesung/Prüfung hinter sich bringen,reicht das waitms locker
aus.Möchte man aber irgendwann wirklich mal mit AVR´s arbeiten,sollte
man Hinweise von erfahreneren Leuten doch mal ansehen und nicht nur
kritisieren.
Paul Baumann wrote:
> Einmal, wirklich nur einmal möchte ich erleben, daß Du an den> Programmvorschlägen anderer Leute nichts auszusetzen hast.
Du hast mich erwischt, Delays sind definitv meine schwache Seite, da
werde ich allergisch.
Ich hab damit einfach schon zuviel supergroßen Bockmist erlebt.
Ist quasi wie Sprechen lernen erstmal mit Babysprache.
Wenn man sichs einmal angewöhnt hat, ist es umso schwerer sich das
wieder abzugewöhnen, statt es gleich richtig zu lernen.
Solange es nur eine Task und ein Delay ist, geht ja alles wunderbar.
Aber Programme haben nunmal die Angewohnheit erweitert zu werden und zu
wachsen und dann krachts unweigerlich irgendwann und da hilft auch keine
schnellere CPU (die wartet nur umso mehr).
Und dann kommen solche komische Ideen raus, wie mehrere MCs zu nehmen
und zu vernetzen, was einen ungeheuren Wust an Protokollentwicklung
bedeutet ehe es auch nur einigermaßen zuverlässig funktioniert.
Peter
@ Peter
> Du hast mich erwischt, Delays sind definitv meine schwache Seite, da> werde ich allergisch.
Wer hätte das gedacht ;-)
> Ist quasi wie Sprechen lernen erstmal mit Babysprache.> Wenn man sichs einmal angewöhnt hat, ist es umso schwerer sich das> wieder abzugewöhnen, statt es gleich richtig zu lernen.
Damit hast wohl recht. Allerdings scheut man die steilere Lernkurve, es
dauert etwas länger ehe es verstanden wird und richtig angewendet werden
kann. Jaja, die Jugend von heute, keine Geduld .. . ;-)
> Und dann kommen solche komische Ideen raus, wie mehrere MCs zu nehmen> und zu vernetzen, was einen ungeheuren Wust an Protokollentwicklung> bedeutet ehe es auch nur einigermaßen zuverlässig funktioniert.
Hehe, ich sehe du kennst deine Pappenheimer. Aus pädagogisch
didaktischer Sicht würde ich einen Kompromiss vorschlagen. Für den
ersten Schnellschuss tuts auch ein Delay, mit dem klaren Hinweiss, das
es wesentlich besser geht und das auch gar nicht schwer zu programmieren
ist.
MFG
Falk
Alle Achtung. :-)
Was so ein kleines Stück Programm doch für Reaktionen auslösen kann :-O
Die WAIT-Befehle werden übrigens nicht mit Timern gelöst sondern über
das verschachtelte Herunterzählen von Registern. Ich könnte das auch
mit $ASM mit einer ganzen Menge Assembler dahinter ins Programm
einfügen.
Aber warum, wenn es fertige Befehle dafür gibt. Das Programm an sich
wird dadurch nicht langsamer aber dafür übersichtlicher.
@Peter
Wenn ich nicht muß, verwende ich auch keine Delays. Oben habe ich den
Grund beschrieben, warum ich es hier getan habe. Ohne irgendwie eine
Zeit zu generieren wüßte ich nicht wie ich die Dauer eines Vorgangs
messen
sollte. Timer wollte ich nicht "vertun".
Gruß Paul
