Il bit-banging si riferisce al concetto di far generare / campionare i segnali che escono o arrivano in un dispositivo dal software piuttosto che dall'hardware. Ovviamente è necessario un po 'di hardware, ma quando si utilizza il bit-banging, l'unico hardware per ogni output è un latch che può essere impostato o cancellato in modo esplicito dal software e l'unico hardware per ciascun input è un'interfaccia che consente al software di testare se è alto o basso (e in genere esegue un ramo condizionale per uno stato ma non per l'altro).
La velocità massima che può essere raggiunta con il bit-banging sarà generalmente una frazione di ciò che potrebbe essere ottenuto con hardware appositamente progettato, ma al di fuori dei limiti imposti dalla velocità del processore, il bit-banging è molto più versatile e può essere utilizzato in circostanze dove l'hardware generico non è del tutto adatto e l'hardware speciale non sarebbe conveniente.
Ad esempio, molti controller dispongono di una porta "SPI-style" che si comporta essenzialmente come segue: quando un byte viene scritto in un determinato registro, l'hardware genererà un numero di impulsi di clock (in genere otto), eseguendo il clock di un bit di dati sul fronte di ogni impulso di clock e campionamento di un bit di dati in entrata sul fronte di uscita. Generalmente, le porte in stile SPI dei controller consentiranno di configurare una varietà di funzionalità, ma in alcuni casi potrebbe essere necessario interfacciare un processore con un dispositivo che fa qualcosa di insolito. Un dispositivo può richiedere che i bit di dati vengano elaborati in multipli diversi da otto, oppure può essere necessario che i dati vengano emessi e campionati sullo stesso fronte di clock, oppure potrebbero avere altri requisiti insoliti. Se l'hardware particolare sul controller che si sta utilizzando può supportare i propri requisiti precisi, ottimo (alcuni forniscono numeri configurabili di bit, tempi di trasmissione e ricezione configurabili separatamente, ecc.) In caso contrario, il bang-bit può essere utile. A seconda del controller, il bit-bang di un'interfaccia SPI richiede spesso 2-10 volte il tempo necessario per consentire all'hardware di gestirlo, ma se i requisiti non si adattano a quello dell'hardware, lo scambio di dati più lentamente potrebbe essere migliore di non riuscire a farlo affatto.
Una cosa importante da notare con i disegni a bit di bit è che sono i più semplici e robusti in circostanze in cui o i dispositivi con cui si comunica sono in attesa sul controller di bang-bit per generare tutti i loro tempi, o dove il controller sarà autorizzato a attendere, senza distrazione, che arrivi un evento e dove sarà in grado di fare tutto ciò che deve fare con quell'evento prima che arrivi qualsiasi altro evento su cui deve agire. Sono molto meno robusti nelle circostanze in cui un dispositivo dovrà essere in grado di reagire agli stimoli esterni entro un intervallo di tempo relativamente breve, ma non può utilizzare il 100% della sua energia per osservare tali stimoli.
Ad esempio, supponiamo che si desideri che un processore trasmetta i dati in stile UART in serie a una velocità molto elevata rispetto alla sua velocità di clock (ad esempio un PIC che esegue 8.192 istruzioni al secondo desidera emettere dati a 1200 bps). Se non sono abilitati interrupt, tale trasmissione non è difficile (clock di un bit ogni sette cicli di istruzione). Se un PIC non stava facendo altro che attendere un byte di dati in arrivo a 1200 bps, poteva eseguire un ciclo a 3 cicli in attesa del bit di avvio, quindi procedere con il clock dei dati a intervalli di sette cicli. In effetti, se un PIC avesse un byte di dati pronto per l'invio all'arrivo di un byte di dati in entrata, sette cicli per bit sarebbero sufficienti per consentire al PIC di inviare il suo byte di dati contemporaneamente alla lettura del byte in arrivo. Allo stesso modo,se tale risposta avrebbe un tempo fisso rispetto alla trasmissione originale . D'altra parte, i PIC non avrebbero la possibilità di gestire le comunicazioni bit-bang in modo tale da consentire a entrambi i dispositivi di trasmettere in qualsiasi momento ritenuto opportuno (al contrario di avere un dispositivo in grado di trasmettere quando vide adattarsi e fare tutto ciò che gli piaceva quando non trasmetteva, e un dispositivo che avrebbe dovuto spendere la maggior parte dei suoi tempi non facendo altro che aspettare le trasmissioni dal primo dispositivo).
