Hallo, nachdem ich nun mal wieder Zeit habe, wollte ich meine Infrarot-Lichtschranke weiter bauen. Dabei soll ein Atmega8 eine Led ansteuern und ein TSOP1738 als Empfänger dienen. Tsop1738 weil, ist vorhanden und wegen Fremdlichteinfluß. Anbei die ersten Entwürfe, aber leider messe ich am Ausgang nur 3,85 kHz. Wo liegt hier der Fehler ? Bitte keine Diskussion warum in Bascom. [code] 'Infrarot-Lichtschranke mit TSOP1738 'Sende-LED an PD4, TSOP1738 an PB0 $regfile = "m8def.dat" $crystal = 8000000 '$sim 'Config Pinb.0 = Input Config Portd.4 = Output Led Alias Portd.4 Config Timer0 = Timer , Prescale = 8 'ergibt 0,1 ms On Timer0 Timer0_isr Enable Timer0 Enable Interrupts Const Timerstart = 131 'für 38kHz mit Ifr-LED Timer0 = Timerstart Do Loop End Timer0_isr: Timer0 = Timerstart Toggle Led 'Sende-LED für TSOP1738 Return [code end] Frequenzmesser ist Elektor-Projekt mit Attiny2313. Danke schon mal in vorraus.
Dein Timer zählt mit einer Taktrate von 1000000 (8000000/8).
d.h. in 1 Sekunde schafft er 1000000/132 = 7575 mal von 0 bis 131 zu
zählen. Bei jedem mal wird getoggelt, also hast du eine Frequenz von
3.8khz
-> der µC macht genau das, was du von ihm aufgetragen hast.
> Wo liegt hier der Fehler ?
Du hast dich bei der Bestimmung der Parameter verrechnet.
Hi, naja nicht ganz. Der zählt von 131 bis 255, was nach meiner Rechnung 4,032kHz ergeben sollte. Prescale = 1 und Timerstart neu berechnen. Gruß, Norbert
Ja, hast recht. Ich hab jetzt CTC gedacht. Die fehlenden 0.13 kHz sind wohl auf die Interrupt Verzögerung zurückzuführen und zeigen als solches, dass dieses Timer-Vorladen nix taugt, wenn es einigermassen genau sein soll. Genau aus diesem Grund hat Atmel seinen Timern ein paar Fähigkeiten in Hardware mitgegeben.
Hi > Genau aus diesem Grund hat >Atmel seinen Timern ein paar Fähigkeiten in Hardware mitgegeben. Allerdings nicht dem Timer0 von ATMega8. MfG Spess
Karl Heinz Buchegger schrieb: > Ja, hast recht. Ich hab jetzt CTC gedacht. > > Die fehlenden 0.13 kHz sind wohl auf die Interrupt Verzögerung > zurückzuführen und zeigen als solches, dass dieses Timer-Vorladen nix > taugt, wenn es einigermassen genau sein soll. Genau aus diesem Grund hat > Atmel seinen Timern ein paar Fähigkeiten in Hardware mitgegeben. Nö. Selbst mit Systemtakt müsste der Wert 151 sein (mit 256 rechnen, nicht 255 wie ich oben getan habe). Er hat also 151 Takte nach dem Überlauf um die ISR anzuspringen und den Timer mit dem neuen Wert zu stellen. Der Spaß (anspringen und wieder zurück) dauert jeweils etwa 50 Takte, reicht also so gerade eben. Ist aber natürlich Mist den µC mit sowas fast komplett auszulasten. Tipp: Timer2 im M8 und FastPWM als Einstieg nehmen. Das ist vielleicht nicht optimal aber im Datenblatt am einfachsten zu verstehen. Ich wühle mich für sowas immer durchs Datenblatt und setze das zu Fuß. Das ist beim ersten Mal etwas eklig aber Bascom unterstützt diese Geschichte mit der PWM nicht so schön, finde ich. Den Simulator in diesem Zusammenhang auch bitte mit Vorsicht geniessen. Gruß, Norbert
Hi
>Tipp: Timer2 im M8 und FastPWM
Eher CTC. Und nicht vergessen: Die TSOPs vertragen kein Dauersignal.
MfG Spess
D. Jäschke schrieb: > Wo liegt hier der Fehler ? Falsch, Einzahl, muss Mehrzahl sein: "die" Fehler. Das 38 im TSOP1738 sagt aus, dass der ein IR-Signal mit 38kHz haben möchte, das beutet per Software mit 76kHz toggeln. Damit hast Du bei 8 MHz 105 Takte für jedes Toggeln zur Verfügung, bei einer Auslastung von 100%. Da Bascom beim Aufruf einer ISR 'ne Menge Register sichert, braucht das allein schon ca. 110 Takte, geht also prinzipiell nicht. Da die Hauptschleife komplett leer ist, würde der Parameter NOSAVE helfen. Weiterer Fehler: Per Prescaler und Preload erhältst Du: 8000000 8 (256-131 =)125 = theoretisch um die 4kHz, was willst Du mit 4kHz anfangen ? Du benötigst 38kHz. Dann kommt hinzu, daß der Einsprung in die ISR + Sichern der Register bis zum neuen Laden des Timers per Preload ca. 50-60 Takte dauert, in dieser Zeit zählt der Timer bei Prescale = 8 um ca. 7 Stellen weiter. Wenn Du die 7 zu den 125 Zählerclocks rechnest, kommst Du auf 132, macht: 8000000 8 132 / 2 = 3788 Hz, das entspricht in etwa Deiner Messung.
Da hat die Forensoft ein paar Zeichen gefressen... MWS schrieb: > Per Prescaler und Preload erhältst Du: 8000000 8 > (256-131 =)125 = theoretisch um die 4kHz, was willst Du mit 4kHz > anfangen ? > 8000000 8 132 / 2 = 3788 Hz Soll heissen:
theoretisch um die 4kHz
ich schrieb ja FastPWM ist nicht optimal aber für den Anfang am einfachsten zu verstehen. Die TSOP sind für Fernbedienungen gedacht (um das mal zu erklären). Also bei dauerhaft 38kHz ist nach wenigen ms schluss, er erkennt das nicht mehr. Also für ne Lichtschranke vielleicht mit 1kHz die 38kHz takten (geht noch etwas schneller, bitte ins Datenblatt schauen). Ich sehe gerade, MWS und Karl-Heinz haben natürlich Recht. Was ich schrieb war wenn der Teiler weiterzählt bis man in der ISR ist. Wenn der Timer selbst schon weitergezählt hat kommt es zu der Abweichung. Bei prescale = 1 ist das natürlich voll daneben. Gruß, Norbert
erstmal Danke für die schnellen Antworten. Die Geschichte TSOP ist mir bekannt. Ich wollte halt mal wieder die Bastelkiste bemühen, glaube aber das ist heutzutage kaum noch machbar, weil die Technik viel zu speziell geworden ist. Die Idee beruht auf ein Projkt aus der Elektor aber da war ein pic 12Fxxx in Gebrauch. Das Prog habe ich neu geschrieben: zwischen do loop LED blinken, Prescale auf 1 = rechnerisch 37,...KhZ. Leider war das alles ein Schuß in Ofen, Led blinkt nur sporadisch und bei 33,...KHz ist schluß. Fazit : die Geschichte taugt so nicht. Weiter grübeln. Hat jemand ne andere Idee ? Das Net gibt leider nicht viel her dazu.
D. Jäschke schrieb: > Hat jemand ne andere Idee ? Ja. Lass den Timer arbeiten (Timer 2). Entweder CTC Modus mit selber umschalten in der ISR oder aber mit Fast-PWM mit Vorgabe des Rücksetzwertes. Dann erledigt der Timer völlig eigenständig die 38kHz und dein Programm kann in der Zwischenzeit Däumchen drehen.
D. Jäschke schrieb: > Leider war das alles ein Schuß in Ofen, Led blinkt nur sporadisch > und bei 33,...KHz ist schluß. > > Fazit : die Geschichte taugt so nicht. Weiter grübeln. > Hat jemand ne andere Idee ? Ja. Nicht nur schreiben, sondern auch die Antworten lesen. MWS schrieb: > Da die Hauptschleife komplett leer ist, würde der Parameter NOSAVE helfen.
Karl Heinz Buchegger > Ja. Lass den Timer arbeiten (Timer 2). > Entweder CTC Modus mit selber umschalten in der ISR oder aber mit > Fast-PWM mit Vorgabe des Rücksetzwertes. Dann erledigt der Timer völlig > eigenständig die 38kHz und dein Programm kann in der Zwischenzeit > Däumchen drehen. Das hat geholfen. Bischen Datenblatt ... Timer2 im CTC modus liefert 36,012 KHz (mußte einen anderen TSOP nehmen) Jetzt nur noch den Ausgang toggeln und siehe da es klappt, mit Toggeln zwischen 500 und 900 µs , mit 10 ms Pause schaltet der TSOP ohne Probleme. Hatte den Eindruck Bascom war mit meiner ersten Variante überfordert. Irgenwo las ich mal, das es manchmal besser unter Bascom ist, Register direkt anzusprechen. Also Danke nochmal
D. Jäschke schrieb: > Die Geschichte TSOP ist mir bekannt. Ich wollte halt mal wieder die > Bastelkiste bemühen, glaube aber das ist heutzutage kaum noch machbar, > weil die Technik viel zu speziell geworden ist. So schlimm ist das nun auch wieder nicht. Mit einem 4-fach OP und etwas Hühnerfutter für I/U-Konverter, Bandpaßfilter und Dekoder ist da schon was hinzukriegen. Mit etwas optimierter Optik zur Fremdlichtunterdrückung kann man sich dabei das Leben wesentlich erleichtern.
D. Jäschke schrieb: > Hatte den Eindruck Bascom war mit meiner ersten Variante überfordert. Hm, ich würd' eher sagen, Du bist überfordert. Wenn Du nur redest und nicht zuhörst, bzw. liest und nachfragst falls Du nicht verstehst, hast Du eine unvorteilhafte Einstellung für die Materie. MWS schrieb: > Da Bascom beim Aufruf einer ISR 'ne Menge Register sichert, braucht das > allein schon ca. 110 Takte, geht also prinzipiell nicht. Da die > Hauptschleife komplett leer ist, würde der Parameter NOSAVE helfen. Denn wenn man Dich zweimal mit der Nase auf NOSAVE stößt und Du suchst nicht wenigstens mal in der Hilfe danach, zeugt das nicht von Aufgeschlossenheit. D. Jäschke schrieb: > und bei 33,...KHz ist schluß. Klar, die Interruptroutine benötigt für die Registersicherung besagte 110 Takte und das eigentliche Toggeln mit Preload des Timers ca. 13 Takte, also insgesamt 123 Takte, da geht die Rechnung so:
Das entspricht dann 100% Prozessorlast. Würde man NOSAVE verwenden, so reduzieren sich die "Kosten" für die Interruptroutine auf ~17 Takte, damit würde der Portpin bei 100% Last mehr als 235kHz erzeugen. Allerdings geht ein Interrupt ohne Registersicherung nur bei leerer Hauptschleife gut. Kommt dort aber zusätzlicher Code rein, so muss gesichert werden, allerdings macht man das sinnvollerweise selektiv, da man ja Prozessorzeit sparen möchte. Als Ergebnis werden dann noch insgesamt ~31 Takte für den Interrupt benötigt, was ~129kHz ergäbe. Um 38kHz zu erreichen, müssen ~30% der Prozessorleistung aufgewendet werden. Das ist der Grund, warum man normalerweise per Hardware toggelt. Nur, funktionieren würde es völlig problemlos, es würde sogar ein 8Bit-Timer reichen. Für Deine anspruchslose Anwendung, reichen Dir 70% Prozessorleistung locker. Da häkelt der µC Dir noch'n Pullover und spielt Balalaika dazu. D. Jäschke schrieb: > Irgenwo las ich mal, das es manchmal besser unter Bascom ist, > Register direkt anzusprechen. Nö, nicht notwendig. Würd' an Deiner Stelle erst einmal die Materie gescheit lernen, bevor Du Dich Aberglauben und Mythen zuwendest ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.