Posso obter funcionalidade semelhante a interrupções no espaço do usuário do Linux?

Question

Uma das funcionalidades que mais sinto falta de "small embedded" no Embedded Linux são as interrupções. Um sinal aparece em um pino específico, ou outra fonte de interrupção é acionada e o que foi feito dentro da CPU é interrompido, e minha função de handler de interrupção é iniciada. No Linux tudo é armazenado em buffer, se algo acontece o sistema segue seu próprio curso e quando (finalmente) o thread é trazido para o primeiro plano, seu estado de espera esperando que a fonte externa termine e seu manipulador seja iniciado.

A coisa mais próxima que eu sei são os sinais, que podem acionar um manipulador interrompendo o fluxo normal do encadeamento, mas ainda assim, o manipulador não captará o sinal até que o kernel coloque o encadeamento em primeiro plano, o que pode ser muitos milissegundos depois o sinal aconteceu - e disparar os sinais também não é tão robusto; Eu preciso de um aplicativo ou de um módulo do kernel para enviar um sinal, não posso simplesmente conectá-lo a um pino GPIO.

Como eu poderia obter uma funcionalidade semelhante a interrupções de hardware dentro do software userspace do Linux - ter uma função específica ativada ou thread específica trazida para primeiro plano imediatamente após uma condição de origem externa ser disparada, sem esperar que a fila de processos traga meu thread para o primeiro plano ?

Se você acha que essa pergunta é muito ampla, vamos reduzi-la a um exemplo específico: uma placa Raspberry Pi recebe um sinal em um de seus pinos GPIO (não necessariamente arbitrário; se apenas alguns pinos puderem fazer isso, tudo bem.) Eu quero que meu aplicativo de espaço de usuário reaja a esse evento no menor tempo possível, esteja fora do estado de espera, iniciando uma função de manipulador ou qualquer mecanismo equivalente, mas acima de tudo não esperando a fila de tarefas percorrer todos os processos pendentes antes do O manipulador é trazido para o primeiro plano, mas acione-o o mais rápido possível. (e especificamente, quando não há sinal, não deixar o sistema bloqueado para sempre com o processo do manipulador ocupando 100% do tempo de CPU pesquisando a entrada e nunca cedendo ao SO.) Existe tal mecanismo?

    

Answer 1

Se eu entendi sua pergunta, isso significa que você está procurando. O artigo é intitulado: Drivers de dispositivo no espaço do usuário .

trecho

UIO drivers

Linux provides a standard UIO (User I/O) framework for developing user-space-based device drivers. The UIO framework defines a small kernel-space component that performs two key tasks:

• a. Indicate device memory regions to user space.
• b. Register for device interrupts and provide interrupt indication to user space.

The kernel-space UIO component then exposes the device via a set of sysfs entries like /dev/uioXX. The user-space component searches for these entries, reads the device address ranges and maps them to user space memory.

The user-space component can perform all device-management tasks including I/O from the device. For interrupts however, it needs to perform a blocking read() on the device entry, which results in the kernel component putting the user-space application to sleep and waking it up once an interrupt is received.

Eu nunca fiz isso antes, então não posso oferecer muito mais orientação do que isso, mas achei que poderia ser útil para a sua busca.

    

Answer 2

Pensando na mesma linha como @RBerteig, o BeagleBone Black contém PRU (Programmable Real-Time Unit) .

Não parece que há uma enorme comunidade usando essas coisas para a capacidade total. Eu nem tenho certeza se há um bom compilador para isso. As vantagens sobre uma montagem de um SBC e um microcontrolador ou placa microcontroladora são que o código PRU pode vir do ARM principal e a memória compartilhada é bastante conveniente.

Não posso dizer que usei isso, ou mesmo que eu tenha executado mais do que alguns exemplos em meus Blacks BeagleBone ainda, mas as necessidades expressas nesta questão podem ser uma daquelas coisas que podem cutucar um desenvolvedor com estes precisa para o negro e longe do Pi.

    

Answer 3

Pensando fora da caixa por um momento, isso pode ser um bom exemplo de uso para algo como o painel de modo ala . Esta é uma "placa pi" que contém um Arduino completo. Você construiria sua resposta em tempo real, protocolo de barramento com bitbit, ou outra lógica profundamente incorporada para rodar em seu processador AVR, e se comunica através de um canal de alta latência de volta a um processo no Linux.

O modo ala não é a única opção de hardware disponível na prateleira. Um modelo Arduino comparável que fornece tanto o Linux quanto o Arduino é o Arduino Yún que tem um SOC Linux incorporado baseado em MIPS, bem como um AVR. O Arduino também anunciou o Arduino Tre baseado em um SOC do ARM, mas está em "breve" há um ano. Se tanto o RPi quanto o Arduino poderiam se beneficiar de mais potência, há também o UDOO , com um ARM CORTEX-A9 quad-core e GPU executando Linux ou Android, e o mesmo chip Atmel ARM CORTEX-M3 como no Arduino Due .

Se o seu problema for receptivo a esse particionamento, você terá todas as vantagens de um sistema integrado embutido rodando diretamente no metal sem nenhuma camada de sistema operacional entre você e os pinos GPIO, enquanto ainda possui um kernel Linux completo para lidar com redes , lógica de negócios, interface de usuário e hardware complexo, como unidades de disco e vídeo. Se um Arduino não é suficientemente poderoso para o seu processamento de baixo nível, então existem muitos módulos e chips alternativos profundamente integrados a serem considerados, quase todos com UART, I2C ou até mesmo USB disponíveis para comunicações com o terminal Linux. das coisas.

Uma vantagem dessa arquitetura é que você provavelmente não precisa tocar no kernel do Linux. O código em tempo real está sendo executado fora do kernel em sua própria CPU, e as comunicações entre os dois podem usar drivers e protocolos existentes.