Projektrapport Datatekniskt Projekt - DAT290

Projektrapport Datatekniskt Projekt - DAT290 Grupp 8 Dzenan Bazdarevic, Hannes Häggander Morhaf Alaraj, Max Hansson, William Hughes Andreas Hagesjö, Tobias Eliasson, Jan Qvick Granskad Godkänd Namn Datum Grupp 8 8 Oktober, 2013

Abstract The following text describes the development of the Gr8Sampler: a device designed to store sound data from an analog electrical source in ash memory and replay it. It is to be controlled via a GUI programmed in C Sharp that can be run on a Windows machine. Through the GUI, Gr8Sampler can be set to echo received sound with a delay and/or store it in memory. All parts have been tested and implemented in compliance with the project directive, resulting in a fully functional prototype. The conclusions this report draws are twofold. Firstly, the project has been a success as Gr8Sampler fulls its purpose in that it can record and play sound as well as communicate with a PC. Secondly: with little modication, the Gr8Sampler would be able to record sound les and deliver them to the PC for editing or play les sent from the PC. In doing so it provides a foundation from which more far more complex and useful sound processing systems can be developed. Följande text beskriver utvecklingen av Gr8Sampler: ett system designat för att lagra ljuddata från en analog elektrisk källa i FLASH-minne och även spela upp det. Den skall styras via en GUI programmerad i C Sharp som kan köras på en Windows-maskin. Igenom GUI:t kan Gr8Sampler ställas in till att eka mottaget ljud med en delay och/eller lagra det i minnet. Alla delsystem har testats och implementerats enligt projektdirektivet, med en fullt funktionell prototyp som. Slutsatserna som dras i denna rapport är två. För det första har projektets mål uppfyllts då prototypen kan spela in och upp ljud inklusive kommunicera med en PC. För det andra : med små modikationer skulle Gr8Sampler kunna spela in ljudler och skicka dem till PC:n för behandling eller spela upp ler skickade från datorn. Detta innebär att grunden lagts för utvecklingen av långt mer komplexa och användbara ljudbehandlingssystem.

Innehåll 1 Introduktion 1 1.1 Syfte.................................. 1 1.2 Mål.................................. 1 1.3 Metodik................................ 2 1.3.1 Subgrupper.......................... 2 1.3.2 Möten och arbetstider.................... 2 1.3.3 Intern kommunikation.................... 2 1.3.4 Fildelning........................... 2 2 Teknisk beskrivning 4 2.1 Teori.................................. 4 2.1.1 SPI (Serial Peripheral Interface Bus)............ 4 2.1.2 SCI (Serial Communication Interface)........... 5 2.2 Krav.................................. 7 2.2.1 Tillägg 1............................ 7 2.3 Bakgrund............................... 7 2.3.1 Given information...................... 7 2.3.2 Given hårdvara och tillhörande manualer......... 8 2.3.3 Given mjukvara och tillhörande manualer......... 9 2.3.4 Given information om dokumentation........... 9 2.3.5 Given C-kod för HCS12................... 9 2.3.6 Ej redan tillgängliga resurser................ 10 2.3.7 Ej given hårdvara...................... 10 2.3.8 Ej given mjukvara...................... 10 2.4 Översikt................................ 11 2.4.1 Komponenter......................... 11 2.5 Delsystem............................... 12 2.5.1 AD- Omvandlare....................... 12

2.5.2 Förstärkarkrets........................ 12 2.5.3 Användargränssnitt..................... 12 2.5.4 Översikt av gränssnitt.................... 12 3 Resultat och diskussion 13 3.1 Resultat................................ 13 3.1.1 Förstärkarkrets och lågpasslter.............. 13 3.1.2 AD-omvandlare........................ 13 3.1.3 SH (Sample and Hold).................... 14 3.1.4 SPI-kommunikation samt DA-omvandlare......... 14 3.1.5 SCI-kommunikation mellan HC12 och GUI........ 14 3.1.6 Ekofunktionen........................ 14 3.1.7 Grundsystemet........................ 14 3.2 Veriering............................... 15 3.2.1 Förstärkarkrets och lågpasslter.............. 15 3.2.2 AD-omvandlare........................ 15 3.2.3 SH (Sample and Hold).................... 15 3.2.4 SPI-kommunikation samt DA-omvandlare......... 15 3.2.5 SCI-kommunikation mellan HC12 och GUI........ 15 3.2.6 Ekofunktionen........................ 16 3.2.7 Grundsystemet........................ 16 3.3 Utfall av tester............................ 16 3.3.1 Förstärkarkrets och lågpasslter.............. 16 3.3.2 AD-omvandlare........................ 17 3.3.3 SH (Sample and Hold).................... 17 3.3.4 SPI-kommunikation samt DA-omvandlare......... 17 3.3.5 SCI-kommunikation mellan HC12 och GUI........ 17 3.3.6 Ekofunktionen........................ 17 3.3.7 Grunsystemet......................... 17 3.4 Diskussion av resultat och slutsats................. 17

1 Introduktion 1.1 Syfte Produkten skall öka tillgängligheten och möjligheten för kunden att snabbt, enkelt samt billigt kunna sampla ljud. Signalbehandlingen att lägga till ett eko på ljudet ingår alltid och kan användas godtyckligt. Eftersom att systemet är uppbyggt av hårdvara och mjukvara som är enkel att hantera, kan kunden med fördel själv konstruera tillägg utefter egna behov. Det kan t. ex. vara att lagra ljud för senare uppspelning eller ladda in ljud från en PC. Allt som krävs av systemet, är att kunden har erfarenhet nog att kunna använda samt förstå: Dokumentation: Datablad Manualer Programmeringsspråk: C C# Hårdvara: Kortet HCS12 PC med ett Windows-operativsystem Ett ytterligare erbjudande till kunden, är att den får specialbeställa ljudsystemet med egna krav på vilka tillägg som behövs. Om dessa tillägg redan har färdigutvecklats inom företaget och kan direkt säljas till kunden, blir priset relativt lågt. Om tilläggen inte redan nns, utan ska utvecklas på beställning, höjs priset beroende på den tid det tar att utveckla de nya tilläggen. 1.2 Mål Målet som skall uppnås är att konstruera ett ljudsystem. Det skall kunna sampla analogt ljud, för att sedan omvandla detta till digital form. Slutligen konverteras ljudet till en analog signal som därefter skall spelas upp. Utöver detta skall ett tillägg (specicerade och listade i projektdirektivet[1]) implementeras. Detta tillägg innebär att modiera den AD-konverterade signalen med hjälp av C#- och C-programmering, för att skapa ett eko. 1

1.3 Metodik 1.3.1 Subgrupper För att arbeta optimalt valde gruppen att dela upp projektet i fyra olika delar. Nedanför anges kort information om dessa subgrupper. Mer information om gruppernas områden kommer senare i rapporten. <INSERT REFERNCE HERE> 1. Signalbehandling Tog snittprovsvärden av buertern med hjälp av en moduloklocka. 2. Hårdvara Skapade en krets för signalbehandling av insignalen till och från hårdvaran. 3. Graskt användargränssnitt Producerade ett graskt användargränssnitt (GUI) för lättare användning av systemet. 4. Kommunikation med hårdvara Hanterade kommunikationen mellan GUI't och hårdvaran 1.3.2 Möten och arbetstider Gruppen genomförde regelbundna möten varje onsdag i 2 timmar. Under dessa möten uppdaterades gruppmedlemmarna om framsteg inom de olika arbetsområdena. Detta ansågs viktigt för att alla i gruppen skulle ha en översikt i vilken fas projektet befann sig i och vid behov omdirigera våra resurser till de områden som låg efter i planeringen eller områden som krävde större arbetskraft. Projektgruppen tittade även igenom kommande inlämningar under dessa möten för att dela upp arbetet på bästa sätt. 1.3.3 Intern kommunikation Under projektets gång har gruppen tagit kontakt med hjälp av en SMS-grupp samt en Facebook-grupp där generella frågor ställdes och grundlig information utgavs, till exempel vart dessa möten hölls vid specialfall eller vart de andra gruppmedlemmarna arbetade. 1.3.4 Fildelning Projektgruppen använde versionshanteringsprogrammet Git där projektgruppen lade upp dokument och kod för att alla skulle ha tillgång till dessa resurser under projektet. För mindre dokument (till exempel individuella bidrag till arbeten som senare sammanställdes) som alla skulle ha lätt att hitta och läsa, använde sig projektgruppen av Pingpongs loggbok samt Facebooks lsystem. Gruppen ansåg det 2

lättare att upptäcka nya dokument i dessa medier till skillnad från Git då alla i gruppen använde dessa tjänster dagligen och kom därför i kontakt med informationen snabbare. Men allt som laddades upp till Facebook samt loggboken låg även upplagt på Git som säkerhetskopior. 3

2 Teknisk beskrivning 2.1 Teori Nedan följer en lite mer djupgående beskrivning av element som kommer nämnas senare i rapporten 2.1.1 SPI (Serial Peripheral Interface Bus) SPI kommer att användas som gränssnitt mellan FLASH-minnet och processorn, samt processorn och DA-omvandlaren. Det är seriellt, asynkront samt full-duplext. Master SCLK MOSI MISO SS Slave SCLK MOSI MISO SS Figur 1: Förenklad bild av SPI Beskrivning av signaler: Genom SCLK (Serial Clock), generarar Master klockcyklar med en frekvens som är mindre-än eller lika-med den maximala frekvensen som Slave tillåter. Det kan variera men det brukar sträcka sig mellan det minimala 10 khz och det maximala 100 MHz. MOSI (Master Out Slave In) används av Master för att skicka data till Slave. MISO (Master In Slave Out) används av Slave för att skicka data till Master. SS (Slave Select) används av Master för att aktivera- och inaktivera anslutna Slave-enheter. För att aktivera en Slave-enhet, sätts dess motsvarande SS-signal som aktiv låg, innan data kan skickas till den. När datan har skickats, sätts SS till hög igen för att inaktivera den. Men om man endast har en Slave-enhet, låter man oftast SS-signalen förbli låg. Följande procedur genomförs när Master och Slave kommunicerar: 1. Master bestämmer frekvensen för genereringen av klockcyklar genom SCLK. Dessutom sätter Master CPOL och CPHA. CPOL styr om klockan börjar räkna med bit 1 eller bit 0. CPHA bestämmer om data ska tas emot och skickas vid positiv- eller negativ ank. Tabellen nedan beskriver vad som sker beroende på hur dessa bitar sätts. 4

Mode CPOL CPHA 0 0 0 Klockans startbit: 0, data tas emot vid positiv ank. 1 0 1 Klockans startbit: 0, data tas emot vid negativ ank. 2 1 0 Klockans startbit: 1, data tas emot vid negativ ank. 3 1 1 Klockans startbit: 1, data tas emot vid positiv ank. 2. Master sätter rätt SS-signal till låg för att aktivera den Slave-enhet, som den ska kommunicera med. Endast en SS-signal får sättas till låg samtidigt. Detta betyder att Master endast kan kommunicera med en Slave i taget. 3. Master börjar generara klockcyklar efter den frekvens som tidigare satts. För varje klockcykel, skickar Master och Slave 1-bit till varandra genom MOSI och MISO. Oftast skickas en byte i taget dvs. utbytet av data sker under åtta efterföljande klockcyklar. Men SPI kan även användas med er bitar. 4. Master inaktiverar Slave-enheten som den kommunicerat med, genom att återställa dess motsvarande SS-signal till hög. Master och Slave har var sitt register som är kopplade till MOSI och MISO. Dessa register är skift-register. Registren skiftar in den minst signikanta biten medan de skiftar ut den mest signikanta. Nedan nns det en bild som beskriver detta. Master Slave MOSI 0 1 2 3 45 6 7 MISO 0 1 2 3 45 6 7 Figur 2: Förenklad bild av ett skiftregister 2.1.2 SCI (Serial Communication Interface) Gränssnittet som möjliggör kommunikationen mellan HCS12 och PC är SCI. Det är ett asynkront seriellt gränssnitt som kan ta emot och skicka data. Data tas emot genom receiver-ingången medan det skickas ut från transmitter-utgången. För att använda SCI i C-kod, använder man dess två interrupt-funktioner. Den som används beror på vilken SCI-port man använder. Det nns en port 0 och en annan port 1. Interrupt-funktionen anropas beroende på om SCI:n tar emot eller skickar data. Om SCI skickar data, anropas interrupt-funktionen när transmitter-data-registret har kopierat sin byte till SCI-data-registret. Samtidigt sätts aggan TDRE (Transmitter Data Register Empty) till 1. TDRE nollställs när man från C-programmet laddar transmitter-data-registret med en ny byte. Om SCI tar emot data, anropas interrupt-funktionen när receiver-dataregistret har kopierat sin byte till SCI-data-registret. Samtidigt sätts aggan RDRF (Receiver Data Register Full) till 1. Denna nollställs genom att läsa SCI-data-registret. 5

I SCI-kabelns ena ände sitter en Seriell-till-USB adapter så att man kan ansluta till USB-porten på PC:n, som HCS12 ska kommunicera med. Programmet som kommunicerar med SCI från PC:n är skrivs i C#. Anledningen är att C#:s färdiga bibliotek lämpar sig för kommunikation med USB. Det används för att hitta-, ansluta till- samt kommunicera med USB-porten som SCI:n är kopplad till. Grundsystem med AD-och DA-omvandlare för att sampla och spela upp ljud. PC-interface för kommunikation mellan dator och ljudsystemet. Signalmanipuleringfunktion. Lagringsfunktion av det samplade ljudet. 6

2.2 Krav Krav är de förutsättningar som krävs för att systemet skall vara funktionsdugligt. Samplingsfrekvens: 20 khz. Signalspann: +-2 volt. Lagringskapacitet i ashminne: 1 Msampel. Systemet skall i första hand kunna sampla och spela upp ljud. Ljudsignalen skall A/D-omvandlas, DA-omvandlas och sedan spelas upp som en analog signal. Samplingen skall kunna startas och stoppas med hjälp av ett seriellt PCinterface. 2.2.1 Tillägg 1 Före D/A-omvandlingen skall en digital behandlig av signalen ske. Signalbehandligs parametrar skall kunna ändrar via ett seriellt PC-interface. 2.3 Bakgrund 2.3.1 Given information Gruppen hade tillgång till hårdvarumanualer. Guider för den hårdvara samt mjukvara som förbestämt skulle användas. Dessutom fanns det mallar och krav för den dokumentation som skulle skrivas. Dessa manualer, guider och mallar omfattade följande: HCS12 Periferienheter till HCS12 Gränssnitt till HCS12 Språket C PTB (Pioneers Test Bench) XCC 7

2.3.2 Given hårdvara och tillhörande manualer Nedan listas hårdvaran som de tillgängliga manualerna beskriver. HCS12 Register Minnen Interrupts Utgångar Ingångar Periferienheter till HCS12 FLASH-minne A/D-omvandlare DA-omvandlare Gränssnitt till HCS12 SCI (Serial Communication Interface) SPI (Serial Peripheral Interface) 8

2.3.3 Given mjukvara och tillhörande manualer Nedan listas mjukvaran som manualerna beskriver. För utveckling av C-programmet: PTB (Pioneers Test Bench) XCC C För dokumentationshantering: Git LaTex PingPong 2.3.4 Given information om dokumentation Nedan listas dokumentationer som krävs och som ges exempel på. Loggar Mötesprotokoll Projektspecikation Projektrapport Oppositionsrapport Presentation 2.3.5 Given C-kod för HCS12 Gruppen har redan tillgång till en del av den C-kod som kommer att behövas för C-programmet som ska köras i HCS12. De tillgängliga lerna är C-ler och header-ler. Listan nedan visar dessa: C-ler: irq_tabell_dat290.c för funktionsprototyper till interrupt-funktioner. main.c för start samt öde av C-programmet. header-ler: generic_handler_dat290.h för att ange vilka interrupts som vi vill hantera. HCS12_DG.h för denitioner till register i HCS12. reg_macro.h för denitioner till de funktioner som används för att läsa samt skriva till register. 9

2.3.6 Ej redan tillgängliga resurser Det fanns ytterligare delar som var tvungen att konstrueras av gruppen. Det första var den elektroniska signalkorrektionen av den inkommande analoga signalen. Det andra var det graska användargränssnittet. Alla som ansvarade för signalkorrektionen och användargränssnittet, var tvungna att hitta information själva om hur dessa skulle konstrueras, implementeras samt integreras med ljudsystemet. 2.3.7 Ej given hårdvara Den hårdvara som helt saknades, är den förstärkande signalkorrektionen av den inkommande analoga signalen. Den korrigerades med en elektronisk koppling innan den når AD-omvandlaren. 2.3.8 Ej given mjukvara För att skapa vektoriserade bilder, använde vi Adobe Illustrator för de som används i projektspecikationen och rapporten. De skulle vektoriseras för att behålla en bra bildkvalitet. Vid programmering i C#, användes IDE:n (Integrated Development Environment) Microsoft Visual Studio. Det hade passande verktyg just för utveckling av graska användargränssnitt. Dessutom fungerade det bra med C#-biblioteket. 10

2.4 Översikt Grundsystemet Första tillägget PC Andra tillägget PC Förstärkarkrets AD HCS12 SPI DA OUTPUT PC FLASH Figur 3: Förenklad bild av systemet Systemet i sin helhet bestod till att börja med av en förstärkarkrets som med hjälp av operationsförstärkare justerade signalen, så att den skulle vara kompatibel med HC12's AD-omvandlare. För att minimera signalstörningar hade vi konstruerat ett lågpasslter som ltrerade bort höga frekvenser. Efter omvandlingen av signalen kommer processorn att skicka informationen över gränssnittet SPI till en externa DA-omvandlaren, samt spara det digitala värdet i minnet för att senare kunna användas för att skapa ett eko. I DA-omvandlaren kommer informationen sedan omvandlas tillbaka till en analog signal. Efter omvandlingen behandlas signalen av ytterligare ett lågpasslter, signalen spelas sedan upp genom en högtalare. I samband med uppspelningen kan även informationen sparas i ett FLASH-minne för senare användning. 2.4.1 Komponenter Komponenterna nedan har använts för att koppla samman delsystemen: Processor HCS12. Enchipsdator MC12S med tillhörande kort. Flashminne. A/D-omvandlare. DA-omvandlare. Operationsförstärkare. 11

2.5 Delsystem Nedan följer en kort beskrivning av delsystemen. 2.5.1 AD- Omvandlare AD-omvandlaren består av en intern krets i MC12S. A/D-omvandlarens uppgift är att omvandla en analog signal till ett digitalt värde, i detta fall 8-bitar som sedan sparas i ett dataregister. Denna information kan sedan läsas och modieras för att kunna användas i andra delsystem. 2.5.2 Förstärkarkrets Kretsens uppgift är att omvandla en analog signal i spannet +-0.5 V till en analog signal med spannet 0-5 V med hjälp av operationsförstärkare och resistorer (Se Figur 3 på nästa sida för illustrion). Detta för att kunna utnytja så mycket som möjligt av AD-omvandlarens kapacitet. Innan signalen når AD-omvandlaren går den igenom ett lågpasslter för att få bort eventuella signalstörningar. 2.5.3 Användargränssnitt Som användargränssnitt används ett GUI. Användargränssnittets uppgift är att förenkla styrningen av systemet genom att erbjuda ett enkelt sätt att kommunisera med processorn samt dess delsystem. 2.5.4 Översikt av gränssnitt Listan nedan ger en kortfattad förklaring av vilka gränssnitt som används mellan användaren, PC:n, HCS12 och FLASH-minnet. Användare mot PC: Ett GUI programmerat i C#. PC mot HCS12: Ska vara SCI. HCS12 mot FLASH: Ska vara SPI. Bilden nedan ger en grask översikt av listan. 12

: Enhet/Användare : : Gränssnitt Användare GUI/CLI SCI PC HCS12 SPI DA Figur 4: översikt av gränssnitt 3 Resultat och diskussion 3.1 Resultat Målet med grundsystemet har varit att ta fram ett fungerande system som kan sampla analogt ljud och omvandla det till digital form för att sedan omvandla tillbaka det till analogt format och spela upp ljudet. Ett system med denna funktionalitet har konstruerats och testats med hjälp av hårdvara tillgänglig på Chalmers, och slutresultatet är fungerande med god pålitlighet. Resultatet för varje delsystem, samt hur vi gick tillväga under konstruktionen kommer presenteras nedan och slutligen kommer grundsystemet att redovisas. Den slutgiltiga koden kan studeras i bilaga X. 3.1.1 Förstärkarkrets och lågpasslter Gruppen beslutade sig att genomföra en förstärkning med hjälp av två operationsförstärkare, en som förstärker signalen och inverterar den och slutligen en som endast inverterar den. Följande beräkningar användes för att komma fram till rätt förstärkning<uträkningar här> Kopplingen konstruerades på kopplingsdäck. 3.1.2 AD-omvandlare En intern AD-omvandlare existerar redan i HC12S och behöver bara aktiveras för att kunna användas och behövde således inte konstrueras, utan endast aktiveras och kongureras till att använda 8-bitars upplösnig. Gruppen valde att låta AD-omvandlaren konstant omvandla en insignal för att sedan sampla med hjälp av en Sample and Hold funktion. 13

Figur 5: Kopplingsschemat för förstärkningskretsen 3.1.3 SH (Sample and Hold) Får att kunna styra samplingsfrekvens valde gruppen att använda en moduloklocka som räknar ner och genererar ett avbrott med en frekvens på 20 Khz. Under detta avbrott samplas signalen som har omvandlas från analog till digital form och skickas över SPI till DA-omvandlaren. 3.1.4 SPI-kommunikation samt DA-omvandlare HC12 och DA-omvandlaren kommunicerar genom ett SPI-gränssnitt. DA-omvandlaren kräver en 16 bitars signal( 8 instruktionsbitar och 8 databitar) för att fungera, och SPI endast skickar 8 bitar i taget. Gruppen löste detta genom att lägga en signal som inte strys av SPI utan kan manipuleras i programmet, denna signal användes sedan som CS(Chip Select). Sålänge denna var nollställd så kan data skickas till DA-omvandlaren, för att slutligen ettställas och då genomförs omvandligen. 3.1.5 SCI-kommunikation mellan HC12 och GUI ((Ni som gjorde detta måste skriva hur ni gjorde här!) 3.1.6 Ekofunktionen ((Ni som gjorde detta måste skriva hur ni gjorde här!) 3.1.7 Grundsystemet ((Någon som har någon bra idé på vad som ska skrivas här? :s)) 14

3.2 Veriering Under denna rubrik evalueras projektresultatet utifrån projektbeskrivningen, problemformuleringen samt kraven angivna i projektspecikationen. Underrubrikerna utvärderar de olika delsystemen (beskrivna i 2.4 Delsystem) i större detalj. För utufallet av testerna, se punk 3.3. 3.2.1 Förstärkarkrets och lågpasslter Förstärkarkretsen verierades i era steg, förs genom tjänsten (INPUTNAME- HERE), för att sedan konstrueras och testas med hjälp av en genererad sinusvåg och ett oscilloskop. 3.2.2 AD-omvandlare AD-omvandlarens verierades genom att inducera en spänning till AD-omvandlaren och sedan låtit en LED-periferienheten visa det digitala värdet. Testet visade att AD-omvandlaren fungerade som tänkt. Den digitala signalen sparas i ett dataregister där den sedan kan avläsas av DA-omvandlaren. 3.2.3 SH (Sample and Hold) Funktionen verierades genom att en dip-switch kopplades som insignal, och varje gång moduloklockan genererade ett avbrott så skrevs detta värde ut på en LED-display. 3.2.4 SPI-kommunikation samt DA-omvandlare SPI kommunikationen samt DA-omvandlaren verierades genom två test. Det första var ett mer grundläggande test som gick ut på att med hjälp av en dipswitch som inslignal testa om utspänningen på DA-omvandlaren ändrade sig, detta för att se om kommunikationen mellan HC12 och DA-omvandlaren fungerade korrekt. Det andra testet var ett mer avanserat test där med hjälp av en Öscillerande spänningskälla"(hitta rätt ord) genererade en insignal i form av en sinusvåg i intervallen 0-5V. Denna signal användes sedan som insignal till AD-omvandlaren som omvandlade signalen till digital, denna siganal samplades sedan och skicakdes över SPI till DA-omvandlaren. Både insignalen samt DA-omvandlarens utsignal visades på ett oscilloskop. 3.2.5 SCI-kommunikation mellan HC12 och GUI SCI verierades med hjälp av att varje gång SCI genererar ett avbrott skriva en sira på LED-periferienheten. Kommunikationen med GUIt verierades sedan 15

genom att man från GUIt skickade en sira över SPI som sedan projecerades på LED-periferienheten när SCIn genererade ett avbrott. 3.2.6 Ekofunktionen (Hur testade ni ekot?) 3.2.7 Grundsystemet Grundsystemet verierades genom att man med hjälp av en 3.5-mm-splitter som kopplades till en PC och sedan in i förstärkarkretsen. Utsignalen kopplades in till en högtalare samt ett oscilloskop. 3.3 Utfall av tester 3.3.1 Förstärkarkrets och lågpasslter I simuleringarna visades tydligt kopplingens funktion, och i testet efter konstruktionen visade oscilloskopet en förstärkning av insignalen med ytterst få förluster, vilket lever upp till kraven. Figur 6: Simuleringsgraf som visualiserar förstärkningen 16

3.3.2 AD-omvandlare Testet visade att en analog signal på 0-5V motsvarade ett digitalt värde på 0-255. Testet visade att AD-omvandlaren fungerade som tänkt och lever upp till kraven. 3.3.3 SH (Sample and Hold) Testet visade att vid avbrott kommer funktionen att genomföra innehållet i dess avbrottsrutin. 3.3.4 SPI-kommunikation samt DA-omvandlare DA-omvandlaren visade under det första testet en förändring när man modierade insignalen och det andra testet visade att DA-omvandlaren genererade en utsignal som var identiskt till insignalen, dock lite förskjuten på grund av den tid det tar för processorn att genomföra operationerna. Trots tidsförskjutningen lever delsystemet upp till de satta kraven. 3.3.5 SCI-kommunikation mellan HC12 och GUI Det första testet av SCI visade att SCI var korrekt kongurerat genom att rätt sira visades på LED-periferienheten, det andra testet visade att kommunikationen PC - HC12 fungerade över SCI genom att rätt sira tändes på LED-periferienheten. 3.3.6 Ekofunktionen (Vad var resultatet av testet?) 3.3.7 Grunsystemet Testet av grundsystemet visade att hela grundsystemet fungerade genom att en ljudl från datorn spelades upp genom högtalarna med god kvalitét efter att ha passerat genom systemet. 3.4 Diskussion av resultat och slutsats Resultaten visar att gruppen lyckats skapa en fungerande slutprodukt utifrån de krav som ställdes. Det primära målet som skulle uppnås var att konstruera ett ljudsystem som möjliggjorde sampling av analogt ljud för att sedan omvandla detta till digital form och slutligen konvertera tillbaka ljudet. Syftet 17

med skapandet av det samplade ljudsystemet var att eektivisera tekniken att A/D- och DA-omvandla ljudsignaler för uppspelning och lagring med ett GUI. Många faktorer har påverkat resultatet, däribland valet av att använda-ett användarvänligt PC-gränssnitt. GUI:t är tätt knutet till syftet om eektivisering av samplingen - då detta används för att enkelt kunna interagera med hela systemet. Den utmärkande betydelsen av resultatet är att den digitala signalen kan lagras, analyseras och redigeras efter önskemål. Med andra ord skulle detta system kunna användas för andra tillämpningar och syften. Istället för lagring till ashminne skulle den digitala signalen kunna lagras i en l och skickas till ett annat system som behandlar ljudet, t.ex. en ljudeditor. Gruppen var vid en tidpunkt tvungen att ändra om i tidsplanen pga. olika faktorer. Signalgruppen planerade att skapa en sample and hold krets och arbetet fortlöpte och pågick i en hel vecka. Veckan därefter ck gruppen vetskap om att en Sample and hold krets redan fanns inbyggd i HCS12. Hade gruppen haft denna information tidigare skulle mer tid kunna läggas fördelas över de härdvaruproblem som uppstod. Saker jag skall skriva mer om: Blev något som vi inte hade tänkt oss, något oväntat? Hur bra lyckades gruppen? Hur påverkade metodiken resultatet? Kunde vi gjort på något annat sätt? Resonera kring hur resultatet hade sett ut ifall vi kunnat arbeta med hårdvaran när vi känner för de (begränsning av tillträde till labbsal) Skall även ta med de utmaningar gruppen ställdes inför vid val av programmeringsspråk 18

Referenser 19