Forum: Mikrocontroller und Digitale Elektronik PIC16f15244 RFM69 sendet nicht


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frederic B. (freddyskyline)


Angehängte Dateien:

Lesenswert?

Moin zusammen,

für ein Hochschulprojekt sollen Distanzmessungen an einem Pic an einer 
Stelle erfolgen und mittels RFM69HCW (433 MHz) an einen ESP32 gesendet 
werden, der diese Daten zusammen mit einem Videobild über einen 
Webserver zur Verfügung stellt.

Soweit so gut, funktioniert alles - lediglich der RFM69 bereitet uns 
Kopfschmerzen. SPI ist konfiguriert und das Auslesen von Daten aus 
einzelnen Registern funktioniert ebenfalls. Die vom RFM (slave) an den 
Master gesendeten Daten kommen nur nicht im Buffer des Pic an, die 
Kontrlle mittels Logic analyzer zeigt aber, dass der RFM69 die korrekten 
Daten (Standardwerte; aus Datenblatt entnommen) sendet.

Da wir sowieso von dieser Stelle nur senden wollen, war das aber kein 
Beinbruch. Jetzt ist es aber so, dass der RFM am Pic keinen Mucks macht. 
Es sollen recht simple Daten übermittelt werden ( 1 Byte) im Package 
mode. Dazu wird der RFM zuerst in den Standby Mode gesetzt, anschließend 
wird ins FIFO Register geschrieben und mittels Einstellung auf TXmode 
die Daten abgesendet. Beim Receiver kommt allerdings nicht an und es 
schaut auch so aus, als würde nichts gesendet werden (Spymode auf dem 
Receiver bleibt ebenfalls still).

Die verwendete Konfiguration ist identisch zu einer funktionierenden 
Config eines weiteren ESP32, der zum Testen genutzt wurde. Dort können 
zwischen ESP1 und ESP2 problemlos Daten getauscht werden. Wird ein 
ähnlicher Code auf dem Pic implementiert, bleibt es still.

Vielleicht ist hier ja ein RFM69 Experte, der einmal unseren Code auf 
Fehler prüfen kann.



Fosc am Pic ist 1 MHz, optional auf 32 Mhz verstellbar und getestet. 
Entsprechend läuft der SPI auf 250 kHz.

Selbst nach dem zehnten Wälzen des Datenblattes werde ich nicht 
schlauer. Für hilfreiche Antworten bedanke ich mich schon einmal im 
Voraus.

: Bearbeitet durch User
von Max M. (prokrastinator)


Lesenswert?

Der PIC klassiker ist es die pins nicht explizit auf digital in zu 
stellen.
Auch wenn Du den ADC oder sonst was an dem multifunction pin nicht 
benutzt, grätscht der rein und kann die lustigsten Sachen machen.
Teilweise halb funktionieren HW ohne jede logig.
Kann man sich totsuchen.

Hatte das auch mal mit PIC und SPI.
Schau Dir an was auf dem Pin sonst noch liegen könnte und schalte alles 
was diesen Pin betrifft in die richtige Betriebsart.
Alte PIC Krankheit über die fast jeder schon mal gestolpert ist.

von Franko P. (sgssn)


Lesenswert?

Jo, wie Max schon geschriebn hat:

siehe Datenblatt Kapitel 16.5 ANSELx - Analog Control
Notfalls:
ANSELB = 0; und alles ist digital

Gruß

von Frederic B. (freddyskyline)


Lesenswert?

ANSELB sitzt auf 0.
Verwendet werden hier RB4 als Clock, RB6 MISO, RB7 MOSI und RC7 chip 
select. Dort könnte jetzt noch maximal ein Interrupt on Change 
passieren, der aber definitiv nicht konfiguriert ist. Lediglich der RC0 
wird mit IOC genutzt.

Leider keine Besserung bis jetzt. Das Datenblatt des RFM finde ich auch 
recht schlecht strukturiert. Nirgendwo ist im Klartext geschrieben, wie 
so eine Senderoutine step by step auszusehen hat. Ich vermute dort einen 
Fehler. Wie gesagt: Die Funktion rfm_test() liest aus dem Register 0x10 
und bekommt die erwartete 0x24 zurück. Diese landet nur komischerweise 
nicht im Buffer des PIC. Die Kommunikation an sich läuft also. Nur 
senden will er nicht und mir sind so langsam die Ideen ausgegangen.

von Franko P. (sgssn)


Lesenswert?

Was steht in dem SSP1CON2 Register? Ist da RCEN=1 ?

Gruß

von Max M. (prokrastinator)


Lesenswert?

Frederic B. schrieb:
> Diese landet nur komischerweise
> nicht im Buffer des PIC

Debugger mit Einzelschritt und bei jedem Schritt die Register ansehen.
Breakpoints setzen, schauen ob er durch die Routinen läuft oder irgendwo 
festhängt.

Schau Dir Miso, Mosi, CLK und SS mit dem Logiganalyser an.
An welcher Flanke wird ausgegeben und an welcher wird gesampelt?
Muss passen.

Schau Dir die PIC Register nochmal genau an.
Musst Du z.B. den Buffer lesen, damit ein Bit rückgesetzt wird, weil er 
sonst kein weiteres Wort empfängt?
Es sind solch kleine Sachen an denen man sich festbeisst.

PIC ist Master, RFM der Slave?

von Franko P. (sgssn)


Lesenswert?

ach, Blödsinn, kann den Beitrag nicht löschen. SSp1COn2 ist nur für 
I2C...

von Max M. (prokrastinator)


Lesenswert?

Frederic B. schrieb:
> Nur
> senden will er nicht

???
Ich habe Dich so verstanden das der RFM sehr wohl sendet, das auch am 
PIC ankommt, aber bei Dir nicht im SSPxBUF Register ankommt.

Das Bild auf S250 des PIC DB hast Du gesehen?
Es gibt nur ein SSPxBUF für senden UND empfangen.
Nicht das Du Dir selbst den Buffer löscht ...
Der PIC muss was senden um empfangen zu können.

von Frederic B. (freddyskyline)


Angehängte Dateien:

Lesenswert?

@Franko

SSP1CON2bits.RCEN ist 0.

@Max

Da kommen wir zum nächsten Problem, das mich schon das ganze Projekt 
begleitet. Das PICkit4 unterstützt zwar das Schreiben, der Debugging 
Mode funktioniert allerdings nicht mit 16F15244. Debugging ging also nur 
per UART und LED. Mein Prof. saß da auch einige Zeit dran und  kam auch 
nicht zur Lösung (Manchmal liest er hier mit, hallo :)  ). Und danach 
habe ich mir auch keine Hoffnung mehr gemacht, das Debugging zum laufen 
zu kriegen.

Habe mal ein Bild vom Analyzer angehängt. Hier wird das Register 0x10 
adressiert und prompt kommt die Antwort (für die natürlich dummydaten 
gesendet wurden).

Laut Datenblatt des RFM soll ja CPOL=0 und CPHA = 0 sein. Ist so 
eingestellt (wenn ich nicht Irre) und funktioniert, wie ihr ja an der 
Antwort des RFM sehen könnt.

Dass es nur einen Buffer gibt, habe ich gesehen. Nach der Testroutine 
bleibt der Buffer trotzdem leer.

Die Funktion sieht ja wie folgt aus:
1
 void rfm_test () {  //should return 0x24 on miso
2
    
3
    LATCbits.LATC7 = 0;  // pull down chip select 
4
    SSP1BUF = 0x10;
5
    while (!SSP1STATbits.BF);
6
    SSP1BUF = 0x00;
7
    while (!SSP1STATbits.BF);
8
    LATCbits.LATC7 = 1;  // pull up chip select

Danach sollten die Daten ja im Buffer liegen. Tun sie aber nicht. Oder 
habe ich hier einen Denkfehler? Aber nichtsdestotrotz brauche ich die 
Empfangen Funktion nicht. Wäre nice2have, aber muss nicht sein für die 
Funktion - höchstens nochmal zum Auslesen der Einstellungsregister wäre 
es ganz gut.

RFM69 ist Slave, PIC ist Master - ja.

von Frederic B. (freddyskyline)


Lesenswert?

Max M. schrieb:
> Ich habe Dich so verstanden das der RFM sehr wohl sendet, das auch am
> PIC ankommt, aber bei Dir nicht im SSPxBUF Register ankommt.


Korrekt. Habe mich wohl missverständlich ausgedrückt. Was ich damit 
meine ist, dass der RFM die Daten, die ich ins FIFO schreibe nicht per 
Funk versendet. Es bleibt einfach still.

Also nochmal zusammengefasst: Daten per SPI an RFM schicken --> Läuft. 
RFM per SPI an PIC--> läuft.

 Vom RFM gesendete Daten aus Buffer des PIC holen--> läuft nicht. An RFM 
gesendete Daten, die zu übertragen wären, per Funk losschicken --> läuft 
nicht.

: Bearbeitet durch User
von Franko P. (sgssn)


Lesenswert?

Wenn ich nicht mehr weiterkomme, versuch ichs immer mal mit dem MCC von 
MPLAB X. Lass dir doch mal den Code für SPI erzeugen und schau was der 
dir da fabriziert.

Gruß

von neuer PIC Freund (Gast)


Lesenswert?

Bitte nochmal in Kapitel 18 schmökern.

Ohne PPSLOCK-Prozedur schreibt es sich schlecht auf RxyPPS.

Gruß

von Franko P. (sgssn)


Lesenswert?

Das könnte aber tatsächlich falsch sein:

SSP1DATPPS = 1;

lt datenblatt Kapitel 18.8.1 xxxPPS

müsste da stehen
SSP1DATPPS = 0x0e; (001 PORTB + 110 PORTx Pin 6 (Rx6)

Wie kommst du auf 1?

: Bearbeitet durch User
von Frederic B. (freddyskyline)


Lesenswert?

So, hatte die letzten Tage mit Klausuren und einem anderen Projekt viel 
zu tun. Danke für eure Antworten, habe das mal getestet und entsprechend 
korrigiert.

Zitat aus dem Datenblatt:

>The PPSLOCKED bit is clear by default (PPSLOCKED = 0), which allows the PPS 
selectionregisters to be modified without an unlock sequence.


PPS Unlock sequence ist also nicht nötig.
Bei dem SSP1DATPPS war ich mir nicht sicher. Habe entsprechend 
korrigiert.

Trotzdem vermute ich den Fehler nach wie vor irgendwie in der 
Ansteuerung des RFM - nicht im SPI selbst. Dieser funktioniert ja.

Noch jemand eine Idee?

: Bearbeitet durch User
von Frederic B. (freddyskyline)


Lesenswert?

@Franko

Der Tipp mit dem SSP1DATPPS hat auf jeden Fall dazu geführt, dass bei 
mir im SPI Buffer die Daten ankommen, die ich erwarte. Das bestätigt 
erneut meine These, dass die Grundlegende Kommunikation funktioniert. 
Wenn ich 0x10 adressiere liegt anschließend, wie erwartet, 0x24 im 
Buffer.

Trotzdem kriege ich den Transmitter nicht ans senden. Habe zwischendurch 
nochmal geprüft, ob es an Masse und Versorgung liegen kann. Dazu habe 
ich auf einem anderen Board (PCB, kein Breadboard - versorgt mittels 
DC-DC Booster und einer 18650 Li-Ion) den Code hochgeladen. Gleiches 
Spiel --> Kein Signal.

Irgendwo im Code, bzw in meiner Konfiguration muss ein Fehler verborgen 
sein. Und ich finde ihn einfach nicht. RIP

von Franko P. (sgssn)


Lesenswert?


: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.