RC5 Senden mit Attiny13

Hallo zusammen,

also der Tiny2313 schafft das locker. Habe für Sohnemann eine Fernsteuerung für seine Fahrzeuge damit gemacht. ATTiny mit internem 4MHz Oszillator.

Es werden 8 Schalter eingelesen und mittels RC5 übertragen. Trägerfreq. wird von Timer1 erzeugt, Timer0 schiebt dann die Bits raus.

Die IR-Diode hängt dabei zwischen zwei Port-Pins.

Das ganze wird bei nicht gebrauch in den Power-Down-Mode versetzt und bei betätigen der Taste an INT0 wieder gestartet.

Über den Timer0 wird auch die Wartezeit von 155ms für das Senden der RC5-Telegramme gemacht.

Habe dummerweise keinen Zugriff auf meinen Server :cry:, sonst könnte ich den Code einmal posten.

Wenn nichts weiteres dazwischen kommt, bin ich heute Abend wieder daheim und kann den Code einmal einstellen.

Grüße

Serwus gummirte ente

Das es ein 2313 schafft is mir schon klar, der quellcode von dir wäre trotzdem interessant.


Wir möchten das ganze auf einen Attiny13 machen um Platz zu sparen!

Mfg Harry

Zu Mic,

Deine Bemühungen zu Timer1 finde ich interessant, aber der Tiny13 hat leider keinen Timer1. (Timer1 16Bit, Timer0 8Bit) ---> sofern ich das richtig verstanden habe!

Zu Gummiental,

Powerdown benötige ich nicht, der sender soll pausenlos senden, Spannungsversorgung wird ein EmpfängerAkku mit min. 1500mAh, das sollte schon eine Zeit reichen..... ;-)

Mfg
Harry

Zu Mic,

Zur Codierung, bzw. Welches bitmuster ich ausgeben möchte, mir würde ein bitmuster für den tiny reichen, da es 10 verschiedene Sender werden und jeder sollte ein anderes Muster verschicken....

Wenn ich das richtig verstanden habe kann man ja bis zu 64 verschiedene Befehle mit "normalen" rc5 bitmuster erzeugen.

Mfg
Harry

Hallo X1CR,

sollte auch mit dem Tiny13 gehen, dann halt den Timer auf 72kHz laufen lassen und im Timer-IRQ, Ausgang toggeln,

wenn was gesendet werden muß. Der Tiny 13 hat ja auch 1kB, sollte dicke reichen.

Grüße

Serwus Gummi Ente kannst ruhig Harry schreiben...... ;-)

Mit dem Programmieren hab ich es noch nicht so,toggeln usw.... muß mich noch einlesen, ist mein erstes Projekt!

Mfg

Harry

Hallo

Ihr müßt schon lesen, was geschrieben wurde, auch wenn es recht viel Text ist. Hier mal eine Zusammenfassung der offenen Punkte:

- Warum ein tiny13? Weil er sehr klein ist und uns der Ehrgeiz gepackt hat.

- Wieviel können die Ports treiben? Laut Datenblatt 50mA.

- Der Tiny13 hat doch nur einen Timer0? Genau, aber der kennt den CTC-Mode mit zwei Kanälen. Kanal A: Trägerfrequenz per OC0A(Pin5), Kanal B: Bits senden per ISR.

- Trägerfrequenz sollte laut dem Startposting 38kHz sein, also müssen wir mit 76kHz toggeln. (Kann man aber später auch locker auf 36kHz anpassen)

- Mit Codierung meinte ich, alle tinys bekommen das selbe Programm und erkennen über Brücken/Jumper an den freien Pins ihre eigene ID und senden dann einen ihnen zugeordneten RC5-Code. Wenn wir den Reset-Pin auch verwenden, wären vier Pins zur Codierung=16 verschiedene IDs möglich.

- Warum bascom? Weil das die Vorgabe von X1CR/Harry ist und ich das mal versuchen wollte. (Mit C wäre es für mich bei meinem jetzigen Kentnissstand wohl kein Problem obwohl ich auch noch newbie bin)

Ich hoffe, hiermit die wesentlichsten Unklarheiten geklärt zu haben. Zurück zum Projekt (das wohl übers Ziel hinausschiest, den eine "Zeitnehmung für eine Mini-Z-Bahn" könnte man wohl auch einfacher realisieren). Ich möchte euch mal ein paar Gedanken dazu zur Diskussion anbieten:

Als Versorgungsspannung hatte ich eine 4*1,2V-NI-MH-Akkuspannung erwartet. Das sind bei vollen Akkus nahezu 5,5V, sehr kritisch für den tiny13, der nur bis 5,5V abkann. Sicherheithalber sollten wir eine Diode vorschalten und deren 0,7V Spannungsabfall nutzen.

Der Vorwiderstand für die IR-LED sollte halbweg genau passen. Da wir den genauen Typ der Diode nicht kennen, würde ich vorerst einen Strom von ca. 30 mA vorschlagen. Um den Spannungsabfall (ich tippe mal auf ca. 1,5-2V) an der Diode zu messen, müssen wir sie mit einem Testwiderstand (150-200Ohm?) an ein Akkupack hängen und die Spannung an der LED messen. Der endgültige Widerstand würde sich dann so berechnen lassen: (U_akkupack - U_led) / 30mA

Bei (gepulsten!) 30mA wäre noch etwas Power für eine kleine 3mm-LED übrig die wir über einen eigenen Widerstand mit ca. 10-15mA zusätzlich zwischen Datensendepin und GND zur Sendekontrolle anschliesen könnten. Alternativ wäre auch ein eigener Pin möglich, aber dann würden wir einen Codierpin verschenken.

Man könnte auch mehrere Jumper über eine Widerstandsmatrix mit dem ADC auswerten oder auf die Codierung komplett verzichten. Dann müste man aber jeden tiny inividuell programieren oder eine Kennung ins EE-Prom schreiben. Jumpern ist bequemer und fexibler)

Als Grundlage für die folgenden Programmvorschläge dient die bascom-Doku. Dort steht u.A.:

Zitat:

---

Notice that the Help was written with the AT90S2313 and AT90S8515 timers in
mind.

---

(Das bedeutet grob übersetzt: Als Grundlage für die Beschreibung der Timer dienten die AVRs AT90S2313 und AT90S8515)

Deshalb stimmen die Zuordnungen der Timer nur bedingt, weil der tiny13 nur einen 8Bit Timer besitzt. Dieser hat aber einige Funktionen die bei den größernen AVRs für die 8-Bit-Timer nicht verfügbar sind. Unter anderem eben die 2-kanalige CTC-Funktion mit Interrupt und direkter Pinsteuerung. Das macht der Timer teilweise selbstständig und ist für unsere Anwendung optimal. Das kann man alles dem Datenblatt entnehmen, den Link habe weiter oben schon gepostet.

Kurze Einführung in den CTC-Mode (wie ich es als Timer-Laie verstanden habe, der Absatz kann von "Profis" übersprungen werden):

Der Timer0 verfügt über zwei Zählregister OCRA und OCRB die mit dem per Prescaler eingestellten Takt heruntergezählt werden. Für beide Register gilt folgende Funktion:

- das Register kann mit einem beliebigen 8-Bit-Startwert geladen werden
- Wenn das Register den Wert null erreicht wird das Register wieder mit dem Startwert geladen.
- Gleichzeitig kann ein Interrupt ausgelöst werden.
- Gleichzeitig kann ein zugordnerter Ausgang umgeschaltet werden(1 wird zu 0 oder 0 wird zu 1. Das nennt man eben toggeln)

Die Anwendung des Timers auf unsere Aufgabenstellung plane ich nun so:

Ein Zählregister erzeugt (vorerst kontinuierlich) die 38kHz-Trägerfrequenz. Dazu wird der Timer0 im CTC-Mode gestartet und schaltet direkt den OC0x-Pin (x steht für A oder B) an dem die Kathode der LED angeschlossen ist. Der Wert für das entsprechende OCRx-Register ergibt sich aus der Taktfrequenz des Kontrollers, aus dem Prescaler und der geforderten Umschalt-Frequenz (zweimal umschalten ergibt eine Periode, deshalb:) 76kHz. Weiter oben habe ich diesen Wert schon mit ca. 126 bestimmt. Wenn das alles funktioniert, sollte man am entsprechenden Pin die 38kHz messen können.

Das andere Zählregister soll die Zeitbasis für die RC5-Bits erzeugen, das sind dann die 0,889ms die ein halbes RC5-Bit dauert. Das Problem dabei ist, dass dieses Register mit dem selben Takt heruntergezählt wird wie das andere Register, also viel zu schnell. Die Lösung ist eine ISR und eine (bzw. 2) 16-Bit Zählvariable die den Aufruf der ISR mitzählt. Um möglichst wenige Interrupts auszulösen sollte der Wert für das OCRx möglichst groß, gleichzeitig aber auch angenehm zum Rechnen sein. Bei 192 hätten wir bei 9,6MHz genau 50000 Aufrufe pro Sekunde (und maximal 192 Takte für die ISR!), das sind dann 1/50000 oder 0,02ms. Soweit, sogut. aber wo sind nun die 0,889ms? Die müssen wir mit einer zweiten 8-bit-Variablen erzeugen: 0,899ms/0,02ms=44,5 also 44 für das zweite OCRx.

Wenn wir nun unsere Daten senden wollen sieht das etwas so aus:

- Ports auf Ausgang schalten
- Timer starten, OCRx mit 126 laden -> Trägerfrequenz wird am 38kHz-Pin ausgegeben.
- Bitnummer auf 1 setzen.
- 16-Bit Zählvariable mit 49999 laden.
- 8-Bit Zählvariable mit 44 laden.
- Interrupts erlauben und zweites OCRx mit 192 laden -> ISR wird alle 1/50000 aufgerufen.

Schleife:
- Nach Manchestercodierung für Datenbit[Bitnummer] den Datenpin für erstes Halbbit setzen.

- Ab jetzt übernimmt die ISR die Kontrolle während wir im Hauptprogramm warten bis das erste Halb-Bit gesendet wurde:

- 16-Bit Zählvariable decrementieren bis 0, dann 8-Bit Zählvariable decrementieren und 16-Bit Zählvariable wieder mit 49999 laden. Das Ganze solange wiederholen bis 8-Bit Zählvariable auch 0 ist.

- Das in einer Schleife wartende Hauptprogramm erkennt nun , das die 8-Bit Zählvariable null ist. Zuerst werden nun wieder die 16-Bit Zählvariable mit 49999 und die 8-Bit Zählvariable mit 44 geladen (der Timer läuft ja im Hintergrund weiter), dann der Datenpin umgeschaltet.

- Anschließend wird wieder gewartet, bis das zweite Halbbit gesendet ist. Gleicher Ablauf in der ISR bis das Hauptprogramm erkennt, das die 8-Bit Zählvariable wieder 0 ist. Dann wird die Bitnummer inkrementiert und das Spielchen ab Schleife: wiederholt bis alle Bits gesendet wurden. Ächz, jetzt noch die beiden OCRs auf 0 setzen, Timer stoppen und Pins auf Eingang (quickunddurty). Fertig.

(Eigentlich sollte das viel einfacher funktionieren, denn die Bitlänge des RC5-Codes entspricht bei 36kHz genau 1/64 der Trägerfrequenz. Bin ich auf dem falschen Weg?*kopfkratz*)

So, das ist es, was man programmieren sollte. Ob die OCRx-Werte so stimmen kann ich noch nicht sagen. Ob die ISR kurz genug wird oder ob sich der tiny13 dabei ins Nirwana verabschiedet weiß ich auch noch nicht. In C könnte ich das jetzt direkt umsetzen, in bascom wirds noch etwas dauern. Viel Spaß bei verdauen.*grins*

Gruß

mic

Serwus Mic

Da hab ich als Newbie einiges zu verdauen!

Werd mal gucken ob ich die 38kHz hinbekomme....

Wie ist das mit dem dritten Bit, sollte der nicht immer wechseln?




Mfg Harry

Zu, Mic....

Kann leider nicht überprüfen ob ich 38kHz habe.... SoftwareOszi kann nicht einmal 19kHz fehlerfrei darstellen..... :-(

Bis bald,

Mfg Harry