rc5send und getrc5

[for_ro]

allerdings wollte ich das nicht so machen (das ist für mich persönlich wirklich die letzte wahl) ...

Wieso nicht? Hast du keine Pins mehr frei oder brauchst du mehr Strom?
Du kannst natürlich auch das komplette Signal (36KHz Träger + Nutzsignal) im µC erzeugen und dann auf einen Pin ausgeben, ist nur ein wenig mehr Aufwand.

genau, ich überprüfe die empfangenen daten vom tsop (command und adress) und wenn diese mit den eingespeicherten werte übereinstimmen, dann weiß der bot, dass da was ist

Dann darf aber während des ganzen Empfangs keine Unterbrechung kommen (z.B. hell-dunkel), sonst sind Ausgang und Eingang verschieden.
Wenn du dauernd hintereinander 101010 schickst, dann reicht auch ein kurzer Signaleingang zur Erkennung. RC5 ist dafür viel zu kompliziert.

kann überhaupt mit einem atmega32 ein signal senden und gleichzeitig empfangen (also DAS signal empfangen, welches auch der µC gesendet hat)?!??!?!

Das ist auch ein Grund warum ich kein RC5 nehmen würde. De Erzeugung und Auswertung ist zu aufwändig.
Wenn du die Ausgabe und die Auswertung über einen Timer machst, denke ich schon, dass das ein AVR hinbekommt. Ich würde das etwa so machen:
Du hast einen Timer, der mit etwa 72KHz läuft (36KHz * 2, kommt sich aber nicht so genau) und der den Ausgang toggelt, wenn dein Nutzsignal gerade high ist. Das Nutzsignal wird z.B. bei jedem 20sten Timer Aufruf getoggelt, ist also immer 10 Zyklen lang, somit 3,6KHz. Anschließend überprüfst du den Pin, an dem der TSOP hängt. Solange er low ist, inkrementierst du eine Variable. Ist er high, setzt du ein Flag, das in der Haupt-Loop ausgewertet wird. Dort vergleichst du den Wert z.B. mit dem Sollwert, setzt die Variable wieder auf 0 und setzt das Flag zurück.

Die 72KHz sind natürlich schon recht schnell. Vielleicht kannst du die Trägerfrequenz auch extern über einen NE555 oder so erzeugen. Dann brauchst du die Timer ISR nicht ganz so häfig aufzurufen. Vielleicht reichen dann auch 5KHz, wenn du das Nutzsignal etwas verlängerst.

Gruß

Rolf