Frage zu RS232 Verbindung

Möglicherweise "überfährst" Du Deinen µC, d.h. Du sendest ihm Daten 
schneller, als er sie verarbeiten kann. Damit meine ich nicht die 
Baudrate, sondern die (fehlende) Zeit zwischen einzelnen Zeichen bzw. 
zwischen den einzelnen übertragenen Strings.

Wenn das gets hier
   gets(_4recive);
auch nur ansatzweise wie ein normales gets funktioniert, dann wartet es 
auf ein Carriage Return von der Gegenstelle, welches aber
  iKey[0] = 't'; iKey[1] = 't'; iKey[2] = 't'; iKey[3] = 't';
  ComWrite(COM1, iKey, 4);
niemals gesendet wird.


Und PS: du solltest dir in deinem C-Buch das Kapitel über Strings 
nochmal durchlesen. Man kann, man muss aber nicht bei Strings ständig 
auf Einzelzeichenebene rumkriechen.

Und noch ein 2.tes PS:
gets ist eine extrem gefährliche Funktion, deren Verwendung bei 
Prügelstrafe verboten werden sollte.

> ComWrite(COM2, "test\r\n\0", 7);

Wozu das \0 Byte?
Ein direkt angegebener String ist sowieso immer automatisch mit einem \0 
Byte abgeschlossen. Das macht der Compiler. Und das \0 Byte brauchst du 
auch nicht zu übertragen.

Hast du auf dem µC neben der UART noch eine andere Möglichkeit um dir 
irgendetwas ausgeben zu lassen? Zb ein LCD?

Wenn ja, dann vereinfache mal dein Empfängerprogramm. Schmeiss alles 
raus, was du nicht brauchst und was das Programm nur in die Länge zieht. 
Empfange eine Zeile und gibt sie am LCD aus. Die Devise heißt: Möglichst 
wenig, was schief gehen kann. Bei dir können momentan 2 Dinge schief 
gehen:
a) die Übertragung einer Text-Zeile vom PC zum µC
b) die Übertragung einer Text-Zeile vom µC zum PC

in einem von beiden steckt ein Problem und du weißt nicht in welchem. 
Also musst du einen der beiden Problemkreise loswerden, damit ein 
möglicher Fehlerfall wegfällt

(PS:

Woher weiß eigentlich das PC-Programm hier

  cout << "GetComReadCount:" << ComGetReadCount(COM1) << endl << endl;
  iLen=ComRead(COM1,cBuffer,64);

wann es eine Zeile empfangen hat?
Das wird so nicht funktionieren.

Wenn du zeilenweise überträgst, was ich dir sehr ans Herz legen würde, 
dann musst du vom µC auch eine Zeile wegschicken.
  puts("RECIVED1\n");

Jetzt ist es eine Zeile und du kannst am PC anhand des \n feststellen, 
dass du eine Zeile bekommen hast.


> Es mag durchaus sein, dass puts() keine gute Wahl ist.

puts() ist nicht das Problem. gets() ist das Problem!
Beantworte doch einfach mal die Frage, wie dich gets() davor schützen 
soll, dass die Gegenstelle mittels eines langen Strings deinen 
char-Buffer überläuft? Dazu müsste gets() wissen, wie gross der Buffer 
ist. Das geht aber mit der Schnittstelle nicht, gets hat keine Chance 
das rauszufinden. Daher ist gets() eine 'Funktiona non grata'. fgets ist 
besser.

Aber lass das erst mal. Deine Problem liegen noch viel einfacher. Erst 
mal sieh zu, dass du die Kommunkation generell hinkriegst.

Wenn du kein LCD oder sowas hast, dann mach dein erstes Testprogramm so 
einfach wie möglich. zb so

1

int main()

2

{

3

   char received[80];

4

5

....

6

7

   while(1)

8

   {

9

     gets( received );

10

     // ideal wäre es hier, wenn du eine LED toggeln könntest oder

11

     // irgendwas anderes machen könntest, was dir zweifelsfrei mitteilt:

12

     // gets hat eine Zeile geliefert

13

     puts( "*" );

14

     puts( received );

15

     puts( "*\n" );

16

   }

17

}

Also einfach nur zurückschicken.
Das testest du erst mal mit Hyperterminal und dann mit deinem 
PC-Programm.
Wenns nicht funktioniert, dann konzentrierst du dich erst mal nur auf 
dein PC-Programm. Das µC Programm ist einfach genug, dass da nicht viel 
schief gehen kann. Solange deine Kontrolle durch zb eine LED mitteilt, 
dass gets mit einem String zurückgekommen ist, ist µC seitig soweit 
alles in Butter.

Und noch was

> Woher weiß eigentlich das PC-Programm hier
>
>  cout << "GetComReadCount:" << ComGetReadCount(COM1) << endl << endl;
>  iLen=ComRead(COM1,cBuffer,64);
>
> wann es eine Zeile empfangen hat?
> Das wird so nicht funktionieren.

Du scheinst hier anzunehmen, dass die ComTools irgendwie magisch wissen, 
wann ein Text, den du vom µC mittels
puts("no match");
auf den Weg schickst, komplett übertragen wurde.

Das tun sie aber nicht!
Ein Computer kann nicht in die Zukunft schauen, ob da von der 
Schnittstelle noch was kommen wird oder nicht.
ComGetReadCount(COM1) sagt dir, wieviele Zeichen bisher eingetrudelt 
sind. Ob das schon alles war oder nicht, oder ob da noch was kommt oder 
nicht, kann auch ComGetReadCount(COM1) nicht vorhersagen.
Insbsondere hast du keine Garantie dafür, dass ein einziger Aufruf von 
ComRead mit einer kompletten Zeile zurückkommt. Er liefert das, was 
bisher eingetroffen ist und wenn der Sender noch gar nicht alles 
weggeschickt hat, dann liefert er eben nur den Teil, der bisher 
übertragen wurde. Es liegt an dir, dein Programm so zu gestalten, dass 
es damit klar kommt, eine komplette Zeile aus mehreren Übertragungen 
wieder zusammenzusetzen.

Christian schrieb:

>> Wenn du zeilenweise überträgst, was ich dir sehr ans Herz legen würde,
>> dann musst du vom µC auch eine Zeile wegschicken.
>>   puts("RECIVED1\n");
>>
>> Jetzt ist es eine Zeile und du kannst am PC anhand des \n feststellen,
>> dass du eine Zeile bekommen hast.
>
> In einer früheren Version meines Programms hatte ich das exakt so
> geschrieben und mich dann gewundert, warum ich nach jedem Empfangen in
> meiner Windows-Konsole immer 2(!) Absätze hatte. Ich kann nicht sagen
> warum das so ist, aber puts("RECIVED1"); scheint schon ein "\n" zu
> enthalten...

Ja, du hast recht. puts hängt von sich aus ein \n an. Zumindest muss es 
das tun, wenn es standardkonform ist.
Daran hab ich nicht mehr gedacht. fputs tut das nämlich nicht und ich 
benutze die puts()/gets() calls praktisch nie, weil mir das eine zu 
unflexibel und das andere zu gefährlich ist.


> NUR, wenn ich C++Programm und µController kommunizieren lassen
> möchte, dann passiert garnichts... ^_^

OK, ok. Ich halt mich schon raus. Wenn du meinst, dass es nicht an 
deinen Programmen liegt, oder der Art und Weise, wie du die Dinge 
gehandhabt hast, dann sei es so.