Falar com o hardware

Ler 0x60 no i8042 pode retirar um byte recebido. Ler uma variável C limita-se a obter o valor guardado. Esta diferença importa: os registos de um controlador ligam o programa aos dados, ao estado e às ordens de um periférico, e os acessos podem alterar esse estado.

Registos e espaços de endereçamento

Há registos de dados, de estado e de controlo. A classificação indica a função, mas não obriga cada um a ter um endereço distinto. O mesmo endereço pode selecionar registos diferentes conforme leias ou escrevas.

No i8042, ler 0x64 consulta o estado; escrever 0x64 envia um comando ao controlador. Ler 0x60 retira dados do output buffer; escrever 0x60 envia um byte pelo input buffer. Os nomes input e output referem-se ao ponto de vista do controlador, não do processador.

Há duas maneiras de colocar esses endereços no sistema:

As portas do timer, do i8042 e da UART são port-mapped I/O. O framebuffer é memória mapeada. Não chames memory-mapped I/O a todas as leituras de portas. A arquitetura ARM usa memória mapeada para este acesso; x86 também suporta memória mapeada, além do seu espaço de portas de 16 bits.

Privilégios e Minix

Um processo normal não pode executar qualquer operação de hardware, porque o sistema limita o acesso para proteger os outros processos. No Minix, os drivers são processos em espaço de utilizador com permissões próprias. O programa de LC usa kernel calls para pedir operações privilegiadas ao microkernel, por exemplo sys_inb e sys_outb.

Uma máquina virtual fornece um PC emulado. O Minix acede ao hardware da máquina virtual, não recebe por isso acesso livre aos dispositivos físicos do computador anfitrião. O código dos laboratórios depende da imagem Minix e das bibliotecas de apoio fornecidas para LC.

VirtualBox com Linux, como complemento

Este vídeo de Rodrigo Dias apresenta Linux numa VM VirtualBox em Windows, não a instalação de Minix nem as bibliotecas Minix/LCF. Para preparar o laboratório, segue a imagem e as instruções da tua edição de LC.

Usa Linux (VM) no Windows com VirtualBoxCarregar vídeo do YouTube

Abrir no YouTube

sys_inb escreve o resultado numa variável de 32 bits, mesmo quando lê apenas um byte. Passar o endereço de um uint8_t através de um cast não aumenta o objeto: permitiria escrever para lá do seu fim. Esta função completa faz a adaptação segura no ambiente Minix/LCF:

#include <lcom/lcf.h>
#include <stdint.h>

int read_port_byte(int port, uint8_t *value) {
  if (value == NULL) return 1;
  uint32_t raw;
  int result = sys_inb(port, &raw);
  if (result != OK) return result;
  *value = (uint8_t)raw;
  return OK;
}

O chamador recebe um byte apenas após uma leitura bem-sucedida. A função não é executável no navegador: precisa dos cabeçalhos, serviços e permissões Minix do laboratório. Os nomes de tipos antigos u32_t e u8_t aparecem em algumas APIs com o mesmo papel.

Testar e alterar campos

Uma máscara tem bits a 1 nas posições que interessam. Num byte r, as operações usuais são:

Os materiais da cadeira definem o bit n como #define BIT(n) (1u << (n)). BIT(7) vale 0x80: é a máscara, não a posição. Quando uma API pede o número do bit, como o hook de sys_irqsetpolicy, passa-se 7 e guarda-se BIT(7) como máscara a testar. Passar BIT(7) onde se pede o número escolheria um bit inexistente.

& faz AND posição a posição. && testa a verdade das expressões e devolve 0 ou 1. Para r = 0x20 e m = 0x01, r & m é 0, mas r && m é 1, por isso o segundo teste não diz se o bit 0 está ativo.

Para substituir um campo, limpa primeiro o campo antigo e insere o novo. Se os bits 4 a 2 contêm um modo, a máscara é 0x1C. Com r = 0xA7 e o novo modo 5:

uint8_t next = (uint8_t)((r & ~0x1Cu) | (5u << 2));

Os três passos conservam os bits exteriores ao campo:

O resultado é 0xB7. Usar apenas OR deixaria bits do modo anterior ligados. Usa valores sem sinal nas máscaras e garante que a contagem de um deslocamento é menor do que a largura do operando.

Esta leitura, alteração e escrita só é válida se o registo for legível e permitir essa semântica. Um registo write-only, ou com bits que se limpam ao escrever 1, exige a sequência descrita pelo dispositivo.

Um endereço não garante um registo legível

O PP1 de 2020 descreve um dispositivo fictício, L3223, para testar a leitura de uma especificação nova. Tem três timers e difere do i8254: as portas 0x20, 0x21 e 0x22 recebem contagens; escrever 0x23 configura, mas ler 0x23 consulta estado. Os bits lidos não são uma cópia da configuração que podemos preservar com read-modify-write.

A palavra escrita usa bits 7:6 para escolher timer 0, 1 ou 2, bit 4 para alarme e bits 1:0 para a unidade: 0 é microssegundo, 1 milissegundo e 2 segundo. Os restantes bits devem ser zero. Em alarme, timer 2 e milissegundos dão (2 << 6) | (1 << 4) | 1, ou 0x91.

Para uma contagem de 1000, que cabe em 16 bits, a sequência é:

Esta contagem representa 1000 ms, ou um segundo; não se calcula TIMER_FREQ / intervalo. Essa fórmula pertence a outro dispositivo e a outro significado da contagem.

O exemplo seguinte apenas constrói e imprime o plano de escritas. Não executa I/O, nem demonstra que um timer real disparou. Define para esta aplicação intervalos de 1 a 65535, timers 0 a 2 e os três códigos de unidade; não atribui ao valor zero a convenção de 65536 do i8254.

#include <stdbool.h>
#include <stdint.h>
#include <stdio.h>

struct escrita { uint16_t porta; uint8_t valor; };

static bool preparar(unsigned timer, uint32_t intervalo, unsigned unidade,
                     struct escrita plano[3]) {
  if (timer > 2 || unidade > 2 || intervalo == 0 || intervalo > UINT16_MAX)
    return false;
  const uint16_t porta = (uint16_t)(0x20u + timer);
  const uint8_t controlo = (uint8_t)((timer << 6) | (1u << 4) | unidade);
  plano[0] = (struct escrita){0x23u, controlo};
  plano[1] = (struct escrita){porta, (uint8_t)(intervalo & 0xFFu)};
  plano[2] = (struct escrita){porta, (uint8_t)(intervalo >> 8)};
  return true;
}

int main(void) {
  struct escrita plano[3];
  if (!preparar(2, 1000, 1, plano)) return 1;
  for (unsigned i = 0; i < 3; ++i)
    printf("porta=0x%02X valor=0x%02X\n",
           (unsigned)plano[i].porta, (unsigned)plano[i].valor);
  return 0;
}

Se o estado lido em 0x23 for 0x05, há pedidos dos timers 0 e 2, pelos bits 0 e 2. Isto é estado do dispositivo, diferente da máscara da notificação Minix. A IRQ partilhada avisa que é preciso consultar a causa; não escolhe sozinha qual timer originou o pedido. Não inventes uma escrita para limpar flags quando a especificação não define essa operação.

Polling e timeout

Em polling, o programa consulta o estado até a condição ser satisfeita, porque ainda não recebeu nenhuma notificação. Antes de ler o output buffer do i8042, espera OBF = 1. Antes de escrever uma ordem, espera IBF = 0. São condições diferentes.

Numa leitura concreta, lê 0x64. Se OBF estiver a 0, espera e volta a ler. Quando OBF for 1, lê 0x60 uma vez e interpreta esse byte. Se o estado assinalar erro de paridade ou timeout, consome na mesma o byte e descarta-o, para não deixar lixo no buffer a bloquear a entrega seguinte.

Um ciclo sem limite pode nunca terminar. Define uma política de falha e deixa o controlador ter tempo para responder. Esta função completa do ambiente Minix espera até cinco tentativas, espaçadas por 20 ms:

#include <lcom/lcf.h>
#include <stdint.h>

int wait_kbc_input_empty(void) {
  const unsigned attempts = 5;
  const unsigned delay_us = 20000;
  for (unsigned i = 0; i < attempts; ++i) {
    uint32_t status;
    int result = sys_inb(0x64, &status);
    if (result != OK) return result;
    if ((status & (1u << 1)) == 0) return OK;
    if (i + 1 < attempts)
      tickdelay(micros_to_ticks(delay_us));
  }
  return 1;
}

O resultado esperado é OK assim que IBF estiver a 0, ou erro se a leitura falhar ou a condição não surgir. São cinco observações e no máximo quatro atrasos, cerca de 80 ms mais o custo das chamadas e o arredondamento a ticks. Isto é uma política para este exemplo, não uma constante do dispositivo.

Polling não implica sempre espera ativa sem corpo, porque o programa pode consultar periodicamente e executar outra tarefa entre consultas. Com período de consulta $P$, um evento que fica disponível até ser lido espera entre aproximadamente 0 e $P$ antes de ser detetado. Se os instantes forem uniformes, a espera média é $P/2$. Um buffer pequeno pode perder eventos durante esse intervalo.

Quando escolher polling

Polling evita o custo de configurar e receber interrupções, por isso pode servir para uma operação curta e esperada, como obter uma resposta a um comando. Interrupções permitem bloquear à espera de eventos pouco frequentes. A escolha depende da frequência dos eventos, do tempo de resposta permitido, da capacidade do buffer e do custo de cada consulta ou atendimento.

Não concluas que uma das opções é sempre mais rápida: o pedido de interrupção do dispositivo, o atendimento no kernel e a notificação recebida pelo programa são etapas distintas, explicadas em Interrupções.