Codebeispiel für Lesen von RC5 Code mit Interrupt-Routine

[Dirk]

Hallo -tomas-,

Das Tool berücksichtigt leider nicht die 52 Takte aus der PUSH-Orgie von 26 Registern (siehe Code oben)

1. Frage: Was hat die Berechnung der Timerwerte mit dem Sichern der Register bei der ISR (also auch mit der Länge des Codes in der ISR) zu tun?

2. Mit CALL und RETI sind es sogar je 57 Zyklen am Anfang und Ende jeder ISR!

Gruß Dirk

[-tomas-]

@Dirk
zu 1: wenn der Timer ein Prescale von 64 hat und Du erst ca. 60 Takte mit Push und andere Dingen verbrauchst, bevor Du den Timer mit

Timer0 = Timervorgabe

neu belädst, dann wäre eigentlich richtig

Timer0 = (Timervorgabe+1)   'Pseudocode

zu 2. Die Takte am Ende beeinflussen nicht mehr das Timing des Timers

@SprinterSB
wie ich schon sagte, es war nicht meine Absicht 1:1 zu programmieren.
Ich konnte es nicht besser (es war meine erste Begegnung mit WinAVR )
Das gut programmierter gcc-Code eher an ASM als an Bascom heranreicht ist unstrittig.

[Dirk]

@-tomas-:

Das Tool berücksichtigt leider nicht die 52 Takte aus der PUSH-Orgie von 26 Registern (siehe Code oben) und kommt dann
bei 8 Mhz auf Const Timervorgabe = 81 (anstatt 78 )...

... das hat mich als BASCOM-User noch weiter beschäftigt. Die Abweichungen gegenüber der "normalen" Berechnung von Timer-Startwerten sind ja teilweise gigantisch.

Ich habe da 'mal einen "Rechner" für Timer-Startwerte für Bascom in Excel geschrieben. Dabei bin ich von 53 Takten ausgegangen, die am Anfang jeder ISR für das Sichern der Register gebraucht werden.

Könntest du das 'mal testen und mir evtl. Fehler schreiben!?

Gruß Dirk

[roboterheld]

hallo, welche aufgabe hat eigentlich die : $lib "mcsbyte.lbx" ?

danke.

mfg

[roboterheld]

das heutige Bascom macht ungefähr 1,3kbyte , also knapp 300 byte mehr.
also ist schon ganz schön verschwenderisch geworden.

mfg

[roboterheld]

also bei mir funktioniert das obige neue originalprogramm ohne änderung.



mfg

[roboterheld]

....Const Timervorgabe = 846.....

ausserdem geht timer0 nur bis 255.

[flipp86]

hey leute.

sorry das ich diesen thread nochmal rauskrame, aber ich benötige genau diese rc5 funktion.
es klappt auch alles wunderbar wenn ich nen atmega16 nehme.

ich wollte aber 4 PWM kanäle benutzen und das glaub ich ging mit der funktion nicht, da der timer0 ja schon benutzt wird. jedenfalls hab ich es nicht hinbekommen.

deshalb, und weil ich sowieso eigentlich nen atmega88 benutze, wollte ich den code jetzt auf diesen übertragen.

eigentlich müsste doch auch alles gleich bleiben, bis auf das ich den regfile und den pin für den rc5 empfang anpassen muss oder ??

tue ich das, passiert aber leider nix mehr. der atmega88 läuft auch auf 8mhz, also müsste sich bei der Timervorgabe nix ändern.

hab ich was übersehen ?? hat jemand ne idee ??

mfg Flipp



EDIT: hat sich geklärt.
man muss natürlich das ClockDiv8-Fuse abschalten.
vielen dank an michael

[LIGHT_MASTER]

Moin...

Könnte mir jemand erklären warum das command_rc5 nicht wieder auf null gesetzt wird wenn die die Taste auf der FB los lasse bzw. wie ich es wieder auf null setzen kann?!


Vielen Dank...


LIGHT_MASTER

[Bumbum]

Hallo,

ich habe den oben genannten Code gerade versucht, leider (noch) ohne Erfolg.
Als µC habe ich einen ATTiny4313 mit einem 8Mhz Quarz. (Exakt 8000000Hz). Die Fuse mit dem Clock-Teiler um den Faktor 8 ist gesetzt.
Die Werte für den Timer müssten also gleich bleiben.
Es ändert sich beim drücken einer Taste auf der Fernbedienung auch die Werte Ir_bittimer und Ir_bitcount. Allerdings kommt der Wert Ir_bitcount nie über 3 Hinaus. (Mit folgender Erweiterung ermittelt: if (Ir_bitcount > Ir_bitcountMax) Ir_bitcountMax = Ir_bitcount;

Woran kann das liegen? Als Fernbedienung verwende ich eine von Technics zum Receiver SA-DX950. Auf der Fernbedienung steht EUR7702030. Laut Google müsste das eine RC5-Code-Fernbedienung sein.
Als Empfänger habe ich einen SFH5110-36 von Reichelt.

Wie kann ich den Fehler weiter eingrenzen?

Viele Grüße
Andreas