Les interrupcions i la seua importància en la computació i la programació de microcontroladors

En el spotify sona “Sympathy for the devil” dels Rolling Stones. Mentrestant via bittorrent estic baixant una pel·lícula de la saga “Jocs de la fam”. Demà és l’últim dia per entregar un treball d’història que estic redactant sobre el feudalisme i estic contínuament transitant del navegador al processador de textos per completar-lo amb informació acurada extreta d’Internet.

Aquesta podria ser una estampa típica de qualsevol adolescent fent un ús habitual d’un ordinador qualsevol. A primer cop d’ull, podria parèixer que s’estan executant moltes coses al mateix temps en el PC. No obstant, la naturalesa dels computadors és essencialment seqüencial i en la unitat central de procés sols s’executa una única instrucció a cada instant precís de temps.(amb varies CPUs o CPUs multicore si que es poden executar en paral·lel varies instruccions)

Però, com pot ser això? La música no s’atura, a més, el punter del ratolí està contínuament menejant-se sense cap retard cada vegada que l’accione, és més, cada vegada que prem una tecla, apareix immediatament el seu caràcter associat en l’aplicació pertinent; ja siga el navegador, processador de textos o la app que tinga en primer pla en eixe moment.

Tot açò és possible gràcies a la màgia de la gestió de processos dels Sistemes Operatius moderns amb les seues rapidíssimes commutacions de context (processos) i al vell mecanisme d’interrupcions dels microprocessadors. Només amb l’ús d’aquestes tecnologies podem enganyar a l’usuari perquè de manera psicològica perceba un flux continu en l’execució de les aplicacions de l’ordinador. Tanmateix, la CPU sols dedica una estona xicoteta a cadascuna d’elles, però intercanviant d’una a altra de manera ràpida i rotativa perquè mai arribem a percebre un discontinu estrany en l’acció.

Per la seua especial importància en el món dels microcontroladors pararem únicament atenció al mecanisme d’interrupcions. Parlar de la gestió de processos d’un sistema operatiu mereixeria moltes més planes per escriure que no venen al cas que es vol exposar.
Podem definir una interrupció, en el context de la informàtica, com una senyal enviada al processador per informar-lo que abandone el que està fent per atendre una petició, fer un processament i seguidament retorne al punt exacte d’execució on s’havia quedat abans de l’ocurrència de la interrupció.

Les interrupcions solen estar associades a dispositius d’entrada i/o eixida dels PCs. Però també hi ha interrupcions que es poden activar per temps i de molts altres tipus. Per exemple, cada vegada que menegem el ratolí, es genera una interrupció que fa que la CPU de l’ordinador l’atenga per representar la seua nova posició i ràpidament retornar al processament que s’estava realitzant prèviament. El mateix succeeix cada vegada que es prem una tecla.

El processament concret associat a una interrupció és un problema de programari que cada sistema operatiu resol de forma diferent. Sempre és segueix la mateixa màxima, el processament de la interrupció cal que siga ràpid. Gràcies a aquest vell mecanisme és pot simular una certa pseudo paral·lelització en l’execució de processos, però al cap i a la fi l’execució interna segueix essent purament seqüencial.

El mecanisme d’activació i desactivació de les interrupcions és quelcom intern al maquinari. Tant els microprocessadors com microcontroladors vells i actuals l’incorporen i és molt determinant el seu ús i programació per fer aplicacions eficients. Del seu bon ús depèn fer bons programes o dolents, sobretot en l’àmbit dels microcontroladors.

Per exemple, últimament he estat programant el mecanisme de comunicació bluetooth (BT) entre un Robot seguidor de línia i un ordinador o aparell mòbil per transmetre paràmetres de configuració i telemetria. En un primer estadi aquesta comunicació es va implementar de manera síncrona usant tècniques de “polling” per escrutar contínuament des del robot si hi havia algun missatge per ell. Òbviament usava aquesta tècnica en els moments que el microcontrolador del robot no estava fent res especial, com per exemple, l’espera de la pulsació del botó d’engegada per començar amb l’algorisme de seguiment de línia. Malauradament aquest tipus d’implementació compta amb no poques contraindicacions, moltes limitacions i algunes deficiències.

Entre els problemes principals estava la impossibilitat d’enviar al robot paràmetres de configuració una vegada el robot havia començat amb el seguiment de línia. Una vegada començat el seguiment, cada milisegon es fa una lectura del sensors d’infrarojos i s’actua de manera diferencial els dos motors mitjançant un algorisme PID per fer el control i no perdre la línia negra. Això, deixa poc temps per entretindres en cada iteració en altres coses menys importants com pot ser la comunicació BT. A més a més, a vegades polsàvem el botó d’engegada i el robot no responia justament per què en aquell moment estava llegint si havia arribat alguna cosa per BT. A tot això, cal afegir que el 99,999% del temps que el robot comprovava si havia arribat alguna cosa, no hi havia res per ell. Un mecanisme de totes totes clarament ineficient.

Arribats a aquest punt, òbviament la solució passava per reimplementar el mecanisme de comunicacions intentant usar interrupcions. L’estratègia ha consistit en programar una interrupció que s’activa en el moment que nosaltres rebem qualsevol bit pel mòdul BT del robot. En eixe precís instant esperarem la resta de bits fins trobar un caràcter delimitador i comprovem quina és la comanda rebuda. Seguidament desactivem la interrupció de recepció i procedim a retornar la informació demanada o simplement contestem amb un codi de confirmació de recepció i execució de comanda. Després, tornem a activar la interrupció de recepció i seguim executant el codi normal del robot fins que una altra comunicació iniciada des d’un ordinador o mòbil torne a activar-la de nou.

Amb aquest mecanisme, tots els problemes anteriorment descrits desapareixen i ara tenim possibilitat de passar informació i ordres al robot en qualsevol estadi d’execució del programa que el governa. Simplement enviem des del mòbil una comanda d’aturada, engegada, canvi de velocitat del Robot etc. Aquest activa una interrupció de comunicació, deixa de fer el que estava fent, atén la comanda i després retorna al punt on s’havia quedat. Amb una comunicació asíncrona com aquesta, aconseguim que un microcontrolador poc potent tinga cert grau de paral·lelització sense la necessitat d’executar cap SO que per altra banda és impossible d’executar en un dispositiu de tant limitades prestacions (32Kbytes EEPROM, 1Kbyte de RAM, arquitectura de 8 bits i 20Mhz de freqüència de rellotge).

En aquest tipus de context és quan te n’adones de la importància d’aquest mecanisme i com un ús apropiat del mateix permet distingir entre bons programadors i bons programadors de microcontroladors. Quan escrius codi per a un SO que és multitasca no has de preocupar-te de molts aspectes com l’entrada/eixida perquè el SO t’abstrau d’aquestos detalls gestionant ell mateix les interrupcions i els processos. Però, quan no disposes d’un SO, com és el cas dels microcontroladors, l’ús d’interrupcions és l’única eixida per a un control eficient de dispositius d’entrada o sensors que vols que funcionen de manera asíncrona.