Det blir nesten litt urettferdig å nevne kun “511″. Jeg må nesten i anstendighetens navn ta med “767″, “1023″ og “1279″ også. Du lurer kanskje på signifikansen av disse tallene. De symboliserer ikke noe mindre enn et gjennombrudd i mine forsøk på å snakke med en Max7221 fra en AtMega8515.

Jeg mistenker at de fleste datablader for integrerte kretser er skrevet av ingeniører for ingeniører. Det du trenger å vite står der garantert, men du får det ikke inn med teskje, og det står ikke søte små symboler eller piler som peker til de viktigste tingene. Det er en haug med forkortelser med produsentens egen terminologi, det er pakkeinformasjon, pinout og elektriske karakteristikker. Enkelte av dem kan fort bli litt tørre, og når de runder 15 sider så blir ihvertfall jeg tung i øyelokkene. Det ender gjerne med at du må lese dem flere ganger – sekvensielt.

Max7221 er en snasen 7-segment LED-driver med serieinterface. En chip kan kontrollere 8 7-segments displayer, eller 64 individuelle LEDs. Jeg tenkte å ta den i bruk på Lamna-kortet for å slippe å la mikrokontrolleren håndtere strobing av displayene. 7221 kan også daisy chaines slik at du kan hekte sammen flere og adressere dem individuelt. Dette gir deg muligheten til å adressere/kontrollere vanvittig mange display kun ved å legge beslag på 3 bits i en av portene til en mikrokontroller.

Som vanlig så startet jeg med å legge ut power, mikrokontroller og kretser på breadboard. Jeg hektet også inn den nyinnkjøpte AVRISPmkII programmereren. Den siste var ikke like lettbeint som jeg hadde forestilt meg. Den var for lettbeint. Den kan ikke levere power via ISP-headeren, så du må ha strømforsyning til kretsen du jobber med (litt pes for oss som er vant til å leeche fra ISP-headeren mens en prototyper). I tillegg, så krever den pull-up resistorer av ymse valører på MOSI, MISO, SCK og RESET-pinnene. Litt mer leamikk, men likevel så ruver den litt mindre i terrenget enn STK500′en. Den har en betraktelig mindre støvsamlersignatur enn STK500.

Det hjelper alltid med litt eksempelkode for å komme i gang og jeg søkte fram en del samples fra avrfreaks.com og ymse kilder på nett, men ingen funket spesielt bra. Det er mulig jeg har misforstått noe, men jeg fikk ikke chippen til å snakke med 8515′en via SPI-interfacet. Løsningen viste seg å “bitbange” et serieinterface over en av de andre portene på avr’en. Eksempelkoden funket sånn tålelig bra for å initialisere chippen, men å få vist noe fornuftig i displayet viste seg å være vanskelig.

Etter en stund så fant jeg ut at jeg tok vare på den koden som virket og leste heller databladet for å sette sammen noen fornuftige testpakker jeg kunne sende til displayet for å teste. Protokollen viste seg å være rimelig enkel. 7221 forventer pakker på 16 bits med følgende format: “XXXXAAAADDDDDDDD”. (“X”=Don’t care, “A”= Register/adresse, “D”=data).  En har kontrollregistere for test, lysstyrke, encoding etc, samt dataregistre for displayene.

511 (base 10) == 00000001 11111111 (base2) som dekodes til at register 1 gis verdien 255. Hvis 7221 er konfigurert til ikke å forvente BCD-encodete data vil dette tenne samtlige segmenter i display 0.

1279 (base 10) == 00000100 11111111 (base 2) => tenning av alle segmenter i display 3.

Det virker kanskje ikke spesielt hard core, men det er som kjent moro å få ting til å funke når en er amatør. 7221 koster nesten mer enn selve mikrokontrollerne, men de bidrar til å redusere antall komponenter, kompleksitet og risiko for tullefeil på grunn av fingertrøbbel betraktelig.

Med litt medvind og et par rolige kveldstimer, så skal en ikke se bort i fra at en kan hjelpe en lokal R2D2-bygger med diagnostikkportene på droiden sin heller. Max7221 er perfekt for formålet, og det er for fristende til ikke å produktifisere. Jeg antar at verdensmarkedet for fake R2D2 diagnistikkporter sannsynligvis er litt mindre enn EL-3-markedet. Det føyer seg derfor pent inn i produktporteføljen vår under sloganet “Overengineered solutions for non-existing problems”.