WindWiz

En GSM-uppkopplad vindmätare

Månadsarkiv: september 2011

Höghastighetsprogrammering

Idag har jag programmerat i 150 km/h! Känns som taget ur SJs reklamkampanj ”Försök göra det där i bilen, om du kan!”. Söndagen har spenderats ombord ett Öresundståg upp till Göteborg,.. och några timmar senare tillbaks till Skåne igen. Mycket tid att slå ihjäl med andra ord. Tur att vindmätaren är mobil och lätt att plocka med i väskan. Många var det som stirrade misstänksamt på mig när de gick förbi mitt uppdukade ”elektroniksmörgåsbord”. Någon tänkte säkert ”GOD DAMN THATS NEERDY!”. Men det bjuder jag på, det gäller att ta vara på den lilla tid man har 😉

Kan för det första meddela att vindmätaren numera kan upprätta TCP-anslutningar. Jepp! Fet milstolpe! Ingen data strömmar över transportsessionen ännu, men det är bara en tidsfråga. Detta innebär att jag t.ex. skulle kunna skicka data direkt till en webbserver, eller annan mottagare av vinddata. Jag har även övervägt att låta e-post vara mitt ”huvudinterface” för vindmätaren, dvs att varje batch av mätpunkter skickas som ett mail. Detta har fördelen att en separat mailserver kan buffra mätpunkter på ett mailkonto, om min egna server skulle gå ner av någon anledning. Detta är ett problem hos den kommersiella AWS-X mätaren vars UDP-paket försvinner ut i cyberrymden närhelst ingen lyssnar. Med en maillösning kan man dessutom sprida mätpunkter på ett intuitvt sätt — mailinglistor. Vinddata anländer och sprids automatiskt till ett godtyckligt antal mottagare. Helt och hållet genom existerande teknologi!

Det råkar även vara så smidigt att GSM-modulen som används, Telit GE-863 QUAD, har färdig funktionalitet för e-post. Den kan hantera allt från autentisering, SMTP-protokoll och även kodning av attachmentdata (BASE64 etc). Den enda nackdelen är att det sannolikt blir mer data att sända jämfört med att uppfinna ett eget binärformat. Beroende på hur många mätpunkter som batchas så kan overhead för SMTP bli rätt stor del av paketet. Dock lär det inte vara något bekymmer med dagens ”trafikvänliga” mobilabb. Själv betalar jag 29 kr/mån extra för ”surf” i mobilen. Fett värt!

Jag skall ge detta lite mer tid att mogna innan jag tar ett beslut, men måste erkänna att det väger tungt för att välja existerande teknik över att återuppfinna hjulet om det bara handlar om några kronors skillnad i trafikkostnad.

Som vanligt har jag även en lite mindre rolig nyhet att dela. De tråkiga ”omstarts”-problemen som jag då och då stött på är tillbaks. Dessa har under hela projektets gång plågat mig och det retar mig oerhört att jag fortfarande inte lyckats hitta källan till problemet. Symptom är spontana omstarter av vindmätaren vid exekvering av slumpmässiga kommandon. Oftast i samband med interaktion med GSM-modem. Jag har nämnt problemet i tidigare inlägg och undersökt olika uppslag. Några gånger tror jag att jag hittat orsaken, men det har tyvärr visat sig att det bara lindrat i olika grad, ej botat. Ibland har problemet försvunnit i flera veckor, men nu är det tillbaks.

I inlägget ”Betongväggen” kan man läsa om de idéer på orsak jag hade då. Stor oro låg i hårdvaran, t.ex. spänningsfall, strömspikar osv. Det har troligtvis inget med saken att göra, med tanke på att jag nu sett samma fel i tre generationer av hårdvara. Hur som helst är sådant väldigt svårt att utesluta utan att köpa in fler enheter. Dyrt! Så vad annars kan orsaka spontana omstarter? På en vanlig PC-maskin hade jag varit orolig för överskrivning av programminne, dvs att någon del av programmet skriver över sin egna kod under körning av misstag. Detta kan få högst slumpmässigt beteende, som oftast slutar i att processorn hoppar till minne där den stannar. När detta händer kommer ”watchdoggen” att bita och enheten gör en omstart. Men en AVR-processor använder sig av en s k Hardvard arkitektur vilket innebär att instruktioner och data ligger i separata minnen. Instruktionerna finns enbart i flashminnet som ej kan modiferas från vindmätaren under körning. Alltså borde enheten vara immun mot denna typen av fel. Vad återstår då som kan orsaka hopp till oönskade adresser? Tja, det kan vara ett hopp till en pekare som felinitialiserats. Men med tanke på att jag använder oerhört få funktionspekare och i övrigt undviker trixig pekarartimetik känns detta också osannolikt. Alla adresser genereras automatiskt av länkaren, vilken vi får hoppas gör ett korrekt jobb.

Just nu undersöker jag om programinstruktionerna kanske blivit felaktiga innan de ens hamnat i det ”skrivskyddade” flashminnet. Detta skulle kunna leda till ett scenario likt ovan. De skrivs dit av min egna bootladdare, Magboot. Kan man lita på att den gör ett korrekt jobb? Jag vet inte! Det är ju jag som skrivit den 😉

Förra inlägget handlade delvis om Magboots nya integritetskontroll av data som skickas över serielänken. Mitt huvudspår just nu är att utöka denna funktionalitet så att integritetskontrollen även inkluderar skrivning till flashminnet. Datan skall alltså kontrolleras efter serielänksöverföring och efter flashskrivning. Först då kan jag med 100% säkerhet säga att programmet som ligger i vindmätaren är samma program som jag kompilerat på min arbetsstation.

Jag återkommer i nästa vecka med en uppdatering. Kanske. Om jag orkar. Och har tid. Och ifall det inte blåser SV 6-8 m/s, som långtidsprognosen visar just nu.

PS. Mina tågtester visar för övrigt att vindmätaren har GSM-täckning på Helsingborg C, a.k.a mobildödsstationen, där min egna smartphone sällan har en chans. Ganska coolt! DS.

Annonser

Size matters

Flygsäsongen lider mot sitt slut, åtminstone för alla oss som ogillar att flyga i minusgrader. Någon vindmätare finns fortfarande inte ute på fältet, vilket är lite av en besvikelse. Arbetet fortgår dock fortfarande, om än långsamt.

I föregående vecka har jag slutfört arbetet med bootladdaren och det utökade stödet för flashladdning över en mjukvaruserieport. I all hast adderade jag även en grundläggande integritetskontroll för serielänken, vilket delvis kan användas för att verifiera serieportsimplementationen, och givetvis för att förhindra timmar av meningslös debugging som orsakats av att inkorrekt programvara skrivits ner i flashminnet på vindmätaren. Ett enstaka bitfel här och där kan kanske verka ofarligt, men tro mig — MYCKET kan gå snett.

Med denna nya funktionalitet på plats i Magboot kan jag nu återgå till att hacka på själva vindmätaren igen! Hurray!

Avslutar med lite Magboot-statistik som jag utvunnit ur mitt källkodsförråd. Nedan plot visar binärstorlek för Magboot mot en tidslinje (uttryckt i commit, i kronologisk ordning). Man kan tolka grafen som programmets storlek över tid, sedan jag började utvecklingen i slutet av Februari.

I och med introduktionen av stöd för mjukvaruserieport bygger Magboot numera två binärer, en med stöd för hårdvaruserieport (”HWUART”-versionen) och en med det nya mjukvaruserieportsstödet (”SWUART”-versionen). Den blå linjen visar SWUART-storlek och den röda representerar HWUART-storlek. Båda versionerna integrerar givetvis det nya verifieringsstödet. Grafen är egentligen ganska meningslös att titta på, men man kan dra några slutsatser:

  1. Ingen version överstiger 1024 bytes, vilket är den övre smärtgränsen. En tidig version av Magboot vägde faktiskt in under 512 byte och fick därmed plats i en ännu mindre bootsektor, men fick skrotas i förmån för mer läsbar kod och ny funktionalitet.
  2. SWUART-versionen väger in på ca 100 bytes mer — ganska nätt med tanke på hur mycket mer mjukvara det handlar om.
  3. Commit #4 adderade stöd för sidbuffring av serieportsdata. Detta gjorde överföringar betydligt mer tillförlitliga.
  4. Commit #8, #10 minskar storleken genom att plocka bort överflöda kommandon och viss EEPROM-hantering, som Magboot ändå inte har stöd för.
  5. Commit #11 ökar förvånadsvärt mycket för den lilla kodmängd som tillförs. Det handlar om en funktion som gör att Magboot ej exekverar utan lämnar över till programmet i flash, förutsatt att vissa villkor uppfylls. Används för att snabba upp ”normal” omstart av enhet. Detta är ett typiskt ställe i koden där man troligtvis skulle kunna optimera ytterligare för binärstorlek.
  6. Vid commit #21 introduceras SWUART-versionen, som även får HWUART-versionen att minska något i storlek, vilket jag inte kan förklara. Skillnaden är att viss kod brutits ut i en separat fil. Min erfarenhet av kompilatorer är att optimeringsrutinerna oftast fungerar bäst när kod samlas i samma fil. Detta beror på att ”whole-program optimization”, dvs att optimering även sker i länkfasen av körning, ännu är en omogen teknologi i GCC. Förvisso har AVRs GCC port troligtvis fallit väldigt långt bakom vad det gäller optimeringar, vilket är trist. Håller ett öga på LLVMs AVR port, that’s for sure!
  7. Likt #8 plockar commit #22 bort ännu ett kommando som blivit överflödigt under utvecklingen. Den bidrar till ett välkomnat drop i filstorlek.
  8. Sist men absolut störst är #25, som adderar det nya stödet för integritetskontroll. En ökning på ca 100 bytes, vilket är i överkant. Jag kommer förmodligen bli tvingad att se över koden igen, checksummeringsrutinen är långt ifrån ”optimerad för storlek”. Det är i stunder som dessa när högnivåprogrammeraren i mig skriker: ”Men jag ska inte behöva ta hänsyn till filstorlek när jag uttrycker mig i programkod!”.