descrittore di file di polling

Question

per la piattaforma embedded MIPS Sto implementando un piccolo programma per il polling GPIO, vale a dire che sto utilizzando livello utente biblioteca GPIO chip fornitore con funzionalità di base (aperto / dev / GPIO, leggere, scrivere pin etc.). Il design è semplice:

int gpio_fd;
fd_set rfds;

gpio_fd = gpio_open(...);

while (1) {
    FD_ZERO(&rfds);
    FD_SET(gpio_fd, &rfds);

    if (select(gpio_fd + 1, &rfds, NULL, NULL, NULL) > 0) {
        if (FD_ISSET(gpio_fd, &rfds)) {
            /* read pins and similar */
        }
    }
}

Ma sto di fronte a un grave problema - questa applicazione quando correva con '&' alla fine, cioè metterlo in background, consuma il 99% della CPU, questo è, ovviamente, a causa del ciclo stretto, ma ho osservato l'approccio simile in molti codice di rete e ha funzionato bene.

Mi sto perdendo qualcosa, può essere un difetto della biblioteca GPIO?

In realtà, un solo "while (1);" fa lo stesso effetto. Può essere il comportamento "naturale" del kernel?

Grazie.

Answer 1

La chiamata select dovrebbe bloccare fino a quando il descrittore di file è leggibile.

Quello che potrebbe accadere è che il driver di periferica non supporta la chiamata select, e così esce immediatamente piuttosto che bloccare.

Un'altra possibilità è che la chiamata a gpio_open in realtà non vi darà un vero e proprio descrittore di file Unix. Se così fosse open("/dev/gpio", O_RDWR) o qualcosa del genere avrei molta più fiducia in esso.