Dieses Programm steuert ein RFM12 Funkmodul an, und sendet/empängt einen
Datenblock einstellbarer Länge. Es ist keine Fehlerkorrektur oder
ähnliches vorhanden.
Die gesamte Hardwareansteuerung wird von der Software in der RF12.c
erledigt, ebenso das Ein/Ausschalten von Sender und Empfänger.
Man muss also nur das Modul initialisieren, die ganzen Parameter
einstellen und kann direkt senden oder empfangen.
Der Takt am CLK Pin ist auf 10MHz eingestellt, damit man damit z.B. den
AVR damit versorgen kann.
Um den Schaltungsaufwand klein zu halten, benutze ich nicht den
Interrupt Pin sondern Polle das Interrupt Bit im Status Register.
Dadurch kommt man mit nur 4 Pins aus (SPI + Chipselect). Da alles ohne
speziellen Hardwarefunktionen läuft, sollte die Software auf jedem AVR
(mit SRAM) lauffähig sein.
Der FSK/DATA/nFFS Pin muss über einen Pullup (z.B. 1-10k) an VDD gelegt
werden, damit alles richtig funktioniert. Alle anderen, in der Software
nicht aufgelisteten IO Pins des Moduls, werden auf Ausgang geschaltet
und brauchen daher nicht angeschlossen zu werden.

Die meisten der Einstellungen habe ich irgendwo in die Mitte gesetzt.
Für eine optimale Datenrate und Reichweite muss man mit Sicherheit noch
ein paar Details anpassen.

Der Grund wiso delay(100ms) nicht funktioniert:
Delay ist eine Schleife mit 16bit Zähler. Diese kann je nach CPU Takt
nicht länger als einige 10ms werden. Bei 20MHz sind daher nur 13,1ms
möglich.

Falls die Software nicht richtig laufen sollte: Eventuell muss die Delay
Zeit vergrößert werden, denn 100ms braucht das Modul nach dem
Einschalten bis es Befehle ausführen kann.

Die Datenblätter von den Modulen und die Beispielcodes sind nahezu
kompletter Mist.
Programmiert habe ich das ganze nach den Datenblättern der einzelnen
ICs, die weitaus besser und vor allem fehlerfreier sind:
http://www.hoperf.com/pdf/RF01.pdf
http://www.hoperf.com/pdf/RF02.pdf
http://www.hoperf.com/pdf/RF12.pdf

Das RFM12 Programm hat nicht ganz 800Bytes (RFM12 Routinen + main mit
Initialisierung auf einem tiny2313). Der Code ist nicht auf Codegröße
optimiert, sondern so dass es erstmal funktioniert. Da kann man mit
Sicherheit noch einiges verbessern.
Die RFM01 und RFM02 Routinen sind etwas kleiner, da bei diesen ja nur
Senden oder Empfangen benötigt wird.

Bei dem RF02 Sender ist das etwas komplizierter: Im Gegensatz zum RF12
besitzt dieser kein Sende FIFO. Man muss die Bits also im Takt der
Baudrate entweder an den FSK oder an den SDI Pin legen (ist per Befehl
umschaltbar). Den FSK Pin braucht man also nicht unbedingt, aber der
SDO/IRQ Pin ist notwendig, denn an diesem gibt der RF02 den Takt der
Baudrate an. Bei jeder fallenden Flanke von diesem wird das Bit an FSK
oder SDI eingelesen und gesendet.
Momementan polle ich die Leitung noch, später möchte ich das aber per
Interrupt oder per USI/SPI im Slave mode machen, denn der IRQ Pin ist
nur für 1,6us high. Wenn da ein Interrupt dazwischen kommt, gehen Bits
verloren.
nSEL kann man nicht auf GND legen, denn damit wird u.a. die Übertragung
beendet.

Ich habe gerade eine Testplatine mit einem RF02 aufgebaut, im Laufe des
Tages werde ich also die Software dafür fertig testen können und diese
dann hier rein stellen.

Hier nun dasselbe für den RF02 Sender. Funktioniert ähnlich, ist aber
etwas einfacher (da nur Senden), und kleiner (rund 650Bytes inkl main).
Ein Nachteil hat das ganze aber: Während die Senderoutine läuft, darf
kein Interrupt auftreten, also Interrupts während dem Senden abschalten.
Eine bessere Lösung wäre, die Senderoutine selbst teilweise in einen
Interrupt zu packen (USI, SPI, INT), aber das würde dann nicht mit allen
AVRs funktionieren, daher erst mal die einfache Lösung.

Und hier die Software für den Empfänger RF01.

Oder auch nicht:
Den einzigen Unterschied den ich sehe ist, dass das Wort "Pinbelegung"
hinzukam.

Hallo Benedikt,

sag mal wo kommt bei dir die utils/delay.h her? Ist das aus einer avr
clib?

Gruss Sven

Die ist beim Libc vom AVR GCC dabei.

Sorry für die dumme Frage aber was genau hat jetzt rfm01 und rfm02 mit
dem rfm12 Modul von Pollin zu tun?

Aaah, danke!

Ich bin noch stark am Überlegen.
Vor allem wieviele Stück (wenn dann nur rfm12) ich mir zulegen soll. Ich
kann leider schwer einschätzen wie "gut" die Dinger wirklich sind.

Pollin wird wohl auch nicht ewig diese Module verkaufen. Deswegen würde
ich mir gleich einen kleinen Vorrat zulegen wollen.

Wenn ich irgendwann mal eine von diesem MCA-25 Kameras wo billig
ergattern würde dann wär die Kombination von Funkübertragung und Kamera
ein Traum (ich weiß es würde lange dauern aber das wäre egal) :)

@ Benedikt

das mit der Library hat sich grade aufgeklärt, meine war etwas veraltet.

Gruss Sven

Hi,

vielen Dank an Benedikt für die Bibliotheken!


Hier noch ein kleiner Optimierungsvorschlag für die Funktion
rf12_trans():

Während das auszugebende Wort am "High-Ende" rausgeschoben wird, kann
vom "Low-Ende" her der Rückgabewert in die gleiche Variable geschoben
werden. Dadurch wird die Variable werti eingespart, es sind nur halb so
viele Schiebeoperationen nötig und der Code wird ein bißchen kleiner.

cu
Reinhard

Nein, der AVR kann beliebig getaktet werden. 10MHz bietet sich nur an,
das dieser Takt von dem Modul zur Verfügung gestellt wird. So spart man
sich den Quarz. Ein weiterer Vorteil ist auch: Man kann den AVR
dynamisch takten, indem man den Takt bis auf 1MHz reduziert.

Das Modul gibt die 10MHz an CLK aus. Am AVr speist man sie dann an XTAL1
ein, lässt XTAL2 unbelegt und setzt die Fusebits auf externen Takt.

Wiso einen Pin verschwenden, wenn ein Pullup reicht ?

Ja, so in etwa. nSEL braucht man aber noch, also das komplette SPI
Interface: Daten, Takt, Chipselect.

Alle anderen Leitungen wie Interrupt oder nFFS sind optional, wenn man
alles auf maximale Geschwindigkeit auslegt, oder es eben mit einem
Interrupt betreiben möchte.

Eigentlich kaum Aufwand, da es kaum hardwarenahe Funktionen gibt, die
irgendwas spezielles vom Compiler erwarten.
Es müssen eigentlich nur die #defines passen, dann sollte das Programm
laufen.

Welche Entfernung willst du schaffen? Mit 15cm Draht ist schon einges
machbar...

Hi,

habe nachdem meine RFM12 endlich gekommen sind, den Code ausprobiert.
Keinerlei Datenverlust. Aber eine Frage mal so nebenbei. Warum Software
SPI und nicht Hardware SPI?

Gruß Sascha

Ganz einfach: Weil nicht jeder AVR SPI hat.
Damit die Software wirklich auf jedem AVR läuft, und nicht jeder erst
die Software an seinen Wunsch AVR anpassen muss.

@bastelbär: Hast du schon dein BASCOM Programm mit den RFM12 Modul
ausprobiert?

@ Stefan
Entweder wurde das Modul nicht richtig initialisiert, oder der Sender
sendet nichts.
Versuch mal die Pause vor der Initialisierung größer zu machen.

Ich nutze einen TV PLL-Tuner um zu sehen ob das Ding sendet. Ergibt
einen wunderbaren Spectrumanalyer im Bereich 45-880MHz mit etwa 100kHz
Auflösung.

Benedikt K. wrote:
> Ich nutze einen TV PLL-Tuner um zu sehen ob das Ding sendet. Ergibt
> einen wunderbaren Spectrumanalyer im Bereich 45-880MHz mit etwa 100kHz
> Auflösung.

ist zwar etwas OT aber:

Wie nutz du den TV-Tuner als Spectrumanalyer?

Ich habe am Ausgang des Tuners (ca 34-40MHz) einen SA615 hängen, der als
Bandpass + logarithmischer Gleichrichter dient (nebenbei kann man an dem
auch noch das FM demodulierte Signal abgreifen, aber das nutze ich
nicht). Das RSSI Signal messe ich mit einem AVR, der dem Tuner die
Frequenz per I2C vorgibt. So durchlaufe ich den ganzen Frequenzbereich.
Leider hat der Tuner nur ein 62,5kHz Abstimmraster, aber das reicht für
die meisten Sachen. Die Bandbreite meiner ZF Filter ist sowiso größer.

Hast du dazu eine Bauanletung oder sowas?

@ Stafan
ich habe hier genau das gleich Problem mit zwei ATmega16s. Das senden
scheint zu klappen nur beim empfangen hängt der zweite Atmel. Der Code
ist nicht angepasst, Original aus dem Zip. Beide können Senden. Sehr
Komisch.

Hat jemand einen Mega16 als Empfänger am laufen?

Gruss Sven

@ Stefan sorry habe mich vertippt.

Ich habe es bei mir gerade nochmal ausprobiert: Die Module an je einen
tiny2313 @ 10MHz, und es funktioniert.
Probiert mal folgendes: Erst den Empfänger einschalten, dann denn
Sender.

Leider kann ich da auch nicht viel machen, da man ja nicht in die Module
reinschauen kann.
Falls du ein Oszilloskop oder einen Frequenzzähler hast: Schau mal ob am
CLK Ausgang (vom Empfänger) 10MHz rauskommen. Falls ja, dann ist das
Modul zumindest halbwegs richtig initialisiert. Dann sollte es
eigentlich funktionieren.
Der Sender sollte etwa im 1s Takt Daten senden. Das müsste man deutlich
an kurzen Rauschimpulsen hören können.

Ich glaube ich habe das Problem: Es liegt am Sender !
Aus irgendeinem Grund funktioniert die Initialisierung nicht immer,
sondern erst nach ein paar Versuchen. Zu Beginn höre ich auch nur ein
Dauerrauschen, schalte ich den Sender aber mehrmals ein und aus, dann
kommen plötzlich die 1s Rauschimpulse. Danach funktioniert es aus
irgendeinem Grund jedesmal beim Einschalten.

Die Module gegeben nach dem Einschalten 1MHz aus. Ich schalte den Takt
auf 10MHz um. Wenn also die 10MHz rauskommen, versteht also das Modul
die Befehle. Ich habe es jetzt noch ein paarmal ausprobiert: Sobald der
Sender läuft, empfange ich jedesmal die Daten problemlos.

Ja, genau dasselbe nutze ich auch. Wenn der Sender läuft, sollte der
Empfänger eigentlich auch funktionieren. Hast du auch die Pause in der
Schleife beim Empfänger auskommentiert ? Funktionieren müsste es aber
trotzdem.

Timingproblem ? Oder ist der Pin nicht richtig angeschlossen ? Wie
schnell läuft der AVR ?
Muss der Tastkopf schon beim Einschalten vorhanden sein, oder reicht es
erst später während dem Empfangen ?
Probier mal ob es mit einem Pullup oder Pulldown funktioniert.

Im einfachsten Fall: etwa 16cm Draht reicht. Die Antennenanpassung macht
den Rest. Falls die Entfernung klein ist, kann man die Sendeleistung per
Software reduzieren.

Es gibt da eigentlich nur 2 Möglichkeiten (vorausgesetzt die Hardware
ist OK):
a) Die Intialisierung des Empfängers ist nicht korrekt angekommen.
Versuch einfach mal die Init Routine mehrmals hintereinander aufzurufen.
b) Der Sender sendet nicht die korrekten Daten.

Hi Leute,
nachdem nun endlich meine Module gekommen sind habe ich mir mal meinen
Code wieder vorgenommen und wollte ihn probieren. Dabei habe ich,
abgesehen von einem Programmierfehler von mir, einige Ungereimtheiten im
Compiler festgestellt. Duch diese Ungereimtheiten war es nicht möglich
dass das Programm richtig lief obwohl beim Compilieren kein Fehler
auftrat.

Als kleine Info: Ohne die Angaben von $hwstack, $swstack und framesize
werden beim Aufruf der Funktionen bzw. Subs die Parameter anscheinend
nicht richtig übergeben bzw. verarbeitet. Und beim Berechnen der
Baudrate wird beim casten der Wert von Temp null anstatt 16 da die
344828 für Word zu gross sind. Also man lernt nie aus was Compiler so
alles machen.
Ich habe den Code entsprechend geändert und mal duch den Simulator
laufen lassen und jetzt klappt es zumindest mit den Aufrufen.
Leider kann ich erst morgen das ganze an der Hardware testen. Aber ich
schick das File mal mit, die Tage gibts dann einen Erfahrungsbericht von
mir.
Also bis denne dann....

@HUMix - geht es bei in bascom und würdest das zur verfügung stellen?

@bastelbär kann ich dein Bascom Programm auf http://www.comwebnet.de
veröffentlichen? Dort sammele ich von Usern Projekte und die werden
veröffentlicht. Gucke mal rein und schreib mir bitte.

Ich nutze den GCC ohne AVR Studio und erstelle alles über das Makefile.

Andy wrote:
> Kann ich irgendwie überprüfen, ob AM Modul etwas empfangen bzw. gesendet

Senden: Mit einem Spectrum Analyser
Empfangen: Mit dem Oszi am Filter Kondensator des RSSI Pin messen:
http://www.mikrocontroller.net/attachment/22519/rfm01.JPG

Wenn du meinen Code verwendest, dann kannst du die Frequenz am CLK Pin
messen: Da sollten 10MHz rauskommen (standardmäßig sind das 1MHz). Durch
die Software wird auf 10MHz umgeschaltet. Wenn das der Fall ist, kann
man eigentlich davon ausgehen dass das Modul OK ist, und auch richtig
angeschlossen ist.

Lade mal die Sender Software rein. Dann kannst du einen Softwarfehler
ausschließen, da der Sender ja anscheinend funktioniert.

Es könnte sein, dass die Software einfach nur den Takt abschaltet, also
falsche Daten am Modul ankommen.
Was hast du mit dem Modul gemacht, wenn du denkst das es kaputt ist ?

Ein 16cm langes Stück Draht dran.

Im Prinzip machst du mit dem Status lesen dasselbe wie ich auch, nur das
ich  nur das 1.Bit und nicht den ganzen Status lese. Probier mal
folgendes: Ersetze die rxdata Funktion durch diese hier:

void rf12_rxdata(unsigned char *data, unsigned char number)
{  unsigned char i;
  rf12_trans(0x82C8);      // RX on
  rf12_trans(0xCA81);      // set FIFO mode
  rf12_trans(0xCA83);      // enable FIFO
  cbi(RF_PORT, SDI);
  for (i=0; i<number; i++)
  {  rf12_ready();
    *data++=rf12_trans(0xB000);
  }
  rf12_trans(0x8208);      // RX off
}

Vielleicht liegt es ja daran, dass SDI high ist.

Hallo Benedikt + Helfer,

vielen Dank für Eure Arbeit. Meine Test HW mit 2 x Atmega16 + RF01 +
RF02 lief mit den Treibern auf Anhieb, d.h. nachdem ich meine
Verdrahtungsfehler beseitigt hatte ;-)

Beim Empfang hatte ich lediglich das Problem, daß das letzte Byte
manchmal falsch empfangen wurde. Ich habe dann ein bisschen
experimentiert, hier die Lösung:
Beim Sender in der rf02_txdata Funktion eine extra Verzögerung einbauen,
vor dem Abschalten des Chip Select und vor dem Ausschalten des
Transmitters, erst dann traten bei mir keine Fehler mehr auf.

void rf02_txdata(unsigned char *data, unsigned char number)
{
  ...
  ...
  ...
  _delay_us(10);
  sbi(RF_PORT, CS);
  while(RF_PIN&(1<<IRQ));  // wait until transfer done
  _delay_us(10);
  rf02_trans(0xC464);    // TX off after 10us
}

@JBecker und Luke H.
Danke für die Fehler. Ich werde es sofort ändern.

@diejenigen bei denen sich das Programm bei rf12_ready() aufhängt:
Funktioniert die Software bei euch, wenn ihr den Code wie folgt ändert ?
Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module"

Ja, das stimmt.
Entweder sendet der Sender also nicht das Startzeichen, oder der
Empfänger empfängt nicht.
Da die Software also prinzipiell lauffähig ist (da sie bei mir und bei
anderen läuft), könnte es ein Timing Problem sein (so ähnlich wie der
Fehler von JBecker, der ist bei mir ja auch nicht aufgetreten.) Daher
die kleine Änderung an der Software. Vielleicht könnte man jemand bei
dem es nicht geht, ausprobieren ob die Änderung was bringt.

Hier nochmal die Änderung in vereinfachter Form. Falls es darann liegt
müsste es funktionieren:

void rf12_ready(void)
{  cbi(RF_PORT, SDI);
  cbi(RF_PORT, CS);
  asm("nop");
  while (!(RF_PIN&(1<<SDO))); // wait until FIFO ready
}

Du meinst, wenn irgendwo in der Mitte ein Byte verloren geht, oder wenn
das Sync Word verloren geht ?

Wenn das Sync Word nicht ankommt, hängt der Empfänger eben. Da muss man
halt vor die Empfangsfunktion anpassen (erst einschalten, dann abfragen
ob Daten vorhanden sind, und falls ja dann empfangen.
Wenn aber während der Übertragung was verloren geht, dann interessiert
das nicht: Nach dem Sync Word emfpängt das Modul egal was kommt, bis man
das FIFO abschaltet.

Seltsam. Jetzt wäre interessant zu wissen, was du anderst machst als
z.B.  Humix, JBecker oder ich. Es ist leider sehr schwierig einen Fehler
zu finden, der nur bei etwa der Häfte der Schaltungen auftritt. Hast du
an der Software irgendwas verändert (außer zwischen Senden/Empfangen
umgeschaltet) ?

Hast du mal die unveränderte Software ausprobiert (also nur
Senden/Empfangen etsprechend angepasst) ?
Welche Optimierungseinstellungen verwendest du ? Ich habe aus -o2
gestellt, da dies meiner Meinung nach das optimalste ist.

Achso, du verwendest das Bascom Programm. Da kann ich dir leider nicht
weiterhelfen, für Bascom Probleme musst du dich an bastelbär wenden.

Ja, genauso ist es. Die Idee mit dem Ende Zeichen ist gut. Wenn man
allerdings nur Steuersignale mit einer festen Länge überträgt, kann man
auf das Endzeichen verzichten, und hat damit schonmal eine Fehlerquelle
weniger.

Das deutet darauf hin, dass entweder die Frequenz oder
Baudrateneinstellung von Sender und Empfänger nicht übereinstimmen, oder
der Sender einfach nicht sendet.

Gibt es eigentlich jemanden, bei dem das C Programm noch nicht läuft ?

Daran dürfte es eigentlich nicht liegen, da die Baudrate im Modul
erzeugt wird.

Ob der Sender sendet, kann ich ohne Spectrum Analyzer nicht feststellen,
oder??

Andy

Mit einem passenden Funkgerät würde es noch gehen, oder zur Not mit
einem TV (das müsste Kanal S38 sein). Keine Ahnung was man auf dem TV
erkennen kann, wie und fein man heutige TVs abstimmen kann, aber
zumindest bei älteren TVs ohne automatischem Sendersuchlauf sollte man
die 1s Sendeimpulse im Ton hören wenn die Frequenz passt.

OK, hab ich beides nicht in der Firma. Mal sehen, ob ich die Dinger mit
nach Hause nehmen kann.

Ansonsten hat keiner eine Idee, was da sein könnte, oder?? Das gibt es
ja nicht - bei allen funktioniert es, nur bei mir nicht. Entweder bin
ich zu blöd (was ich langsam glaube gg) oder meine Module sind
wirklich defekt! Aber dann könnte ich doch überhaupt nichts auslesen,
oder. Und auch die Frequenz lässt sich einstellen!

Ich steh jetzt echt an!!!

mfg
Andy

Claude wrote:
> Wie JBecker schon meinte Signalisiert der Empfänger nicht wenn das
> Empfangene Byte/Daten vom FIFO abgeholt wurde. Welche Funktion hat dann
> das FFIT Signal?

Das gibt an, ob im FIFO mehr Bits sind, als das eingestellte Level. Bei
mir signalisiert FFIT also ob ein komplettes Byte im FIFO ist oder
nicht.
Ich verwende aber nicht den FFIT Pin, sondern lese das Bit über das
Statusregister aus, um einen Pin zu sparen.
Bei all denjenigen wo das Programm hängt, müsste also der FFIT Pin auf
Low liegen. Denn im Gegensatz zum INT Pin ist der FFIt Pin high aktiv.

@Benedikt:
Ich habe noch eine Idee. Wäre es möglich, dass du mir 2 Hex-Files mit
deinem C-Programm machst. Das wäre super, dann würde ich gleich sehen,
ob es am Modul oder am Programm liegt, oder?

Der Sender wäre ein Mega48 mit 8Mhz und der Empfänger ein Mega8 mit
4Mhz. SPI-Pins nicht vergessen!

Das wäre ganz nett von dir - nur wenn du Zeit hast!!

Vielen Dank schon im Voraus!!


mfg
Andy

Ich erstelle jetzt mal 2 Hexdateien, beide für einen mega8 für Sender
und Empfänger, teste die mal bei mir an einer Minimalhardware und wenn
beide sicher funktionieren, dann lade ich die hier hoch (vermutlich
heute Nachmittag bis Abend.) Das sollte dann bei jedem funktionieren.
Falls nein -> Hardwarefehler, ansonsten liegt es an der Software.

Hier 2 Programme, die bei mir mit einem Minimalaufbau laufen:
RFM12 an einen mega8 gelötet. Der hängt über einen FT232 am PC.
Sonst sind keine weiteren Bauteile verbaut (weder Quarz, noch
Kondensatoren oder sonstwas). Den mega8 habe ich mit dem internen 8MHz
Takt laufen.
Die Module sind am SPI Interface angeschlossen, verwenden dieses aber
nicht (Software SPI.)
Die Hex Dateien kann man direkt den AVR brennen.

Jetzt bin ich mal gespannt.

JJJUUUUUUUUHHHHHHHHHHHUUUUUUUUUUUUU!!!!!

Es kommt die Meldung Empfänger läuft und dann im Sekundentakt "Dies ist
ein 433MHz-Test". Und ein bisschen wirres Zeug herum!!

Wow, danke!! Hast mir sehr geholfen! Jetzt muss ich nur mehr rausfinden,
warum das mit Bascom nicht funzt!! Irgendeine Idee? gg


Danke nochmal!!

Andy

Hallo zusammen!

Mich würde interessieren, ob es jemand mittlerweile geschafft hat, die
Module unter Bascom richtig anzusprechen. Ich würde das RF12 nämlich
gerne im Zusammenhang eines kleines Roboterprojektes einsetzen, dass
ansonsten auf Bascom basiert.

Gruß&Dank!
Malte

Okay, sorry! Ich hatte die Probleme die Andy hatte, als Probleme des
Bascom-Codes interpretiert. Danke für den Hinweis!

Gruß,
Malte

Kommuniziert bei benedikts letzten beispiel das RFM12 modul mit sich
selbst?

Meine Idee ist so ein Modul per software usb an den PC zu bringen. Ist
es eigentlich wichtig wie die Daten die ich sende aussehen? Bringt es
vielleicht die irgendwie zu kodieren (nicht in Bezug auf Sicherheit
sondern in Bezug auf Reichweite/Stromverbrauch oder sonstige komischen
Effekte)?

Marius Schmidt wrote:
> Kommuniziert bei benedikts letzten beispiel das RFM12 modul mit sich
> selbst?

Nein, ein Modul kann nicht gleichzeitig senden und empfangen.

> Meine Idee ist so ein Modul per software usb an den PC zu bringen. Ist
> es eigentlich wichtig wie die Daten die ich sende aussehen? Bringt es
> vielleicht die irgendwie zu kodieren (nicht in Bezug auf Sicherheit
> sondern in Bezug auf Reichweite/Stromverbrauch oder sonstige komischen
> Effekte)?

Manchester Kodierung bringt vermutlich ein kleinwenig, da die Bittakt
Wiederherstellung dann einfacher wird. Zwingend notwendig ist das aber
nicht, solange es ausreichend Flanken im Datenstrom gibt.
Ich teste gerade einen 8-4 Hamming Code, der eigentlich immer
ausreichend Flanken in einem Byte erzeugt. So benötigt man zwar auch
16bit für 1Byte Nutzdaten, aber dafür kann man immerhin noch ein
falsches Bit wieder korrigieren.

Vielleicht kann man das ja hiermit kombinieren:
http://www.jrobot.net/Projects/AVRcam.html

Ist irgendwie logisch, dass das modul nicht beides gleichzeitig kann,
schließlich hat es ja nur eine Antenne :-)

Um den Thread etwas zurück zu geben,
eine kleine Bastelei von mir. Das RFM12 als Bidirektionaler RS232
Tunnel.

Folgendes ist bis jetzt Implementiert:
- Basierend auf Benedikts Code
- Timeout für RX , wie von JBecker beschrieben.
- STX/RTX Stack von der Procyon AVRlib.
- Verpacken von UART RX Bytes in STX/ETX Packete .
- Entpacken von STX/ETX Packeten und schicken an den UART.
- Erkennen von validen STX/RTX Paketen (STX,ETX,CRC).
- Bidirektional Half Duplex mit 1200 Baud.

Was noch fehlt :
- Neuanforderung von STX/ETX Paketen falls diese nicht valid sind.
- Nutzung aller Features der STX/ETX Library.
- Sauberer Code ...
- Schneller Code ...

Als Testhardware habe ich 2 ATmega8 mit 14,7456MHZ Quarzen benutzt.
Das RFM12 ist ,wie in Benedikts Code, nur mit 4 Leitungen am ATmega.

PS: Bitte klopft nicht zu arg auf mich ein, Programmieren ist nicht so
mein Ding. Das Werkzeug meiner Wahl ist der Lötkolben,und so
Programmiere ich auch :-)

Was ist ein STX/ETX Packet und was warum sollte ich das noch Tunneln?
Ich verstehe den Sinn der Anwendung nicht kannst du das mal erläutern?

Auszug aus der Beschreibung der STX/ETX Lib von Procyon :

STX/ETX is a simple packet protocol for serial data streams
and offers packetization, type tagging, and checksum protection
for user data.
Common uses of STX/ETX might include radio communications
were it can improve data reliability over lossy channels.
STX/ETX may also be used effectively anywhere multiple access
to the communication medium is required.
The packets can be made to contain destination addresses
or routing information as well as data.

Ich benötige das STX/ETX für meine Anwendung. Als Test hab ich die RS232
durchgetunnelt.
Gruß
Claude

Ohmann, Fossie...

da haste mir ma ein Ei gelegt :)

Die Bascom Version läuft wunderbar, man muss nur wissen, dass bei

"Spi_sdo Alias Pinb.6    ' MOSI-PIN"

der "MISO" Pin gemeint ist!

>_<

Das hat mir und möglicherweise noch ein paar anderen die nicht den
Mega32 verwenden und von daher die Pins umdefinieren müssen "das Genick
gebrochen"...

Aber einen Vorteil hatte es, ich hab kurz vorm Seppuku noch eine "Soft
SPI" Routine (angelehnt am C Code) geschrieben:

' werden benötigt für rf12_ready bzw SoftSPI (Definitionen für Mega8)
Spi_sdi Alias Portb.3                          ' MOSI-PIN
Config Spi_sdi = Output

Spi_sck Alias Portb.5                          ' Clock-Pin
Config Spi_sck = Output

Spi_cs Alias Portb.2                           ' SS-Pin
Config Spi_cs = Output

Spi_sdo Alias Pinb.4                           ' MISO-PIN

...
...
...

Function Rf12_trans(byval Wert As Word) As Word
 Dim I As Integer

 Reset Spi_sck
 Reset Spi_cs

 For I = 0 To 15

  If Wert.15 = 1 Then
   Set Spi_sdi
  Else
   Reset Spi_sdi
  End If

  Shift Wert , Left , 1

  If Spi_sdo = 1 Then
   Wert = Wert Or 1
  End If

  ' clock
  Set Spi_sck
  $asm
    nop
    nop
  $end Asm
  Reset Spi_sck

 Next I

 Set Spi_cs

 Rf12_trans = Wert

End Function

Und die ready methode noch abgeändert:

Sub Rf12_ready
  Reset Spi_sdi
  Reset Spi_cs

  $asm
    nop
    nop
  $end Asm

  While Spi_sdo = 0
  Wend
End Sub

Ich hoffe das war das Problem.

Verwendest du irgendwelche Interrupts ?

Hast du ein Oszilloskop ?

Falls ja, dann sollte and der nIRQ (=SDO) Leitung kurze Impulse im
Baudratentakt zu sehen sein.
Falls ja, dann überprüfe ob die an dem Pin landen, der abgefragt wird.
Liegen am CLK Pin 10MHz oder 1MHz an ?

Matze, könnte es vielleicht sein, daß Du den IRQ-Pin am falschen Port zu
lesen versuchst? Weiter oben hattest Du ja geschrieben, daß die Pins
über zwei Ports verteilt sind.

Poste doch mal Deine Pinbelegung und die entsprechenden #define-Zeilen
für RF_PIN, RF_PORT, usw.

Ah - sorry, das Attachment hatte ich übersehen.

Mir ist noch aufgefallen, daß Du util/delay.h inkludierst ohne vorher
F_CPU zu definieren. Das ist OK, wenn Du den Tiny44 mit 1MHz taktest
oder F_CPU in einem vorher inkudierten Header oder an der
gcc-Kommandozeile definierst.
Falls der Controller aber schneller getaktet ist und F_CPU nicht
entsprechend gesetzt wird, sind Deine Delays zu kurz und das kann dazu
führen, daß das Modul das Sendekommando nicht erkennt und Dir deshalb am
IRQ-Pin keine Takte liefert.

Hast Du es denn schonmal mit 8MHz versucht, vielleicht ist die CPU ja
mit 1MHz zu langsam? Auf jeden Fall sollte F_CPU der tatsächlich
eingestellten Taktfrequenz entsprechen, damit die Delays die korrekte
Dauer haben.

Noch ein Gedanke: Hast Du schonmal untersucht, ob die Schleife gleich
beim ersten Aufruf von rf02_shiftout hängen bleibt, oder erst nachdem
schon ein paar Bytes zum Modul geschickt wurden?

1MHz ist definitiv zu langsam: Die zu erkenenen Impulse haben 1,6µs.
Vielleicht solltest du besser die USI oder einen Interrupt nutzen,
anstelle der Software Routine.

Hallo,

Hab noch eine ganz andere Frage.

Und zwar: Woran kann es liegen, dass Zeichen "verschwinden" (bei der
Übertragung)? Ich will eigentlich nur 3 Byte übertragen. Das erste kommt
immer an und die letzten zwei nur selten oder falsch.

Was kann da sein?


THX Andy

Das liegt am Sendepuffer. Der fasst 2 Byte, die noch nicht übrtragen
sind wenn der Sender abgeschaltet wird.
Hier mal die neueste Version, wo alle mir bisher bekannten Fehler
behoben sind.

Und warum funktionierts dann mit der Version, wo 32 Byte übertragen
werden??

Da funktioniert es nicht so ganz, aber das merkt man nicht, da die
letzen paar Zeichen "!\n" sind.

Hallo,

OK, ich will 3 Bytes übertragen, d.h. ich muss eigentlich 5 Bytes
übertragen, weil die letzten beiden irgendwie verschwinden, oder?
Das habe ich nun gemacht und es funktioniert jetzt auch besser als
vorher. Nur hab ich nochwas komisches festgestellt! Wenn ich z.B. 02 FF
03 übertrage, klappt das wunderbar - immer wieder. Nur wenn ich 02 01 03
sende, dann kommt der Wert 02 immer an und die folgenden nur manchmal.
D.h. wenn ich in der Mitte der 3 Bytes eine höhere Zahl sende, klappt es
gut, nur bei kleineren funktionierts nicht richtig.

Woran kann das nun wieder liegen??


THX Andy

Vielleicht sind dem Empfänger zu wenige Pegelwechsel in den Daten. Da
müsste eine Manchestercodierung helfen.

Matze wrote:
> Bedeutet das dass die InitRoutine schon nicht funktioniert?

Ja.

@Andreas:
Wenn im Empfangsstream zu wenig Pegelwechsel vorliegen, dann kann der
Empfänger den Takt nicht genau genug rekonstruieren.
Mögliche Abhilfe: Bit- oder Byte Stuffing.
Ich würde erstmal mit Byte Stuffing anfangen, d.h. wenn in einem Byte
weniger als z.B. Vier "1"en vorkommen, dann einfach ein Füllbyte "0xAA"
hinterher senden. Im Empfänger muß dann das Füllbyte natürlich wieder
entfernt werden.
Wenn das nicht genügend funktioniert, muß man wohl auf Bit Stuffing
umsteigen was aber wesentlich mehr Performance frisst.

Matze wrote:

> Kann das sein dass das eigentlich Problem an den Kabeln liegt?

Gut möglich. Ich wollte Dir eh schon vorschlagen die Verbindung zwischen
AVR und Funkmodul nochmal zu überprüfen.

Wenn die Kabel zu lang sind (und auch noch unterschiedlich lang) kann es
durchaus sein, daß am Funkmodul die Signale an der Daten- und
Taktleitung so verschliffen sind, daß sie nicht mehr ordentlich erkannt
werden. Außerdem fangen die Leitungen sich mit zunehmender Länge (und
ohne Abschirmung) leichter Störungen ein.

Was für eine Distanz kann man eigentlich ohne Antenne überbrücken mit
den Modulen?

Mit 15cm Draht am Sender (hab ich fest angelötet, kann ich also nicht
einfach abnehmen) komme ich auf 10m Meter störungsfrei bis zum Empfänger
ohne Antenne (bzw. eine Kontaktreihe auf dem Steckbrett, macht ca. 1,5cm
effektive Länge)

Hallo,

Wie geht das genau, wenn ich nur etwas empfangen will, wenn der Sender
gesendet hat. Kann mir jemand dazu Auskunft geben?

THX Andy

Hallo,

So, ich hab jetzt meine Daten Manchester-codiert (wegen des
Pegelwechsels). Dann sende ich nach meinen Nutzdaten noch 2 Byte
Wirr-Warr hinterher (weil der Empfänger ja 2 Bytes "frisst"), aber es
funktioniert immer noch nicht ordentlich. Die Daten kommen an, wie sie
wollen. Zweimal kommen sie vollstädnig an, dann wieder 3 mal nicht usw.
Was kann da sein?

Ich verwende noch die Variante von ganz oben, d.h. ich frage dauernd den
Buffer ab, auch wenn nichts gesendet wurde. Liegt darin der Fehler?

Bin für jede Hilfe dankbar!

THX Andy

Verwendest du das Programm von ganz oben, oder diese rf12.c ?
http://www.mikrocontroller.net/attachment/23418/rf12.c

Die erste Version hatte noch ein paar kleinere Fehler, die bei der neuen
Version behoben sein sollten (inklusive dem Verschlucken der 2 Bytes.)

Naja, das Problem ist, dass ich Bascom verwende, und ich C nicht so
beherrsche!

Aber gibt es nicht eine Möglichkeit, dass den Buffer nur auslese, wenn
ich auch wirklich etwas gesendet habe??

Dazu musst du die Software anpassen:
- Empfänger einschalten.
- den Status auslesen (FFIT bit)
- Nur wenn dieses gesetzt ist, sind Daten im Puffer.

Also im Prinzip die Empfangsfunktion zerlegen und die einzelnen Teile in
dein Programm einbauen.

Das heißt, ich muss trotzdem immer ein Bit auslesen, oder? Oder gibt es
vielleicht einen Pin, der den Pegel beim Empfang von Daten ändert??

Ja, der FFIT Pin. Aber ob du den einließt, oder den SDO Pin ist
eigentlich egal (denn das FFIT Bit wird als erstes am SDO Pin
ausgegeben, wenn SDI und nSEL low sind). Daher habe ich mich für die SDO
Version entschieden, da man so einen Pin spart.

Hallo, danke nun mal für deine Antworten.

Ich möchte das ganze gerne mit dem FFIT-Pin lösen. Ich habs nun selbst
versucht, aber irgendwie klappt das nicht! Ich komme jetzt nur in die
rx-Routine, wenn der FFIT-Pin HIGH wird, aber da sind keine Daten im
Buffer.

Kannst du mir vielleicht kurz aufzählen, was ich wie aktivieren muss,
damit ich meine Daten bekomme? Und was kann ich jetzt von deinem
Programm weglassen, weil ich den FFIT-Pin verwende!

Wäre echt cool, wenn du mir da weiterhelfen könntest!!

Vielen Dank!!

mfg
Andy

Andreas Posch wrote:
> Kannst du mir vielleicht kurz aufzählen, was ich wie aktivieren muss,
> damit ich meine Daten bekomme? Und was kann ich jetzt von deinem
> Programm weglassen, weil ich den FFIT-Pin verwende!

- Empfänger einschalten
- FIFO Modus Einschalten
- FIFO einschalten (Sync Word Erkennung aktivieren)

- FFIT Pin abfragen, wenn high Daten empfangen
- Wenn Daten empfangen, FIFO ausschalten und Sync Erkennung neu
einschalten (das sind diegleichen Befehle wie beim Einschalten des FIFO
Modus).

Die Befehle dazu finden sich in der rf12.c in der Funktion void
rf12_rxdata(unsigned char *data, unsigned char number).

Hier wird es nächste Woche nochmal eine Sammelbestellung direkt beim
Hersteller in China geben: Beitrag "Sammelbestellung RFM12"

Hallo Benedikt,

Zuerst mal vielen Dank für deine Hilfe!! Ich hab das ganze nun probiert,
und es schein auch prinzipiell zu funktionieren.
Nur hab ich jetzt das Problem, dass ich nur 2 von 8 Bytes empfange! Der
Rest ist 0. Was ist da schon wieder los!

Ich weiß, ich bin lässtig, aber ich will das sch... Ding endlich
verstehen!!


THX... Andy

Gibt´s bereits einen Schaltungsvorschlag/Softwarelösung um mit HP03D,
FOST02A und RFM12-868-S1 (wenn möglich basierend auf dem Pollin
AVR-Board) Wetterdaten aufzunehmen und an eine Master-Station (ebenfalls
das Pollin-Board) zu übertragen. Von dort sollen die aufgenommenen
Messwerte per Seriell/USB an den PC zur weiteren Auswertung übertragen
werden. Am besten Pufferung der Daten in der Master-Station (SRAM?!?),
sofern der PC nicht eingeschaltet ist.

Gruß,

Klaus

Sonst noch irgendwelche Wünsche ?
Vielleicht fertig aufgebaut frei Haus zugeschickt ?

Sicher kannst Du in Deiner Master-Station (Pollin-Board) die Messdaten
im SRAM zwischenspeichern... zumindest soviel wie Dein verwendeter
Controller RAM (und evtl. noch EEPROM) hat. Da ich davon Ausgehe, dass
Du mit dem Pollin-Board das Funk-AVR-Evaluations-Board meinst hat dieses
auch keinen Sockel für ein externes EEPROM (im vergleich zum ATMEL
Evaluations-Board Version 2.0).

Da hier wahrscheinlich noch keiner ein HP03D oder ein FOST02A hat ist
diese Anfrage noch was zu früh.

BK>Sonst noch irgendwelche Wünsche ?
Für den Anfang denke ich sollte das ausreichen, oder fehlt Dir noch
etwas?

BK>Vielleicht fertig aufgebaut frei Haus zugeschickt ?
Nein, das würde ich schon noch gerne selber machen.

Wenn´s so etwas noch nicht gibt (hört sich ja danach an), dann werde ich
mich mal ans Werk machen und dieses (sofern es von Erfolg gekrönt ist)
gerne hier für alle anderen zur Verfügung stellen.

Gruß,

Klaus

Du hast Deine HP03D und FOST02A schon? ;-)

Hallo Marvin,
habe Dein Soft-SPI-mega8 in Bascom eingearbeitet.
Sollte der rf12 auf senden bleiben,macht er bei mir,
oder im Zeitintervall immer wieder auf Senden schalten.


wigbert

Nachtrag
also wenn ich bei ready

> While Spi_sdo = 0 auf 1 ändere sendet er im Sekundentakt
ist das richtig?

Wigbert

Hallo zusammen,

ich muss mich jetzt auch einmal melden... Gestern hab ich mich
nachmittags hingesetzt und die Bibliothek etwas erweitert.

Zunächste einmal habe ich die Sende- und Empfangs-Methoden etwas
modifiziert.

void rf12_txdata(unsigned char *data, unsigned char number);
unsigned char rf12_rxdata(unsigned char *data);

Beim empfangen von Strings muss man jetzt nicht mehr wissen wie lange
das Paket ist. Es können variable Paketlängen bis zu 240Byte übertragen
werden. Der Rückgabewert von rf12_rxdata() ist die Länge des Pakets.
Zusätzlich sind die Pakete noch mit einem CRC16 gesichert und wurden
bereits überprüft und nur richtige Pakete ausgegeben.

Dann ein großer Punkt ist das blockieren der Funktionen. In einem
eingebetteten (meist echtzeit) System sind solche Funktionen eigentlich
unerwünscht. Vorallem wenn einmal ein Paket nicht empfangen wird.
Deadlocks sind hier ja schon fast vorprogrammiert. (Dieses Urteil mase
ich mir jetzt einfach mal an.) Asynchrones programmieren (mit
Interrupts) ist nie verkehrt...

Deshalb hab ich die Bib noch etwas erweitert. Mit den defines:

#define RF12_UseBlockingCalls  //NEVER USE BOTH
#define RF12_UseNoneBlockingCalls  //NEVER USE BOTH

kann man die blockierenden Methoden durch nicht blockierend ersetzten.
Das Senden/Empfangen wird dann im Hintergrund abgearbeitet. Allerdings
braucht man dazu einen Interrupt Pin. Der Prozessor blockiert jetzt nur
noch kurz wenn man Daten an das Modul überträgt, oder anders herum.

// start receiving a package
unsigned char rf12_rxstart(void);

// readout the package, if one arrived
unsigned char rf12_rxfinish(unsigned char *data);

// start transmitting a package of size size
unsigned char rf12_txstart(unsigned char *data, unsigned char size);

// check whether the package is already transmitted
unsigned char rf12_txfinished(void);

// stop all Rx and Tx operations
void rf12_allstop(void);

Zugegeben ich war irgendwie unfähig einen Hardware SPI zu verwenden. Da
hat das Empfangen der Daten irgendwie nie geklappt. Ka Wieso. Aber wenn
das wer zum laufen bringt, dann kann man das blockieren noch weiter
reduzieren G
Vom Prinzip her reicht mir das aber erstmal.

Probiert es einfach mal aus. Ich hab 2 Sample Projekte mit dem
Kontrollerlab angelegt. Die Bib selber liegt in dem Lbr Verzeichnis und
sind in die Projekt Verzeichnise gelinkt. Wenn wer Windoof verwendet
dann muss er sie ggf in die passenden Verzeichnise kopieren.

Auch interessant ist vielleicht meine

unsigned char UART_Tx_Str(unsigned char *str, unsigned char size);

Methode, die ist ähnlich nicht blockierend... Man schickt einen
beliebigen String über den UART ab und während der String gesendet wird
kann man schon etwas anderes tun (mit winzigen Unterbrechungen).

Guggs euch an und sag mir was ihr davon haltet, oder wie scheiß ich bin
G


Sers
Jürgen

file vergessen G

Hier noch ein kleines Bugfix. schäm

Es gab kleine Probleme beim empfangen wenn die CRC Checksumme nicht
gestimmt hat.

Ich hab bei der Gelegenheit auch gleich ne Versionsnummer eingeführt,
falls andere die Lbr noch weiter entwickeln wollen.

2.0.1 ist der momentane Stand.

So far
Jürgen

Hallo,

Ich hatte ja vorhin das Problem, dass ich von 8 gesendeten Bytes nur die
ersten 2 empfangen konnte!
Ich verwende den FFIT und habe diesen an Int0 meines Mega8
angeschlossen. Immer, wenn ein Interrupt auftritt, führe ich dann die
RX-Routine aus! Nun bin ich draufgekommen, dass, wenn ich eine Baudrate
unter 2400kbps verwende, am FFIT-Pin mehrere Impulse hintereinander
kommen und daher die RX-Routine vom Int0 unterbrochen und nochmals
gestartet wird. Und siehe da, die Daten kommen vollständig an!
Also stimmt irgenetwas mit meiner Empfangsroutine nicht! Aber was könnte
da sein??


Vielen Dank!

Andy

Andreas Posch wrote:
> Ich verwende den FFIT und habe diesen an Int0 meines Mega8
> angeschlossen. Immer, wenn ein Interrupt auftritt, führe ich dann die
> RX-Routine aus! Nun bin ich draufgekommen, dass, wenn ich eine Baudrate
> unter 2400kbps verwende, am FFIT-Pin mehrere Impulse hintereinander
> kommen und daher die RX-Routine vom Int0 unterbrochen und nochmals
> gestartet wird.

Wie hast du das genau gemacht ? Normalerweise wird ein Interrupt nicht
durch einen anderen Interrupt unterbrochen.

Das ganze erinnert mich an meine Versuche das ganze Interruptgesteuert
zu machen: Es kam nur jedes 2. Byte an.

Ich führe einfach folgenden Code in der Interruptroutine aus:

On_int0:
  Print "Bin da"
  Call Rf12_rxdata(maxchar)
  For J = 1 To 6
    Print J ; " " ; Rfdata(j)
  Next
Return

und Rf12_rxdata macht folgendes:

Sub Rf12_rxdata(byval Maxchar As Byte)
  For Count = 1 To Maxchar
    Rf12_ready
    Temp = Rf12_trans(&Hb000)
    Temp_byte = Temp

    'Wenn Temp_byte gleich 89 ist, Werte in Variable speichern
    If Temp_byte = 89 And J = 1 Then
      Set Rec_data
      Timer1 = 0
      Start Timer1
    End If

    'Laufvariable erhöhen, wenn Empfang freigeschaltet ist
    If Rec_data = 1 Then
      Rfdata(j) = Temp_byte
      Incr J
    End If

    'Empfang beenden, wenn Temp_byte gleich 85 ist
    If Temp_byte = 85 And J = 7 Then
      Stop Timer1
      Reset Rec_data
      Set Got_data
    End If
  Next Count
  Auswertung

  Temp = Rf12_trans(&Hca81)
  Temp = Rf12_trans(&Hca83)
End Sub

Ich weiß, du bist kein "Bascom-Mensch", aber könntest du vielleicht doch
einen Blick drauf werfen?? Besten Dank!!


Andy

Auch wenn ich diese Art der Programmierung als schrecklich betrachte
(soviel Code in der Interruptroutine), müsste es aber trotzdem
funktionieren. Ich kenne mich mit Bascom überhaupt nicht aus, daher weiß
ich nicht, ob während einer Interruptroutine die Interrupts auch aus
bleiben, oder ob bascom die Interrupts wieder aktiviert. Letzeres würde
den Fehler erklären.
Eine bessere Lösung wäre: Einen Empfangspuffer einrichten, in den im
Interrupt nur die empfangenen Daten geschrieben werden und ein
Bytezähler erhöht wird. Dann noch eine Variable, die anzeigt ob der
Empfang vollständig ist.

Ich würde vorschlagen, pro Interrupt jeweils nur ein Byte zu empfangen
und für das nächste empfangene Byte wieder einen neuen Interrupt
generieren zu lassen, ansonsten wird zwar der Start des Empfangs per
Interrupt angestoßen aber der eigentliche Empfang des Pakets läuft dann
wieder pollend.

Danke einaml für deine Antwort, ich werd es mal so probieren.

Aber in meiner Empfangsroutine hab ich ja schon so eine Art Buffer. Ich
speichere zunächst alles in der Variable Rfdata und wenn der Empfang
abgeschlossen ist, werte ich die Daten aus. Nur ist ja das Problem, dass
nur die ersten 2 Bytes ankommen. Nur wenn ich während des Empfangs
nocheinmal sende, kommen weitere Daten an!

Irgendwelche Ideen??

Ich weiß nicht mehr weiter.

Mann, bin ich blöd...

ich hab die ganze Zeit am nIRQ ausgang gehangen und hab mich gewundert
warum das nicht geht ^____^;

mit FFIT gehts natürlich. Und zwar genau so wie Benedikt das schon
irgendwann mal beschrieben hatte...

also:

FFIT an INT1

...

Config Int1 = Rising
On Int1 Ffit_handler
Enable Int1

...

Ffit_handler:

    ' Byte lesen
    Temp = Rf12_trans(&Hb000)
    Rfdata(count) = Temp
    
    ' Momentan einfach feste länge lesen, STX ETX oder sowas ist aber
    ' hier auch kein problem...
    If Count >= Maxchar Then
      
      ' Wenn 32 Bytes gelesen wurden, Text ausgeben
      For Count = 1 To Maxchar
        Print Chr(rfdata(count));
      Next Count
      
      ' FIFO SYNC Erkennung wieder scharf machen
      Temp = Rf12_trans(&Hca81)
      Temp = Rf12_trans(&Hca83)
 
      ' und von vorne zählen
      Count = 1

    Else
      ' ansonsten nur zähler erhöhen
      Incr Count
    End If


Return

....

Ich programmier mir jetzt mal die STX ETX Erkennung mit einem timeout,
dann seh ich weiter...

@Wigbert: ich hab jetzt mal gerade beim empfänger die abfrage auf
spi_sdo=1 geändert... funktioniert auch... wenn er beim sender dann ne
sekunde aufhört zu senden, dann wird das wohl richtig sein...

@wigbert:

wenn ich spi_sdo auf "1" abfrage bleit mein programm stehen...

Hallo Marvin,
ich habe Deinen Soft SPI Code
und deine ready Methode in den Code von Fossy eingebaut.
wenn ich spi_sdo auf 0 lasse.
pendelt das programm nach dem Durchlauf zwischen

>While Spi_sdo = 0
  >Wend
wenn es klappt habe ich mein Code beigelegt.
Irgendetwas stimmt bei mir dann nicht

Wigbert

Nachtrag:
Pinb.4 ist ja wohl als Eingang declariert.
Kann mir mal jemand erklären wann der Spi_sdo Port des RFM12 ein H
Pegel hat.Wenn bei Empfang Daten empfangen werden, oder wann noch?

>Spi_sdo Alias Pinb.4                           ' MISO-PIN

Dank Euch


Wigbert

@Jörg:
Ich habe nun meine Interrupt-Routine so abgeändert, dass ich dort nur
eine Bit-Variable setze und dann den Code im Hauptprogramm ausführe.
Aber es geht trotzdem nicht!
Was mir aufgefallen ist: Wenn ich die Baud-Rate auf 1200 stelle, kommt
für jedes Byte ein extra Interrupt; und dann funktioniert die
Übertragung auch! Aber wenn ich die Baud-Rate auf 19200 stelle, kommt
nur mehr ein Interrupt für alle Bytes! Wahrscheinlich kommen die
einzelnen Interrupts dann schon zu schnell, dass nur mehr einer erkannt
wird. Und bei 19200 funktionierts nicht! Ich würde gern wissen, was da
falsch läuft!

THX Andy

also bei mir funktioniert das byteweise lesen über interrupt mit 19.200
baud mit einiger logik in der interruptroutine (STX/ETX+CRC8)

Ich hab mich noch nicht komplett mit den Modulen beschäftingt, da meine
noch nicht da sind aber so wie ich das verstanden habe haben die Module
einen Fifo. Und für Jedes ankommende Byte wird ein Interrupt erzeugt.
Dann würde ich, solange die Main nicht so lang ist, dass der Fifo
überlaufen kann in der maximalen zeit bis zur Bearbeitung, in jedem
Interrupt eine Variable hochzählen, die anzeigt, wieviele Bytes noch
gelesen werden müssen. Wenn du dann ein Byte ausliest, ziehst du wieder
eins von dieser Variable ab. Wenn sie 0 ist brauchst du natürlich auch
nichts zu lesen.

Hauke Radtki wrote:
> aber so wie ich das verstanden habe haben die Module einen Fifo.

Ja, der ist aber nur 16 Bit (also 2 Byte) lang. Man muß also jedes
empfangene Byte aus dem FIFO holen, bevor das nächste komplett ist, sost
läuft der FIFO über.

> Und für Jedes ankommende Byte wird ein Interrupt erzeugt.

Nein, ein Interrupt wird immer dann erzeugt, wenn der FIFO den bei der
Initialisierung eingestellten Füllstand erreicht hat. Wird er dann nicht
geleert, gibt es den nächsten Interrupt erst wieder wenn er übergelaufen
ist, was dann bedeutet, daß man Daten verloren hat.

Hallo,

Ich lese nun jedes Byte einzeln ein und siehe da: Es funktioniert bei
jeder Baud-Rate! An dieser Stelle mal danke an alle, die mir geholfen
haben!

Einen Fehler hab ich aber noch! Beim ersten Senden nach dem Einschalten
funktionerts nicht. Es wird nur bei ersten Byte ein Interrupt ausgelöst.
Bei den folgenden nicht! Sende ich dann nocheinmal haut es hin!

Was könnte da noch sein? Hab schon einiges durchprobiert - komm aber
nicht dahinter!

THX
Andy

Danke, hat sich erledigt! Beim ersten Einschalten habe ich den FIFO
doppelt initialisiert!

Andy

Ja, der funktionierende BSACOM-Code würde mich auch interessieren!

Danke!
Malte

das würde mich ja mal interessieren wiedu das mit der TV Karte testest

Junge Junge, lebst mit deiner TV Karte aber ganz schön gefährlich

Jürgen

PS:
Keiner was zu sagen zu meiner Erweiterung der Lib (siehe oben)? Hat die
überhaupt schon mal wer getestet?!

Hallo,

Mein Bascom-Code funktioniert doch noch nicht so einwandfrei, wie ich
mir das gedacht hatte. Beide, der Empfänger und der Sender, stürzen in
regelmäßigen Abständen ab.
Der Empfänger empfängt dann einfach nichts mehr. Zumindest kommen keine
Impulse mehr aus dem FFIT-Pin. Ich habe aber auch schon mal beobachtet,
dass dann dauernd Impulse am Pin anliegen und der Empfänger ebenfalls
nicht mehr reagiert. Ist aber erst 1-2mal vorgekommen.
Und der Sender resetet sich einfach.

Beide Abstürze kommen ziemlich gleichzeitig, d.h. in gleichen Abständen
vor.

Hat irgendwer eine Idee, was da sein könnte? Vielleicht falsche
Einstellungen bei hw- und swstack? Hab mich damit schon gespielt - kommt
aber nix brauchbares raus!

Vielleicht kann mir irgendwer weiterhelfen!

THX Andy

@Claude

naja also das Senden ging einwandfrei. (Getriggert über nIRQ) aber
empfangen habe ich immer nur mist bzw: 0xFF. Ka wieso.

Momentan geht aber die Uni wieder vor und ich habe momentan keinen
wirklichen Verwendungszweck für die Teile, deshalb lass ich es etwas
schleifen...

Eigentlich wollte ich einen ultra leicht empfänger für Flugmodelle damit
bauen, aaaaber die Reichweite (die im Datenblatt mit 150m angegeben
wurde) ist mir dann doch eteas zu gering... Auch wenn ich schon eine
Platine anfertigen hab lassen, die mit ATmega48 und Pinout (also Prog
Anschluss + 4 Servos) nur 19x19mm hat....

Jürgen

Naja weil du wenn du direkt in deine TV karte rein gehst, sehr leicht zu
Leistung auf den Eingang legen kannst und ihn dadurch kaput machen
kannst.

> Is sowieso ein uraltes Ding und wird ohnehin nicht mehr verwendet.
> Reicht aber um festzustellen, ob der Sender funktioniert.

... dazu reicht auch ein 16..17cm langes Stück Draht am Sender und eine
Zimmerantenne oder ein weiteres Drahtstück an der TV-Karte. Damit kannst
Du den Sender testen, ohne gleich die Karte aufs Spiel zu setzen.

Ja gut so weit war ich auch schon. Nur das ich eben den SPI mit voller
Geschwindigkeit laufen hab lassen. Nur ging dann das Empfangen nicht
mehr. Und ich hatte das warten dann über den nIRQ bin gelöst. Wieso hast
du eigentlich meine Async routinen weg gemacht?! Ist doch wesentlich
besser wenn der CPU nicht blockiert oder?!

Ahm als CRC Start Polynom hab ich jetzt einfach die 0x0000 genommen. Ich
denke wenn man da ein anderes nimmt kann man Fehler besser dedektieren,
das muss ich mal nachlesen...

Jürgen

Jürgen: Eine Funkfernsteuerung für Modellflieger würde ich lieber auf 27
MHz machen (das ist die "Spielzeugfrequenz"...)

Aber dafür gibt es glaube ich keine Fertigmodule. Gibt es überhaupt
TX/RX Module für Modellfunk? Also nur rein zur Signalübertragung, keine
Aufbereitung etc.

Naja also die Flugfrequenzen sind 35 bzw 40Mhz. Aber gut da is die
Reichweite halt mal >500m. Deswegen hab ichs auch sein lassen. Mich hat
halt nur das Gewicht und die Größe interessiert und das ich dann am
Modell alles selber gemacht hätte.... Aber gut ich hab eh ned so viel
Zeit G

Hallo,

Also habe nun das Senden und Empfangen von Daten getestet, funktionieren
mit einen Mega8, Mega88 und Mega32. Mal sehen was passiert wenn man den
SPI-Bus höher taktet. Ich werde auch bald eine Interruptroutine
benutzen, ist besser als Polling, habe auch noch irgendwo schon einen
fertigen Ringbuffer für Senden und Empfangen herumliegen.

Gruss
Ulrich

Hallo@Marius Schmidt

Natürlich gibt es nur Sendemodule für 27 und 35MHZ Band z.B. hatte ich
mal eins von Graupner habe dann mit einen Mega88 das RC SummenSignal
erzeugt und auf den Sender gegeben. Den SourceCode dafür habe ich sogar
auf meiner HP. Für den Empfang baue ich mir immer die Module um.

Gruss
Ulrich

Moins,

bin auch gerade am Spielen mit den RFM12. Eigentlich wollte ich damit
eine RS232-Verbindung verlängern, muß nun aber in diesem Thread
betroffen zur Kenntnis nehmen, daß die Module nicht gleichzeitig senden
und empfangen können.
Gibt es noch Hoffnung (hab ich vielleicht was falsch verstanden)?
Die Funkverbindung soll transparent für die jeweilige Applikation sein,
d.h. wenn die Anwendung eine full-duplex-Verbindung erwartet, muß die
Funkstrecke das realisieren.
Hat hier jemand eine gute Idee, ob sowas mit den RFM12 prinzipiell
überhaupt zu realisieren wäre? Wie schnell kann so ein RFM12 zwischen
den Betriebsarten Senden und Empfangen umschalten?
Würden sich zwei Funkstrecken mit RFM01 und RFM02 gegenseitig ins Gehege
kommen?

Fragen über Fragen...

Gruß
Horst

Hallo@all,

Hier die komplette Zusammenfassung des SourceCodes.

Gruss
Ulrich

@ Horst Meier
Du hast 2 Möglichkeiten:

1) Du sagst das das eine 38k4 oder 56k6 Verbindung ist und läßt die
Funkstrecke selbst mit 115k2 laufen (also mindestens doppelt so schnell
wie die Kabel Verbindung).
Oder
2) Du nimmer 2 Einheite pro Seite und gibt ihnen nicht gegenseitig
stöhrende Sende/Empfangs Freq. Also z.B. das eine Paar 500kHz mehr als
dem anderen.



Hmm oder
3) Du arbeitest mit Handschaking und/oder mit einem Buffer der groß
genug ist.



Jürgen

Hallo Leute,
Ich lese mit meinen Bascomcode über ein Interrupt meine RXD-Strings
ein.Soweit so gut.Kann also mit ein Terminalprogramm mein Text
von rf12 zu rf12 senden.
Jetzt soll jeder rf12 mit Empfang starten,nach übertragen der Strings
zum Controller (m8) auf Senden umschalten. Benötigt der rf12 zum
umschalten Empfang-Senden ein Reset,oder wie macht Ihr das generell.

Wigbert

Wigbert: nur ein Gedanke sende doch ein Code, damit er umschaltet

Hallo Avr Nix,
das Problem ist ,glaub ich das bei Empfang die Schleife nicht
beendet wird.Er wartet das ein Pin H wird.Wollte mal wissen ob das
warten
zeitlich begrenzt wird, oder Reset oder ?

Wigbert

Wenn ein Reset geben soll - vielleicht den Watchdog einschalten wird der
nicht immerhalb von max 2sek zurückgesetzt wird ein REset gemacht.

Oder die lässt einen Zähler hochlaufen bis er einen Wert hat und
springst dann raus.

Ich hoffe ich habe dich richtig verstanden.

hi

bin auch gerade an den RFM12 Modulen. Habe das gleiche Problem wie schon
andere beschrieben haben. Senden scheint zu funktionieren, nur empfangen
nicht. Auch bei mir bleibt die Empfängerseite in der Funktion
rf12_ready() hängen.

Den Sender konnte ich heute ein wenig in der Uni testen (OSZI). Der
Sender schaltet den CLK auf 10Mhz um und wenn ich die Messspitze an die
Antenne halte sieht es wie im Bild zu sehen aus.

Wie geht ihr bei testen vor?

hab ich ganz vergessen;   kann mir jemand erklären was ich da auf dem
Oszi sehe?

Claude: Versuch doch mal Sound abspielen zu lassen, das wär doch mal was
:)

so klingt es wenn ich meine TV-karte auf 433,93MHz stelle. Viel rauschen
und im Sekundentakt ein klicken oder piepen. Mein Sender sendet also.

Mit dem empfang bin ich auch noch nicht weiter. Ich wollte es eigentlich
vermeiden noch extra die Interruptleitung zu verwenden. Habt ihr noch
andere änderungen vorgenommen? Also ich habe jetzt
- rf12.c aus dem erten beitrag
- in der rf12_ready() nop's eingefügt und den timeout von JBecker
- in der main() die Warteschleife verkürzt;

Bringt es was, wenn ich die Baudrate verkleiner?
Hat der Kontroller eingentlich ein Register das ich nur auslesen kann,
Revisionsnummer oder so? Vieleicht ist ja mein SDO im A**.

Hallo Leute,
habe Marvin seine Interrupt-Empfangscode (Ffit an Int1)
eingebaut. Emfange aber nur das 1.Zeichen und noch irgendeins.
Hardwaremässig sollte dann alles ok sein.
Versaut mir das Print das Zeitfenster?
und wo bleibt rf12_ready

Wigbert

Hallo Leute,
selbstverständlich funktioniert Marvin sein Interrupt-Code
Man muss ihn nur richtig einbauen. schäm.

Enable Interrupts 'Interrupts global zulassen

sollte nicht fehlen.

Wigbert

Hallo alle
Ich kriege die Verbindung der Module einfach nicht hin.
Deshalb stelle stelle hier mal meine Sende und Empangsroutine ein, mit
der Bitte mal rüber zu sehen, was an der Konfiguration nicht passt.
Original-Listings im Anhang

Empfänger:
nSEL=1    ; Grundzustand der Selekt-Leitung
SCK=0    ; Grundzustand der Clock -Leitung
nSEL=0    ; Modul selektieren
Initialisieren:
  C2E0  CLK: 10MHz
  C42B Data Filter: internal
  CE88  FIFO mode
  C6F7 AFC settings: autotuning: -10kHz...+7,5kHz
  E000 disable wakeuptimer
  CC00 disable low duty cycle
  A640   set freqenz
  C823  baudrate
  898A Bandbreite
  C0C1 RX on
  CE89 FIFO
  CE8B enable FIFO
Statusregister und FIFO auslesen:
SEL=1    ; Grundzustand der Selekt-Leitung
SDI=0    ; Datenleitung auf Lo
nSEL=0    ; Modul selektieren
16 mal SCK auf High und wieder auf Lo setzen für Statusregister aus SDO
lesen
8 mal SCK auf High und wieder auf Lo setzen für FIFO aus SDO lesen

Sender:
nSEL=1    ; Grundzustand der Selekt-Leitung
SCK=0    ; Grundzustand der Clock -Leitung
nSEL=0    ; Modul selektieren
Initialisieren an SDI:

  CC00  ? was macht das?
  8B61   Config. Setting commands (CLK - Pin - Frequenz, ...)
  A640   Semdefrequenz
  D040   ????
  C823   Baudrate
  C220   enable TX, ...
  C038   Power - Amp., Disable CLK-Pin, ...
4 mal 0xAA (preamble) an FSK
Frame 0x2DD4 an FSK
Daten zum Senden an FSK schicken
 Beim übertragen der Daten an SDI habe ich eine Warteschleife eingebaut,
beim übertragen an FSK frage ich den IRQ - Pin ab.

Hallo,

Ich hab da wieder mal eine Frage! Und zwar will ich das RFM12 als Sender
und Empfänger nutzen. Und zwar soll das Modul etwas senden und dann in
den Empfangsmodus wechseln. Aber wann und wie schalte ich auf Empfänger
um? Ich habe einmal probiert, gleich nach dem Senden mit:

Temp = Rf12_trans(&H82c8)
Temp = Rf12_trans(&Hca81)
Temp = Rf12_trans(&Hca83)

auf Empfang zu schalten, aber das hat nicht so recht funktioniert!

Wie stelle ich das richtig an??


THX... Andy

Hab jetzt auch zwei RFM12 + ATmega8 am laufen. Software ist die von
Jürgen Eckert.

Könnten alle, die an der Firmware weiterentwickeln bitte jeweils die
aktuellste Version hier verlinken:
http://www.mikrocontroller.net/articles/AVR_RMF12#Software

Dann muss man nicht immer den ganzen Thread durchsuchen.

Ulrich hat das Lbr noch etwas erweiter. (Hardware SPI)
Das sollte auch noch mit rein.

Jürgen

Hallo,

Da ich noch einen Fehler hatte hier der aktuelle Source von mir.

Gruss
Ulrich

hallo,

Sollte SPSR &=~(1<<SPI2X) sein.
Da aber das SPSR Register sowieso 0x00 nach dem einschalten ist ist die
Zeile auch überflüssig.

Gruss
Ulrich

Hallo zusammen,

Also ich hab ja jetzt alles zusammen. Das Pollin Evaluations-Board und
den RFM12. Die hier herunterladbaren Bascom-Beispiele laufen nicht
darauf. (So wird nirgends PortD.4 eingeschaltet (und das RFM12 bekommt
so auch keinen "Saft")
Bevor ich jetzt  das Rad komplett neu erfinde:

Hat jemand einen laufenden Code für das Evaluations-Board?

(Mir reicht ja schon ein einfaches Beispiel, das nur sendet.)
Pollin hat da ja leider gar nix parat...

Wolfgang

Hallo Wolfgang,
der Code von Bastelbär(blätter mal hoch)funktioniert.
Wobei bei dem Pollinboard gibt es mit den Optokoppler probleme.
Ich hab Ihn durch eine Brücke ersetzt.Würde mal Deine Erfahrung
dazu gerne lesen.

http://www.roboternetz.de/phpBB2/viewtopic.php?t=30824

Wigbert

Hallo,

Mit dem Optokoppler hatte ich die gleichen Probleme. Spannung am RM12
Module brach zusammen. Habe dann den Optokoppler durch einen
Jumperbrücke ausgetauscht.

Gruss
Ulrich

@wigbert, @radiguli

Vielen Dank, da werde ich mir wohl heute Abend auch nen Jumper
einbasteln. Mal schauen ob ich heute noch dazu komme. Melde mich auf
jeden Fall mit dem Ergebnis!

Schöne Woche

Wolfgang