Linux C Read von ttys0

Lars schrieb:

> Warum kann ich den dem While kein Strcopy machen? Da hängt das Programm

Ja, hast du denn überhaupt Strings?


Ich seh schon.
WIr sind wieder mal an dem Punkt an dem man sagen muss: Es hilft alles 
nichts. Wer Programm in der realen Welt schreiben will muss erst mal die 
Grundlagen lernen! Das geht nun mal nicht so, wie sich manche das 
vorstellen: vormittags den Entschluss gefasst Programmierer zu werden, 
und nachmittags die Killerapplikation geschrieben, die einen reich 
macht.

Karl Heinz Buchegger schrieb:
> Lars schrieb:
>
>> Warum kann ich den dem While kein Strcopy machen? Da hängt das Programm
>
> Ja, hast du denn überhaupt Strings?

Und ehe du dich in einen Wirbel reinredest.
Nein, du hast erst mal keine Strings.
read befüllt dir den buffer mit den Zeichen die gerade da sind bzw. in 
den buffer passen. Nicht mehr und nicht weniger. Von Strings kann zu 
diesem Zeitpunkt noch überhaupt keine Rede sein.

Gleiche Hausaufgabe wie Beitrag "Serial Stream Line by Line ausgeben Linux C"?

Lars schrieb:
> Ist nicht ein Char ein String?

Nein das ist ein Array of Bytes, In C sind Strins mit \0 terminert. Dann 
sind es Strings und können mit den Funktionen aus der string.h behandelt 
werden. Sonst ist das nur irgendwelcher Datenkram...

Gegenvorschlag:

char *spei; // Wir machen einen Pointer daraus
spei = (char)malloc(10000) // Speicher reservieren;
char *mark;

mark = spei; // alten Pointer merken

do{

    res = read(fd,(char *)buf,sizeof(buf));
if (spei < mark + 10000) { // Sicher stellen, dass nocht über den 
allocierten Speicher geschrieben wird
    memcpy(spei, buf, res); // anzahl der gelesenen Zeichen umschaufeln
    spei += rc // pointer hochzählen
  }
  }while( res > 0);

// hoffen, dass es sich um strings handelt, sonst als letztes Zeichen \0 
anfügen


  printf("read:%s\n",mark); // nicht wundern, wir nehmen hier den Anfang 
des spei Pointers, da wir den ja oben laufend verschoben haben


// Speicher wieder frei geben
free(spei);
free(mark);


So, das ist nicht getestet, sollte aber gehen..

Grpßle aus dem Ländle von Jörg

Jörg Bernau schrieb:
> spei = (char)malloc(10000) // Speicher reservieren;

Wozu denn malloc, wenn die Größe eh als Konstante vorgegeben ist? Mal 
abgesehen von dem überflüssigen und hier auch noch falchen Cast.

(Zwar nicht die Antwort auf Deine Frage)
Dem Compiler ist die Laenge des Strings bereits bekannt, weshalb ich 
anstelle von strlen() sizeof() benutzen würde.

In dem Codeschnipsel ist kein Fehler, also muß er irgendwo anders 
liegen. Sinnvoll ist es deshalb, ein minimales, aber vollständiges 
Programm zu posten, das den Fehler noch enthält.
Folgendes Programm funktioniert bei mir jedenfalls einwandfrei:

1

/* lesen.c */

2

#include <termios.h>

3

#include <fcntl.h>

4

#include <sys/ioctl.h>

5

#include <stdio.h>

6

#include <sys/types.h>

7

#include <sys/stat.h>

8

#include <string.h>

9

#include <stdlib.h>

10

11

int main(void)

12

{

13

    char string[] = "Die schoenen Dinge im Leben sind umsonst.";

14

    int laenge = strlen(string);

15

    printf("Laenge: %d Zeichen\n", laenge);

16

    return 0;

17

}

Es gibt aus:

1

Laenge: 41 Zeichen

Mehmet Kendi schrieb:
> Dem Compiler ist die Laenge des Strings bereits bekannt, weshalb ich
> anstelle von strlen() sizeof() benutzen würde.

Der Compiler (zumindest gcc) ist so intelligent, in so einem Fall auch 
bei strlen() die Länge schon zur Compilezeit zu ermitteln.

Lars schrieb:
> Wenn ich string[100] schreibe gehts.

Und wenn du den exakten Code von mir nimmst, geht es nicht? In dem 
Fall stimmt irgendwas mit deinem Compiler nicht, oder er ist extrem 
veraltet. Oder hast du's nur in deinem Programm probiert? Dann gilt 
immer noch:

Rolf Magnus schrieb:
> Sinnvoll ist es deshalb, ein minimales, aber vollständiges
> Programm zu posten, das den Fehler noch enthält.

> Wie kompilierst du mit gcc?

gcc datei.c -o datei

In dem Code kommt doch gar kein read() vor und auch nichts, von dem aus 
es aufgerufen würde.

Lars schrieb:
> res = read(fd,(char *)buf,sizeof(buf));
>
> aber irgendwie kommen da nur ca.9 Zeilen an....Ist das die große des
> Hardware Buffers? Wie zeichnet mann denn alles auf in C?

Der Linux-Kernel macht bei einem read()-Syscall keine Garantien, dass 
der Buffer gefüllt wird, es wird das rausgereicht, was gerade da ist. 
Nur wenn nix da ist wird blockiert (ok, man kann die Datei auch 
nonblocking öffnen, dann kommt "nix" zurück).

Wenn man darauf angewiesen ist, dann macht man das mit den 
"highlevel"-Funktionen der libc (fread etc.).

Ich habe mal ein winz-Programm angehängt, welches auf eine serielle 
Schnittstelle zugreift und die empfangenen Daten auf stdout als Hexdump 
ausgibt. Als Bonus wird da auch gezeigt, wie man mit poll() auf das 
Vorhandensein von Daten warten kann - hier nutze ich das dafür, dass 
nach einer kleinen Pause ein Zeilenumbruch ausgegeben wird, also 
typischerweise nach einem Telegramm.

Ich hoffe das hilft weiter.

Viele Grüße,
         Simon

@Simon
Nice trick with the polling.

@Lars
I have used this code on an Arduino , and it seems to be ok. For reading 
serial responses from an Arduino.
Beitrag "PortableSerialLib - Portable Serial Port Library"

Maybe it should be extended with the poll Simon shows.

I haven't tried it on windows , but used it in hope of a "dual platform" 
support.

regards
Karsten - Denmark

mar IO schrieb:
> Muss man ret hier wirklich auf /EAGAIN/prüfen? - Mit der vorigen
> Abfrage sollte doch sichergestellt sein, dass Daten vorhanden sind, oder
> nicht (immer)?

Ja, im Prinzip hast Du recht, es sollten Daten verfügbar sein.

Hier ist das ein bischen defensiv programmiert und schützt einen vor 
irgendwelchen komischen Situationen mit z.B. kaputten Treibern. Ich weiß 
jetzt gerade nicht, ob ich diese Situation schonmal konkret hatte, aber 
ich weiß: Wenn read() EAGAIN zurückgibt, dann will ich es nochmal 
probieren, insofern teste ich lieber drauf.

Viele Grüße,
         Simon

mar IO schrieb:
> Muss man ret hier wirklich auf /EAGAIN/prüfen? - Mit der vorigen
> Abfrage sollte doch sichergestellt sein, dass Daten vorhanden sind, oder
> nicht (immer)?

In der Man-Page steht:

1

BUGS  See the discussion of spurious readiness notifications under the

2

      BUGS  section of select(2).

Und bei select steht dann:

1

BUGS:

2

       Under Linux, select() may report a socket file  descriptor

3

       as  "ready  for  reading", while nevertheless a subsequent

4

       read blocks.  This could for example happen when data  has

5

       arrived  but  upon  examination  has wrong checksum and is

6

       discarded.  There may be other circumstances  in  which  a

7

       file  descriptor is spuriously reported as ready.  Thus it

8

       may be safer to use O_NONBLOCK on sockets that should  not

9

       block.

O_NONBLOCK hat er ja wohl schon, aber dann muß man auch auf EAGAIN 
prüfen, um das von einem echten Fehler unterscheiden zu können.