Ansteuerung RC LED Scheinwerfer

[Sauerbruch]

Ohne den zweiten Timer könnte man Servopuls-Dekodierung und PWM mit einer etwas trickigen ISR lösen - vermute ich mal.

Sooo tricky ist das gar nicht - Timer einfach durchlaufen lassen, bei Impulsbeginn (steigende Flanke) Wert ablesen, bei Impulsende (fallende Flanke) nochmal Zählerstand ablesen, beide Stände voneinander subtrahieren - fertig! Und der durchlaufende Timer kann dann im Fast-PWM-Modus das PWM-Signal erzeugen.

[StephanHD]

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ß

[oberallgeier]

.. am Servotester nur 3V rauskommen weiß halt nicht ob der Tiny das immer als High interpretiert. Deshalb der Transistor ..

Solche Fragen lassen sich anhand des Datenblattes bestens und relativ sicher beantworten. In meinem Datenblatt zum tiny13, 8126F–AVR–05/12, steht auf Seite 117 ne Tabelle 18.2 DC Characteristics, in der u.A. diese Werte genannt werden:

....
                         Min           Max
Input High Voltage,
Any Pin as I/O
VCC = 1.8 - 2.4V        0.7VCC      VCC + 0.5 V
VCC = 2.4 - 5.5V        0.6VCC      VCC + 0.5 V
....
“Min” means the lowest value where the pin is guaranteed to be read as high.

SEHR empfehlenswerter Lesestoff.

[Sauerbruch]

Das ist ja putzig - das Eingangssignal ist ja vollkommen okay, aber woher kommt dieses Ausgangssignal, dessen Periodendauer ja noch nichtmal ein Vielfaches der Eingangs-Periodendauer ist...?
Die Fuses scheinen auch richtig zu sein; einen extrem nützlichen Fuse-Calculator gibt´s übrigens hier: http://www.engbedded.com/fusecalc/ (eines meiner meistgenutzten Lesezeichen!). Der gibt für Deine Einstellungen (4,8 MHz, CKDIV8 deaktiviert) genau FF und 79 an.
Im Zweifelsfall kann man einen ganz einfachen Test machen, ob die bei $crystal angegebene Taktfrequenz tatsächlich stimmt:

Do
Toggle PORTx.y
waitms 500
Loop

An PORTx.y schließt man ´ne LED an, und wenn $crystal und die tatsächliche Taktfrequenz übereinstimmen, blinkt sie im 1Hz-Takt.

Aber jetzt müssen wir Dein Problem glaube ich ein wenig einkreisen. Ich würde als erstes überprüfen, ob das Eingangssignal auch tatsächlich dazu führt, dass die ISR ausgeführt wird. Am einfachsten ginge das so:

Zaehlung:
PORTB.0 = PINB.1
Return

Wenn die ISR korrekt angesprungen wird, liegt am PORTB.0 genau Dein Eingangssignal an - das würde das Problem schon einkreisen... probier das doch mal aus und berichte!

[Unregistriert]

If Flag = 1 Then Flag = 0
If Signal >= 160 Then Portb.0 = 1 Else Portb.0 = 0

Was soll hier passieren? Änderung von PORTB.0 nur wenn Flag = 1 ist?

Dann muß es so sein:

If Flag = 1 Then
  Flag = 0
  If Signal >= 160 Then Portb.0 = 1 Else Portb.0 = 0
end if

Lesbarer und angenehmer für die Hilfeleistenden ist es, wenn du Code tags zum Einschließen des Codes nutzt.
[ CODE] zu Beginn und [ /CODE] zum Ende des Codes ohne die Leerzeichen nach der führenden eckigen Klammer.

[StephanHD]

Hi,

Also folgendes hab ich ausprobiert :

Do
Toggle PORTb.0
waitms 500
Loop

Die Led blinkt im Sekundentakt so wie se soll. Also sollte die Taktfrequenz ja mal stimmen, hätte mich auch gewundert, da ich mit den Vergleichswerten für die "Signal" Variable ja in dem Bereich liege den wir ganz am Anfang mal besprochen hatten.

Zaehlung:
PORTB.0 = PINB.1
Return

Hab ich auch ausprobiert mit dem Oszi gemessen, ist das Ausgangssignal genau gleich dem Eingangssignal an PinB.1

[Sauerbruch]

Manchmal sieht man den Wald vor lauter Bäumen nicht:
Du hast in der ISR nicht berücksichtigt, dass der Transistor das Signal invertiert! So wie die ISR jetzt ist, misst sie die Dauer des High-Impulses, und der ist mit seinen ca. 12ms so lang, dass der Timer mehrfach überläuft. Da kann also nix gutes bei rauskommen

[StephanHD]

Mist verdammter Hast ja recht des hätte ich auch selbst merken können.

Hab jetzt einfach in der ISR die Portabfrage gedreht.

Aber so richtig funktioniert es doch noch nicht.

Hab mal mit den Vergleichswerten gespielt ab einem Wert von >72 geht die LED dauerhaft a. Das ist klar weil das bei 1ms Impulslänge der kleinste Timerwert ist. Ab einem Wert von 150 geht se gar nicht mehr an. Das ist auch klar weil der Timer nicht so hoch zählt da die Impulslänge zu kurz ist. Alles kklar soweit das stimmt ja auch alles mit den Berechnungen von ganz am Anfang überein.

Ich hab den Wert jetzt mal auf 110 gestellt was so ungefähr der neutralstellung entspricht.
Es ist jetzt so ich dreh den Servotester auf die kleinste Impulslänge -> Die LED ist aus. Jetzt dreh ich die Impulslänge langsam hoch dann fängt so ab der Neutralstellung die LED wieder an zu blinken. Wieder mit dem 12ms Intervall. Erst wenn ich die Impulslänge noch etwas höher dreh dann leuchtet die LED dauerhaft.

Dafür noch irgend eine Idee woran das liegt.

[Sauerbruch]

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...