Sehr schön! Diese Controller sind wirklich mit allem ausgestattet.
Ich nehm jetzt erst mal ein Macro
Code:
.macro nimp
reti
nop
.endmacroLight to frequency
- Ersteller wer
- Erstellt am
Dann könntest Du es auch auf die Spitze treiben, und Dir eine Bibliothek anlegen die:
-für jeden möglichen Interruptnamen aller Controller (das geschieht in der vorher inkludierten Controller-Definitionsdatei, je mit ".equ") prüft, ob dieser definiert wurde und dann mittels bedingter Compilierung (.ifdef)
-genau an dieser Adresse (.org) den entsprechenden Code einfügen lassen.
-Dabei die Breite der inerruptvektortabelle beachten, in den Controller-Definitionsdateien sollte sich mMn bereits eine definierte Konstante finden lassen, die Aufschluß über die Flashgröße gibt, und die man heranziehen kann
Diese Bibliothek kannst Du dann nach der Controller-Definitionsdatei inkludieren, dann brauchst Du gar keine nicht verwendeten IRQs mehr (auf Deine Art) abzuschließen. Daß ganze klappt natürlich nur dann, wenn Du im Sourcecode die zu verwendenden Interruptvektoren danach nochmal überschreiben kannst (mit .org an der richtige Stelle) - kA, ob der Assembler das schluckt, und korrekt überschreibt, kannste ja mal ausprobieren...
-für jeden möglichen Interruptnamen aller Controller (das geschieht in der vorher inkludierten Controller-Definitionsdatei, je mit ".equ") prüft, ob dieser definiert wurde und dann mittels bedingter Compilierung (.ifdef)
-genau an dieser Adresse (.org) den entsprechenden Code einfügen lassen.
-Dabei die Breite der inerruptvektortabelle beachten, in den Controller-Definitionsdateien sollte sich mMn bereits eine definierte Konstante finden lassen, die Aufschluß über die Flashgröße gibt, und die man heranziehen kann
Diese Bibliothek kannst Du dann nach der Controller-Definitionsdatei inkludieren, dann brauchst Du gar keine nicht verwendeten IRQs mehr (auf Deine Art) abzuschließen. Daß ganze klappt natürlich nur dann, wenn Du im Sourcecode die zu verwendenden Interruptvektoren danach nochmal überschreiben kannst (mit .org an der richtige Stelle) - kA, ob der Assembler das schluckt, und korrekt überschreibt, kannste ja mal ausprobieren...
Also das aktuelle Unterprogramm bzw. die ISR für Timer 2 sieht so aus:
Ich schalte den Sensor mit PD4 ein und die Daten werden über PD5 (Timer 1) eingelesen. Alles funktioniert bisher, wie es soll! Muß aber noch besser testen.
Vielen Dank für den guten Rat!
Code:
GetLightFreq:
sbi PORTD,TSL_vcc ; TSL einschalten
ldi temp1, 5 ; Timer 2 Ovfl-Counter
mov freqC, temp1
clr temp1
sts TCNT2, temp1 ; Timer 2 löschen
sts TCNT1H, temp1 ; Timer 1 löschen
sts TCNT1L, temp1
ldi temp1, 1<<CS12 | 1<<CS11 | 1<<CS10 ; T1=PD5 steigende Flanke
sts TCCR1B, temp1
ldi temp1, 1<<CS22 | 1<<CS20 ; Vorteiler 1024
sts TCCR2B, temp1
set
WaitTSL:
brts WaitTSL
clr temp1 ; beide Timer ausschalten
sts TCCR1B, temp1
sts TCCR2B, temp1
cbi PORTD,TSL_vcc ; TSL ausschalten
ret
T2ovfl:
in temp2, SREG ; Statusregister sichern
dec freqC
brne T2oGoon
lds freqL, TCNT1L ; Zähler sichern
lds freqH, TCNT1H
in temp1, TIFR1
sbrc temp1, TOV1 ; Bit 17
sbi TIFR1, TOV1 ; Overflow löschen
andi temp1, 1
mov freq3, temp1
cbr temp2, 1<<6 ; T-Bit setzen
T2oGoon:
out SREG, temp2
retiVielen Dank für den guten Rat!
Ich möchte jetzt noch einen Taster abfragen und die Helligkeit dann auf Tastendruck in einer Schleife ausgeben. Zum Problem des Tastenentprellens habe ich folgende Routine Timer-Verfahren (nach Peter Dannegger) gefunden. Die Routine nutzt Timer 0. Was mich dabei ein wenig bedrückt, ist die Tatsache, daß ich dann keinen Timer mehr frei habe.
In meinem Temperaturprogramm habe ich folgendes gemacht:
Das hat bei 1MHz Takt gut funktioniert. Allerdings stecken hier wieder die üblen Warteschleifen drin.
Gibt es eine Alternative?
Abgesehen von einer Hardwarelösung!
Ach! Und noch eine Frage:
Peter Danneggers Routine oben wird im Beispiel so abgefragt:
Ist das cli ... sei Pärchen hier nötig? Beide Befehle (eor und clr) sind unabhängig voneinander und werden in einem Takt abgearbeitet.
In meinem Temperaturprogramm habe ich folgendes gemacht:
Code:
Loop:
sbis PIND, 0x05 ; Taster gedrückt
call Taster
rjmp Loop
Taster:
ldi temp1, 0
TLoop1:
nop
nop
nop
dec temp1
brne TLoop1 ; warte etwa 1/4ms
sbic PIND, 0x05 ; verschwinde wenn nicht mehr gedrückt
ret
call GetTemp
TLoop2:
sbis PIND, 0x05 ; warte bis losgelassen
rjmp TLoop2
ldi temp1, 0
TLoop3:
nop
nop
nop
dec temp1
brne TLoop3 ; warte etwa 1/4ms
retDas hat bei 1MHz Takt gut funktioniert. Allerdings stecken hier wieder die üblen
Warteschleifen drin.Gibt es eine Alternative?
Abgesehen von einer Hardwarelösung!
Ach! Und noch eine Frage:
Peter Danneggers Routine oben wird im Beispiel so abgefragt:
Code:
cli
eor leds, key_press ;toggle LEDs
clr key_press ;clear, if key press action done
seiIst das cli ... sei Pärchen hier nötig? Beide Befehle (eor und clr) sind unabhängig voneinander und werden in einem Takt abgearbeitet.
Hallo,
Sieh mal hier ...
Wie alles begann - oder - 4Kanal-PWM mit AT90S2313 für einen Magierstab - Beitrag #22 - Die Digitalisierung
da findest du einen komplett dokumentierten Quellcode wie man sowas ohne Wartezyklen machen kann. Da habe ich eine Soft-PWM gebaut die ohne Timer läuft und darum keine Warteschleifen haben darf die das Programm unregelmäßig laufen lassen würden.
Gruß
Dino
ich hab mal bei mir eine Tastenentprell-Routine in Assembler gebaut die einfach durchläuft. Das Entprellen wird durch den Shift-Befehl erledigt.Das hat bei 1MHz Takt gut funktioniert. Allerdings stecken hier wieder die üblen
Gibt es eine Alternative?
Abgesehen von einer Hardwarelösung!
Sieh mal hier ...
Wie alles begann - oder - 4Kanal-PWM mit AT90S2313 für einen Magierstab - Beitrag #22 - Die Digitalisierung
da findest du einen komplett dokumentierten Quellcode wie man sowas ohne Wartezyklen machen kann. Da habe ich eine Soft-PWM gebaut die ohne Timer läuft und darum keine Warteschleifen haben darf die das Programm unregelmäßig laufen lassen würden.
Gruß
Dino
Naja, ganz unabhängig sind sie nicht. Ich habe Peters Code jetzt mal nur "quer gelesen" - letztendlich werden "neue" gültige (=entprellte) Tastendrücke in der TOV-ISR in key_press abgelegt.
eor... bewirkt, daß die (und nur die) LEDs (bits) toggeln, wo in key_press 'ne 1 steht.
clr... setzt danach alle Taster auf 0 zurück, also erst, wenn die LEDs korrekt gesetzt sind.
Tritt jetzt zwischen diesen beiden Instruktionen ein TOV ein, wartet der IRQ bis die Ints wieder freigegeben sind. Somit werden diese "neuen" Tastendrücke beim nächsten Durchlauf mitbearbeitet.
Ohne dort Ints zu unterbinden könnte der neue Status in keypress dort einfach unbearbeitet verschluckt (gelöscht) werden, klar?
Und jetzt zu der Sache mit den gebundenen Timern. Du siehst den Wald vor lauter Bäumen nicht. Wenn ich das recht verstanden habe, nutzt Peter einen TOV alle 24ms. Du hast bereits einen Timer, der alle 25ms (?) überläuft. Wenn Du Timer2 also nicht abschalten würdest, könntest Du in dieser ISR Peters Code mit einbauen. (Wahrscheinlich sogar, ohne Korrekturen wegen der einen ms)
Ein Tastendruck ist ja, gerade wegen des Prellens, ein komplexerer Vorgang. Zwischen zwei Befehlen kann sich doch höchstens eine Zustandsänderung an dem betreffenden Port ereignen und das kann ja noch unter Prellen laufen.
Na, vielleicht bin ich nur ein wenig vorsichtig! Aber danke für den Hinweis. Ich denke, so langsam verstehe ich, warum Du den Timer durchlaufen lassen würdest. Mein Timer läuft alle 40/3ms über (ein bischen kurz). Alle 200/3ms ist meine Messzeit um (ein bischen lang). Ein weiterer Zähler um z.B. zwei Überläufe zu zählen (~27ms)?
herrje...
klar kann das Entprellen eine ziemlicj komplexe Angelegenheit werden - entscheidend ist, welche Anforderungen Du an den entprellten Taster stellst:
-maximal erlaubte Reaktionszeit
-nach Erkennung der entprellten Flanke ist der Taster bis zur entprellten entgegengesetzten Flanke "gesperrt", oder darf das zu erzeugende Ereignis dann mehrfach ausgelöst werden?
-mit welcher Frequenz dann?
...
ich hatte bei Dir 25ms in Erinnerung - ok, also Deine TOV jetzt also alle 13,33ms (Messwerte alle 66,67ms). Wenn Du Peters Code in jeder 2ten TOV ausführen laßt, wärst Du bei 26,67ms. Peter hat 24ms verwendet - Du würdest also so nicht ganz so fix tippen können...
Ich hatte bei meinem Phasenanschnittsdimmer damals ganz simpel die sowieso detektierten Nulldurchgänge (alle ~10ms) eine Hilfsvariable runterzählen lassen (bei Überlauf auf 0 festgenagelt). Tastenabfrage nur bei Hilfsvariable=0, bei erkannter Betätigung wird die Hilfsvariable wieder hochgesetzt. Ich hatte damals (glaub ich) ein "Blockierfenster" von 330ms gewählt, also 1s Drücken entsprach 3 Stufen hoch/runter; mit einem kurzen Antippen 1 Stufe.
Hmm... was mir jetzt grad so durch den Kopf geht: wenn man an einen µC-Pin einen Taster gegen Gnd und parallel dazu einen (noch festzulegenden) Kerko legt, und den Pin über den internen Pullup speist, hat man ja quasi einen Tiefpaß, was das Laden betrifft. Kritisch wäre beim Laden der Bereich um den schwellwert, klar - ABER beim ADC schaltet man ja üblicherweise die digitalen Input Filter ab (DIDR) - was ist das eigentlich? Mal im Datenblatt schmökern.
@Dino und andere Oszi-Besitzer: kann mal wer ein paar Bilder zu der ganzen Geschichte posten?
klar kann das Entprellen eine ziemlicj komplexe Angelegenheit werden - entscheidend ist, welche Anforderungen Du an den entprellten Taster stellst:
-maximal erlaubte Reaktionszeit
-nach Erkennung der entprellten Flanke ist der Taster bis zur entprellten entgegengesetzten Flanke "gesperrt", oder darf das zu erzeugende Ereignis dann mehrfach ausgelöst werden?
-mit welcher Frequenz dann?
...
ich hatte bei Dir 25ms in Erinnerung - ok, also Deine TOV jetzt also alle 13,33ms (Messwerte alle 66,67ms). Wenn Du Peters Code in jeder 2ten TOV ausführen laßt, wärst Du bei 26,67ms. Peter hat 24ms verwendet - Du würdest also so nicht ganz so fix tippen können...
Ich hatte bei meinem Phasenanschnittsdimmer damals ganz simpel die sowieso detektierten Nulldurchgänge (alle ~10ms) eine Hilfsvariable runterzählen lassen (bei Überlauf auf 0 festgenagelt). Tastenabfrage nur bei Hilfsvariable=0, bei erkannter Betätigung wird die Hilfsvariable wieder hochgesetzt. Ich hatte damals (glaub ich) ein "Blockierfenster" von 330ms gewählt, also 1s Drücken entsprach 3 Stufen hoch/runter; mit einem kurzen Antippen 1 Stufe.
Hmm... was mir jetzt grad so durch den Kopf geht: wenn man an einen µC-Pin einen Taster gegen Gnd und parallel dazu einen (noch festzulegenden) Kerko legt, und den Pin über den internen Pullup speist, hat man ja quasi einen Tiefpaß, was das Laden betrifft. Kritisch wäre beim Laden der Bereich um den schwellwert, klar - ABER beim ADC schaltet man ja üblicherweise die digitalen Input Filter ab (DIDR) - was ist das eigentlich? Mal im Datenblatt schmökern.
@Dino und andere Oszi-Besitzer: kann mal wer ein paar Bilder zu der ganzen Geschichte posten?
Hi,
elektronische Tastenentprellung (zB beim Pollinboard)
Von Cassio ist da auch noch was mit nem LA dazugekommen.
Wie ich das mit dem entprellen in Assembler gelöst habe sieht man ja im Quellcode von dem Beitrag den ich weiter oben verlinkt habe. Ich hab da in dem Sinne keine feste Verzögerung benutzt sondern es über ein softwaretechnisches Schieberegister gelöst. Im Quellcode ist es 8Bit lang. Beim Mega32-Daddelboard (Projekte) hab ich es für den Incrementalgeber auch mit nem Schieberegister gemacht. Da habe ich aber wegen Geschwindigkeit nur 4Bit verwendet. Das läuft recht gut und zuverlässig.
Mal sehen ob ich heute nochmal nen prellenden Taster ohne den Kondensator ans Oszi hänge. Die Schaltung lebt glaube ich noch auf nem Mini-Steckbrett.
Gruß
Dino
zum entprellen hab ich bei den Schaltungen ja mal was reingestellt.
elektronische Tastenentprellung (zB beim Pollinboard)
Von Cassio ist da auch noch was mit nem LA dazugekommen.
Wie ich das mit dem entprellen in Assembler gelöst habe sieht man ja im Quellcode von dem Beitrag den ich weiter oben verlinkt habe. Ich hab da in dem Sinne keine feste Verzögerung benutzt sondern es über ein softwaretechnisches Schieberegister gelöst. Im Quellcode ist es 8Bit lang. Beim Mega32-Daddelboard (Projekte) hab ich es für den Incrementalgeber auch mit nem Schieberegister gemacht. Da habe ich aber wegen Geschwindigkeit nur 4Bit verwendet. Das läuft recht gut und zuverlässig.
Mal sehen ob ich heute nochmal nen prellenden Taster ohne den Kondensator ans Oszi hänge. Die Schaltung lebt glaube ich noch auf nem Mini-Steckbrett.
Gruß
Dino
Hallo Dino,
die Idee mit einem Schieberegister gefällt mir. Den Takt geben da wohl die Schleifendurchläufe an, oder? Wie lange ca. dauerte ein Schleifendurchlauf bei Dir?
keine Ahnung wie lange da ein Schleifendurchlauf dauert. Aber so lange wie die Bits nicht alle 1 oder alle 0 sind prellt es noch. Die Entprellzeit ist also dynamisch.
Nehmen wir mal an das der Taster prellt ungefähr so wie in Cassio seinem Mitschnitt mit dem LA ...
elektronische Tastenentprellung (zB beim Pollinboard) - Beitrag #3
wenn ich den Screenshot ausmesse dann sind von +0,1ms bis +0,9ms auf meinem EeePC etwa 10cm. also 1,25cm pro 100µs. Ich komme dann beim größten Impulsabstand auf etwa 160µs. Wenn man das in eine Frequenz umrechnet wären das 6,25kHz. Bei 20MHz würde er in dieser Zeit im optimalsten Fall etwa 3200 Befehle schaffen. Wenn man dort die 8 Schleifendurchläufe reinsetzt dann wären das etwa 400 Befehle pro Schleifendurchlauf. Wenn der Atmel also bei 20MHz (höchste mögliche Taktfrequenz eines Atmels) weniger wie 400 Befehle pro Schleifendurchlauf abarbeiten muß dann wird diese Lösung eventuell nicht mehr greifen. Das wären dann 20µs für einen Schleifendurchlauf.
Also bei 8 Schleifendurchläufen wirst du mit mit hoher Sicherheit das Prellen rausgerechnet haben. Ich hab bei meinem Incrementalgeber nur 4 Bit (4 Schleifendurchläufe) als Schieberegister verwendet. Der mach 24 Pulse pro Umdrehung und ich dreh den beim testen innerhalb einer halben Sekunde einmal rum. Also etwa 50 "Tastenwechsel" pro Sekunde. Ber Mega32 läuft dabei mit Assembler und 16MHz.
Nach meiner Meinung ist diese Lösung wesentlich effizienter und sauberer wie dieses elendige Zeugs mit der Wartezeit. Vor allem verlängert sich das bei dem Schieberegister automatisch wenn noch prellen festgestellt wird. Die Schleifendurchläufe müssen auch nicht wirklich im gleichmäßigen Zeitraster sein. Es ist also sehr einfach aber auch sehr effizient.
Gruß
Dino
Ich lese das so: Die 0,9 entspricht 691,9 und die 0,1 entspricht 692,1, also 0,2ms. D.h. der größte Abstand wären ca. 42,1µs und damit etwa 842 Befehle (bzw. 1/8 also 105 Befehle). Das hört sich noch besser an.
Casio: Wie ist Dein Bild zu lesen?
Man könnte ja noch einen Zähler mitführen und nur in jedem n-ten Durchlauf schieben.
Hallo,
Das Schieberegister samplet ja bei jedem Schleifendurchlauf ein Bit in das Register. Also 8 Abtastungen lang bis es komplett "runderneuert" ist.
Das Ende des Prellens ist für den Algorithmus erreicht wenn alle 8 Bits im Schieberegister entweder 0 oder 1 sind. Es müssen also alle 8 identisch sein. Das kann bei Cassio seinem mitgeschnittenen Signalverlauf nur an einer Stelle innerhalb des Signals passieren ...
Nur an dieser Stell ist die Zeit innerhalb des Prellens mit identischem Pegel maximal (eta 160µs lang gleicher Pegel).
Wenn der Atmel es also schafft innerhalb dieser Zeit 8 Durchläufe durchzukriegen und bei jedem Durchlauf den selben logischen Pegel einzulesen und ins Schieberegister zu schieben, dann würde dieser AAbschnitt so aussehen als wenn der Tasteneingang auf Low liegt und das Prellen vorbei ist.
Das habe ich mit meiner Berechnung versucht darzustellen.
Ein Befehl benötigt mindestens eine komplette Schwingung des Quarzoszillators. (ein Befehl pro Taktzyklus). Bei einem 20MHz Quarz währe ein Taktzyklus (1 / 20MHz = ) 50ns lang. Das paßt (160µs / 0,05µs) = 3200 mal in diese 160µs. Also könnte er innerhalb dieser Zeit maximal 3200 Befehle ausführen.
Da er ja innerhalb dieser Zeit 8 Bits in das Schieberegister laden muß und bei einem Schleifendurchlauf nur ein Bit reinlädt muß man also nochmal durch 8 teilen. 3200 / 8 = 400 Befehle pro Schleifendurchlauf.
Wenn der Atmel also weniger wie 400 Befehle (Calls brauchen mehr Taktzyklen, Sprünge auch und Bedingungen teilweise auch) in einem Schleifendurchlauf ausführt, könnte es bei 20MHz Takt zu Fehlinterpretationen kommen. Da ist die Entprell-Routine bereits mit eingerechnet.
Bei 8MHz sieht es wieder anders aus ...
1/8MHz = 125ns Taktzyklus.
160µs/0,125 = 1280 Befehle
1280 / 8 = 160 Befehle pro Schleifendurchlauf als Minimum.
Ist doch ganz einfach
Gruß
Dino
Du mußt die Funktion des Entprell-Algorithmus mit bedenken.
Das Schieberegister samplet ja bei jedem Schleifendurchlauf ein Bit in das Register. Also 8 Abtastungen lang bis es komplett "runderneuert" ist.
Das Ende des Prellens ist für den Algorithmus erreicht wenn alle 8 Bits im Schieberegister entweder 0 oder 1 sind. Es müssen also alle 8 identisch sein. Das kann bei Cassio seinem mitgeschnittenen Signalverlauf nur an einer Stelle innerhalb des Signals passieren ...
Nur an dieser Stell ist die Zeit innerhalb des Prellens mit identischem Pegel maximal (eta 160µs lang gleicher Pegel).
Wenn der Atmel es also schafft innerhalb dieser Zeit 8 Durchläufe durchzukriegen und bei jedem Durchlauf den selben logischen Pegel einzulesen und ins Schieberegister zu schieben, dann würde dieser AAbschnitt so aussehen als wenn der Tasteneingang auf Low liegt und das Prellen vorbei ist.
Das habe ich mit meiner Berechnung versucht darzustellen.
Ein Befehl benötigt mindestens eine komplette Schwingung des Quarzoszillators. (ein Befehl pro Taktzyklus). Bei einem 20MHz Quarz währe ein Taktzyklus (1 / 20MHz = ) 50ns lang. Das paßt (160µs / 0,05µs) = 3200 mal in diese 160µs. Also könnte er innerhalb dieser Zeit maximal 3200 Befehle ausführen.
Da er ja innerhalb dieser Zeit 8 Bits in das Schieberegister laden muß und bei einem Schleifendurchlauf nur ein Bit reinlädt muß man also nochmal durch 8 teilen. 3200 / 8 = 400 Befehle pro Schleifendurchlauf.
Wenn der Atmel also weniger wie 400 Befehle (Calls brauchen mehr Taktzyklen, Sprünge auch und Bedingungen teilweise auch) in einem Schleifendurchlauf ausführt, könnte es bei 20MHz Takt zu Fehlinterpretationen kommen. Da ist die Entprell-Routine bereits mit eingerechnet.
Bei 8MHz sieht es wieder anders aus ...
1/8MHz = 125ns Taktzyklus.
160µs/0,125 = 1280 Befehle
1280 / 8 = 160 Befehle pro Schleifendurchlauf als Minimum.
Ist doch ganz einfach
Gruß
Dino
Ja, ich hatte schon verstanden, was Du meintest. Allerdings kann ich nicht nachvollziehen, wie Du darauf kommst, daß der Bereich zwischen den grünen Marken 1ms breit ist.
Liebe Profis,
ich habe ein Problem an dem ich jetzt schon eine ganze Weile festsitze. Ich denke ich hab es auch ganz gut eingekreist. Aber die Lösung finde ich nicht.
Dem Datenblatt des [URL="http://www.ams.com/eng/content/download/250249/975925/file/TSL235R-pdf]TSL235R.pdf[/URL] nach, sollte der Sensor Frequenzen bis etwas unter 1MHz liefern. Das Maximum dessen, was meiner liefert sind 97kHz. Das ist um den Faktor 10 (oder 8) zu wenig.
Ich habe zuerst nach einem Rechenfehler gesucht, bin aber nicht fündig geworden.
Heute nun habe ich versuchsweise das Meßintervall auf 3s (theoretisch) vergrößert (225 statt 5 Überläufe) und vor der Messung eine LED entzündet, die ich hinterher wieder gelöscht habe.
Ergebnis: Das Licht leuchtet, aber deutlich kürzer als eine Sekunde.
Wie ist das zu erklären?
Mein Vorteiler ist doch richtig eingestellt oder?
19660800/1024 = 19200
19200/256 = 75
75/5 = 15
Messzeit also 1/15s, d.h. Zählerstand * 15 ergibt Hz.
Edit: Mist! Ich hab's gefunden! (1024 bei Timer 2 ist 111, nicht 101 wie bei den beiden anderen Timern)
ich habe ein Problem an dem ich jetzt schon eine ganze Weile festsitze. Ich denke ich hab es auch ganz gut eingekreist. Aber die Lösung finde ich nicht.
Dem Datenblatt des [URL="http://www.ams.com/eng/content/download/250249/975925/file/TSL235R-pdf]TSL235R.pdf[/URL] nach, sollte der Sensor Frequenzen bis etwas unter 1MHz liefern. Das Maximum dessen, was meiner liefert sind 97kHz. Das ist um den Faktor 10 (oder 8) zu wenig.
Ich habe zuerst nach einem Rechenfehler gesucht, bin aber nicht fündig geworden.
Heute nun habe ich versuchsweise das Meßintervall auf 3s (theoretisch) vergrößert (225 statt 5 Überläufe) und vor der Messung eine LED entzündet, die ich hinterher wieder gelöscht habe.
Ergebnis: Das Licht leuchtet, aber deutlich kürzer als eine Sekunde.
Wie ist das zu erklären?
Mein Vorteiler ist doch richtig eingestellt oder?
19660800/1024 = 19200
19200/256 = 75
75/5 = 15
Messzeit also 1/15s, d.h. Zählerstand * 15 ergibt Hz.
Edit: Mist! Ich hab's gefunden! (1024 bei Timer 2 ist 111, nicht 101 wie bei den beiden anderen Timern)
Hallo,
Also ich war der Meinung das die Angaben oben ( +0,1ms und +0,9ms ) vom Triggerzeitpunkt oder so stammen. Tja ... das war leider ein Fehler. Man sollte doch mal öfters mit dem LA arbeiten
Also das +0,1ms und +0,9ms bezieht sich auf die 692,0ms. An den Stellen sind also 691,9ms und 692,1ms. Es sind also etwa 37µs (25µs plus nochmal etwa die Hälfte von 25µs). Hier mal die berichtigte Grafik ...
Also nochmal alles mit 37µs bei 20MHz Takt ...
37µs / 50ns = 740 Zyklen (Befehle)
740 / 8 = 92,5 Befehle pro Schleifendurchlauf.
Das verbessert den Algorithmus noch ein wenig Es wird also noch wahrscheinlicher das er selbst bei kleinen Schleifen (mit wenigen Befehlen) und hohem Prozessortakt eine saubere Entprellung bewältigt.
Nun sollte es aber stimmen
Gruß
Dino
ich hab mir das für ne Erklärung nochmal genau angesehen. Dabei ist mir doch glatt nen Fehler aufgefallen
Also ich war der Meinung das die Angaben oben ( +0,1ms und +0,9ms ) vom Triggerzeitpunkt oder so stammen. Tja ... das war leider ein Fehler. Man sollte doch mal öfters mit dem LA arbeiten
Also das +0,1ms und +0,9ms bezieht sich auf die 692,0ms. An den Stellen sind also 691,9ms und 692,1ms. Es sind also etwa 37µs (25µs plus nochmal etwa die Hälfte von 25µs). Hier mal die berichtigte Grafik ...
Also nochmal alles mit 37µs bei 20MHz Takt ...
37µs / 50ns = 740 Zyklen (Befehle)
740 / 8 = 92,5 Befehle pro Schleifendurchlauf.
Das verbessert den Algorithmus noch ein wenig
Es wird also noch wahrscheinlicher das er selbst bei kleinen Schleifen (mit wenigen Befehlen) und hohem Prozessortakt eine saubere Entprellung bewältigt.Nun sollte es aber stimmen
Gruß
Dino
Neues Problem!
Der TSL235R ist zu empfindlich. Ich werde ihn durch einen TSL230RD ersetzen. Leider gibt es den nur noch in einem SOIC-Gehäuse (DIL ist abgekündigt). Habt Ihr einen Tip, wie man sowas für Lochrasterplatinen verfügbar macht?
Der TSL235R ist zu empfindlich. Ich werde ihn durch einen TSL230RD ersetzen. Leider gibt es den nur noch in einem SOIC-Gehäuse (DIL ist abgekündigt). Habt Ihr einen Tip, wie man sowas für Lochrasterplatinen verfügbar macht?
Hi,
Gruß
Dino
das ist kein Problem. Schau mal im FAQ-Bereich (Beitrag über SMD-Winzlinge) oder bei meinen Projekten. Da sind auch welche dabei die mit SOIC20 (tiny2313) sind. Da habe ich nen Lochstreifenraster genommen und mit nem Teppichmesser an den benötigten Stellen auf 1,27mm Raster gebracht.
Gruß
Dino
Ich habe gerade ein einfaches Schieberegister implementiert, für einen Taster. Dabei kam ich ein wenig ins grübeln.
Im Prinzip sind es ja 5 Zustände, die man auseinander halten will:
1. undefinierter Zustand (Prellen)
2. Taste gedrückt (0xff), unabhängig vom vorherigen Zustand
3. Taste nicht gedrückt (0x00), unabhängig vom vorherigen Zustand
4. Taste erstmalig gedrückt, letzter definierter Zustand war: 'nicht gedrückt'
5. Taste gerade losgelassen, letzter definierter Zustand war: 'gedrückt'
Jetzt wäre es schön, man könnte diese 5 Fälle so in einem Byte codieren, daß sie bequem abgefragt werden können. Natürlich könnte man einfach 4 Bits setzen für die Zustände 2 - 5 (Zustand 1 wäre dann die Null), oder aufeinander folgende Codes für aufeinander folgende Zustände, z.B.
1. 0
2. 2
3. 4
4. 1
5. 3
Gibt es da schon Lösungen, die sich bewährt haben? Was habt Ihr dazu für Gedanken?
Im Prinzip sind es ja 5 Zustände, die man auseinander halten will:
1. undefinierter Zustand (Prellen)
2. Taste gedrückt (0xff), unabhängig vom vorherigen Zustand
3. Taste nicht gedrückt (0x00), unabhängig vom vorherigen Zustand
4. Taste erstmalig gedrückt, letzter definierter Zustand war: 'nicht gedrückt'
5. Taste gerade losgelassen, letzter definierter Zustand war: 'gedrückt'
Jetzt wäre es schön, man könnte diese 5 Fälle so in einem Byte codieren, daß sie bequem abgefragt werden können. Natürlich könnte man einfach 4 Bits setzen für die Zustände 2 - 5 (Zustand 1 wäre dann die Null), oder aufeinander folgende Codes für aufeinander folgende Zustände, z.B.
1. 0
2. 2
3. 4
4. 1
5. 3
Gibt es da schon Lösungen, die sich bewährt haben? Was habt Ihr dazu für Gedanken?