Hallo allerseits, ich stehe vor einer ärgerlichen Problematik. Kurze Vorgeschichte: Vor ein paar Jahren gab es im AAA-Forum mal ein Projekt zu einer Lautstärke- und Quellenregelung für einen Verstärker. Dazu wurde von einem Foren-Mitglied das Board und ein dazugehöriges Programm für einen Atmega48. Das Programm blieb unter Verschluss, man konnte für kleines und faires Geld die fertig geflashten µC's beim 'Entwickler' kaufen. Irgendwann kam dann jemand daher und hat ebenfalls ein Programm passend zu der Hardware geschrieben und dieses Program als OpenSource im Forum gepostet. (http://www.analog-forum.de/wbboard/index.php?page=Thread&postID=621202#post621202) Dieses Programm habe ich der Einfachheit halber unverändert mal als Anhang hier beigefügt. Nun zum Problem: Da ich meine Hardware so aufgebaut habe, dass es für die Quellenwahl 2 Taster statt einem Dreh-Encoder (ALPS STEC11B 20/20) gibt, muss ich auf die Opensource-Variante ausweichen und entsprechend den Quellenwahl-Encoder durch Taster im Programm ersetzen. DAS ist nicht das Problem gewesen und schon gelöst. Mein Problem ist es nun, dass das OpenSource-Programm einen sehr störanfälligen IR-Empfang hat. Will heißen: sobald ne Energiesparlampe im Raum leuchtet oder die Sonne doof steht, reagiert das Gerät nicht mehr auf meine IR-Signale der Fernbedienung. Mit identischer Hardware und dem 'ClosedSource-µC' funktioniert dies hingegen tadellos und äußerst stabil. (Dafür fehlt mir halt die Quellenwahl per Knopfdruck) Ich habe schon mit den timings in der ir-rc5.c rumgespielt (leicht rauf und runter), dies brachte keine Besserung, eher im Gegenteil. Hat von euch jemand die Muße da mal drüber zu schauen und die Erfahrung/Ahnung, wodurch der instabile IR-Empfang zustande kommen könnte und wie ich dem entgegen wirken kann? Ich muss gestehen, dass ich mich ein wenig in die C-Programmiererei hereingefuchst habe, aber bei weitem nicht behaupten kann, dass ich Ahnung davon habe. Hardware ist folgende: http://www.symasym.holgerbarske.com/doku.php?id=dispre#lautstaerkeregelung_eingangswahl (verbaut ist ein TSOP4836) Schaltpläne gibt's in der 'Anleitung', falls von Intresse: http://www.symasym.holgerbarske.com/lib/exe/fetch.php?media=quellen--und-lautst-rkesteller.pdf Grundlage für beide Programme soll wohl dieser Code hier sein: Beitrag "Fernbedien RC5 Empfänger" (Nach Aussage vom Entwickler dient dies auch (leicht abgewandelt) für das funktionierende ClosedSource-Programm als Grundlage) Gruß, Markus
Wenn es mit dem einen Programm funktioniert und nur bei Deinem die Sparlampen stören, wird in Deinem Programm wohl die Fehlererkennung od. irgend eine Plausibilitätsprüfung noch nicht ganz optimal sein? Bau doch erst mal ein paar Prüfpunkte ein oder sammle Roh-Daten was der Empfänger an Müll einsammelt.
So viel Müll ist das gar nicht. Ich hätte erwähnen sollen, dass ich das Oszi schon mal dran hängen hatte. Wie sich aber gerade herausstellt habe ich an einer völlig falschen Ecke gesucht. In der timer.h gibt es ein OSCCAL-Parameter (Oscilator Calibration). Das habe ich mal Schrittweise verringert und siehe da, auf einmal wird das alles so, wie es sein soll. Ursprünglich stand der OSCCAL auf 158 (laut Kommentar war 157 beim Entwickler bereits zu langsam). Ich hab ihn im Moment auf 154 stehen, damit läuft das schon sehr gut. Kann mir bitte jemand relativ leicht verständlich erklären, wofür der OSCCAL-Parameter in der timer.h ist, was man genau mit ihm einstellt und ob es da einen Richt-/Sollwert gibt, nach dem man ihn einstellen sollte oder ob man damit einfach 'herumspielt' bis alles klappt? Wenn ich das richtig deute, kalibriert man mit diesem Parameter den Internen Oszillator vom Atmega. Was sagt die Zahl im Parameter aus? 154mS? Hz? Eier, Kartoffeln? Und welche genaue Auswirkung hat das Verändern des Parameters auf das ganze Programm? (Was würde passieren, wenn ich einen Wert von "1" und was, wenn ich "1000" einstelle oder den OSCCAL komplett weg lasse?) Die einzige Auswirkung, die ich momentan subjektiv merke ist, dass die IR-Verarbeitung auf einmal deutlich stabiler funktioniert. Mir scheint es so, als wäre der Parameter ein 'Feinabgleich' für den µC-Oszillator. Wenn dem so wär, müsste man das doch bei jedem neuen µC aufs neue 'feinabgleichen' Ich stehe da gerade ein wenig auf dem Schlauch und finde nichts für mich verständliches. Gruß, Markus
FoFi schrieb: > Mir scheint es so, als wäre der Parameter ein 'Feinabgleich' für den > µC-Oszillator. Ja, ist so! > Wenn dem so wär, müsste man das doch bei jedem neuen µC aufs neue > 'feinabgleichen' Richtig. Hab nicht in die HW geschaut - externer Quarz/Oszillator/Resonator ist eine Alternative.
Nun okay, das macht's für mich schon mal deutlich verständlicher. Kannst du mir auch noch verraten, was das nun für eine Einheit ist, die man beim OSCCAL angibt? Angenommen es wären Hz - 154Hz daneben wär ja schon ne Menge. Gibt's ne einfache Möglichkeit rauszufinden, auf welcher Frequenz genau der interne OSC schwingt um sich das 'rumspielen' mit dem OSCCAL zu ersparen und direkt den 'richtigen' Korrekturfaktur einzugeben?
Vllt sollte ich es auch anders formulieren: Wie finde ich raus, welcher der 'optimale' OSCCAL-Wert für 'meinen' Atmega48 is?
FoFi schrieb: > Kannst du mir auch noch verraten, was das nun für eine Einheit ist, die > man beim OSCCAL angibt? Angenommen es wären Hz - 154Hz daneben wär ja Das steht im Datenplat des Prozessors. Nein, Hz sind es nicht. fonsana
@FoFi: zum Kalibrieren gibt es eine Application Note von Atmel: http://www.atmel.com/Images/doc2555.pdf Oder kürzer: CLKO Pin per Fuse aktivieren, Frequenzzähler/Oszi dran und OSCCAL Werte mit kleinem Testprogramm durchprobieren. Datenblatt des Mega48 benutzen. Da stehen Hinweise dafür drin.
Himmel ist das ein Aufwand. Ein weiterer Grund in Zukunft auf externe Quarze zu setzen. Danke für die Infos!
Angehängte Dateien:
-
Unbenannt.png
26 KB
Um das Thema abzuschließen möchte ich noch folgendes mitteilen: Ich habe bezüglich diesem Thema noch eine Menge gegooglet und 'gespielt'. Aus den Google-Ergebnissen wurde ich persönlich nicht sonderlich schlau, das überschreitet alles noch meinen aktuellen Kenntnisstand, aber was ich rausgefunden habe war, dass das Programm und der IR-Empfang immer stabiler und 'besser' wurde, je tiefer ich den OSCCAL-Wert in de rtimer.h angesetzt habe. Irgendwo bei ca 135 lief das ganze dann so, dass ich es als 'perfekt' empfunden habe. Irgendwann habe ich dann einfach mal die komplette OSCCAL rausgenommen und siehe da, so einfach kann es laufen - voila! Zufällig bin ich dann über den 'Advanced'-Reiter im AVR-Studio -> AVR-ISP-Mode gestolpert und habe einfach mal auf 'read' geklickt. (Siehe Anhang) Dort spuckt mir mein Atmega48 den Wert "0x8A" aus, der Dezimal "138" ist, was auch mit meiner 'Versuchsreihe' überein stimmt, in der ich auf ~135 kam. Wenn ich also richtig verstehe steht die Standard-Kalibrierung MEINES Atmega48s auf 138 - der Atmega48 des Programmentwicklers stand wohl auf 167 (dem Kommentar nach zu urteilen). Beim Entwickler lief die 167 zu schnell, weshalb er auf 158 'feinjustierte'/drosselte. Bei mir ist 158 immer noch deutlich zu hoch, weil der Standard bei 138 liegt (womit auch alles exzellent läuft). Was mir jetzt noch unbegreiflich ist: Scheinbar haben verschiedene µCs des gleichen Modells unterschiedliche 'Grundkalibrierungen' für den internen OSC. Wenn dem so ist, ist die Funktion doch reines Glücksspiel, wenn jemand ein Programm für einen Atmega XYZ entwickelt und den Code (oder sogar nur die *.hex) öffentlich zur Verfügung Stellt. Wenn jemand das Projekt 'nachbaut' und den µC einfach nur flasht ohne am OSCCAL zu drehen (sofern ein OSCCAL gesetzt wurde), ist die Wahrscheinlichkeit, dass die Kalibrierung mit der des Entwickler-µCs übereinstimmt, ja äußerst gering. Kurzum ist es bei 'öffentlichen' Projekten, in denen eine Feinjustierung des internen Oszillators vorgenommen wird äußerst ratsam den kompletten C-Code zu veröffentlichen und nicht nur die fertige *.hex. Oder sogar die OSCCAL komplett weg zu lassen und mit der +/-10% Ungenauigkeit des internen OSC zu leben. Verstehe ich das richtig oder habe ich mich gedanklich irgendwo vertan?
FoFi schrieb: > Was mir jetzt noch unbegreiflich ist: Scheinbar haben verschiedene µCs > des gleichen Modells unterschiedliche 'Grundkalibrierungen' für den > internen OSC. Der 'interne Oszillator' ist nichts anderes als ein RC-Glied. Also ein Widerstand und ein Kondensator. Sowohl der Widerstand hat Fertigungstoleranzen als auch der Kondensator. OSCCAL hat meines Wissenes keine Einheit. Das ist einfach nur ein Wert von (ich glaube)0 bis 255, mit dem der Schwingkreis verstimmt werden kann. Höhere Werte machen ihn schneller, kleinere Werte machen ihn langsamer. > Wenn jemand das Projekt 'nachbaut' und den µC einfach nur flasht ohne am > OSCCAL zu drehen (sofern ein OSCCAL gesetzt wurde), ist die > Wahrscheinlichkeit, dass die Kalibrierung mit der des Entwickler-µCs > übereinstimmt, ja äußerst gering. Ja, das ist in der Tat etwas unglücklich gemacht. Solche Dinge müssen laut und deutlich kommuniziert werden. > Kurzum ist es bei 'öffentlichen' Projekten, in denen eine Feinjustierung > des internen Oszillators vorgenommen wird äußerst ratsam den kompletten > C-Code zu veröffentlichen und nicht nur die fertige *.hex. In der Realität schreibt der Programmentwickler dem Nachbauer vor, wie schnell sein µC zu takten hat. Und der Nachbauer muss sehen, wie er das macht. D.h. im Regelfall lässt man bei einer Veröffentlichung das OSCCAL komplett in Ruhe - das taucht da im Code gar nicht auf. Eben WEIL jeder einzelne µC seinen eigenen Wert braucht um dann einigermassen exakt mit 1Mhz zu arbeiten.
FoFi schrieb: > Ursprünglich stand der OSCCAL auf 158 Ein fester Wert im Code ist ganz schlecht, stimmt eben nur für einen MC. Ältere AVRs haben das OSCCAL nicht automatisch mit der Werkseinstellung gesetzt. Als Würg-Around stand der Wert auch auf der letzten Flash-Adresse, da konnte man ihn auslesen. Nach dem ersten Löschen ist er jedoch futsch. Die neueren AVRs laden ihn aber automatisch, also Finger weg vom OSCCAL! Peter
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.