TX und RX Kommunikation PIC16F688

[Stefan H. (stefan_h68)]

Guten Morgen,
ich habe wieder mal eine Frage, und zwar habe ich ein kleines Programm 
geschrieben, um die serielle Kommunikation meiner beiden PIC16F688 zu 
testen. Hier mein C-Programm:

Sender:

#include <htc.h>              //include header file
#include <pic16f688.h>            //include PIC header
#ifndef _XTAL_FREQ  
#define _XTAL_FREQ 4000000
#define FOSC_INTOSCIO        0xFFFC      //set internal oscillator I/O function on RA4/OSC2/CLKOUT and RA5/OSC1/CLKIN
#define WDTE_OFF             0xFFF7      //disable Watchdog Timer
#define MCLRE_OFF            0xFFDF      //MCLR pin function is digital input, MCLR internally tied to VDD
#endif

void main (void)
{
  char byte;

  ANSEL = 0b00000000;            //All I/O pins are configured as digital 
  CMCON0 = 0b00000111;          //Comperators turned OFF
  PORTC = 0b00000000;          
    TRISC = 0b00000000;            
  SPBRG = 32;               
    BRG16 = 0;               
  TXEN = 1;
  SYNC = 0;
  SPEN = 1;
  TXSTA = 0b00100000;
  RCSTA = 0b10000000;

  while(1) {
    byte = 0xAF;
    TXREG = byte;
  }
}

Empfänger:

#include <htc.h>              //include header file
#include <pic16f688.h>            //include PIC header
#ifndef _XTAL_FREQ  
#define _XTAL_FREQ 4000000
#define FOSC_INTOSCIO        0xFFFC      //set internal oscillator I/O function on RA4/OSC2/CLKOUT and RA5/OSC1/CLKIN
#define WDTE_OFF             0xFFF7      //disable Watchdog Timer
#define MCLRE_OFF            0xFFDF      //MCLR pin function is digital input, MCLR internally tied to VDD
#endif


void main (void)
{
  ANSEL = 0b00000000;            //All I/O pins are configured as digital 
  CMCON0 = 0b00000111;          //Comperators turned OFF
  PORTC = 0b00000000;          
    TRISC = 0b00000000;            
  SPBRG = 32;               
    BRG16 = 0;                 //8 bit generator.
  CREN = 1;
  SYNC = 0;
  SPEN = 1;
  TXSTA = 0b00100000;
  RCSTA = 0b10010000;

  while(1) {
    if ( RCREG == 0xAF ) {
      PORTC == 0b00000001;
    }

    
  }
}

Leider funktioniert das Programm nicht und ich kann meine Fehlerquelle 
nicht finden. Ich hoffe ihr könnt mir helfen.
Mein Ziel ist es, am Senderpic ein Signal auszugeben, das der 
Empfängerpic erkennt und dann einen Port High schaltet.

Vielen Dank im vorraus.
MfG Stefan

[Martin (Gast)]

Auf den ersten Blick ist mir folgendes aufgefallen:

PORTC == 0b00000001;

Mit == wird der Port verglichen und nicht gesetzt. Zum setzen des Ports 
= verwenden.

[Stefan H. (stefan_h68)]

Martin schrieb:
> Mit == wird der Port verglichen und nicht gesetzt. Zum setzen des Ports
> = verwenden.

Danke, es schleichen sich halt immer wieder kleine Fehler ein :D
Nur habe ich jetzt das Problem, dass der Port nicht Konstant auf High 
geschaltet. Wie kann ich das den bewerkstelligen?

[Karl H. (kbuchegg)]

Stefan H. schrieb:
> Martin schrieb:
>> Mit == wird der Port verglichen und nicht gesetzt. Zum setzen des Ports
>> = verwenden.
>
> Danke, es schleichen sich halt immer wieder kleine Fehler ein :D
> Nur habe ich jetzt das Problem, dass der Port nicht Konstant auf High
> geschaltet. Wie kann ich das den bewerkstelligen?

Wenn der mit DEM Programm nicht dauerhaft auf High-schaltet, dann gibt 
es dazu eigentlich nur eine Möglichkeit: dein µC stürzt laufend ab. Denn 
innerhalb der while-Schleife gibt es keine Möglichkeit, wie der Port 
jemals wieder von 0x01 auf irgendwas anderes geschaltet werden könnte.
Nach einem Absturz allerdings wird der Port, weil ja das Programm wieder 
von vorne erneut losläuft, tatsächlich auf 0 geschaltet.

[Stefan H. (stefan_h68)]

Karl Heinz Buchegger schrieb:
> Denn
> innerhalb der while-Schleife gibt es keine Möglichkeit, wie der Port
> jemals wieder von 0x01 auf irgendwas anderes geschaltet werden könnte.

Das habe ich mir auch schon gedacht, nur warum stürzt er denn ab? An was 
kann das liegen und wie kann ich das verhindern?

Edit: Oszi zeigt, dass die Zustandsänderungen nicht regelmäßig sind, 
schließt das dann ein Abstürzen des PICs denn nicht aus?

[Karl H. (kbuchegg)]

Stefan H. schrieb:
> Karl Heinz Buchegger schrieb:
>> Denn
>> innerhalb der while-Schleife gibt es keine Möglichkeit, wie der Port
>> jemals wieder von 0x01 auf irgendwas anderes geschaltet werden könnte.
>
> Das habe ich mir auch schon gedacht, nur warum stürzt er denn ab? An was
> kann das liegen und wie kann ich das verhindern?

Das weiß ich nicht. Ich such mir jetzt nicht auch noch die PIC 
Datenblätter zusammen um zu identifizieren, was deine Binärzahlen 
eigentlich so alles freischalten. Einen Interrupt vielleicht, der nicht 
behandelt wird?

> Edit: Oszi zeigt, dass die Zustandsänderungen nicht regelmäßig sind,
> schließt das dann ein Abstürzen des PICs denn nicht aus?

Dein Sendecode ist ja auch alles andere als regelmässig. Einfach Bytes 
nach gutdünken willkürlich in die Register stopfen während die USART 
noch beschäftigt ist .... ich kenn eigentlich keine Architektur, auf der 
man das so machen kann. Aber gut, ich kenn auch nicht alle.

Mach halt folgendes:
Nimm einen Pin .. kabel eine LED drann und im main() ehe es in die while 
Schleife reingeht schaltest du die LED für 1 Sekunde ein und wieder aus. 
Wenn dann im laufenden Betrieb die LED mal aufleuchtet, dann weißt du, 
dass es einen Reset gab.

[Chris B. (dekatz)]

Die UART-Initialierung ist eigentlich OK, aber wie schon angesprochen - 
das permanente "Befeuern" von TXREG mit Werten ohne auf den Sendestatus 
zu achten ist nicht die "normale" Art...
TXSTA.TRMT testen (Transmit Shift Register Status bit:0 = full, 1 = 
empty)

[Stefan H. (stefan_h68)]

Karl Heinz Buchegger schrieb:
> Dein Sendecode ist ja auch alles andere als regelmässig. Einfach Bytes
> nach gutdünken willkürlich in die Register stopfen während die USART
> noch beschäftigt ist .... ich kenn eigentlich keine Architektur, auf der
> man das so machen kann. Aber gut, ich kenn auch nicht alle.

Ich kann es leider noch nicht anders, da ich noch nicht allzulange in C 
programmiere.

Karl Heinz Buchegger schrieb:
> ch such mir jetzt nicht auch noch die PIC
> Datenblätter zusammen

Das erwarte ich auch nicht von dir :)

Chris B. schrieb:
> TXSTA.TRMT testen (Transmit Shift Register Status bit:0 = full, 1 =
> empty)

Was genau meinst du damit?
Wäre nett, wenn ihr mir vielleicht einen kleinen Beispielcode geben 
könntet, an dem ich mich "entlanghangeln" kann, um zu lernen.

Vielen Dank

[Chris B. (dekatz)]

while( !TXSTA.TRMT);
wartet bis TXSTA.TRMT auf "1" ist - also der Senderegister leer ist.
Ein Beschreiben von TXREG überschreibt das Senderegister und startet 
eine neue Übertragung.
Wie jetzt TXSTA, TXREG und das "Transmit shift register" genau verknüpft 
sind und sich gegenseitig enablen/disablen ....siehe Datenblatt!

[Stefan H. (stefan_h68)]

Karl Heinz Buchegger schrieb:
> Mach halt folgendes:
> Nimm einen Pin .. kabel eine LED drann und im main() ehe es in die while
> Schleife reingeht schaltest du die LED für 1 Sekunde ein und wieder aus.
> Wenn dann im laufenden Betrieb die LED mal aufleuchtet, dann weißt du,
> dass es einen Reset gab.

Hab ich jetzt mal probiert und ja, mein Programm bleibt einfach nicht in 
der while(1){}
aber warum das? Hab jetzt schon den ganzen morgen sämtliche 
Einstellungen am PIC ausprobiert, aber er bleibt einfach nicht in der 
Loop. Könnt Ihr mir helfen?

[Chris B. (dekatz)]

Möglich das der Controller dauern Resetet (Watchdog).
Ich glaube nämlich nicht, das der Controller damit Configuriert wird:
.....
#define FOSC_INTOSCIO        0xFFFC
#define WDTE_OFF             0xFFF7
#define MCLRE_OFF            0xFFDF
.....

Beim HTC-C sieht das so aus (nur Beispiel):
#include <htc.h>
__CONFIG(WDTDIS & HS & UNPROTECT);
usw....

Oder du machst es aus der ID (MPLAB) heraus mit "config -> Configuration 
bits"...

Denn am Simulator laufen die beiden Beispiele - zumindest in Bezug auf 
Abarbeitung der while-Konstruktion!

[Stefan H. (stefan_h68)]

Chris B. schrieb:
> Ich glaube nämlich nicht, das der Controller damit Configuriert wird:

Ja, du hattest recht, danke. Habe es mit configuration bits probiert und 
siehe da, er bleibt in der while(1){}.

Chris B. schrieb:
> Denn am Simulator laufen die beiden Beispiele - zumindest in Bezug auf
> Abarbeitung der while-Konstruktion!

Wo gibt es denn einen solchen Simulator? Könnte mir echt helfen in 
zukunft, so muss ich es immer aufbauen und ausprobieren. Was an sich ja 
nicht schlimm ist.

Noch eine Idee, wie ich es mit der UART besser hinbekomme?

[Chris B. (dekatz)]

Der Simulator ist in der IDE (MPLAB bzw. MPLABX) von MICROCHIP 
integriert.
Und der HIGHTECH Compiler wird von MPLAB(X) auch unterstützt.

[Stefan H. (stefan_h68)]

Hi, ich habe jetzt mal meinen Code angepasst und habe nun folgendes:

#include <htc.h>              
#include <pic16f688.h>            
#ifndef _XTAL_FREQ  
#define _XTAL_FREQ 4000000
#endif

/* Transmitter */

        

void Init(void)  {
  RCSTA  = 0b10010000;
  TXSTA  = 0b00100110;  
  SPBRG  = 25;      
  RCREG  = 0;        
  RCIE  = 1;        
}

void PutChar(unsigned char input)  {
  while( !TXIF )  {
    continue;
  }
  
  if ( RC0 == 1 ) {
  TXREG = input;
  }
  while( !TRMT )  {
    continue;
  }
}

void main()  {
  
  ANSEL = 0x00;         
  CMCON0 = 0b00000111;                    
  PORTA = 0x00;
  PORTC = 0x00;
    TRISC = 0x00;          
  TRISA = 0x00;
  RA0 = 1;
  _delay( 100000 );            
  RA0 = 0;            
  _delay( 100000 );


  while (1) {
    Init();
    PutChar(0xAF);
  }
}

#include <htc.h>            
#include <pic16f688.h>            
#ifndef _XTAL_FREQ  
#define _XTAL_FREQ 4000000
#endif

/* Reciever */

void Init(void) {  
  BRGH = 1;
  SPBRG = 25;  
  SPEN = 1;
  SYNC = 0;
  CREN = 1;
  SPEN = 1;
  RCREG = 0;
  RCIE = 1;
  RCSTA  = 0b10010000;
  TXSTA  = 0b00100110;
  OERR = 0;
}


void main()  {
  ANSEL = 0x00;            
  CMCON0 = 0b00000111;          
  PORTC = 0x00;
  PORTA = 0x00;          
    TRISC = 0x00;
  TRISA = 0x00;            
        
  _delay( 1000000 );          
  RA0 = 1;          
  _delay( 100000 );          
  RA0 = 0;            
  _delay( 100000 );          
  while (1) {
    Init();  
    while ( RCREG == 0xAF ) {    
      RC0 = 1; 
    }
    RC0 = 0;
  }
}

Die Übertragung und das Auslesen des RCREG des Recievers funktioniert 
Problemlos, also mein RC0 am Reciever schaltet auf High.
Mein Problem ist nun, dass er nicht mehr auf Low schaltet, sobald der 
Transmitter das Signal nicht mehr sendet.
Meine Überlegung war nun, dass das RCREG nicht Resettet wird, und er 
somit in der while ( RCREG.... feststeckt. Was kann ich da tun? Wenn ich 
innerhalb der while(RCREG... die Init nocheinmal aufrufe, oder CREN = 0; 
schreibe, funktioniert das auch nicht.

An was kann das sonst noch liegen? Oder hab ich irgendetwas falsch 
gemacht?

[Karl H. (kbuchegg)]

Ich hätte ja gesagt, dass du das Prinzip einer UART überhaupt nicht 
verstanden hast.
So etwas beruht nicht darauf, dass der Empfänger aufs Geratewohl das 
zuletzt empfangene Byte auswertet und der Sender auf 'Dauerfeuer' gehen 
muss.

Sondern der Sender sendet 1(!) Byte, welches der Empfänger empfängt und 
darauf hin etwas macht. Will der Sender etwas anderes veranlassen, dann 
sendet er ein anderes Byte und der Empfänger empfängt es, wertet es aus 
und macht dann was anderes.

So eine UART-Verbdindung ist kein Takttrommler auf einer Gallere, in der 
die Ruderer nur dann rudern, wenn der Trommler trommelt, sondern wie ein 
U-Boot: Der Captain kriegt einen Befehl und den führt er solange aus, 
bis ein neuer Befehl eintrifft oder der Befehl eben 
erledigt/abgearbeitet ist.
Das man darüber dann natürlich noch eine Zeitsteuerung in FOrm eines 
Timeouts legen kann - sprich: wenn der Capatin 5 Tage lang von seinem 
Hauptquartier nichts gehört hat, kehrt er eigenständig in den 
Marinestützpunkt zurück - ist eine andere Geschichte, die so erst mal 
nichts mit der UART an sich zu tun hat, sondern damit wie die UART im 
Programm eingebettet wurde.


Es muss auch im PIC in irgendeinem Register ein Flag geben, welchem du 
entnehmen kannst, ob ein Zeichen auf der UART eingetroffen ist. Das ist 
zuallererst mal das Signal für dein Programm, dass im RCREG ein sinnvoll 
auszuwertendes Byte vorliegt. Und nur dann, wenn dieses Flag aussagt, 
dass ein Byte vorliegt, nur dann macht es überhaupt Sinn auf RCREG 
zuzugreifen und mit dem Byte etwas zu machen. Ob sich durch dieses 
Auslesen das Flag automatisch wieder zurücksetzt oder ob du das händisch 
tun musst, kannst du dem Datenblatt zu deinem Prozessor entnehmen. Aber 
in irgendeiner Form gibt es dieses Flag mit Sicherheit.