Whac A mole. Ett rektionstest i kursen Digitala Projekt EITF11 utfört av: Axel Spångberg I10 Marcus Witting I10. Handlett av: Bertil Lindvall

Transkript

1 Whac A mole Ett rektionstest i kursen Digitala Projekt EITF11 utfört av: Axel Spångberg I10 Marcus Witting I10 Handlett av: Bertil Lindvall

2 Abstract In the course Digitala Projekt the students are tasked with coming up with an idea for an electrical gadget which incorporates a microprocessor. The goal is then for the students to develop this idea into a working prototype. Our gadget is inspired from the classical Arcade game Whac A mole. We simulated the moles with 4 RGB LEDs in four directions. The whacking was to be done with an accelerometer in the players hand. On top of that we used a LCD Dot Matrix display to display reaction times and high scores. Due to problem with the accelerometer we had to use four buttons in each direction instead. However, the outcome was still great and we had much fun in playing the game.

3 Contents Introduktion... 4 Produktbeskrivning... 4 Huvudsakliga komponenter:... 4 Kravspecifikation... 5 Allmänna krav... 5 Hårdvarukrav... 5 Mjukvarukrav... 5 Problem... 6 Lärdomar... 7 Förbättringsmöjligheter... 7 Bilagor... 8 Kopplingschema... 8

4 Introduktion I kursen EITF11 Ingenjörsprocessen, har vi fått i uppgift att planera och genomföra ett digitalt projekt. Projektet ska ha det omfång att det rimligtvis kan genomföras under en läsperiod. Tanken är att projektet ska återspegla industriellt utvecklingsarbete i de tidigare stegen av produktutvecklingen. Samtidigt som vi utvecklat vårt projekt har löpande dokumentering om hur projektet fortskridit skett. Redovisning och opponering av arbetet kommer ske i slutet av maj månad. Vidare i dokumentet följer en produktbeskrivning, föreslagna komponenter samt kravspecifikation för vad vi valt som vårt digitala projekt. Produktbeskrivning Vår ambition var att skapa ett spel inspirerat av det klassiska arkadspelet Whac-A-Mole. Spelet består av två komponenter, dels själva spelbrädet, och dels en accelerometer som man håller i handen som fungerar som kontroll för att interagera med spelet. Spelbrädet består av fyra flerfärgade dioder, en i varje väderstreck. Dessa dioder lyser i början av en spelomgång grönt. När en av dessa dioder slår över till rött ska man vifta med accelerometern i den riktning som dioden befinner sig. Då återgår dioden till att lysa grönt och spelaren väntar på att nästa slumpmässigt utvalda diod ska slå över till rött. Spelet är alltså en form av reaktionstest. En spelomgång består av 10 sådana slumpmässiga färgförändringar på dioderna. När spelet är slut visar en tvåradig display på spelbrädet medelvärdet på reaktionstiden för den spelande samt snabbaste reaktionstid. En highscore över bästa medelvärde på reaktionstiden kommer att sparas och visas på hemskärmen (det som visas på skärmen när det inte är en spelomgång igång). Omständigheter under utvecklandet av produkten ledde dock till att vi valde att skippa accelerometern och istället ersätta denna med en egenbyggd kontroll med fyra knappar, varje motsvarande en LED på spelbrädet. Huvudsakliga komponenter: Accelerometer: LIS331HH (borttagen) Detta är den acceloremeter som använts för att mäta acceleration i x- och y-led ( markplanet ). Accelerometern klarar även av mätningar av acceleration i z-led, men förutsättningarna för spelet gjorde att vi inte behövde mäta detta. Kommunikation mellan processorn och accelerometern skedde via SPI, där processorn agerade master och accelerometern slav. Processor: ATmega16 En 16-bitars processor med 40 ben. Totalt användes 25 av dessa ben. All kod som finns bifogad i rapporten exekverades från processorn. Processorn kördes på klockfrekvens 8 Mhz. Display: SHARP Dot-Matrix LM162XXX Numerisk tvåradig display för kommunikation med spelaren. 4 istället för 8 databus-pinnar användes, främst pga. avsaknad av lämplig port att sätta 8 pinnar på. Dioder: RGB-LED. Möjliggör för totalt sju färger, men endast grundfärgerna blå, röd samt grön användes för spelet.

5 Voltregulator: LP3855(borttagen) I och med att accelerometern kräver spänning 3,3 V behövdes denna komponent. Strömbrytare: 6st Generisk modell 6st strömbrytare användes för tre olika funktioner på kretskortet, en för att sätta igång spelet, fyra på spelkontrollen för att interagera under själva spelomgången och en för att resetta processorn. Kravspecifikation Allmänna krav A1 Spelet ska vara enkelt att interagera med och ha liknande egenskaper som arkadspelet Whac- A-Mole. A2 Givet att man slår i en samma riktning som LED:en som slagit över till rött så ska denna LED ändra färg till grönt igen. Reviderat: Givet att man trycker på knapp på spelkontrollen i motsvarande riktning som LED:en som lyser rött ska LED:en ändra färg till grönt igen. A3 Givet att man slår annan riktning än lampans ska ingenting hända. Reviderat: Givet att man klickar på knapp på spelkontrollen i annan rikning än rödfärgad LED, ska ingenting hända. A4 Efter 10 omgångar ska spelet ta slut och medelvärdet på reaktionstiderna samt snabbaste reaktionstiden visas på displayen. Hårdvarukrav H1 Accelerometern och spelbrädet måste kunna kommunicera. Givet att man rör accelerometern i en viss riktning måste spelbrädet kunna ta emot denna signal. Reviderat: Spelkontrollen och spelbrädet måste effektivt kunna kommunicera. Givet att man rör accelerometern i en viss riktning måste spelbrädet kunna ta emot denna signal. H2 (I mån av tid) Kontrollen (accelerometern) görs trådlös. Reviderat: Spelkontrollen görs trådllös. Kommentar: Hanns inte med. Mjukvarukrav M1 Fungerande kod för att tolka rörelserna från accelerometern och därmed styra dioderna. Reviderat: Fungerande kod för att tolka knapptryckningarna från spelkontrollen och därmed styra dioderna. M2 Det måste finnas ett skydd mot fusk i koden (man ska inte kunna skaka kontrollen och på så sätt få en väldigt kort reaktionstid). Reviderat: Det måste finnas ett skydd mot fusk i koden (man kan inte hålla in alla knappar och på så sätt få en väldigt snabb reaktionstid),

6 Proccesorn och dess pinnar. Problem Vårt kopplingsschema var relativt komplicerat jämfört med andra grupper, men trots detta gick all dragning av sladd till alla komponenter relativt smärtfritt. Vår största utmaning låg istället i att få kommunikationen mellan processor och display samt processor och accelerometer att fungera någorlunda smärtfritt. Ingen av gruppmedlemmarna hade erfarenhet av att programmera i c eller för den delen att programmera en processor. Även fast mycket av logiken i c är lik den vi känner igen från java uppstod mycket småproblem som ibland kunde ta onödigt lång tid att åtgärda. Majoriteten av den första tiden som lades på att programmera bestod i att skriva lämplig kod för att sätta diverse portar till antingen etta eller nolla, något som låter enklare än vad det egentligen är. Tiden som följde gick i huvudsak till att få kommunikationen mellan processorn och accelerometern att fungera (så kallad SPI, Serial Peripheral Interface). Detta är ett användargränssnitt som ska vara relativt enkelt för användaren. Det tyckte inte vi. Nivån på de datablad som gick att tillgå kändes som att de var framtagna för människor med bättre kunskaper inom både elektronik och programmering. När man väl kom över den kunskapströskel som fanns så blev det betydligt enklare att lösa problemen.

7 Lärdomar Det fysiska kopplandet av pinnar och portar gick förhållandevis lätt. De största problemen kom när mjukvaran till hårdvaran skulle skrivas. Att styra enskilda pinnar var lätt, däremot var det betydligt svårare att få igång displayen. Detta berodde mycket på att vi hade valt att använda oss av 4-bitars databuss istället för den vanliga 8-bitars. Detta betydde att vi själva var tvungna att skriva stödfunktioner som kunde dela upp en byte (8-bitar) i två halvor (4-bitar) och skicka dem separat. Detta gav ett extra inlärningsmoment som vi gärna hade undvikit. De andra grupperna hade nog med problem att få motsvarande skärm att fungera med 8-bitars utförandet. Detta var nog det moment som slukad mest tid förutom SPIn. Andledningen till att vi valde att köra med en 4-bitars databuss var av ren platsbrist. Vi hade redan konsumerat tillräckligt många portar på processorn och valde därför att endast använda fyra pinnar på processorn och därmed fick vi begränsa oss till 4-bitars datakommunikation till skärmen. Trots att vi i slutändan inte använde oss av SPI har vi lärt oss en hel del kring hur interfacet fungerar. Vi är tämligen övertygade om att vi hade fått acceleromtern att fungera givet lite mer tid och en fungerande sådan. Att kunna gå vidare och fortsätta med nästa moment när man har gjort en lösning som fungerar, trots att man inte är helt nöjd, har varit väldigt viktigt för att hinna med allt. Oftast löser sig det mesta på vägen och det är viktigt att inte stanna upp för länge vid problem. Den random-funktion vi konstruerat i programmet är egentligen bara en ticker som går från 0 till 3 och sen börjar om igen, alltså inte alls slumpmässigt. Det slumpmässiga uppkommer ur att denna ticker uppdateras varje millisekund och stoppas när en knapp trycks ned, alltså beror vilken nästa lampa att lysa rött är på hur lång tid det tog att reagera på föregående lampa. Förbättringsmöjligheter Med lite bättre planering hade vi kunnat använda oss av en 8-bitars data buss. Det hade underlättat mycket och förmodligen sparat in på en del tid. I slutet av skedet fick vi in ny information om hur SPIn skulle kopplas. Det var detta som föranledde bytet till vanliga knappar istället. Naturligtvis hade man velat ta del av sådan information i början av projektet för att kunna hantera det på rätt sätt. Att läsa databladen noga och ordentligt från början hade också sparat en del tid. Det som hade underlättat allra mest är någon kurs i elektronik eller liknande. Vi besitter inte den kunskapen som krävs för att på ett effektivt sätt utföra ett arbete som detta. Nu går det dock med vilja, och tur är det. Referenser Datablad för ATmega16: Datablad för displayen:

8 Bilagor Kopplingschema