Bärbar spelkonsol (ARM MCU Team) (6 / 6 steg)

Steg 6: Kernel och Middleware - MCU ARM CORTEX M3

Hög nivå grafik API

Vårt mål är att genomföra ett grafikkort med Nexys 3 FPGA. STM32 mikrokontroller kommer att vara den som kör operativsystemet och skicka kommandon till FPGA. Kommandona skickas via en buss försäkra meddelandet av båda korten med FSMC perifera. För att underlätta denna process, skapat vi primitiver, strukturer och makron. Dessa tre verktyg förutom en DOXYGEN documentation hjälpa användaren att enkelt styra grafikkortet. Det är samma idé som för STM bibliotek.

Makron

Konfigurationen av ett system kräver en riktigt hårt arbete av forskning i de olika dokumentation och källkod filerna tillgängliga. Naturligtvis fungerar av källfiler direkt kan ändras av användaren, men vi bör undvika att. Eventuella ändringar kan orsaka en dysfunktion i någon tidigare program använder dessa källfilerna och skriven av en annan användare. För att undvika alla dessa risques, La vi i en fil (makro) den information som behöver ändras för att se till att programmet fungerar.

Det finns två huvudsakliga kategorier för makron:

• Konfiguration makron:
  

Dessa makron ger användaren möjlighet att ändra de olika kringutrustning sätta för att använda under meddelandet. Genom att göra detta finns det ingen anledning att ändra något i källfilen. Exempelvis kan detta makro fullt konfigurera cykler av FSMC varaktighet.

• Makron definiera de tekniska specifikationerna:
  

Huvudsyftet med detta makro är att ange specifikationen av vårt system, som skärmstorlek, första adresserna till hyvlar och adresserna till FSMC. Dessa makron garanterar ett API som kan användas var som helst. Vi kan till exempel ändra en större skärm genom att bara ändra den rätta konstanten.

Doxygen documentation innehåller alla nödvändiga förklaringar för att använda makron.

Strukturer

Med samma idé som de drivrutiner som skapats för STM32, är alla strukturer som skapats för detta API utformade för att göra användningen av primitiver och datalagringen mycket enklare. Till exempel är det viktigt att komma ihåg i vilken adress ram en bild har lagrats. Som ett faktum, kan adressen till en bild eventuellt ändra i FPGA efter en operation som Bit Blit till exempel. Om den ursprungliga adressen inte lagras någonstans, förlorar användaren bilden.

• Bild struktur:
  

Det används för varje bild skapat. Användaren att identifiera dess namn, storlek och dess adress. Allt vi behöver göra efter detta är att sätta denna struktur som en parameter i ett drag skriver primitiva för drift på bilden ska äga rum. Uppdateringen av dessa parametrar ingår i verksamheten.

• Färg struktur

Det är mycket användbart för funktionerna med hjälp av färger. Denna struktur används för att undvika att de 3 primära färgerna och alfagenomskinlighet nivå vid varje användning.

• Display plan struktur

Vår GPU kan hantera upp till 4 plan. Det är därför vi skapat 4 plan typ struktur för var och en av de 4 display flygplan. Vi förklarade hänvisningen i en global variabel. Det är inte nödvändigt att skapa en ny display plan på denna FPGA, eftersom 4 är det maximala antalet tillåtna. Denna struktur innehåller alla uppgifter som krävs för att konfigurera ett lager: bredd, längd, RAM-minne adress, rullning ovec X och Y.

• ConfPlane struktur

Detta är konfigurationsstruktur för de 4 lagrarna. Det finns bara en typ av denna struktur som deklarerats i programmet, med en referens som en global variabel. Det hjälper användaren att välja vilket lager till aktivera, Aktivera genomskinlighet eller inte, att lansera ett provningsförfarande för kommunikation och att aktivera 4 visning flygplan eller

Dessa 4 strukturer skapas inte ska ändras direkt. Det rekommenderas starkt att använda varje struktur för att initiera eller ändra dem tillhörande funktioner. Som ett faktum, är skriftliga uppgifterna i dessa struktur bara en reflexion av vad som finns inuti kortet FPGA. Ändra parametrarna endast i STM är värdelös. Till exempel om vi vill att manuellt ändra storleken på ett lager, kommer det inte att ändras på GPU eftersom kommandot inte skickas. De tillhörande funktionerna bidrar också till att fastställa kommunikationen mellan båda korten.

Förare

Detta lager används för att konfigurera olika kringutrustning används för kommunikation mellan de två korten. Till exempel kan vi använda det för att initiera FSMC. FSMC initieras på ett sätt att ha samma beteende som beskrivs i avsnitt 2.b. En GPIO initieras också för att spela rollen av den upptagetsignal som används i gränssnittet MCU.

Vi kan också hitta i detta lager de ursprungliga funktioner används för att läsa och skriva in PIN ansluten till FPGA associerade adressen. Parametrarna av dessa funktioner är adressen till registret ändras i FPGA och data skrivs i registret.

De tillhörande funktionerna för dessa förare görs inte kan användas direkt. De används redan i service-skiktet. Ändå, användaren kan i vissa fall komma åt dessa funktioner för att ändra konfigurationen av programvaran.

Servicefunktioner:

Tjänsten fungerar är de viktigaste funktionerna i våra grafikkort. I detta lager, kan vi hitta alla funktioner nödvändiga för utförandet av de olika operationerna av GPU.

Information om dessa funktioner blir tillgängliga i avsnittet doxygen documentation. Vi bör bara klargöra att det är möjligt att placera en över lager för att uppfylla mer komplexa verksamheter med hjälp av de ursprungliga funktioner skrivna i tjänst lager. Det är till exempel möjligt att skapa en funktion för att kunna hantera en animering. Denna funktion kommer att använda åtgärden flytta för att göra det.

Hög nivå ljud API och realtidsoperativsystem genomförs inte ännu.