PIC läuft durch String viel zu langsam

[Jörg M. (joerg1)]

Hey,
bei meinen neuen Projekt versuche ich zum ersten mal einen PIC18f4550 
über ein RS232-Kabel mit meinen PC zu verbinden. Das Empfangen und 
Senden von Daten von und zum PC funktioniert erstmal super. Nur leider 
nicht mehr wenn ich das vom PC Empfangene Zeichen in einen String 
schreibe.
Das blinken an PortA0 wird deutlich langsamer (immer 1sek an und 1aus). 
Singnale an PortA1 nur noch verzögert und an PortA2 kommt garnix mehr.

Pic läuft mit 18,432MHZ

Bitte helft mir! Ich bin am Verzweifeln...

main.c

#include <htc.h>
#include <pic18f4550.h>
#include <string.h>
#include "usart.h"


// main.c
void main(void);
void delay( int ms );

char usartbuffer[25] = 0;
int usartcount = 0;

void main(void)
{
  // PORT A
  LATA = 0b00000000;
  TRISA = 0b00000000;    // Alle Ports sind Ausgänge

  // PORT B
  LATB = 0b00000000;
  TRISB = 0b00000000;    // Alle Ports sind Ausgänge

  initUSART(239);  
  /* 
  Bound 9600   = 379
  Bound 19200  = 239
  Bound 38400  = 119
  Bound 57600  = 79
  Bound 76800  = 59
  Bound 115200 = 39
  Bound 230400 = 19
  */

  while(1) 
  { LATA0=!LATA0; delay(100);
    char received = getcUSART();
    if(  received ) {
      //usartbuffer[usartcount] = received;
      LATA1=!LATA1;
      if (received=='b') { LATA2=!LATA2;  putsUSART("Test"); }  
      /*if (usartbuffer[usartcount] == '\r') {
        usartbuffer[usartcount+1] = 0;
        putsUSART(usartbuffer);
        usartcount=0;
      } else {
        usartcount+=1;
      }*/        
    }  
  }
}

void delay( int ms ) {
  int i;
  i = 0;
  //1 ms = 4608 Befehlstakte (18,432 MHz Quarz / 4)
  for( i=0; i<ms; i++ ) {
    _delay(4608);
  }   
}

usart.h

//Initialisiert die USART Schnittstelle
void initUSART(unsigned int spbrg) {
  TXSTA = 0b00001110;  //Asynchroner Mode, 8bit
  RCSTA = 0b00000000;  //Empfang konfigurieren

  RCIE = 0;  //Empfangs-Interrupt disablen
  TXIE = 0;  //Sende-Interrupt disablen

  BAUDCON = 0b1001000;    //BRG16 = 1

  SPBRG = (spbrg&0x00FF);       //Baudrate festlegen
  SPBRGH = (spbrg&0xFF00) >> 8;

  TXREG = 0;        //Schreibregister löschen
  char temp = RCREG;      //Leseregister löschen

  CREN = 1;  //Kontinuierlicher Empfang
  TXEN = 1;  //Transmitter enablen
  SPEN = 1;  //Receiver enablen

  return;
}

//Schreibt ein Byte in das Tranmit-Register und
//überträgt dieses
void writeUSART(char data) {
  TXREG = data;      // Write the data byte to the USART
}

//Prüft, ob gerade Daten über die USART-Schnittstelle
//übertragen werden
int busyUSART(void) {
  if(!TRMT) { //Prüfe, ob das Schieberegister leer ist
    return 1; 
  }       //Nein, gebe 1 zurück
  return 0;          //Ja, gebe 0 zurück
}

//Überträgt mehrere Zeichen über die USART-Schnittstelle
void putsUSART(char *data) {
int i=0;
  while (data[i]) {
    while(busyUSART() == 1) {}
    writeUSART(data[i]);  //Übertrage das Zeichen
  i++;
  }
}

//liest ein Zeichen aus dem Empfangspuffer aus
char getcUSART(void) {
  //Prüfen, ob der Empfang gültig war
  if( FERR == 1 ) {
    //Framing Error aufgetreten
    return 0;
  }
  if( OERR == 1 ) {
    //Overrun Error aufgetreten
    CREN = 0;  //Empfang ausschalten
    CREN = 1;  //und wieder einschalten, um
                  //den Fehler zulöschen und
                  //das nächste Byte zu empfangen
    return 0;
  }
  if( RCIF == 1 ) {
    //Es wurde ein neues Zeichen empfangen
    return RCREG;    //gelesenes Byte zurückgeben
  } else {
    return 0;
  }  
}

[B. S. (bestucki)]

Wo benutzt du einen string? Du hast zwar die Library eingebunden, nutzt 
sie aber nicht. Du verwendest ein char Array, was zugegebenermassen auch 
ein string ist.

Die einzige "Falle", wo das Programm stecken bleiben könnte, sehe ich in 
der Funktion putsUSART:
Du übergibst ein Array (hier ein string). Du sendest solange Zeichen, 
bis im übergebenen Array der Wert 0 steht. Am Ende eines strings steht 
jedoch immer ein '\0'. Finde heraus, was dein Programm dort wirklich 
tut. Ausserdem kann das Programm auch hier

while(busyUSART() == 1) {}

steckenbleiben

Was ich sonst noch gesehen habe:
- In der main Funktion wird nicht geprüft, ob die Variable usartcount 
grösser gleich 25 ist (ist zwar auskommentiert, vielleicht willst du's 
ja mal verwenden).
- Warum wartest du zwischen den einzelnen Zeichen immer 100ms? Bei 
19.2kbaud dauert das Senden/Empfangen eines Zeichens ca. 520us (8 Bits + 
2 Start-/Stoppbits).

[B. S. (bestucki)]

Noch was. Wenn dieser Teil nicht auskommentiert ist:

if (usartbuffer[usartcount] == '\r') {
  usartbuffer[usartcount+1] = 0;
  putsUSART(usartbuffer);
  usartcount=0;
} else {
  usartcount+=1;
}

wirst du Probleme haben. In der Funktion putsUSART werden Zeichen 
gesendet, bis der Wert 0 im Array steht. Du schreibst aber nie den Wert 
0 in das Array. Daher kann das Programm quer durch den Speicher Werte 
senden und mit etwas Glück hört es irgendwann auf.

[W.S. (Gast)]

Jörg Marschner schrieb:
> while(1)
>   { LATA0=!LATA0; delay(100);
>     char received = getcUSART();
>     if(  received ) {

Ich hasse solche Art des Quellcodeschreibens. Versuche doch wenigstens, 
nicht ständig Variablendeklarationen und deren Benutzung in einen Topf 
zu werfen. So unsäglich faul kannst du doch wohl nicht sein!

void MyBlaBla(void)
{ char received;

  while(mycondition)
  { if CharAvailable()
    { received = GetTheChar();
      DoSomethingWithIt(received);
    }
  }
}

Es ist immer eine oberfaule Sache, ein Array einfach vollaufen zu 
lassen, ohne zu prüfen, ob man damit einen Bufferoverrun verursacht. Am 
PC ist das immer noch die beliebteste Methode, um Scheunentore für 
Malware aufzureißen. Also lerne mal, einen Ringpuffer zu programmieren.

Ansonsten sieht dein Programm reichlich prozedural aus und das ist keine 
gute Sache, wenn man mehrere Dinge erledige will, z.B. Empfangen, darauf 
vor Ort reagieren und obendrein noch was senden. Für sowas solltest du 
dir einen anderen Ansatz für's Ganze angewöhnen: Ereignisorientierte 
Programmierung.

Und wozu du unbedingt 100 ms vertrödeln willst, außer zum Verpassen von 
empfangenen Zeichen, ist mir ebenfalls unklar.



W.S.

[ich bin so schön ich bin so toll ich bin EIN TROLL (Gast)]

In die Headerdatei gehören die Prototypen, nicht die ganzen Funktionen!

[Michael L. (michaelx)]

Jörg Marschner schrieb:
> Hey,
> bei meinen neuen Projekt versuche ich zum ersten mal einen PIC18f4550
> über ein RS232-Kabel mit meinen PC zu verbinden.

Nur mal so aus Neugier: Hat dein PC kein USB?
Der Rest wurde ja schon gesagt.

Grüße.

[Jörg M. (joerg1)]

Vielen Dank für die Hinweiße! Ich wird es mir zu Herzen nehmen und mich 
heut Abend gleich noch mal hinsetzen und die ganze Sache überarbeiten.
Die 100-ms-Verzögerung hab ich nur zum Debuggen einprogrammiert, um 
besser sehen zu können wann und wo meine LEDs angesteuert werden bzw. 
die Ports ein Signal ausgeben. Später soll die Verzögerung natürlich 
komplett weg.

Also dann vielen Dank ich werd euch informieren, wenn es funktioniert!

Gruß Jörg

[Jörg M. (joerg1)]

Update: Ich hab in den letzten Wochen fast alles Getestet... Ich hab mir 
extra noch 2 PICs zugelegt mit dem ergebnis das ich Daten zum Pic 
schicken kann und vom Pic zum PC. Allerdings scheinen sich die Pics alle 
zu weigern meine einzeln gesendeten Zeichen in eine Array zuschreiben 
und auf ein Enter (\r) an mich zurückzusenden...
Bitte schaut doch nochmal drüber ihr seit meine letzte Hoffnung!


PIC18F4550
18,432MHZ
9600Bound


usart.h (Ja ich weiß ich verwende den Datentyp hier falsch - bitte ni 
böse sein)

//Initialisiert die USART Schnittstelle
void initUSART(unsigned int spbrg) {
  SPBRG=spbrg;                 
  RCSTAbits.SPEN=1;          
  TXSTAbits.TXEN=1;    
  RCSTAbits.CREN=1;    
}

//Schreibt ein Byte in das Tranmit-Register und
//überträgt dieses
void writeUSART(unsigned char data) {
  while(PIR1bits.TXIF==0);       // Wait for USART
  TXREG=data;                    // Store data in Transmit register
}


//Überträgt mehrere Zeichen über die USART-Schnittstelle
void putsUSART(unsigned char *data) {
  int i=0;
  while(data[i]) {
    writeUSART(data[i]);  //Übertrage das Zeichen
    i++;
  }
}

//liest ein Zeichen aus dem Empfangspuffer aus
unsigned char getcUSART(void) {
  if(PIR1bits.RCIF!=0) {   // Wait until RCIF gets low
    return RCREG;        // Retrieve data from reception register
  }
  return 0;
}

main.c

#include <htc.h>
#include <pic18f4550.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "usart.h"

#define FREQ 18432000    // Frequency = 12MHz
#define baud 9600
#define spbrg_value (((FREQ/64)/baud)-1)    // Refer to the formula for Baud rate calculation in Description tab

void main(void)
{
  // PORT A
  LATA = 0b00000000;
  TRISA = 0b00000000;    // Alle Ports sind Ausgänge

  // PORT B
  LATB = 0b00000000;
  TRISB = 0b00000000;    // Alle Ports sind Ausgänge

  TRISCbits.TRISC7=1; //Make UART RX pin input
  TRISCbits.TRISC6=1; //Make UART TX pin output

  void initUSART(spbrg_value);
  
  unsigned char buf[32];
  unsigned int count=0;

  putsUSART("Hallo "); // Funktioniert und kommt am pc ohne fehler an
  putsUSART("TEST"); // Funktioniert und kommt am pc ohne fehler an
  
  while(1)
  {
    unsigned char usartin = getcUSART(); // Funktioniert
    if ( usartin != 0 ) {
      if (usartin=='\r') { // Funktioniert wird aufgerufen
          buf[count] = '\0';
          putsUSART(buf); // Geht nicht
          count=0;
      } else {         
          writeUSART(usartin); // Funktioniert und kommt am pc ohne fehler an
          buf[count] = usartin; // Scheint nicht zu funktonieren.. WARUM????
          count++;
      }
    }
    if(count == 32) { count = 0; }
  }
}

Ich danke euch jetzt schon wie verrückt

[Martin (Gast)]

Jörg Marschner schrieb:
> buf[count] = usartin; // Scheint nicht zu funktonieren.. WARUM????
Probiere direkt nach dieser Zeile mal ein
writeUSART(buf[count]);
Kommt das auch an? (Bitte mit -O0 kompilieren.)

[Jörg M. (joerg1)]

wenn ich direkt nach: buf[count] = usartin;
writeUSART(buf[count]); schreibe,
dann kommt von der Funktion nur Mist zurück der Rest funktioniert...
Also scheint ja wirklich mit der Zuweisung was nicht zu stimmen..

[Martin (Gast)]

Von welcher Funktion kommt Mist zurück? Und was funktioniert dann 
plötzlich? Die spätere Ausgabe von buf?

Verschiebe die Deklaration von buf mal aus der main raus. Also mache 
eine globale Variable daraus. Ich hätte evtl. noch ein Bug beim Inlining 
von getcUSART vermutet, aber wenn es mit -O0 auch auftritt, dann kann 
man das ausschließen. Ansonsten poste mal noch die Ausgabe von 
avr-objdump -S "dein binary". Dann kann man mal schauen ob mit dem 
generierten Code etwas nicht stimmt.

[Martin (Gast)]

Args, du verwendest ja ein PIC und kein avr, dann halt das entsprechende 
Äquivalent für PIC um ein binary zu disassemblieren.

[Jörg M. (joerg1)]

Hier mal das ganze Projekt incl des HEX-Files. Das verschieben von buf 
und count vor die main-Funktion hat nix gebracht.

[egr25z2h (Gast)]

So ein Rumgestocher im Code.

Gibt es für den µC keine vernünftige Debug-Möglichkeit?

[Jörg M. (joerg1)]

Ich hab den PIC18-Simulator von OshonSoft... Dort funktioniert das 
Programm/das HEX-File jedoch fehlerfrei. Und die Fehlersuche im 
Schaltkreis hat Ergeben das der PIC keine Daten in die char array 
schreiben kann/will. Weder so wie es im Programm steht noch mit 
strcpy(); und auch nicht wenn man direkt char buf[] = "Text der rein 
soll"; schreibt.
Mir ist leider absulut nicht klar warum, vorallen da alles andere 
Funktioniert und dieser Fehler bei 3 verschiedenen PICs auftritt.

[Chris B. (dekatz)]

Auch wenn mit SPEN=1 die Portpins für den UART geschaltet werden, würde 
ich sicherheitshalber
"TRISCbits.TRISC6=1; //Make UART TX pin output" in
"TRISCbits.TRISC6=0;" ändern. Bei dir ist der Pin auf INPUT gestellt.

[Jörg M. (joerg1)]

Laut Datenblatt sollen TRISC6 und TRISC7 auf 1 gestellt werden. Habs 
trotzdem probiert und es bringt keine Veränderung. Die reine 
USART-Übertragung funktioniert ja auch ohne Probleme.

[Chris B. (dekatz)]

Eventuell findet sich ja auch hier etwas:
http://ww1.microchip.com/downloads/en/DeviceDoc/80478a.pdf

[Jörg M. (joerg1)]

Wie gesagt USART-Kommunikation funktioniert.

[RAY (Gast)]

Jörg Marschner schrieb:
> Wie gesagt USART-Kommunikation funktioniert.

Tja - vielleicht wird der String / Array falsch übergeben, wenn es an 
der USART nicht liegt.

Kannst ja mal probieren statt

unsigned char buf[32];

char *buf='dummytext........................'; // <- genügend Zeichen in 
den String, damit Speicherplatz belegt wird

zu verwenden.

VG
Ray

[Martin B. (Gast)]

teste doch mal:

...
      if (usartin=='\r') { // Funktioniert wird aufgerufen
          buf[count] = '\0';
          putsUSART("TEST");
          writeUSART('0'+count);
          putsUSART(buf); // Geht nicht
          count=0;
      } else {

...

vg
Martin

[Jörg M. (joerg1)]

Hey Ray, dein Vorschlag liefert ein echt interessantes Ergebnis. Wenn 
ich Enter drücke bekomm ich vom PIC immer den Dummytext zurück. 
Komischerweiße nie die Zeichen die der PIC vorher empfangen hat... 
komisch

@Martin: writeUSART(count); funktioniert und liefert mir die Anzahl der 
Zeichen die der PIC vorher empfangen hat.

Hier noch der Code von main.c an usart.h hat sich nix geändert...

#include <htc.h>
#include <pic18f4550.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "usart.h"

#define FREQ 18432000    // Frequency = 18,432MHz
#define baud 9600
#define spbrg_value (((FREQ/64)/baud)-1)    // Refer to the formula for Baud rate calculation in Description tab

void main(void)
{
  // PORT A
  LATA = 0b00000000;
  TRISA = 0b00000000;    // Alle Ports sind Ausgänge

  // PORT B
  LATB = 0b00000000;
  TRISB = 0b00000000;    // Alle Ports sind Ausgänge

  TRISCbits.TRISC7=1; //Make UART RX pin input
  TRISCbits.TRISC6=1; //Make UART TX pin output

  initUSART(spbrg_value);

  unsigned char *buf = "....a....a....a....a....a....a....a";
  unsigned int count=0;

  putsUSART(buf); // Funktioniert und kommt am pc ohne fehler an
  putsUSART("TEST"); // Funktioniert und kommt am pc ohne fehler an

  while(1)
  {
    unsigned char usartin = getcUSART(); // Funktioniert
    if ( usartin != 0 ) {
      if (usartin=='\r') { // Funktioniert wird aufgerufen
          buf[count] = '\0';
          putsUSART(buf);
          count=0;
      } else {         
          writeUSART(usartin); 
          buf[count] = usartin; 
          count++;
      }
    }
    if (count==32) { count=0;  }
  }
}

[Karl H. (kbuchegg)]

Jörg Marschner schrieb:

>   unsigned char *buf = "....a....a....a....a....a....a....a";

so und jetzt wirfst du das gleich wieder raus und ersetzt es, wie 
gehabt, duch

    unsigned char buf[30];


Denn so, mit dem Pointer, ist es definitiv falsch. Nicht wegen dem 
Pointer, sondern weil der Pointer auf ein Stringliteral zeigt. Und an 
dem hast du nichts rumzufummeln.

[Karl H. (kbuchegg)]

Welcher Compiler ist das?

Es gibt/gab da auf den PIC mal ein Gewirx, so dass StringLiterale anders 
behandelt wurden als char-Arrays.

[Jörg M. (joerg1)]

Echt? Da werd ich direkt ma google anwerfen...

[Karl H. (kbuchegg)]

Jörg Marschner schrieb:
> Echt? Da werd ich direkt ma google anwerfen...

zb hier
Beitrag "[Pic] C18 Probleme mit Strings"


ist aber Fehlalarm. Da müsste dann das Problem genau umgekehrt sein.

[temp (Gast)]

also bei jedem halbwegs normalen Compiler wird bei folgendem Ausdruck:

unsigned char *buf = "....a....a....a....a....a....a....a";

die Variable buf ins Ram gelegt und mit der Adresse des Strings 
"....a....a....a....a....a....a....a" initialisieren. Compiler und 
Linker sorgen dafür, dass ale Strings sortiert und von Doubletten 
befreit ins Flash wandern. Und dort kann man nun mal nichts 
hinschreiben. Du kannst zwar buf eine andere Adresse zuweisen aber den 
String selbst nicht ändern. Kommst du von AVR? Dort würdes das gehen, 
deshalb macht man auch die Krücke mit dem PROGMEM um solche Strings in 
den Flash zu verlagern um nicht den Ram damit zu zu müllen. "buf[count] 
= usartin;" geht des wegen nicht!

unsigned char buf[] = "....a....a....a....a....a....a....a";

Dieser Ausdruck (ob das bei allen Comiplern geht weiss ich nicht) macht 
das anders. Er belegt soviel Bytes im Ram wie der String lang ist +1. 
Diesen Buffer kann man dann nach belieben ändern.

Hoffe das das bei deinem PIC Compiler so ist. Zumindestens ist das der 
normalfall für den gcc.

[Jörg M. (joerg1)]

Würde unsigned char buf[] = "....a....a....a....a....a....a....a"; nicht 
das selbe bewirken wie unsigned char buf[30];?
Also RAM freihalten/belegen?
Funktioniert aber jedenfalls auch nicht.
Ich verwende MPLAB X IDE und Hi-Tech PICC18-PRO (v9.80) als Compiler

Ich hab vorher keine noch nie Programme für mC geschrieben (Außer ein 
paar kleine LED I/O für PIC16). Daher hab ich mit Arrays nie viel 
gemacht. (Zumindest bei mC). Ansonsten schreibe ich abundan PC-Programme 
(c/c++ und das nur als xxs-Hobby! Also ohne viel Ahnung) wo ich so ein 
Problem noch nie hatte.

[temp (Gast)]

das schon, aber wenn man macht:

unsigned char buf[30];
buf="....a....a....a....a....a....a....a";

hat man wieder das gleiche Problem. buf zeigte am Anfang schön auf 30 
Bytes im Ram. Nach der Zuweisung zeigt er auf einen readonly Bereich im 
Flash.

Ich habe den Thread aber nicht im Detail verfolgt. (Heute ist Feiertag!) 
Also mit anderen Worten, ob du das so machst weiss ich nicht,, aber wenn 
dann ist das falsch!

[Jörg M. (joerg1)]

@Gast
Kurz und Knapp. Nein das mach ich nicht.
Das Feiertag ist weiß ich und nimm es mir bitte nicht übel aber niemand 
zwingt dich zum Feiertag oder sonstwann sich um meine Probleme zu 
kümmern.
Nicht falsch verstehen ich bin für alle Hinweiße und Ratschläge dankbar 
und ich weiß zu schätzen das es Leute gibt die sich vollkommen 
unentgeldlich um Probleme anderer kümmern! Wenn es so eine Seite bzw so 
ein Forum mit all seinen Mitgliedern nicht gäbe.... Ich will gar ni dran 
denken... Aber trotzdem muss ich sagen niemand zwingt dich (schon 
garnicht an einem Feiertag)
Gruß Jörg

[Jörg M. (joerg1)]

Hey Leute! Vielen Dank für eure Hilfe, jetzt hab ich die Lösung...
Seht hier Beitrag "Array beschreiben schlägt fehl"

Einfach volatile vor die char-Array und vor int count=0; und schon 
gehts...

Optimierung steht zwar schon auf none aber na gut...