Etter å ha dillet rundt med kompilatorer med “airbags” i litt for lang tid, så er det nesten litt forfriskende å begå kode som dette med null errors og null warnings etter kompilering (sakset fra SIGNAL(SIG_UART_RECV))

if (cbIndex >> cmdLength) {…}

Har irritert meg i flere kvelder over hvorfor klokka tilsynelatende bare aksepterte annenhver kommando. Brukte derfor det eldgamle stirre-på-koden trikset [1].

Etter et å ha erstattet shiftoperatoren med gt-operatoren, som jeg nok egentlig hadde tenkt å benytte (hadde jeg ikke vært så farget av et lass med bit-initialisering av ymse registere et par linjer lenger opp) – så ble kommunikasjonen med klokka dønn stabil – over blåtann.

[1] rasjonalet bak denne debuggingsteknikken er som følger: “Hvis du stirrer lenge nok på din egen kode, så vil du før eller senere forstå den – eller finne feil i den. Det krever minimalt med egeninnsats bortsett fra påfyll av snus og kaffe, samt regelmessig rynking av panna.”

Da har jeg fått testet noen flere features på nixiekortet. In circuit-programmering funker, dekatronkontroll funker, og alle 6 displayutganger funker. Fant en bug i skjemaet, men det verste som kan skje er at powersupply-LED’en brenner ut, så det kan vi leve med.

Jobber nå med dokumentasjon, testing av RF-interfacet, samt implementasjon av en protokoll som gjør det mulig å bruke kortet på en vettug måte – tenker vi setter av opp til flere kvelder akkurat til denne biten. Hvis jeg kjenner meg selv rett, så blir det en lang drakamp med feature-creep-demonene her…

Planen så langt er at kortet kan operere i 2 forskjellige modus. Dvs som klokke, der en kan sende kommandoer for å synke/stille klokka eller som generisk displaymodul, der en kan kontrollere de 6 displayene og dekatronen individuelt. Må grave litt i skuffa for å finne igjen en eller annen Max-IC som gjør meg i stand til å hekte sendermodulen på laptoppen. Når dette er i boks, så blir det å sette seg foran en eller annen terminalemulator med kryssede bein og armer.

Istedet for å stage-dive ned i hylekoret, så lar vi heller datalagringsdirektivet inspirere oss til litt “roll your own”- crypto. Jeg antar at dette også kan gjelde flere – kanskje til og med de som datalagringsdirektivet er myntet på ?

Jeg lovte for 14 måneder siden en flaske Crème de menthe til førstemann på jobben som klarte å knekke en RSA cipher med en astronomisk 25-bits nøkkel. Det er fremdeles ingen som har hentet flaska – og jeg må innrømme at jeg er bittelittegrann skuffa over kollegene.

Lett inspirert av Simon Singhs “The Code Book”, samt Neal Stephensons “Cryptonomicon”, så kjører vi nå på med 2 crypto-challenges på TimeExpander (Må innrømme at jeg håper bittelittegranne på at Mr.Black kliner til med et vakkert CUDA-basert angrep her). Førstemann som tar oppgave 1, har sikret seg en av de viktigste ingrediensene til en Long Island Iced Tea. Tar noen oppgave 2, så er jeg målløs – selv om vi fremdeles er milevis unna sterk kryptering (den er kanskje noe i nærheten av 3300 bits nøkkel).

De fleste har vel allerede tafset på PGP en eller annen gang i livet, men det er jo alltid mye morsommere å implementere selv.

Algoritmen er mainstream RSA, og encoding er den samme for begge oppgavene. Blokkstørrelsen er på 6 ASCII-tegn. (Eks. ABABCC kodes om til tallet 065066065066067067, som så krypteres til en blokk)

Challenge 1

Eksponenten er her 13, og modulus er 67678791760781523437. Dette koker ned til en 64-bits nøkkel, og på en gjennomsnittlig laptop, så vil du finne faktorene i denne på litt over 6 sekunder i GHC-interpretern (Vil anbefale å laste ned factors.hs + avhengigheter ). Når du har funnet faktorene, så kan du beregne dekrypteringseksponenten med Euclids litt mer hårete algoritme. Har du funnet faktorene p & q, så beregner du (q-1)*(p-1) som du sender inn som første parameter i algoritma. Eksponenten sender du inn som andre parameter. Tredje-(ut)parameter gir deg den überhemmelige dekrypteringseksponenten du trengre for å få ut klarteksten.

Meldinga er:

29643486281214166221
31754568318096595222
18866919755208611117
55040353993448503713

Challenge 2

Samme eksponent, men litt mer spenstig modulus (

678648287556408617566069222098092902319638579724763875423231780887782326290241

8744935562591753666395263203428475274164718768544714991285086897539719863791118

6738188516300965912313252519347371139520672783464398243462618474462789121940809

9114315856609681214446240262839281497875178239697354955962530884728294167958882

1810144649133171263643828721099263415616160241960347422876670232802323954916153

203458325605447155696165221304951552737653043673235876789182276584555029158316

306025226515214149292624577476985142800101585906921256842656760345220750940800

773391507375838096484475814715991700775116950996058350550623510986740512768220

5901173058576812786694734254940160714262362347388194271548813831795003045136323

4931117226890457894237151923513658606018447058856460088641456991246871553798871

6321044744986262680135316851295044487842324672058126529415662142249679080097680

3872828355872743194309262734480141233313566807508114373357542300631203369795753

89505524061770859087441543471000292176019523256017430869)

Meldinga er:

Blokk1:

377115642735908117634179214447605612540218329872407165870138140622416033271

897546885685495927151782530732361682604928598246196985267990225557751408420

636520989535311669448003738074476220310868379166880607681043991761231
Blokk2:

385003780674235349593353258943692556522883981777147082636946189123366585988

38762006293275050883553693166734753353162741955253799670514390196940297464

753492879286385543131085777359141224795483055628098023956281545231
Blokk3:

62262973840636976542976222853245241536540257579793119620781087099370189332

145848943412187781153561779540870288111901778724323262918299776123951572354

8842888816551428732027287524442967514199041656065173235375891920166015625

Blokk4: 688579136852433871931703296

(Konkatener linjene i h.h.v. modulus of hver blokk til ett tall – worpress sliter med lange ord…):

I motsetning til gjengs oppfatning, så er “kunst” et ord som ikke referer til noe annet enn beherskelse av en ferdighet. Ordet beskriver mestring av en displin. Om denne disiplinen er visuelle skildringer, arkitektur, kampsport, programmering, utøvelse av musikk, er likegyldig for forståelsen av ordet.

Den totale beherskelse av et fag virker på ikke-fagkyndige så imponerende at resultatet av utøvelsen tilsynelatende bare kan forklares av en unik medfødt begavelse eller en ukjent X-faktor. Sjelden har Arthur C. Clarkes tredje lov vært så treffende som i dette tilfellet, d.v.s “Any sufficiently advanced technology is indistinguishable from magic.”.

Den, for enkelte nok litt skuffende konklusjonen, er at mestring i de aller fleste tilfeller er et resultat av fokusert og hardt arbeid over ubehagelig lang tid. D.v.s. en må påregne å anstrenge seg noe for å ende opp som mester – uansett disiplin.

Det jeg lurer fryktelig mye på er hvorfor det er så enormt stor forskjell på hvordan en forholder seg til mestere innen de forskjellige disiplinene. Innen eksempelvis musikk, litteratur og billed-(nekter å sette inn ordet her, men du vet hva jeg mener), så er mestrene frie sjeler.

Innen de litt hardere disiplinene, der samfunnet har gjort seg avhengige av hva som produseres, så er mestrene satt under administrasjon.

Mitt første spørsmålet er: “Hvorfor ?”. Hva oppnår en ved å umynddiggjøre de som best er i stand til å utøve sitt fag ? (Jeg mistenker at det riktige svaret er “Sole seg i glansen, kompensere for egen utilstrekkelighet, samt skimme en ikke ubetydelig del av kaka”)

I IT-verdenen, så er vi belemret med evigvarende “hva er den beste prosessen”-diskusjoner. Nye prosessmodeller oppstår, og gamle dør. Likevel viser all statistikk at de er irrelevante. Resultatet blir like begrædelig hver jækla gang. Det som er litt interessant, er at et fellestrekk for alle prosessmodeller jeg kjenner til (også de smidige) er at alle faglige ressurser skal administreres – enten av en bønneteller, eller av prosessen selv. “Kontroll” er et nøkkelord for alle, og kontrollen ligger ikke hos den som har de beste forutsetningene for å ha den.

Mitt andre spørsmål er: “Kan en administrere seg fram til et mesterverk ?”. Øker den faglige utførelsen i kvalitet ved at det sitter noen på toppen som er flinke til å telle ?

La oss ta eksempelet med taket i det sixtinske kapell. Hvordan hadde dette sett ut hvis pave Julius den andre hadde kjent til en eller annen prosessmodell ? (tenk litt på den).

Mitt tredje spørsmål er: “Kan en i det hele tatt forvente resultater i form av mesterverk uten at mesteren selv har den totale kontroll over utøvelsen ?”. Får lærlingene eksempelvis klædde på bildene til Nerdrum etter eget forgodtbefinnende ? Er det noe som heter “min og din” ? (Hei til XP’erne forresten !)

Mitt fjerde spørsmål er: “Hvorfor gir vi ikke kontrollen tilbake til mestrene ?” Hvilket nek var det som kom på den glitrende ideen at de skulle gi fra seg kontrollen i utgangspunktet ?

(Nå er det sikkert noen som er fristet til å si “Software craftsmanship”. Til dere vil jeg si “bollocks !”.  Ideen er ikke ny, og de nødvendige rammenebetingelsene finnes ikke. Søt tanke, men de eneste som vinner på at du velger å dele kunnskap er de som administrerer deg (tenk litt på den også…).

Mitt femte og siste spørsmål er: “Hvorfor er organisasjonene forundret når mestrene velger å finne på noe annet ?”.

PS. Hvis du vil opp og frem, så kan du ihvertfall i IT-bransjen være litt bevisst på Larry Nivens inverse variant av Arthur C Clarkes tredje lov. Denne går som følger: “Any sufficiently advanced magic is indistinguishable from technology.”. Følger du den, så vil du nå langt – kanskje helt inn på styrerommene.

De av dere som leser Make-bloggen jevnlig vil sikkert dra litt på smilebåndet av denne posten. Jepp, dette er atter en “Ooooh ! Jeg klarer å blinke en LED”-post.

Jeg har egentlig aldri hatt dilla på LED-matriser, men siden ELFA og/eller postmannen tydeligvis har gått i vranglås, og nekter å levere meg pakkelapp for neste batch av komponenter, så måtte jeg finne på noe for å unngå å dø av kjedsomhet. Jeg begynte derfor å lodde LED-matrise. Det krever ikke store forberedelsene foruten en neve LEDs og det er bedre tidsfordriv å lage sin egen skjerm enn å glo på den i stua (Jeg har jo også allerede skrytt på meg at Lamna-kortet kunne adressere intet mindre enn 192 individuelle LED, så jeg kunne like gjerne lage en liten proof of concept.)

Monteringen var unnagjort på et par timer (, men jeg måtte begrense meg til 128 pixler istedet for 192, da jeg gikk tom for plass på eksperimentkortet). D.v.s hvis du går med planer om en sånn i full HD, så må du påregne å sette av ca 32000 timer med inhalering av lodderøyk. Blyfritt tinn er derfor å anbefale.

Den fysiske adresseringen av en slik matrise er på rad og kolonne-nivå, så koblingen er rimelig enkel. Du seriekobler bare katodene og anodene innenfor adresseringsområdet. Bruker du 7221/7219, så trenger du ikke tenke på å beregne seriemotstander til radene. Du slipper også å legge beslag på mer enn 3 pinner på mikrokontrolleren, da du har en enkel serieprotokoll mellom denne og displaykontrollerne.

For å gjøre bruken fra software enklest mulig, så laget jeg meg en liten memorymap som håndterte konverteringen av displayinformasjon i displaybufferet (som jeg baserte på det mer tradisjonelle kartesiske koordinatsystemet) mitt og det litt mer aparte forventingene til kontrollerne. Deretter var det “tut og kjør”.

Frameraten er helt akseptabel. Jeg må faktisk legge inn kunstpauser på ganske mange titusen klokkesykluser mellom hver frame for at teksten ikke skal scrolle for fort.

Videoen under viser en relativt enkel scrollende tekst, men jeg ser for meg at den kan ha ganske mange andre anvendelser. Lurer eksempelvis litt på å lage en automatisk blinds-klokke / infodisplay til neste pokerkveld. Et annet alternativ er å rebrande Lamna som R2D2-kontroller. Jeg vurderer også å sjekke ut om de gamle K155ID1/74141 Nixie-dekoderne kan pulses. Isåfall kan jeg kanskje hekte dem bak Max-kontrollerne for å bruke i custom-knipsekasse med Nixie-display.

Jeg har i de siste dagene (i tillegg til å handle hus), vært så heldig at jeg har fått gjøre det som er få utviklere forunt. Vi hadde ei lita glippe mellom releaser, og jeg har tillatt meg / fått tillatelse til å rydde i kode – som burde vært røsket opp i for lenge siden. Ettertiden får bedømme om jeg har gjort et bra stykke arbeid eller forårsaket et bra stykke merarbeid for mine kolleger, men jeg har ihvertfall hatt det moro. Det føles omtrent like godt som når du begynner å skimte konturene av gulvet når du rydder opp etter ungene (og deg selv…).

Normalt så drives prosjekter fremover av funksjonaltitet. Krav spesifiseres av forretningsressurser. Teknikerene skriver tester og implementerer. Testlinjene verifiserer så at ting henger sånn tålelig sammen før det settes i produksjon. Dette funker forsåvidt ok – helt til prosjektene blir lange og kodebasen blir stor.  Da skriker koden sårt etter vedlikehold, og det er av en eller annen grunn få organisasjoner som evner å se konsekvensen av å ignorere skrikene.

Mengden av penger som ramler inn i et prosjekt er en funksjon av – wait for it – “funksjonalitet” som kan leveres til en gitt deadline. Kunden driter i om det er vanskelig eller lett å lage funksjonaliteten. Det er den de betaler for og det er den som gir dem forretningsverdi.

Kode som ikke aktivt forvaltes parallelt med endring/innføring av funksjonalitet, blir med tiden “innfeit” og kreftsyk. Den krystallklare luften du engang kunne beskue tindene av elegante strukturer gjennom er blitt tett og ugjennomtrengelig av forurensning.  Tankene som en gang måtte ha vært lagt til grunn er umulig å rekonstruere. De har for lengst forduftet bak horisonten – sammen med de opprinnelige utviklerne

Symptomet på “innfeithet” er gjerne at det kreves enorme mengder innsats, penger og dødsforakt, som kun et fåtall utviklere er begunstiget med, for å gjøre selv den minste endring i koden, uten at en må leve i frykt for å bli skutt i bakhodet en lørdags kveld – av en sideeffekt som valgte å propagere opp av myra et par uker etter release. Ting blir dyrere enn de burde ha vært, men samtidig må de i en prosjektorganisasjon løses innenfor de funksjonelle rammene. Å spørre etter mer penger for å “reparere” kode en har laget selv og allerede levert er vanskelig.

Rockstar-groupiene nikker sikkert gjenkjennende nå. Hørte jeg noen som sa “kohesjon” og ”kobling” ?. Svært få utviklere tør å protestere hvis en fanboy skriker “Dårlig kohesjon! Ikke rart det går til hælvete!?! Har du ikke hørt om S’en i SOLID ?!?. Vi er jo fagmenn ! Vi skal kunne sånt”.

Yeah, right … Det er nesten litt søtt.

I en forsamling vil som regel alle utviklere med respekt for seg selv nikke anerkjennende og tilsynelatende gjenkjennende til sånt – samtidig som de innerst inne ber en stille bønn om ikke å bli hørt i prinsippene, eller gud forby få et spørsmål fra podiet om hva kohesjon egentlig er for noe.

Jeg skal hive ut av meg en påstand.

Det er kun et fåtall av de som til daglig arbeider med utvikling av programvare som har noe som helst forhold til metrikker og designprinsipper. Jeg sier ikke dette for å fornærme kolleger, men svært mange programmerere (inklusive meg selv, hvis jeg er uopplagt eller skulle mangle inspirasjon en dag) ser på dette som en jobb, ikke en religion. De sikter seg derfor inn på den ene metrikken de og lederne deres er opptatt av, dvs “kortsiktig virk”. Det er dette de blir målt på. Det er dette som betaler fredagspilsen og prosjektlederbonusene. Det er dette som gir stjerner i boka på styringsgruppemøtene – dessverre.

Jeg kjenner en del som er dyrisk opptatt av metrikker, designprinsipper og om pilene i siste UML-profil skal være stiplede i en eller annen kontekst. Dette er vel og bra for blind intellektuell vold mot tilfeldige forpipasserende ved kaffemaskina, men for å løse utfordringen med “vedlikeholdbar programvare i praksis”, så er metrikker og designprinsipper i stor grad er irrelevante.

Jepp, du leste riktig, og rasjonalet mitt er som følger:

1. Funksjonalitet er i praksis lokal – dvs det finnes ingen mekanismer for å unngå redundans, utilsiktet kobling pga misforstått gjenbruk, samt tap av kohesjon i kode så lenge du ikke krever at samtlige utviklere har eierskap til (og full forståelse av) all kode, samtidig som de kontinuerlig refaktorerer ting som er utenfor scopet deres – på idealistisk grunnlag. (yeah, yeah, jeg vet hva fanboys’ene sier, men i praksis så _er_ det “min” og “din” kode når du kommer over en viss størrelse. Grow up !)
2. Selv om du staffer opp prosjekter utelukkende med rockstars, så vil koden råtne over tid pga pkt 1. I verste fall har du ved et uhell istedet staffet opp med cargo cult-medlemmer, da de til forveksling ligner – samtidig som de benytter mye det samme vokabularet (og da kan du like gjerne tenne på sjappa og starte på nytt).
3. Arkitektur defineres dessverre som regel som en initiell powerpoint som presenteres på kick-off (dvs irrelevant), eller de “litt mer tekniske” grepene som alltid må gjøres i bakkant av prosjektet for unngå å bli saksøkt av kunden når systemet står i sju stein. Er du involvert i det siste, så gjør du sjelden større omskrivninger for å gjøre koden vakker og mer vedlikeholdbar. Du fokuserer på “virk”, ikke endringsvillig og vedlikeholdbar kode.

Prosjektdrevet utvikling av funksjonalitet i en eksisterende kodebase medfører en verden av smerte (Hvis en er litt ondsinnet, så kunne en kalt dette iterativ utvikling, men jeg har ikke lyst til å bli oppfattet som reaksjonær…)

En del har begynt å dra frem ord som “craftsmanship” i et forsøk på å gjenvinne selvrespekten, samt skape en viss distanse til kolleger som ikke fikk med seg akkurat _den_ boka, men det hjelper så sørgelig lite å være i stand til å konstruere vakre katedraler av logikk, så lenge ingen er villige til å ansette vaktmestere for å vedlikeholde dem.

Jeg har et noe anstrengt forhold til termer postfikset med ordet “arkitektur”. Ditto med akronymer designet for fremmedgjøring av kjøpere, skreddersydd for intellektuell vold mot tilfeldige faglige forbipasserende, eller nye begreper som mer eller mindre, gjerne tilfeldig, helt eller delvis dekker konsepter som allerede har levd en stund.

Den totale ironi oppstår gjerne når du i tillegg spotter “KISS” og “YAGNI” i den samme utfloden av konstruerte begreper.

Føler du at du drikker av den evinnelige brannslangen ? Er du på hæla og føler for litt etterutdanning ?

Frykt ikke ! Ingen grunn ikke la deg skremme av all hypen. Som du snart skal få se, så skal det ikke mye til før du kan erklære compliance med det meste, og dermed rettferdiggjøre et saftig påslag i timeprisen din. Vi bringer et lite eksempel fra kjelleren:

Det hele startet med at Are etter ferdigstilling av Spar7-kortet, i en chat nevnte at det hadde vært kjekt med et generelt erstatningskort for de gamle kassene. Jeg var enig, og etter i overkant mye bitfikling og assemblerprogrammering, så slo det meg at et eget språk måtte være kjekt, slik at det skulle bli lettere å uttrykke seg.

>”ekstern DSL” – check !

Jeg ser det står noen connectorer på kortet. Jeg kan sende signaler inn og få signaler ut. Signalene går mye i 0′er og 1′er men det er definitivt semantikk knyttet til dem. Det er legitimt å kalle et sett av disse for “kommandoer”, eller kanskje “meldinger” ?

Iom at klientene ikke trenger å  vente på prosessering av meldingene, men forsåvidt får eventer tilbake, så kan jeg kanskje også bruke ordet “asynkront”. Det går noen kobberbaner mellom connectorene og en stor svart brikke på kortet. Da dette nok er mediet for transport av meldinger, så kan jeg kanskje også benytte ordet “meldingsbuss” med god samvittighet.

> “asynkron meldingsbuss” – check !
> “eventdrevet arkitektur” – check !

Signalene er organisert i funksjonelle grupper. Det er klare grenser mellom gruppene. Alle meldinger deler det samme skjemaet. Alle er operasjoner er autonome.

>”Tjenesteorientert arkitektur” – check !

Da jeg har strenge realtimekrav, så må jeg route eventene inn i en intern meldingskø så fort som overhodet mulig, slik at task-schedulern min kan snappe meldinger ut fra køa i ledige stunder og dispatche disse til riktig eventhandler. Vi er bare et lagrekall unna…

>”Event sourcing” – check !

Hmm, når jeg tenker meg om, så er alle meldingsreturer av typen void.

>”Idempotent” – check !

Displayenes state lagres i egne buffer og pulses av egne kretser slik at prosessoren skal slippe å tenke på dette. Dvs at vi har egne datastore for skriving, og synking av lesedatastore fra denne.

>”CQRS” – check !

Jeg har ikke fulgt noen prosess i dette arbeidet. Men det har blitt flere runder med bestilling av prototypbatcher som jeg så har testet. dette har gjerne ført til at jeg har funnet feil slik at jeg har måttet korrigere designet. Jeg har også kommet på nye lure ting jeg har kunnet inkorporere på kortet

>”Iterativ prosess” – check !

Den eneste måten jeg kunne justere programvaren på med noen grad av sikkerhet, var ved å lage en slags testharness med knapper og display på en diger breadboard. Når jeg trykker på en knapp, så forventer jeg at noe skal skje enten på en output-port, på et display, eller ingenting (kanskje bare medføre en state-change). Deretter har jeg prototypet programvaren i C og flashet over på kortet for å se om oppførselen nå er ihht boka.

>”TDD” – check !

Jeg har begrenset budsjett og kan ikke kaste ressurser ut av vinduet. Hverken tid eller penger. Alt jeg gjør må tilføre verdi.

>”Lean” – check !

Jeg gjør forsåvidt aldri noe før jeg må…

>”Kanban” – check !

Jeg ser nå på fungerende hardware som kjører (foreløpig delvis) generert kode på et sanntids multitaskende OS. Er så langt ganske fornøyd med resultatet, og ting begynner å snøre seg sammen i et, om jeg skal få si det selv, ganske så tight lite regime.

Men…,

det jeg lurer litt på er hvordan det hadde gått med dette prosjektet hvis jeg hadde startet ut med en intensjon om å designe denne plattformen i en tjenesteorientert arkitektur med en asynkron eventdrevet buss med idempotent prosessering av meldinger, CQRS, eventsourcing og TDD’ing av DSL en som skal kompileres til en realisering av de to forrige akronymene ?

Sannsynligvis hadde en endt opp med noe i grenseland mellom en Borg-kube og en kreftsvulst.

På tur hjem fra jobb på fredag, så la jeg løypa innom sjokoladebutikken for å bunkre opp med kirsebær-i-rom-marsipanbrød til helga. Deretter gikk turen innom Narvesen for å plukke opp siste Elektor før det ble revet vekk fra hyllene av fellow geeks.

Februarutgaven har en artikkel om FemtoOS. Dette er et multitaskende real-time OS med absurd liten footprint. Vi snakker her om minimumskrav i størrelsesorden 2K flash og 128 byte med RAM. Jeg har jo en duggfrisk hardwareplattform under utvikling, så jeg tenkte “hmm…hvorfor ikke ?”.

Jeg så for meg at dette måtte være en perfekt match for Lamna-kortet (og forøvrig DSL’en), men møtte dessverre veggen i løpet av lørdag. FemtoOS-koden er gratis så det holder, men ikke akkurat overdokumentert. Du får heller ikke spontane assosiasjoner til “Öppna landskap” når du leser kildekoden. Jeg meldte pass og begynte å snuse på alternativer.

Jeg landet til slutt på FreeRTOS. Denne ruver bittelittegrann mer i terrenget, men siden jeg har 32K Flash å boltre meg på til OS+applikasjon, så valgte jeg å gjøre et forsøk. Den er portet til en drøss med kontrollere (bl.a. AtMega323) og er mer enn veldokumentert.

Etter å ha snublet litt i starten, så fant jeg ut at det var litt forskjeller mht konfigurasjon av timer-interrrupt-registrene på ATMega323 og ATMega325p. Dette resultete i at det bare var mulig å kjøre en eneste task (Forøvrig Darth Dahls definisjon av *skikkelig* thread-safe…). Etter litt tafsing i sourcen til FreeRTOS i ettermiddag, så snurrer nå Lamna-kortet faktisk sin egen lille ATMega325P-port. Slapp heldigvis unna med å endre en define, samt to kodelinjer.

Dette har noen implikasjoner for veien videre. Jeg kommer til å gå over til å bruke C som mellomformat for Lamna-DSL’en. Koden vil også bli mye mindre kompleks, nå som jeg slipper å implementere ting etter det tradisjonelle big-loop-from-hell-patternet (Hvis du går bort til DVD/BlueRay-spillern din og begynner å trykke på knapper mens noe annet skjer, så tror jeg du skjønner hva jeg mener) . Fatter ikke at jeg ikke har tenkt på denne muligheten før.

Det du ser på YouTube-klippet under er en test der to tasks spinner rundt hvert sitt display. Hver task kommuniserer synkront med en Max7221 på ekte bit-bang-vis inni hver sin critical section. I tillegg pulser en task heartbeat-LED’en. Hver task venter her ganske lenge, slik at det skal være mulig å se hva som skjer.

Jeg trodde vel egentlig ikke jeg hadde plass til flere hobbyer, men takket være et tips fra Borud for en ukes tid siden, så har jeg nå havnet på Ableton Live-kjøret. Korg Nano keyboardet ramlet inn av døra i dag, og jeg må innrømme at jeg vurderer pad’en også.

Jeg er komplett tone-døv og mangler basic rytmesans, men trommeloopene mine rocker likevel nå Bregneveien, og eldstejenta fikk Fame-stjerner i øynene når jeg kjørte demo. Vi har nå endelig et skikkelig møblert hjem med (virtuelt) piano. Anbefales varmt !

Jeg handlet for en tid tilbake 3 “chumby guts” – fordi de var billige. To av dem ble videresolgt før de hadde ankommet og den tredje ble liggende på arbeidsbenken “i påvente av tid”.

Den ble skrudd sammen i går kveld, og det var med en viss skepsis jeg koblet den til 12V-adapteret fra Clas Ohlsson. Ikke bare bootet den, men den hilset meg velkommen med en lengere intro-sekvens også. Noen sekunder etterpå var den på nett og jeg kunne aktivere den via Chumby.com.

Jeg får skikkelig dårlig samvittighet av å tenke på at jeg jeg tenkte “deler” når jeg handlet inn disse. Dette er en skikkelig gjennomtenkt wi-fi enablet gizmo med touch-skjerm, aksellerometer, stereolyd, mikrofon, USB og ett lass med sjarm.
 

 
Chumbyen snurrer kontinuerlig gjennom et konfigurerbart antall widgets som eksempelvis twitter, din personlige ebay-watchlist, interaktive spill, Chuck Norris facts, Dilbert, nyheter, vær – whatever.

Etter aktivering, så konfigurerer du chumbyen din via chumby.com. Er du litt fingernem Flash-mann, så kan du også lage dine egne widgets for opplasting.