Hallo, ich suche , da ich noch sehr frisch bin , einen Lösungsansatz für
folgendes Problem:
Allgein will ich eine LED mit einer Fernsteuerung bedienen.
Taste 1 schnell blinken
Taste 2 nicht so schnell blinken
Außerdem will ich das wenn das LED im Modus 1 ist und man 2 drückt der
Modus wechselt .
Das geht bisher mit dem Programm auch :
1
$regfile = "attiny13.dat"
2
$crystal = 1200000
3
$hwstack = 20
4
$swstack = 10
5
$framesize = 22
6
Dim Address As Byte
7
Dim Command As Byte
8
Dim A As Byte
9
Config Portb.2 = Output
10
Config Portb.4 = Input
11
Portb.4 = 1
12
Led Alias Portb.2
13
14
Config Rc5 = Pinb.4 , Timer = 0 , Wait = 2000
15
Enable Interrupts
16
Do
17
Anfang:
18
Led = 0
19
Getrc5(address , Command)
20
If Address < 255 Then
21
Command = Command And &B01111111
22
23
Select Case Command
24
Case 1 :
25
For A = 1 To 255 Step 1
26
A = 1
27
Toggle Led
28
Waitms 1000
29
Getrc5(address , Command)
30
If Address < 255 Then
31
Command = Command And &B01111111
32
Exit For
33
End If
34
Next A
35
36
37
38
Case 2 :
39
Do
40
41
42
Toggle Led
43
Waitms 10
44
Getrc5(address , Command)
45
Loop Until Address < 255
46
47
48
49
End Select
50
51
52
End If
53
54
55
Loop
56
57
End
das Problem ist nun dass ich Config Rc5 = Pinb.4 , Timer = 0 , Wait =
2000 benutzen muss um jedes Signal zuverlässig zu empfangen .
Ich möchte die LED aber auch ganz schnell blinken lassen was aber nicht
geht das das wait 2000 131ms sind .
Er fragt da ja immer ab damit man den Modus wechseln kann.
gibt es da einen weg?
PS : ich hab den empfänger leider nicht an einem interrupt.
pascal schrieb:> Ich möchte die LED aber auch ganz schnell blinken lassen was aber nicht> geht das das wait 2000 131ms sind .
???
Mit deinem "Waitms 1000" blockierst du deinen Programmablauf für eine
ganze Sekunde.
Warum machst du das?
Na ja.
Der ganze Ansatz ist schon zweifelhaft.
Die 2000 bei der RC5 Konfiguration wird wohl das Timeout sein, wie lange
der RC5 Code wartet, ehe er auf 'nichts' empfangen geht und zurückkehrt.
D.h. diese Zeit muss runter.
Das andere ist die ganze Blinkerei.
Mit diesem Blinken durch lange Wartezeiten wirst du nicht glücklich
werden. Das musst du umstellen. Was du brauchst ist eine Art Status, der
über die Hauptschleife hineg Gültigkeit hat.
Ungefähr so
1
do
2
3
frage rc5 ab
4
5
wenn Kommando empfangen dann
6
wenn Kommando gleich kurze Blinkzeit dann
7
SollBlinkzeit = 200
8
9
wenn Kommando gleich lange Blinkzeit
10
SollBlinkzeit = 1000
11
endif
12
13
IstBlinkzeit = IstBlinkzeit + 1
14
wenn IstBlinkzeit grösser SollBlinkzeit dann
15
IstBlinkZeit = 0
16
schalte LED um
17
endif
18
19
waitms 1
20
21
loop
Ziel der Sache ist es, die ganzen langen Wait auf Vielfache von kurzen
Wait zurückzuführen. Ein Durchlauf durch die Haupt do-loop wird hier
künstlich auf zirka 1 Millisekunde getrimmt. Dazu darf natürlich der RC5
Code nicht allzu lang umtun, sondern muss sofort, wenn feststeht, dass
keine Übertragung da ist zurückkommen. Ist ja so gesehen auch kein
Problem, denn 1 Millisekunde später, beim nächsten Durchlauf wird der
RC5 Code ja sowieso wieder aufgerufen.
Gewartet wird auf nichts und niemanden, ausser vielleicht ganz kurz
(hier 1 Millisekunde) und das auch nur, weil du keinen Timer mehr frei
hast. Und in dem Fall geht es dann eben nach dem Muster: wenn man 1000
mal 1 Millisekunde wartet, hat man in Summe auch 1000 Millisekunden
gewartet. Der Unterschied ist aber, dass ich im zweiten Fall nur alle
1000 Millisekunden alle Eingänge bzw. Datenzulieferer abfragen kann, ob
sie etwas zur Bearbeitung haben, während im zweiten Fall jede 1
Millisekunde das ganze Abscannen der Zulieferer erfolgt um darauf zu
reagieren. Eine Verzögerung von 1000 Millisekunden ist für einen
Menschen merkbar. Eine Verzögerung von 1 Millisekunde aber nicht.
pascal schrieb:> außerdem hab ich ja keinen timer mehr frei
Dann solltest du da vielleicht ansetzen und prüfen, ob sich daran etwas
ändern läßt. Mit was für hochwichtigen Dingen hast du die denn
beschäftigt, dass einer davon nicht auch als Zeitbasis dienen kann?
Karl Heinz schrieb:> Na ja.> Der ganze Ansatz ist schon zweifelhaft.>> Die 2000 bei der RC5 Konfiguration wird wohl das Timeout sein, wie lange> der RC5 Code wartet, ehe er auf 'nichts' empfangen geht und zurückkehrt.> D.h. diese Zeit muss runter.
Wenn du allerdings die 2000 nicht weiter reduzieren kannst, weil der
Empfang dann nicht mehr funktioniert, tja, dann hast du wohl mit
Zitronen gehandelt.
>> außerdem hab ich ja keinen timer mehr freiMike schrieb:> Dann solltest du da vielleicht ansetzen und prüfen, ob sich daran etwas> ändern läßt.
Nein, daran läßt sich nichts ändern, da die RC5-Routine den Timer nutzt.
>Mit was für hochwichtigen Dingen hast du die denn> beschäftigt, dass einer davon nicht auch als Zeitbasis dienen kann?
Beschäftige Du Dich mal mit dem Datenblatt des Tiny13, dann siehst Du
daß
es nur EINEN Timer gibt!
SCNR
Karl Heinz schrieb:>> Gewartet wird auf nichts und niemanden, ausser vielleicht ganz kurz> (hier 1 Millisekunde) und das auch nur, weil du keinen Timer mehr frei> hast. Und in dem Fall geht es dann eben nach dem Muster: wenn man 1000> mal 1 Millisekunde wartet, hat man in Summe auch 1000 Millisekunden> gewartet. Der Unterschied ist aber, dass ich im zweiten Fall nur alle> 1000 Millisekunden alle Eingänge bzw. Datenzulieferer abfragen kann, ob> sie etwas zur Bearbeitung haben, während im zweiten Fall jede 1> Millisekunde das ganze Abscannen der Zulieferer erfolgt um darauf zu> reagieren. Eine Verzögerung von 1000 Millisekunden ist für einen> Menschen merkbar. Eine Verzögerung von 1 Millisekunde aber nicht.
soweit verstanden, wenn ich aber diesen Timeout oder was auch immer
runterschraube reagiert das programm nicht auf jede taste zuverlässig.
Karl Heinz schrieb:> Karl Heinz schrieb:>> Na ja.>> Der ganze Ansatz ist schon zweifelhaft.>>>> Die 2000 bei der RC5 Konfiguration wird wohl das Timeout sein, wie lange>> der RC5 Code wartet, ehe er auf 'nichts' empfangen geht und zurückkehrt.>> D.h. diese Zeit muss runter.>> Wenn du allerdings die 2000 nicht weiter reduzieren kannst, weil der> Empfang dann nicht mehr funktioniert, tja, dann hast du wohl mit> Zitronen gehandelt.
das heißt murks, wegwerfen? :D
pascal schrieb:> Karl Heinz schrieb:>> Karl Heinz schrieb:>>> Na ja.>>> Der ganze Ansatz ist schon zweifelhaft.>>>>>> Die 2000 bei der RC5 Konfiguration wird wohl das Timeout sein, wie lange>>> der RC5 Code wartet, ehe er auf 'nichts' empfangen geht und zurückkehrt.>>> D.h. diese Zeit muss runter.>>>> Wenn du allerdings die 2000 nicht weiter reduzieren kannst, weil der>> Empfang dann nicht mehr funktioniert, tja, dann hast du wohl mit>> Zitronen gehandelt.>> das heißt murks, wegwerfen? :D
Sieht wohl so aus.
Die Online-Hilfe spricht ja davon, dass man die Zeit bis auf ca. 6.5ms
runterschrauben könnte. Aber die Hilfe ist da etwas eigenartig
formuliert. Wenns nicht funktioniert, dann funktioniert das eben nicht.
Jetzt stehst du natürlich im Regen. So schön es auch in BASCOM ist, wenn
man vorgefertigte Module verwenden kann und sich um nichts kümmern muss
bzw. verstehen muss, so sehr steht man dann auch im Regen, wenn es nicht
funktioniert und man sich selbst helfen müsste und nicht kann.
Karl Heinz schrieb:>> Jetzt stehst du natürlich im Regen. So schön es auch in BASCOM ist, wenn> man vorgefertigte Module verwenden kann und sich um nichts kümmern muss> bzw. verstehen muss, so sehr steht man dann auch im Regen, wenn es nicht> funktioniert und man sich selbst helfen müsste und nicht kann.
naja , ich kann mir schon helfen, ich nehme dann einfach ein atmega mit
2 timer . dachte halt nur ich frag mal nach ob ihr ne idee hättet...
Ich vermute mal, die vorgefertigte RC5-Empfangsroutine arbeitet
blockierend.
Das ist natürlich äußerst praxisfern.
Du mußt daher die Routine auf interruptbasiert umschreiben.
Es ist dann auch kein Hexenwerk, den Timer durchlaufen zu lassen und ihn
für RC-5 und Blinken zu verwenden.
