[Fedora] seriele poorten niet te openen met eigen programma

[peterkuli]

Ik heb een vrij specifieke vraag, ik hoop dat dit het juiste forum is. Het volgende:

Ik wil een kleine Linux server maken met twee seriele poorten. Eerder gebruikte ik een simpele consumenten pc met voor de seriele poorten een Sweet PCI kaart . Type moederbord weet ik helaas niet meer.

Nu heb ik een machine op basis van een ASRock E350M1 met een DeLock PCI Express Card. Voor de aansturing van de twee seriele poorten gebruik ik het volgende (in C):

C:

int SerialOpen( int port)
{
    int fd;
    char device[ 80];
    struct termios tio;

    if( fd_map[ port] != -1)        ///< port already opened
        return SERIAL_ERROR_OPEN;

    sprintf( device, "/dev/ttyS%d", port);
    fd = open( device, O_RDWR|O_NOCTTY);
    if( fd <0)
        return SERIAL_ERROR_OPEN;

    fd_map[ port]= fd;

    bzero( &tio, sizeof(tio));      ///< clear struct for new port settings

    tio.c_iflag = 0;
    tio.c_oflag = 0;
    tio.c_cflag = B9600|CS8|CREAD|CLOCAL;
    tio.c_lflag = 0;

    tio.c_cc[ VTIME] = 0;           ///< inter-character timer unused
    tio.c_cc[ VMIN] = 1;            ///< blocking read until 1 character arrives

    tcgetattr( fd, &(oldtio[ port]));   ///< save current serial port settings
    newtio[ port]= tio;

    tcflush( fd, TCIFLUSH);
    tcsetattr( fd, TCSANOW, &newtio[ port]);

    return fd;
}

Het probleem: als ik ttyS1 (ttyS0 is volgens mij de seriele poort op het moederbord, op de header zit geen uitvoer naar buiten) probeer te openen, hangt het programma op

C:

fd = open( device, O_RDWR|O_NOCTTY);

Het zal ongetwijfeld komen door het feit dat dit een blocking functie is. Maar in andere situaties heeft dit altijd gewerkt. Op de vorige pc (met de Sweex kaart) had ik Fedora 17 draaien en daar werkt dit. Op de nieuwe pc heb ik Fedora 19, 17, 14 en 13 gehad maar in geen enkel geval werkt deze code.

In de voorgaande gevallen heb ik met 'lspci -v' het I/O adres van de seriele poorten opgevraagd maar dat geeft Fedora nu ook niet weer. Dus ik kan met 'setserial' de poorten ook niet instellen (in ieder geval niet zoals ik dat altijd gewend was).

Als ik gtkterm installeer kan ik beide poorten gebruiken en communiceren met een Windows pc met Hyperterminal. Het lijkt me dat de poorten dus opzich wel goed werken.

Het enige wat ik kan bedenken is dat deze code niet werkt op de gebruikte hardware maar is dat een juiste conclusie?

Iemand die hier een idee over heeft?

[blaataaps]

Ik zou het niet op je code gooien, maar op die seriele kaart+linux. Weet je zeker dat er drivers zijn voor de chipset van dat ding? Laat

code:

dmesg | grep ttyS

ook nog iets zien over gevonden seriele poorten? Wat zegt lspci?

[Hero of Time]

blaataaps schreef op donderdag 03 oktober 2013 @ 19:59:
Ik zou het niet op je code gooien, maar op die seriele kaart+linux. Weet je zeker dat er drivers zijn voor de chipset van dat ding? Laat

code:

dmesg | grep ttyS

ook nog iets zien over gevonden seriele poorten? Wat zegt lspci?

Het werkt gewoon, dus verder zoeken met lspci en of 't werkt met Linux hoeft niet:

peterkuli schreef op donderdag 03 oktober 2013 @ 19:52:
Het zal ongetwijfeld komen door het feit dat dit een blocking functie is. Maar in andere situaties heeft dit altijd gewerkt. Op de vorige pc (met de Sweex kaart) had ik Fedora 17 draaien en daar werkt dit. Op de nieuwe pc heb ik Fedora 19, 17, 14 en 13 gehad maar in geen enkel geval werkt deze code.

In de voorgaande gevallen heb ik met 'lspci -v' het I/O adres van de seriele poorten opgevraagd maar dat geeft Fedora nu ook niet weer. Dus ik kan met 'setserial' de poorten ook niet instellen (in ieder geval niet zoals ik dat altijd gewend was).

Als ik gtkterm installeer kan ik beide poorten gebruiken en communiceren met een Windows pc met Hyperterminal. Het lijkt me dat de poorten dus opzich wel goed werken.

Het enige wat ik kan bedenken is dat deze code niet werkt op de gebruikte hardware maar is dat een juiste conclusie?

---

Die gtkterm die je gebruikt, moet je daarvoor root rechten hebben of doet het nog iets anders speciaals? Kan je zelf het device ttyS1 openen met 'screen'? Zit SELinux niet toevallig in de weg en ben je vergeten dat je 't op de vorige systemen had uitgeschakeld?

[peterkuli]

@blaataaps

Ik ben het eens met Hero of Time dat de combi linux+kaartje wel werkt omdat gtkterm werkt. Maar voor de volledigheid:

code:

01:00.0 Serial controller: Oxford Semiconductor Ltd Device c158 (prog-if 02 [16550])
    Subsystem: Oxford Semiconductor Ltd Device c158
    Flags: bus master, fast devsel, latency 0, IRQ 16
    Memory at fea00000 (32-bit, non-prefetchable) [size=16K]
    Memory at fe800000 (32-bit, non-prefetchable) [size=2M]
    Memory at fe600000 (32-bit, non-prefetchable) [size=2M]
    Capabilities: [40] Power Management version 3
    Capabilities: [70] Express Endpoint, MSI 00
    Capabilities: [b0] MSI-X: Enable- Count=16 Masked-
    Capabilities: [100] Device Serial Number 00-30-e0-11-11-00-01-50
    Capabilities: [110] Power Budgeting <?>
    Kernel driver in use: serial

@Hero of Time
Ik moet inderdaad root rechten hebben om gtkterm te laten werken. Naar mijn weten doet gtkterm verder niks speciaals. Overigens draai ik mijn programma ook als root.

Ik weet niet wat 'screen' is, daar zou ik even naar moeten kijken.

Tot nu toe heb ik niet iets bewust met SELinux gedaan. Op het vorige systeem heb ik dat in ieder geval niet bewust uitgeschakeld (en op dit systeem heb ik er dus ook niks mee gedaan).

[blaataaps]

peterkuli schreef op donderdag 03 oktober 2013 @ 21:43:
@blaataaps

Ik ben het eens met Hero of Time dat de combi linux+kaartje wel werkt omdat gtkterm werkt. Maar voor de volledigheid:

Aaah, had ik scheef gezien, ik dacht dat het alleen met een windowstooltje werkte

[Hero of Time]

peterkuli schreef op donderdag 03 oktober 2013 @ 21:43:
Ik moet inderdaad root rechten hebben om gtkterm te laten werken. Naar mijn weten doet gtkterm verder niks speciaals. Overigens draai ik mijn programma ook als root.

Ik weet niet wat 'screen' is, daar zou ik even naar moeten kijken.

Tot nu toe heb ik niet iets bewust met SELinux gedaan. Op het vorige systeem heb ik dat in ieder geval niet bewust uitgeschakeld (en op dit systeem heb ik er dus ook niks mee gedaan).

Het commando 'screen' is een terminal multiplexer wat op de achtergrond kan blijven draaien. Veel mensen gebruiken het bijvoorbeeld icm irssi IRC client. Als je veel met SSH werkt en servers beheert kan het ook zeer handig zijn mocht je een lange taak moeten draaien met een instabiele netwerkverbinding of je moet weg/herstarten/whatever. Je taak blijft dan draaien na verbreken van de verbinding, ipv dat 't afgebroken wordt.

Kijk in je logs of SELinux wat doet, of gebruik strace of gdb met je programmaatje om te zien wat er mis gaat. Gdb is wel wat overkill wellicht.

[peterkuli]

Ik heb SELinux in z'n geheel uitgeschakeld in /etc/selinux/config. Tevens strace geinstalleerd en daarin hangt mijn programma ook weer op

code:

fd = open( device, O_RDWR|O_NOCTTY);

Edit:
Ik heb een beetje gespeeld met 'stty' en daardoor lijkt het alsof ik nu ttyS1 kan openen. Mijn programma opent deze poort nu goed en ik zie communicatie op Hyperterminal.

Als ik ttyS1 open wordt 'fd' 3 maar als ik ttyS2 open wordt 'fd' -2. Ik kan nergens vinden wat dat betekent omdat dit eigenlijk niet voor kan komen. 0 is voor success en -1 voor error.

Als ik dit doe:

C:

fd = open( device, O_RDWR|O_NOCTTY);
perror("open");

Krijg ik "open: Success" als ik ttyS1 open maar bij ttyS2 wordt niets geprint.

Ik kan zowel

code:

echo 'test' > /dev/ttyS1

als

code:

echo 'test' > /dev/ttyS2

doen en dit werkt in beide gevallen (ook hier zie ik 'test' op Hyperterminal binnen komen).

Het vreemde is dus dat mijn programma ttyS1 wel kan openen en ttyS2 niet en dat in het laatste geval -2 terug gegeven wordt......

Edit2:
Het werkt inmiddels. De fout zat in een stukje code dat kijkt of de poort in gebruik is. Omdat dat stukje niet verder keek dan poort 1 leek het of poort 2 elke keer in gebruik was

Dank voor het meedenken!

[ Voor 79% gewijzigd door peterkuli op 07-10-2013 09:33 ]