Internetradio

[ePyx]

Mit meinem PS meinte ich, dass es sehr gefährlich sein kann Befehle per System auszuführen. Beispielsweise durch Pufferüberläufe etc. . Daher gibt es die Möglichkeit Prozesse mit fork zu starten und ihnen Parameter zu übergeben bzw. sie während der Laufzeit zu steuern.

[gesamtplan]

Hallo Daniel,

ich hab den Code jetzt mal aufgeräumt und alles rausgeworfen was ich im Moment nicht brauche.

// Compile GCC -o serial_wiring -l rt serial_wiring.c -lwiringPi

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <termios.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <time.h>
//WiringPi include für SEN/STA Erkennung
#include <wiringPi.h>
//Konfig RASPI USART
#define BAUDRATE B9600  // 9600 Baud definieren für 8E1 I-Bus
char MODEMDEVICE[]= "/dev/ttyAMA0";    // Schnittstelle wählen
int getit; //Nachrichtenblock angekommen
int    fd;                // File descriptor
struct    termios newtio={};

unsigned char receive()                        //Zeichen empfangen
{
    
    int res;
    unsigned char buffer;

    res = read(fd, &buffer, 1);

    getit = fd;
    return buffer;
}

int init()                        //Schnittstelle parametrieren und öffnen für I-Bus 9600 8E1
{
    //O_RDONLY, O_WRONLY or O_RDWR -
    //O_NDELAY (geht weiter, wenn keine Daten da sind und gibt "-1" zurueck)
    // man 2 open fuer mehr Infos - see "man 2 open" for more info
    // O_NOCTTY No ControllTeleType 

    fd = open(MODEMDEVICE, O_RDONLY | O_NOCTTY );
    if (fd < 0){
        printf("Fehler beim oeffnen von %s\n", MODEMDEVICE);
        exit(-1);
    }
    memset(&newtio, 0, sizeof(newtio));
    newtio.c_cflag = BAUDRATE | CS8 | CLOCAL | CREAD | PARENB;    //setzt Einstellungen vom UART 
    newtio.c_iflag = IGNPAR;
    newtio.c_oflag = 0;
    newtio.c_lflag = 0;         /* set input mode (non-canonical, no echo, ...) */
    newtio.c_cc[VTIME] = 0;     /* inter-character timer unused */
    newtio.c_cc[VMIN] = 1;    /* blocking read until 1 chars received old 1 */
    newtio.c_cc[VSTART]   = 0;     /* Ctrl-q startet Datenübertragung */
    newtio.c_cc[VSTOP]    = 0;     /* Ctrl-s stoppt Datenübertragung*/
    
    tcflush(fd, TCIFLUSH);
    tcsetattr(fd, TCSANOW, &newtio);
    return fd;
}

int main(int argc, char** argv)        //Programmstart
{
  //new
  int pin = 7;  //GPIO 4
  int value = 0; // Deklaration Eingangswert GPIO4
  getit = 0;
  printf ("Raspberry Test UART+wiringPi\n") ;

  if (wiringPiSetup () == -1)
    exit (1) ;
  //Fehlerrückgabe wiringPi
  
  pinMode(pin,INPUT); //wiringPi GPIO4 Pin7 deklarieren
  

    char c;
     init();                    //Schnittstelle UART parametrieren und öffnen
    //sleep(5);                 //nix tun
     
    while (1)
        {
    
    value = digitalRead (pin);
     printf("Status SEN/STA %d \n", value );
    
    //printf("SEN/STA: %d\n", value); // BUSRUHE?
    
    c=receive();
    //if((value==1)){
        printf("MESSAGE %X\n", c); // c in Hex ausgeben    %d = Dezimal %H = Hex
        
  
        } 
    
    close (fd);
    return 0;
}

Welche manpages meinst du? In der "open" hab ich nichts entdeckt. Wie vielleicht schon erwähnt ich bin leider kein Profi deshalb wohl auch die dummen Fragen.

Wie geht das genau mit SIGIO bzw in welchem man finde ich das?

Grüße

Rainer

[ePyx]

Gibt keine dummen Fragen. Nur zusammen kopieren, sich danach wundern das nichts geht und dann fragen ist der falsche Weg. Bin auch kein Profi und habe mir das auch selbst beibringen müssen, da ich es benutzen wollte.

Bei SIGIO handelt es sich um ein Signal, welches an den Prozess (also dein Programm) gesendet wird, sobald auf einem Filedescriptor ein I/O-Event stattfindet. Ähnlich funktioniert es bspw. wenn man CTRL+C sendet, dass wird
auch als Signal an den Prozess geschickt. Damit ist es dann möglich trotz des Abbruchs das Programm sauber zu beenden. Signale haben Nichts mit open oder anderen Syscalls zu tun, daher wirst du dort auch nichts finden.

Beispiel : http://www.tldp.org/HOWTO/Serial-Pro...OWTO/x115.html , Beispiel 3.3 Asynchronous Input

Ein Beispiel auf Deutsch findet sich beispielsweise hier : http://www.cs.hs-rm.de/~linn/vpdv01/...u/addendum.htm

Als Tipp kann ich nur noch geben, dass man die manpages auch auf deutsch installieren kann.

[gesamtplan]

Naja ich dachte bei Fragen zu dem hier geposteten Code auf dessen Basis ich aufsetzen wollte ist keine so schlechte Idee, da ich bis auf die serielle Com eigentlich dachte alles verstanden zu haben. Dass das gleich so ans eingemachte geht, wenn man Anfang und Ende bestimmen will, war mir dann doch nicht Bewusst. Aber hey werde das schon irgendwie hinbekommen.

Immerhin funktioniert schon mal die Hardware und die Umsetzung auf den K-Line Bus des Autos. Da werde ich die Komm auch noch hinkriegen...

Und auf den Lerneffekt freu ich mich schon. Will ja nicht das jemand für mich mein Programm schreibt. Naja senden wird dann hoffentlich einfacher .

Danke für die Links und viele Grüße

Rainer

[ePyx]

Und auf den Lerneffekt freu ich mich schon. Will ja nicht das jemand für mich mein Programm schreibt. Naja senden wird dann hoffentlich einfacher .

Wollte ich damit auch nicht sagen, nur für klare Verhältnisse sorgen. Das Thema serielle Schnittstelle ist unter Linux halt um einiges gewichtiger, da sich dort früher halt alles abgespielt hat und es auch nichts anderes gab. Senden ist wirklich um einiges einfacher, von daher brauchst dir da nicht allzu viele Gedanken machen. Aber auch beim empfangen gibt es nicht so viel zu beachten, mit dem Gröbsten habe ich dich ja nun beworfen.

Im Übrigen ist die Netzwerkprogrammierung noch um einiges trickreicher, da man sehr oft fragmentierte Datenströme hat und das Empfangen in der Regel nicht so schön einfach geht. Besonders wenn Daten möglichst synchron sein sollen.

[peterfido]

In die serielle unter Linux musste ich mich auch erst reinlesen. Bei mir läuft das alles aber ohne bemerkbare Verzögerung.

Ich habe in der Zwischenzeit ein Projekt fertiggestellt, welches auf dieses hier aufbaut. Dabei handelt es sich um einen Radiowecker. Den Radioteil übernimmt der Raspberry Pi. Der Chef ist aber der AVR. Dieser steuert das LCD an und wertet eine Tastaturmatrix sowie Fernbedienung aus. Das Protokoll AVR<>Raspbi habe ich etwas optimiert. Es wird zuerst ein Startzeichen gesendet und dann der eigentliche Befehl, zuletzt noch ein Abschlußzeichen. Dann wird gewartet, oder der andere jeweils entsprechend antwortet.

Z.B. wenn der AVR die Weckzeit erreicht, "sagt" er zum Raspbi: Sender 1. Dieser stellt dann den Sender ein und antwortet mit dem aktuellen Sendernamen sowie der Senderplatznummer. Bleibt diese aus, versucht es der AVR nochmal. passiert immmer noch nichts, dann kommt der "Notfallplan" und ein lapidarer Summer wird angesteuert. Dieses war bisher aber nur bei den Tests vorgekommen, wo ich die Internetverbindung gekappt hatte.

So ähnlich könntest Du es auch lösen. Ansonsten läuft der Empfänger wie aufm Seite 1 beschrieben. Kommt ein Zeichen größer chr(13) an, dann wird es dem Einganspuffer angehängt. Kommt das "Habe fertig-Zeichen" (Im Urzustand chr(13)) dann wird auch sofort ausgewertet. Das geht alles so schnell, das keine Verzögerung bemerkbar ist.

Bei der neuen Version ist das Start und Endezeichen außerhalb der normal vorkommenen Zeichen (<13). Wenn natürlich bei Dir alle Zeichen vorkommen können, dann brauchst Du ein anderes Protokoll. Um die Kommunikation zu testen, habe ich den Raspbi während der Entwicklungsphase per Terminalprogramm (Putty) angesprochen und die Antworten kamen auch ohne Verzögerung. Da könntest Du mit testen, wo die Pausen entstehen.

Negative Erfahrungen habe ich gemacht, als ich die ttyAMA0 nach jedem Sendevorgang wieder geschlossen hatte. Da kamen dann undefinierte Zeichen an. Wird der Port offen gelassen, läuft es ohne diese Probleme. Meine Vermutung ist, dass beim Öffnen der Schnittstelle am Raspbi irgendwelche Signal(flanken) erzeugt.

Wenn statt der ttyAMA0 ein USB-Seriell Wandler genutzt wird, treten die Probleme auch nicht auf. So gehe ich in einem anderen Projekt vor, welches jede Minute einmal die Uhrzeit zu einer externen großen LED Anzeige schickt.

[gesamtplan]

Wenn ich ein Abschlusszeichen hätte wäre alles in Butter. Dann könnte man die Routine so machen. Leider schickt der I-Bus keine Abschlusszeichen. Als Abschlusszeichen kommt immer die XOR Checksumme vom Datensatz der empfangen wurde. Auf den kann ich aber schlecht auswerten, da es auch passieren kann dass der HEX Wert der Checksumme irgendwo sonst vorkommt und dann läuft der Auswerter los. Ich brauche wie Daniel oben schon erwähnt hat entweder ein SGIO Event.

Da lässt sich aber leider das Beispiel
http://www.cs.hs-rm.de/~linn/vpdv01/...u/addendum.htm
nicht kompilieren und bricht mit einem Fehler ab, bei saio.sa_mask = 0; ab, den ich leider noch nicht interpretieren kann.

aserial.c:46:22: error: incompatible types when assigning to type â__sigset_tâ from type âintâ

und das

ioctl(fd,FIONREAD, &bytes_avaiable);

hab ich wohl an der falschen Stelle eingefügt. Ich bin gerade mal am wursten woran das liegen kann. Canonical Mode habe ich ausprobiert. das wäre was wenn man wieder ein Abschlusszeichen hat. Aber das geht ja wieder nicht. Mhm...

Muss mal weiterchecken.