Category Archives: Enginyeria de la programació

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.

Software engineering endemic problems and why we need good programmers. My experience

This is, a manipulated compendium of the most notable quotes, words and ideas of the most brilliant computer scientists we have ever had. Edsger Dijkstra, Ken Thomson, Dennis Ritchie, Alan Turing, Niklaus Wirth, Alan Kay, Bjarne Stroustrup, Richard Stallman, Frederic Brooks, Martin Fowler, Donald Knuth …  I have experienced these vivid thoughts as if they were my own flesh and blood many times in my professional career. It is my desire to share with you, written in a sequential and linked order, trying to construct a reasoning related text and not a mere bunch of isolated ideas. I hope you enjoy the reading.

Main idea: All large and medium software projects always tend to fail, be it finishing on time, overbudget or both.

When we talk about the software crisis we are exactly referring to the previous assertion and the fact most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.  Some, in an humorous mood, think this is due to all programmers tend to be optimists in their estimations, but the reality is that the complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstracts away its essence.

In the practical world of computing, it is rather uncommon that a program, once it performs correctly and satisfactorily, remains unchanged forever. As a consequence, systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence. And what is worst, contrarily to other engineering disciplines, adding manpower to a late software project, makes it later.

In addition, specifications contribute to software complexity, sometimes extracted from requirements that are ambiguous, conflicting, or incomplete and we must work to resolve, as soon as possible, with a kind of customer that most of the times don’t even really knows what he wants. Be very carefull! even the best planning is not so omniscient as to get it right the first time. The complexity is something inherent to the software building act and it is preferable to convince your customer to work in collaboration over fixed contract negotiation, trying to respond to change instead of a following plan. Obviously the main problem of this desirable approach, it will be the budget deviation and make it understandable to our customers.

Program construction consists of a sequence of refinement steps. One of my most productive days was throwing away 1,000 lines of code. The lurking suspicion that something could be simplified is the world’s richest source of rewarding challenges. The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague.

If your code its well documented, or better, auto-documented and clean, as a result it will be easy to understand and consequently easy to fix mistakes, verify and maintain. Simplicity is prerequisite for reliability. Remember, any fool can write code that a computer can understand but good programmers write code that humans can understand.  It is a common error when programmers sacrifice clarity in favor of execution speed because they often develop software that runs fast, but is error-prone and difficult to change.

Golden rule of software development: Write software for others as you wish they would write for you.

From my experienced point of view the easiest way to debug is to write software without any bugs. Debugging sucks, testing rocks,  but remember that program testing can be used to show the presence of bugs, but never to show their absence ! It had to be punishable working in teams not using batteries of unit testing, regressive tests , coverage tests or other similar techniques that serves as an effective premature alert mechanism prompting any important bug coming out from our code.

All inherent problems and complexity related to software engineering and programming always have been there, try to know and identify these problems and avoid trendy and miraculous techniques, methodologies or paradigms without any critical approach. The computer industry is the only industry that is more fashion-driven than women’s fashion. Certainly not every good program is object-oriented, and not every object-oriented program is good. Quality programming is usually taught by design patterns  and good examples. We have thousands of free software projects with tons of wisdom hidden among their lines of code. Please take advantage of this, don’t be a  fool ! There are lots of different tools and languages. Open your mind ! You must perform like a plumber, for every job, there is required a tool or set of them that best suit to complete successfully the work.

It is important to be good working in a team and learn to write. The ability to communicate your ideas to others will aid you more than anything else you will learn, and make you more valuable to employers.

Study after study shows that the very best designers and programmers are A+ team players. They produce structures that are faster, smaller, simpler, clearer, and produced with less effort. The differences between the great and the average, approach an order of magnitude.

From my point of view as a consequence of all having said before we can state that a good programmer is someone who:

Loves to code in a creative way and it’s ready to get things done rather than only speak. Continuously refactors code in a leveraging way trying to make it faster, smaller, clearer, simpler, more general and produced with less effort. One that don’t reinvent the wheel, reuse code and use design patterns that are the smart experienced solution of many programmers that have had the same problems than you, maybe many years before you were born. A good programmer is a A+ team player and writes tests because its preferably over debugging and wasting lots of time verifying manually the correctness of the software. He is alway prone to reuse good third-party code and to develop, using either as a base or inspiration, good quality free software. From the engineering point of view you must love free software because is the greatest source to learn by example. A good one, should focus on usability and writing maintainable code. Be able to code in any language and choose the right languages and tools that best fits for every different project. We can’t use a hammer for all kind of works! Definitively, a person that should be instructed thoroughly and know more than basic computer science.

We need good programmers (A+), they are the most promising weapon to fight against software intrinsical complexity nature.

Google crea el seu propi navegador web

Amb una política frenètica d’innovació continua, google posa a disposició de l’internauta una beta d’un nou navegador web.  Plana web del projecte
No estan massa clares les raons per les que Google s’ha involucrat en un projecte d’estes característiques ja que en el mercat existeixen nombrosos navegadors (IExplorer, firefox, opera, safari, konqueror etc.)  i fer-se un lloc és molt costós i a més a més diluir esforços tenint navegadors lliures tant potents com mozilla firefox pareix un disbarat. Ells addueixen raons molt ambigües i genèriques que no aporten res nou al panorama tecnològic com, eficiència, velocitat de càrrega, convertir el navegador en una plataforma real d’execució complexa d’aplicacions etc. Més bé pareix un projecte experimental que intentaran que tinga gran difusió d’una manera o altra. En cas de tindre sort i poder posicionar-se com navegador dominant s’estalviaran tots els costos associats a la promoció del motor de cerca google en altres navegadors. Cal recordar que la principal fons d’ingressos del navegador mozilla firefox prové de la companyia google simplement pel fet de posar un  cuadret de cerca a la part superior dreta on les cerques per defecte és fan al motor de google (Este detall són alguns mil·lions de dolars a l’any).

Google Chrome és un navegador dissenyat per fer que l’ús del web sigui més ràpid, fàcil i segur gràcies a un disseny minimalista que no destorba. Realment no és una navegador web creat des de cero sinó que està fet a partir d’altres components de programari lliure ben coneguts com són Apple’s WebKit i Mozilla’s Firefox.  La beta actual està lluny de ser un projecte acabat i només està disponible per a windows però la companyia té previst llançar el producte en un futur com a mínim també per a les plataformes linux i Mac.

La UOC llibera tots els materials del seu màster de programari lliure

M’entere a partir de barrapunto que en l’adreça http://ocw.uoc.edu/informatica-tecnologia-i-multimedia podem accedir al llistat complet de materials dels cursets que abaix adjunte.Enhorabona a la UOC per tan magnífica iniciativa

 M2001 – Introducció al programari lliure, Febrer 2008
  M2002 – Sistema operatiu GNU/Linux bàsic, Febrer 2008
  M2003 – Administració avançada del sistema operatiu GNU/Linux, Setembre 2007
  M2004 – Implantació de sistemes de programari lliure, Febrer 2006
  M2005 – Xarxes de computadors, Maig 2005
  M2006 – Ampliació de xarxes de computadors, Febrer 2008
  M2007 – Aspectes avançats de seguretat en xarxes, Novembre 2006
  M2008 – Desenvolupament d’aplicacions web, Febrer 2006
  M2009 – Bases de dades, Febrer 2007
  M2010 – Introducció al desenvolupament de programari, Febrer 2006
  M2011 – Conceptes avançats en desenvolupament de programari lliure, Febrer 2006
  M2012 – Enginyeria del programari en entorns del programari lliure, Febrer 2006
  M2013 – Utilitats i eines, Febrer 2006
  M2014 – Aspectes legals i d’explotació, Febrer 2007