Ansteuerung RC LED Scheinwerfer
Hallo RN-Gemeinde,
Ich bin neu hier und hoffe darauf, das ich hier ein bisschen Hilfe bei beinen Projekten bekomme.
Erst mal zu meiner Person, ich bin 33 Jahre, gelernter Elektriker und komme aus dem Rhein Neckar Kreis Rund um Heidelberg. Mein grosses Hobby ist der RC -Modellbau.
Ich möchte mich etwas mehr mit den ganzen AVR Mikropozessoren beschäftigen um damit die ein oder andere Funktion an meinen Modellen zu realisieren.
Ein konkretes erstes Projekt gibt es auch schon.
Zu meinem Vorhaben:
Ich habe ein Modell eines Polizeibootes (Robbe W3) gebaut, dies ist auch schon komplett fertig bis auf eine Funktion.
Auf dem Aufbau befindet sich ein Scheinwerfer, welchen ich auch schon mit einer LED (weiss 3V 20mA) bestückt habe. Dieser Scheinwerfer lässt sich über ein Modellbauservo drehen.
Aktuell habe ich aber keinen Schaltkanal mehr frei, um diesen Scheinwerfer einzuschalten. Hier soll nun ein Mikroprozessor ran.
Am liebsten würde ih es gerne mit einem Tiny13 realisieren aber ich befürchte der ist dafür schon fast zu klein.
Ich möchte gerne das Signal des Servos welches den Scheinwerfer dreht auswerten. Sprich Servo bewegt sich dann Scheinwerfer an, Servo steht für eine Zeit x still, Scheinwerfer geht wieder aus.
Am liebsten wäre mir auch, wenn die LED nicht einfach nur an und aus gehen würde sondern per PWM heller und dunkler wird.
Da der Tiny 13 ja nur einen Timer besitzt, denke ich mal ist hier das größte Problem.
Der Timer0 muss sofern das überhaupt gehen 3 Funktionen übernehmen.
- PWM vom Empfänger einlesen und auswerten
- PWM für die LED erzeugen
- Nachlaufzeit für LED nachdem keine Servobewegung mehr erkannt wurde zählen.
Meine konktrete Frage ist nun ist das mit dem Tiny 13 realisierbar ? oder doch eher ein 2313?
und welche Betriebsart für den Timer benutzen ? Verstehe ich das in dem Datenblatt richtig das er zwar nur einen Timer aber zwei unabhängig Compare register hat. Kann man dann das erste register nehmen um den Empfänger auszuwerten und das zweite für die LED PWM ? Und mit einem Überlauf kann ich mir dann ja evtl. die nachlaufzeit zusammen addieren oder?
Danke für eure Meinungen im Voraus.
Gruß
Stephan
Liste der Anhänge anzeigen (Anzahl: 3)
Hallo zusammen,
hab mal ein paar Fotos gemacht. Zum einen Vom Ausgang des Servotesters, dann vom Eingang nach meinem Transistor am Int0 (PinB.1) Am Oszi waren je 2V/div und 2ms/div man sieht das am Servotester nur 3V rauskommen weiß halt nicht ob der Tiny das immer als High interpretiert. Deshalb der Transistor. Auf dem Bild vom Int0 sieht man das der Signalpegel 5 V hat aber logicherweise Invertiert ist. Auf dem letzten bild sieht man den Ausgang auf dem die LED angeklemmt ist, dort allerdings mit 5ms/div
Momentan ist es immer noch so, das ab einer bestimmten Position des Servotesters die LED leuchtet und bei der anderen Seite die LED blinkt wie im Bild zu sehen.
Das ist der aktuelle Programmcode
Do
If Flag = 1 Then Flag = 0
If Signal >= 160 Then Portb.0 = 1 Else Portb.0 = 0
Loop
Zaehlung:
If Pinb.1 = 1 Then
Signal_alt = Timer0
Else
Signal_neu = Timer0
Signal = Signal_neu - Signal_alt
Flag = 1
End If
Return
Bei der Frage ob deriny wirklich mit 4,8 MHz läuft bin ich mir nicht 100% sicher.
Ausgeliefert wird der Tiny 13 angeblich mit 9,6 und Ckdiv8 aktiv
CKSEL1..0 Nominal Frequency
10 = 9.6 MHz
01 = 4,8 MHz
so stehts im Handbuch habe die zwei Bits halt einfach getauscht und den Hacken bei Ckdiv8 entfernt.
Die Fuses sind :
HighFuse: FF
LowFuse: 79
Hoffe mal das stimmt so.
Gruß
Liste der Anhänge anzeigen (Anzahl: 1)
Das ist ein ziemlich typisches Phänomen, was darauf zurückzuführen ist, dass die Anzahl der gemessenen Taktzyklen immer um den Wert 1 hin- und hergeht - und zwar auch dann, wenn der zu messende Impuls exakt auf die Nanosekunde konstant bleibt. Und das liegt letzten Endes daran, dass der Interrupt nicht dann ausgelöst wird, wenn sich der Pegel des zu messenden Signals ändert, sondern genau betrachtet erst mit der ersten steigende Flanke des Controller-Taktes nach dem Pegelwechsel des INT-Eingangs. Ich glaube ich male mal ein Bild und erkläre es damit:
Das Gemälde soll sieben Taktzyklen darstellen sowie einen Impuls, der die Länge von 4,5 Taktzyklen hat. Angenommen der Controller fragt seine Eingangspins immer bei der steigenden Taktflanke ab, wird er beim Impuls A eine Änderung zu Beginn der Taktimpulse 2 und 6 registrieren. Beginnt der gleiche Impuls einen halben Systemtakt später, wird der LH-Übergang zwar immer noch zu Beginn des Taktimpulses 2 erkannt, der HL-Übergang aber erst mit dem Taktimpuls 7 - er ist also scheinbar länger. Das ganze ist also darauf zurückzuführen, dass die Flanken des zu messenden Impulses und des Taktimpulses nicht synchronisiert sind. Bestimmt gibt´s in der Expertensprache auch einen schlagkräftigen Fachbegriff für dieses Phänomen - aber ich kann´s nur so erklären.
Wenn Du einen Controller mit ´ner UART-Schnittstelle hättest, könntest Du Dir nach jedem Servoimpuls die gemessene Länge ausdrucken lassen und würdest sehen, dass sie auch beim stabilsten Impuls immer um 1 variiert. Das macht sich natürlich nicht bemerkbar, wenn die gemessenen Werte weit weg von Deiner Entscheidungsgröße sind. Aber wenn sie genau auf der Grenze liegen, wird der Port halt im schnellen Wechsel ein- und ausgeschaltet.
Abhilfe kann hier eine Art "Software-Hysterese" schaffen: Wenn die gemessene Impulslänge den Grenzwert in eine bestimmte Richtung überschritten hat, wird der Grenzwert einmalig (!) um den Wert 1 oder 2 in die Gegenrichtung verschoben, und auf dem Rückweg wieder zurück. Das lässt sich relativ einfach programmieren :-)
Kleiner Nachtrag: Wenn er zu messende Impuls exakt ein ganzzahliges Vielfaches des Taktimpulses ist, tritt dieses Phänomen natürlich nicht auf - aber dann sind der zu messende Impuls und der Taktimpuls ja auch synchronisiert...
Anhang 31447
