Funken mit dem Attiny

Hier können Sie ihre eigenen Projekte vorstellen
Antworten
Heinrichs
Beiträge: 185
Registriert: Do 21. Okt 2010, 18:31

Funken mit dem Attiny

Beitrag von Heinrichs » Fr 30. Dez 2011, 18:32

In diesem Beitrag wollen wir zeigen, wie man eine Funkverbindung zwischen zwei Computern aufbauen kann. Dabei benutzen wir den Transceiver-Baustein rfm12. Dieser Baustein ist in der Lage, zu senden und zu empfangen - und dies über eine Strecke von bis zu 100 m. Er ist preisgünstig: Bei Pollin kostet er z. Zt. 4,95 Euro. Leider ist die mitgelieferte Anleitung sehr knapp gehalten, und die Original-Manuals von HopeRF sind für den Einsteiger eine recht schwere Kost, beschränken sie sich im Wesentlichen doch auf die Beschreibung der einzelnen Kontrollbits. Und davon gibt es sehr, sehr viele!

Hier soll auch keine Luxus-Funkverbindung vorgestellt werden; vielmehr kommt es uns darauf an, die wesentlichen Grundzüge aufzuzeigen. Auf diesen aufbauend kann dann der Leser selbst Verbesserungen nach eigenen Vorstellungen vornehmen.

funkuebertragung.jpg
Funkübetragung mit zwei rfm12-Modulen
funkuebertragung.jpg (64.71 KiB) 22110 mal betrachtet

Die Abbildung zeigt, wie die Verbindung aussehen soll: Beide PCs sind über ein COM-Kabel (oder USB-COM-Kabel) jeweils mit einer Attiny-Platine verbunden; an diese wiederum ist ein rfm12-Modul angeschlossen. Der Sende-PC schickt über ein Terminal-Programm einen Datenstrom (bei uns maximal 10 Byte) an den Attiny. Der Mikrocontroller sendet die Informationen an das angeschlossene rfm12-Modul; dieses muss natürlich als Sender konfiguriert sein. Die Kommunikation zwischen Attiny und rfm12 erfolgt dabei über das SPI-Protokoll. Das Sende-Modul sendet die Daten in so genannten Paketen (s. u.) aus. Diese werden von dem zweiten rfm12-Modul, welches als Empfänger eingestellt ist, aufgenommen und von dem zweiten Attiny abgefragt. Der wiederum gibt die empfangenen Bytes über die COM-Schnittstelle an das Terminal-Programm auf dem Empfangs-PC weiter, und so haben wir letztlich eine Funkverbindung zwischen den beiden PCs. Natürlich könnten wir auf Sender- oder Empfängerseite auch auf einen PC verzichten und die Mikrocontroller selbstständig arbeiten lassen. Für unsere einführenden Betrachtungen wäre das aber nicht so sinnvoll.

Der ausführliche Beitrag im Anhang behandelt folgende Themen:
  • Der Attiny2313 als SPI-Master
  • Anschuss des rfm12-Moduls an die Attiny-Platine
  • Funktionsweise und Ansteuerung des rfm12-Moduls
  • Das Sendeprogramm
  • Das Empfangsprogramm
  • Die rfm12-Module im Betrieb
  • Funkempfänger mit LCD
Dateianhänge
funken.zip
Ausführlicher Beitrag zum Funken und zugehörige BASCOM-Programme
(833.01 KiB) 2621-mal heruntergeladen
Zuletzt geändert von Heinrichs am Sa 18. Feb 2012, 12:21, insgesamt 1-mal geändert.

RedBaron
Beiträge: 1
Registriert: Fr 10. Feb 2012, 12:07

Re: Funken mit dem Attiny

Beitrag von RedBaron » Di 14. Feb 2012, 22:24

Hallo!

Ich studiere nun schon seit einiger Zeit den Code und kommen nicht ganz klar.

Als erstes ist der Code im PDF und in den .bas-Dateien nicht identisch. Im PDF wird DDRB im Hauptprgramm, in der .BAS-Datei jedoch in der Routine SPI() initialisiert. Bei der initialisierung in SPI() liegen, da PORTB zunächst komplett als Output konfiguriert wird, kurzzeitig zwei Ouput-Pins aneinander (PB5 und SDO vom rfm12). Je nach Potential an den Pins gibt das einen Kurzschluss.

Als zweites ist mir die Initialisierung von DDRB/PORTD suspekt. Die PINS sind nicht belegt / benutzt. Habe ich hier etwas übersehen?

Viele Grüße
RedBaron

Heinrichs
Beiträge: 185
Registriert: Do 21. Okt 2010, 18:31

Re: Funken mit dem Attiny

Beitrag von Heinrichs » Sa 18. Feb 2012, 12:33

Hallo RedBaron,

der in der PDF-Datei angegebene Souce-Code weicht tatsächlich hinsichtlich der Festlegung von DDRB von den beigefügten BAS-Dateien ab. Sorry, da war bei den BAS-Dateien eine Änderung stehen geblieben, die mit den Versuchen zu tun haben, dem im Text erwähnten Konflikt USI-LCDisplay auf die Spur zu kommen. Ich habe die BAS-Dateien in funken.zip entsprechend korrigiert.

Die auf den ersten Blick merkwürdige Initialisierung von Port D ist darauf zurückzuführen, dass das Programm für die im Programm-Kommentar angegebene Attiny-Platine geschrieben ist. Bei dieser Platine sind einige Anschlüsse von PortD standardmäßig mit Tastern verbunden.

Viele Grüße

G. Heinrichs

Antworten