A batida de bits refere-se ao conceito de gerar / amostrar os sinais que saem ou entram em um dispositivo por software em vez de por hardware. Obviamente, é necessário algum hardware, mas, ao usar a troca de bits, o único hardware para cada saída é uma trava que pode ser explicitamente configurada ou limpa por software, e o único hardware para cada entrada é uma interface para permitir que o software teste se é alto ou baixo (e normalmente executa uma ramificação condicional para um estado, mas não para o outro).
A velocidade máxima que pode ser alcançada com o bit-banging geralmente será uma fração do que poderia ser alcançado com o hardware criado especificamente, mas fora das limitações impostas pela velocidade do processador, o bit-banging é muito mais versátil e pode ser usado em circunstâncias onde o hardware de uso geral não é bastante adequado e o hardware de uso especial não seria econômico.
Por exemplo, muitos controladores possuem uma porta "estilo SPI", que se comporta essencialmente da seguinte maneira: quando um byte é gravado em um determinado registro, o hardware gera um número de pulsos de clock (normalmente oito), atingindo o tempo limite de um bit de dados no ponta de cada pulso de clock e amostragem de um bit de dados recebido na borda de fuga. Geralmente, as portas no estilo SPI dos controladores permitem que vários recursos sejam configurados, mas, em alguns casos, pode ser necessário fazer a interface de um processador com um dispositivo que faz algo incomum. Um dispositivo pode exigir que os bits de dados sejam processados em múltiplos diferentes de oito, ou pode exigir que os dados sejam de saída e amostrados na mesma borda do relógio, ou pode ter algum outro requisito incomum. Se o hardware específico no controlador que você está usando pode suportar os requisitos precisos, ótimo (alguns fornecem números configuráveis de bits, tempo de transmissão e recepção configurável separadamente, etc.) Caso contrário, a troca de bits pode ser útil. Dependendo do controlador, a troca de bits de uma interface SPI-ish geralmente leva de 2 a 10 vezes o tempo que o hardware permitir, mas se os requisitos não se encaixarem no hardware existente, a troca de dados mais lentamente pode ser melhor do que não ser capaz de fazê-lo.
Uma coisa importante a ser observada nos projetos com interrupção de bits é que eles são mais simples e robustos em circunstâncias em que os dispositivos com os quais estão sendo comunicados aguardam que o controlador de interrupção de bits gere todo o tempo, ou onde o controlador poderá aguarde, sem distração, a chegada de um evento e onde ele poderá fazer tudo o que precisa fazer com esse evento antes de chegar outro evento em que ele precise agir. Eles são muito menos robustos em circunstâncias em que um dispositivo precisará ser capaz de reagir a estímulos externos dentro de um período de tempo relativamente curto, mas não pode usar 100% de sua energia para observar esses estímulos.
Por exemplo, suponha que se deseje que um processador transmita dados no estilo UART em série a uma taxa muito alta em relação à sua velocidade de clock (por exemplo, um PIC que esteja executando 8.192 instruções por segundo deseja gerar dados a 1200 bps). Se nenhuma interrupção estiver ativada, essa transmissão não será difícil (relógio um bit a cada sete ciclos de instruções). Se um PIC não estivesse fazendo nada além de aguardar um byte de dados de 1200bps de entrada, ele poderia executar um loop de 3 ciclos aguardando o bit de início e depois prosseguir com o registro dos dados em intervalos de sete ciclos. De fato, se um PIC tivesse um byte de dados pronto para enviar quando um byte de dados recebido chegasse, sete ciclos por bit seriam tempo suficiente para o PIC enviar seu byte de dados simultaneamente com a leitura do byte recebido. Da mesma forma,se tal resposta tivesse um tempo fixo em relação à transmissão original . Por outro lado, não haveria maneira de os PICs acelerarem o tratamento das comunicações bit-bang de tal forma que um ou outro dispositivo pudesse transmitir a qualquer momento que entendesse (em vez de ter um dispositivo que pudesse transmitir quando visse encaixar e fazer o que quiser quando não estiver transmitindo, e um dispositivo que teria que passar a maior parte do tempo sem fazer nada além de aguardar transmissões do primeiro dispositivo).