Mijnenveger: 5 stappen (met afbeeldingen)

2024 Auteur: John Day | [email protected]. Laatst gewijzigd: 2024-01-30 11:19

Voor ons CPE 133-eindproject besloten Chase en ik een 'Mijnenveger'-game te maken die gebruikmaakte van knop- en schakelaarinvoer van een Basys-3-bord en VHDL-code. Een betere naam voor het spel zou heel goed 'Russisch Roulette' kunnen zijn, maar we wilden een meer gezinsvriendelijke naam gebruiken. Bij het spel moet de gebruiker op de middelste knop op het Basys-bord drukken om willekeurig een van de 16 schakelaars toe te wijzen om 'actief' te zijn met een bom. Twee spelers zetten dan om de beurt schakelaars om, een voor een, totdat een van de spelers de schakelaar met de 'bom' omdraait. Wanneer dat gebeurt, waarschuwt het display met zeven segmenten de spelers dat die speler zojuist het spel heeft verloren.

Stap 1: Overzicht

Het project maakte gebruik van veel van de VHDL-modules die we in de loop van dit kwartaal hebben gebruikt. Een vier-bits teller werd gebruikt in combinatie met de klokflank om een willekeurig vier-bits getal te simuleren om een van de schakelaars te activeren. Er werd ook een toestandsdiagram gebruikt om verschillende woorden uit te voeren naar het display met zeven segmenten, variërend van 'PLAY' wanneer de spelers in het midden van hun spel zijn, tot 'VERLIES' wanneer een van de spelers de actieve schakelaar heeft omgedraaid.

Stap 2: Materialen

• Basys3-ontwikkelingsbord van Digilent, Inc.
• Vivado Design Suite BC_DEC.vhd (Dit bestand is aan ons verstrekt op Polylearn en is geschreven door Bryan Mealy)
• Een 4-bits teller gemaakt van T-flip-flops
• een FSM

Stap 3: Het spel maken

De eerste stap naar het maken van dit spel was het tekenen van een schakelschema met alle componenten die we zullen gebruiken. Ingangen voor dit systeem waren knop 1, de 16 schakelaars en de klok. Uitgangen waren het zevensegmentendisplay en de anodes. Nadat we het schakelschema hadden getekend, hebben we voor elk onderdeel in Vivado afzonderlijke bronbestanden geschreven en deze samengevoegd met behulp van poortkaarten onder het hoofdbronbestand.

De hele basis van het spel draait om het willekeurig toewijzen van een van de 16 schakelaars om actief te zijn met een bom, en voor de spelers om niet te weten welke schakelaar actief is totdat die actieve schakelaar is ingeschakeld. We hebben online gekeken naar willekeurige en pseudo-willekeurige nummergeneratoren, maar uiteindelijk besloten we dat het gebruik van een 4-bits teller en het toewijzen van de bijbehorende schakelaar om actief te zijn voldoende willekeurig is voor wat we zochten. We hebben onze 4-Bit-teller die we in een eerder project hebben gemaakt, opnieuw kunnen gebruiken om voor deze opdracht te kunnen werken. We hebben de teller gebruikt om een willekeurig getal tussen 0-15 te maken; vervolgens hebben we in de main1-component het decimale equivalent van het willekeurige getal toegewezen aan de bijbehorende schakelaar op het bord. Zoals te zien is in het schema, gaan zowel de output X ('actieve bom') van main1-component als de schakelaars die de spelers aanzetten naar FSM1. De toestandsmachine voert een één-bits Z-waarde uit die vervolgens wordt gelezen door BC_DEC1. De Finite State Machine die we gebruikten heeft twee verschillende toestanden: in toestand A geeft het zevensegmentendisplay 'PLAY' weer en de machine blijft in die toestand totdat hij herkent dat de geactiveerde schakelaar is omgedraaid. Zodra dat gebeurt, gaat de FSM naar toestand B, waar hij 'VERLIES' uitvoert naar het zevensegmentendisplay en in die toestand blijft totdat alle 16 schakelaars op '0' worden gezet. Wanneer aan die voorwaarde is voldaan, gaat de FSM opnieuw naar toestand A en wacht op de spelers om een ander spel te starten. Een Moore-diagram om deze FSM te helpen begrijpen, is hierboven weergegeven.

Stap 4: Toekomstige wijzigingen

Een paar wijzigingen die we overwogen om aan ons spel aan te brengen, zijn onder meer het toevoegen van meer bommen aan het veld (mogelijk van één naar drie), het toevoegen van een scoreteller en meerdere rondes. We hebben uiteindelijk besloten deze verbeteringen niet te gebruiken, omdat we ontdekten dat het spelen van een langer, uitgebreid spel doorgaans meer gespannen en uiteindelijk leuker was dan een spel dat meestal eindigde na drie of vier keer omschakelen.

Stap 5: Conclusie

We waren erg blij met het eindresultaat van dit project; niet alleen omdat de definitieve versie van het spel leuk was om te spelen, maar ook omdat we het meeste, zo niet alles, moesten gebruiken dat we dit kwartaal hebben geleerd om het project te maken en te programmeren. We gebruikten flip-flops, tellers, FSM's, de klok, gebruikersinvoer van het bord en uitvoer naar het zevensegmentendisplay.

We hebben ook geleerd hoe een paar syntaxisfouten het programma volledig konden breken (zelfs als ze in andere programmeertalen zoals Python of Java als prima zouden worden beschouwd) en dat pas na meerdere simulaties en meerdere iteraties van de code waarnaar wordt geüpload en getest op de board, zul je eindelijk in staat zijn om alle bugs uit je code te halen.