Ett förlorat interrupt är funnet och därmed en naturlig vilopaus efter att några andra bitar är på plats. Det får mig att fundera över hur ett interrupt egentligen ser ut. Såhär kanske?
För er som inte håller på med programmering så är den engelska översättningen “avbrott” en god start. Program körs i sekvens till de är klara. Ungefär som att handla varorna en efter en från en handlingslapp. Avbrotten kommer när det är något annat som måste fixas medan man gör det där. Jämför man med handlingen så kan det vara att telefonen ringer eller någon hejar på en och man går fram och pratar med den personen. Man avbryter det man höll på med och gör något annat en stund och går sedan tillbaks till det ursprungliga. I datorernas värld kan det vara en tangent som trycks ned eller något annat som pockar på uppmärksamhet. Man löser det där och sen fortsätter man med det man gjorde tidigare.
Har man ett flöde och ett avbrott så är ju allt väl. Har man flera så blir det struligare. Alltså man har gjort ett avbrott i sin handling och står och pratar med någon och så ringer telefonen och samtidigt blir man kissnödig och borde gå på toaletten samtidigt som brandlarmet i affären går… Ja ni fattar. Man måste liksom prioritera till slut samtidigt som man skall ta hand om alla händelser så att alla blir glada och nöjda. Är man i en bil och någon vill panikbromsa samtidigt som lampan för spolarvätska slut skall tändas så gäller det liksom att prioritera rätt.
Som inbäddad programmerare så sitter man alltså och försöker få till sådant där. Bäst jobb gör man om ingen märker att det man gjort finns. Ett inbäddat program skall liksom bara fungera. Som en bil t.ex., vem funderar nämnvärt över all programkod som körs i den när allt fungerar som det skall. Börjar bilen gasa full gas när man lägger i backen så blir det en annan sak såklart. Då märks koden eftersom den är trasig. Bra inbäddad kod syns och märks alltså inte.
Man skapar när man programmerar. Det är inte stor skillnad mot att göra musik, måla, tälja skedar eller skriva en text. Man vill att det man gör skall bli vackert och funktionellt och använder mycket tid just för att få det så smidigt som möjligt. Eftersom det finns många ställen man kan göra fel på och det är mycket information man skall hantera så blir det naturligtvis också en massa fel i det man gör. Man får alltså försöka leta de där felen också som en ganska stor del av sitt jobb. Betänker man att en mikroprocessor idag har en manual som består av flera tusen sidor tätskriven text och lägger till alla annan information som hör till ett projekt så är det inte konstigt om det blir fel och missuppfattningar. All kod innehåller fel, eller “buggar” som man säger, men de skall såklar vara så få som möjligt och helst finnas på ställen där de gör minst skada. Ibland kan de bli allvarliga som marslandaren som tog miste på tum och milimeter och kraschade. Sånt får inte hända. Då har man missat att testa och kanske att dokumentera. Att dokumentera är nämligen en annan viktig del av arbetet.
Varför är det då roligt att programmera? Ingen aning! Men det är det!