http://avrhelp.mcselec.com/index.html?getrc5.htm
Hier ist der IR Empfänger an PinD.2 vom AtTiny 2313 angeschlossen, dies ist ein Interrupt Anschluss, also kannst du die 6PWM Channels problemlos nutzen.
Und ein Timer wird in den Programmen auch nicht gestartet.
Hi,
wenn Du es einfach haben willst und die Funktion von Bascom z.B. für den RC5 Empfang benützt, dann ja, dann hast nur noch 4 PWM Kanäle. Wenn die IR Empfangroutine selbst schreiben kannst, egal ob mit Bascom, C oder ASM, dann kannst eventuell auch irgendwie alle 6 PWM Kanäle verwenden.
Gruß, Benny.
http://avrhelp.mcselec.com/index.html?getrc5.htm
Hier ist der IR Empfänger an PinD.2 vom AtTiny 2313 angeschlossen, dies ist ein Interrupt Anschluss, also kannst du die 6PWM Channels problemlos nutzen.
Und ein Timer wird in den Programmen auch nicht gestartet.
Das ist so nicht richtig. Wenn man die RC5 Routine von Bascom nutzt, dann kann man zwar den Timer0 Interrupt noch nutzen, aber mehr auch nicht. Die Zeiten des Timers und der Modus ist fest vorgeschieben. Und da er somit nicht den Timer als Timer sondern als PWM braucht, geht das nicht so einfach.
Gruß, Benny.
Das ist so nicht richtig. Wenn man die RC5 Routine von Bascom nutzt, dann kann man zwar den Timer0 Interrupt noch nutzen, aber mehr auch nicht. Die Zeiten des Timers und der Modus ist fest vorgeschieben.
Das ist auch das Problem bei allen Routinen, die man im Netz so findet, und die vorgeben, der Timer wäre noch anderweitig nutzbar - ist er ja auch, aber eben nur mit Einschränkungen...
ich bin jetzt auch nicht der ultra-geniale sw-fuzzi, aber sehe da irgendwie leider keine echte Möglichkeit - was soll der Controller denn können...? - wenn nur Befehle empfangen und dann ne Farbe einstellen, sollte es so gehen:
die HW-PWM läuft einfach, die belastet die CPU ja nicht - der µC wartet auf einen Flankenwechsel... dann arbeitet er einfach eine Warteschleife ab, und schaut nach ner bestimmten Zeit nach, ob der Pin immer noch "high" ist - wenn ja, ist das Bit ne "1", wenn nein, dann ne "0"
und das so lange, bis ein gültiger Befehl empfangen wurde - der wird dann ausgewertet, und die Farbe entsprechend eingestellt, dann wird auf den nächsten Befehl gewartet...
der µC steckt da halt die meiste Zeit in Warteschleifen fest, kann also nix anderes mehr machen ausser RC5 empfangen - evtl. noch in nem Timer-Interrupt (*der* geht ja zusätzlich zur HW-PWM) irgendwie Rainbowfader etc. - darf dann aber nicht zu lange dauern, damit beim RC5-Empfang keine zu großen Toleranzen entstehen...
"schön" programmiert ist das dann nicht, und in Bascom geht's auch nicht, weil Du da *genau* wissen musst, was wie lange dauert - also Assembler und Takte abzählen... 
Muss es denn Bascom sein? Ob das Problem in C mit Hardware-PWM lösbar ist, weiß ich nicht. Aber auf jeden Fall verwendet die RC5-Routine bei mir auch einen Timer. Bleibt aber alternativ immer noch Software-PWM. In meinem MoodLight habe ich 12 Kanäle in Verwendung. Das sollte Dir auch genügen. Und für die Fernbedienung steht Dir alles offen.
Das hat nix grundsätzlich mit Bascom zu tun. SW PWM geht auch in Bascom und ASM kann man auch jederzeit in Bascom einfügen. Bascom ist hier nur der Compiler für das "Einfache".
Man könnte doch auch einen Tiny, 8 DIP, nur als RC5 Empfänger missbrauchen und diesen nur den Code zum "Hauptcontroller" schicken lassen. Dann wäre der Controller komplett vom RC5 Empfang getrennt.
Gruß, Benny.
Hi,
Im Prinzip ist es schon möglich, ich habe das bei diesem Projekt hinbekommen das Timer 1 mit 10BIT / 1220 Hz HW-PWM gearbeitet hat und gleichzeitig die Zeitbasis für die IR-Dekodierung liefert (NEC-Protokoll). Die PWM ist dabei etwas zu schnell für den ZXLD1366, so dass nicht wirklich 1024 unterschiedliche Dimmstufen dargestellt werden können aber ich rechne das intern einfach in 256 um und das geht dann wieder und ist auch völlig analog zu den 2 8-Bit Timern, die ja auch nur 256 Stufen liefern.
Daraus resultieren also 6 HW-PW Kanäle mit 8-Bit Auflösung und die IR Dekodierung wird nebenbei gemacht, wobei ich sagen muss, dass das Zeitraster welches von Timer 1 neben der PWM generiert wird gerade noch ausreicht um damit die IR Signale sicher zu empfangen, wobei die PWM Frequenz den Regler fast schon überfordert.
Ich habe ziemlich lange herumprobiert (Vorteiler/PWM Modi) damit es bei 20 MHz Basistakt einwandfrei funktioniert. Je höher die PWM Frequenz sein kann -ohne den Regeler oder was auch immer zu überfordern - desto einfacher wird es den Timer so einzusetzen, das PWM und IR gleichzeitig möglich sind.
lg Sol.
Deshalb nur nen Tiny, nen 2. ATMEGA wäre wohl etwas übertieben. Aber so nen kleinen 8-Pin Tiny wäre ok. Das Problem ist eben, wie es Pesi schon sagte, das wenn die PWM per Software machst oder eben die IR Auswertung selbst schreibst, das dies sehr zeitkritisch werden kann. Also der Atmega kann dann kaum mehr was anderes nebenher machen. Wenn aber so nen kleiner 8-Pin Tiny den IR Empfang übernimmt, dann hast den Atmega wieder frei für alle andere Sachen.
Schau Dir da z.B. mal meinen Eiwomisa an, KLICK , der macht so viel nebenher das da kein IR Empfang mehr möglich wäre ohne diesen Timer bzw. ohne den Interrupt für die RC5 Routine. Ich war ja schon froh das damals mit dem RC5 per Interrupt hinbekommen zu haben damit der während seiner Arbeit keinen IR Befehl "verpasst".
Gruß, Benny.
Hi Wurzel,
Ich werde nacher mal code Posten, der zeigt, daß HW-PWM + IR + Interrupt gleichzeitig möglich ist, ohne den uC stark zu belasten. Das ist jedoch alles in 'C', ich hoffe Du kannst damit dann was anfangen ...
I
lg Sol
Das Problem ist eben, wie es Pesi schon sagte, das wenn die PWM per Software machst oder eben die IR Auswertung selbst schreibst, das dies sehr zeitkritisch werden kann.
Naja, von SW-PWM habe ich gar nix geschrieben... - da hatte ich gar nicht dran gedacht, den Wald vor lauter Bäumen nicht gesehen... 
- in Assembler oder C wäre das kein Problem, die 6 Kanäle, in Bascom kann's (bzw. wird es) dann natürlich vorkommen, dass er da zu lange in der ISR steckt und so ein Bit verpasst...
Sol: ist das ein Tippfehler, oder ist das bei Dir wirklich NEC-Protokoll...? - weil hier geht's ja um RC5... - müsste man mal ausrechnen, evtl. geht's bei RC5 ja sogar mit ner geringeren PWM-Frequenz so dass man trotzdem ein passendes "Raster" für die IR-Dekodierung findet...
Yes pesi,
Ist das NEC (Extended) Protokoll, habe jetzt 3 FB getestet und alle sprachen NEC bzw NEC-Extended (auch die RGB FB hier aus dem Shop). Das Zeitraster ist ~ 1/2000 Sekunden und die ISR macht nicht weiter als eine Wert Hochzuzählen. Die IR Interrupt ISR macht dann den Rest. Und das Hauptprogramm verarbeitet das Kommando...
lg sol.
Also man soll doch BASCOM nicht schlechter reden als es ist . Es ist von der Geschwindigkeit und von generierten Code her mindestens so gut wie auch die üblichen C-Compiler. Man muss nur wissen, wie man was macht und nicht immer nur stur die vordefinierten Funktionen und Config-Befehle verwenden. Das Datenblatt-Lesen sollte man auch als BASCOM-Programmierer nicht verlernen und im Zweifelsfall lieber die Register direkt entsprechend setzen, als sich blind immer auf die jeweiligen Config-Befehle zu verlassen. ISRs sind in BASCOM auch ohne automatische Register-Sicherung machbar (also auch ohne entsprechenden Overhead), wenn man in der ISR dann selbst die verwendeten Register sichert. Und das geht sogar dann, wenn man BASCOM-Befehle in der ISR nutzt. Man muss nur vorher im Simulator testen (ja, das kann man), welche Register die ISR-Routine (bzw. der entsprechende Code-Abschnitt) verwendet. Nichtsdestotrotz ist es sicherlich zu empfehlen, eine ISR und generell auch zeitkritische Code-Abschnitte in Assembler zu schreiben, weli man nur so die absolute Kontrolle über das genaue Timing hat (gilt im Übrigen aber auch für C- und alle anderen Hochsprachen-Compiler). Und gerade was Assembler angeht, so bietet BASCOM eine sehr gute und einfach anwendbare Implementation von Inline-Assembler (Assembler gemischt mit BASCOM-Basic in der gleichen Datei) an, was man zum Bsp. von AVR-GCC nicht behaupten kann. Auch kann man in Assembler-Codeabschnitten in BASCOM sehr einfach auf in BASCOM-Basic definierte Variablen zugreifen etc. Man kann in BASCOM also sowohl hocheffizienten als auch hochkomplexen (wenn man zum Beispiel komplexe Fliesskommaberechnungen benötigt) Code schreiben, wenn man weiss wie bzw. wo man welche Methodik anwenden muss. Aber ich denke, das ist bei jedem Compiler so, den man verwendet. Man wird erst dann richtig guten Code damit schreiben können, wenn man das Tool auch beherrscht, was man verwendet, seine Stärken und Schwächen kennt und somit auch weiss, wie man was am effizientesten bewerkstelligen kann. In BASCOM werden einem diesbezüglich (Verwendung von Assembler) zumindest keine unnötigen Steine in den Weg gelegt.
So, das war jetzt etwas o.T., weil's mich grad in den Fingern gejuckt hat , doch jetzt zum Thema:
Wenn man den Timer1 für die PWM-Generierung und auch als Zeitbasis verwenden will, dann sollte man den Phase-Correct-Modus (generell für Dimm-Anwendungen immer) und als TOP-Wert das ICR1-Register verwenden. Der Vorteil dabei ist, dass dann sowohl bei TOP als auch bei BOTTOM ein Interrupt ausgelöst werden kann, bei TOP der ICR1-Compare- und bei BOTTOM der Timer-Overflow-Interrupt (im Phase-Correct-Modus zählt der Timer ja rauf und runter). Worauf ich hinaus will, ist folgendes: man kann dann für die PWM-Frequenz auch deutlich tiefere Werte einstellen, also z.Bsp. auch ca. 150 Hz bei 8 Bit PWM. Der Timer1 zählt ja dann mit 512 x 150 = ca. 77 kHz, was einem Vorteiler von 256 bei 20 MHz Takt entsprechen würde. Mit 77 kHz hat man eine genügend hohe Zeitauflösung für die meisten IR-Protokolle. "Ok, aber wie soll das gehen?", höre ich da einige Stimmen . Nun, man definiert noch einen Flanken-Interrupt für den IR-Demodulator-Eingang und liest in der entsprechenden ISR jeweils den aktuellen Timer1-Wert aus (und speichert den in eine Variable etc.). Zwischen zwei Flanken-Interrupts zeichnet man jeweils die Reihenfolge (und Anzahl, falls es ein lahmes IR-Protokoll ist ) der TOP- und BOTTOM-Interrupts auf (in den jeweiligen ISRs). Aus der unter Berücksichtigung der Reihenfolge der TOP- und BOTTOM-Durchläufe ermittelten Differenz der Timer1-Werte von zwei Flanken kann man dann die entsprechende Dauer in Timer1-Zähltakt-Einheiten bestimmen. Somit liesse sich dann eine IR-Pulssequenz entsprechend dekodieren, wenn man das Protokoll kennt. Man muss allerdings dazu sagen, dass so ein Verfahren für einen Anfänger möglicherweise nicht leicht umzusetzen ist, zumal man hier zumindest die ISRs sicher in Assembler (Inline-Assembler in BASCOM) schreiben müsste.
Gruss
Neni
ah, OK - NEC-Protokoll sollte aber etwas leichter auszuwerten sein, weil die Bits ja hier durch variable Pulslängen kodiert werden...
sehe ich das richtig, dass Du das so machst: der Zähler in der ISR zählt einfach alle 1/2000 sek (= 0,5 ms) eins hoch - immer beim Überlauf, also hast Du auch ne PWM-Frequenz von 2000 Hz..?
wenn nun ne positive Flanke kommt, springst Du in ne ISR, diese speichert den Zählerstand ab, und vergleichst den aktuellen mit dem zuletzt gespeicherten - ist dieser Unterschied z.B. kleiner als 3 (also 1,5 ms zwischen 2 Flanken, wird oft als "Schwelle genommen), dann ist's ne "0", ist er größer als 3 ist's ne "1"...?
da könntest Du das doch auch so machen, dass Du den Zählerstand des Timers selbst abspeicherst - dann kann der Timer auch langsamer laufen und damit niedrigere PWM-Frequenz...
bei dem langen Impuls für den Start kann dann natürlich der Timer-Zähler öfter überlaufen, aber da kann man ja noch zusätzlich nen eigenen mitlaufen lassen...
EDIT: oh, da hat jetzt Neni schon das selbe gesagt...
wie das dann bei RC5 genau gehen soll, da müsste ich auch überlegen, weil da muss man ja auch den Flankenwechsel auswerten... NEC ist einfacher, etweder diese Länge oder jene Länge zwischen zwei positiven Flanken...
Noch mal EDIT: und, klar, wenn sol phasenkorrekte PWM hat und immer beim Überlauf auslöst, ist's ja dann ne PWM-Frequenz von "nur" 1000 Hz, richtig...? - da komme ich immer durcheinander, weil ich HW-PWM höchst selten benutze...
im übrigen wollte ich auch nicht auf Bascom "rumhacken" oder sowas, ich war nur der Meinung, dass das Ganze *rein in Bascom*, also ohne Inline-Assembler o.ä. doch etwas schwierig werden dürfte, vom Timing her...?
