Projektspecikation DAT290 Datatekniskt Projekt - Grupp 8

Transkript

1 Projektspecikation DAT290 Datatekniskt Projekt - Grupp 8 Dzenan Bazdarevic, Hannes Häggander Morhaf Alaraj, Max Hansson, Liam Hughes Andreas Hagesjö, Tobias Eliasson, Jan Qvick 11 september, 2013 Granskad Godkänd Namn Datum 1

2 Del I Kravspecikation 1 Syfte I projektet ska det tas fram och konstrueras en fungerade datateknisk produkt som kan sampla samt spela upp analogt ljud genom konvertering till digital form. Syftet med projektet är att kursdeltagarna ska lära sig att driva och realisera ett projekt utifrån en projektspecikation, samarbeta i en projektgrupp, ta fram realistiska tidsplaner och att dela upp arbete inom gruppen. Dataprogrammet har tidigare inte haft projektkurser förrän senare i utbildningen, och det är tänkt att utförandet av detta projekt ska förbereda deltagarna inför kommande sådana. Vidare är syftet att utveckla kunskaper man fått i tidigare kurser i Dataprogrammet både vad gäller mjuk- och hårdvara samt att kombinera dessa med nya kunskaper man skaar sig under kursens gång. 2 Mål Det primära målet som ska uppnås är att ta fram ett funktionellt grundsystem som ska kunna sampla analogt ljud för att sedan omvandla detta till digital form och slutligen konvertera tillbaka ljudet till en analog signal som sedan ska spelas upp. Utöver detta bör minst 2 tillägg (specicerade och listade i projektdirektivet implementeras. Det första tillägget innebär att modiera den AD-konverterade signalen med hjälp av ren programmering, antingen för att skapa ett eko eller för att modiera volymen för olika frekvenser. Det andra tillägget som bör implementeras är möjlighet att lagra det samplade ljudet i ett FLASH-minne för senare uppspelning. I mån av tid bör även de sista 2 tilläggen implementeras - att överföra det samplade ljudet till en PC och tillbaka samt att överföra waveler från en PC till systemet för uppspelning. 3 Bakgrund Kursledningen för DAT290 - Datatekniskt projekt har valt ut 8 kursdeltagare för att bilda en grupp som tillsammans ska utföra projektet. Gruppen har fått 2

3 ett projektdirektiv som ska realiseras med hjälp av existerande hårdvara och eventuella egenkonstruerade tillägg. Hjälpmedel som nns tillhands innefattar bland annat föreläsningar, en dokumentsamling påplattformen pingpong samt en tilldelad gruppmentor från en högre årskurs. Utöver detta förväntas gruppen använda sig av kunskaper de tillförskaat sig tidigare under sin utbildning. 4 Systemöversikt Grundsystemet Första tillägget PC Andra tillägget MIC AD HCS12 EDIT DA OUTPUT PC FLASH Figur 1: Systemöversikt I grundsystemet samplas ljud som kommer från en ljudkälla. Ljudet skall därefter AD-omvandlas för att kunna processeras och i slutändan DA-omvandlas för att kunna spelas upp som analog signal. Samplingen kommer ske genom PC-interfacet där start- och stoppknappar är tillgängliga. I första tillägget utförs digital signalbehandling (DSP) av ljudet. Signalbehandlingen består antingen av en ljudeekt, frekvenskorrigering eller ett eko. I andra tillägget skall lagring av den samplade signalen i FLASH-minnet ske för senare uppspelning. 4.1 Delsystem Grundsystem med AD och DA omvandlare för att sampla och spela upp ljud PC-interface för kommunikation mellan dator och ljudsystemet 3

4 Signalmanipuleringfunktion Lagringsfunktion av det samplade ljudet Komponenter Processor HCS12 Enchipsdator MC12S med tillhörande kort Flashminne AD-omvandlare DA-omvandlare Operationsförstärkare 4.2 Övergripande funktionella krav Samplingsfrekvens: 20kHz Signalspann: +-2 volt Lagringskapacitet i ashminne: 1Msampel Systemet ska i första hand kunna sampla och spela upp ljud. Systemet bör kunna behandla den inkommande signalen med hjälp av ett pc-interface, där man ska kunna styra bas, diskant eller eko. Systemet bör kunna lagra det samplade ljudet i ett ashminne för att sedan kunna spelas upp genom systemet igen. I mån av tid kan funktionalitet för att överföra det samplade ljudet till PC och återföring av ljudet från PC:n till systemet för uppspelning. 4.3 Beroenden till andra system För att systemet skall fungera i sin helhet behöver kopplingarna mellan systemet fungera felfritt. Kopplingen via t.ex. SPI som sköter kommunikationen mellan system och minne, sker genom den mjukvara som är skriven, medan den fysiska kopplingen bara är ett krav för att kommunikationen ska etabliseras. En annat viktigt beroende är de omvandlingar som sker.för att kunna processera ljudet digitalt måste det först AD-omvandlas. När AD-omvandlingen ägt rum kan man säga att signalen är kompatibel med det system där bland annat frekvenskorrigering kommer ske. För att kunna spela upp ljudet i outputenheten (en högtalare) måste signalen DA-omvandlas. 4

5 4.4 Projektavgränsningar Systemet ska begränsas till funktionerna som är nämnda i föregående avsnitt. Enbart i mån av tid skall funktionalitet för att överföra ljud från pc till och från PC:n vara möjligt. 5 Delsystem 5.1 Funktionella krav Grundsystemet Ljudsignaler skall samplas med frekvensen 20 khz. Ljudsignalerna skall AD-omvandlas, DA-omvandlas och sedan spelas upp som analog signal. DA-omvandlingen sker via pulsbreddsmodulering (PWM). Samplingen skall kunna startas och stoppas via ett seriellt PC-interface Tillägg 1 Före DA-omvandlingen skall en digital behandling av signalen ske. Man skall kunna ändra tonkontroll, bas och diskant. Signalbehandlingsparametrar skall kunna ändras via ett seriellt PC-interface Tillägg 2 Det samplade ljudet skall kunna lagras i ett externt FLASH-minne. Man skall kunna styra ljudets längd via användargränsnittet Tillägg 3 Det samplade ljudet skall kunna överföras från FLASH-minnet till PC:n. Det samplade ljudet skall kunna lagras eller ändras via PC:n. överföringen till PC skall ske efter samplingen. överföringen från PC skall ske före samplingen. 5

6 5.1.5 Tillägg 4 Systemet skall kunna spela wave-ler från PC:n. Header:n från wave-len skall tas bort innan len laddas ner till FLASHminnet. 5.2 Gränssnitt SPI (Serial Peripheral Interface Bus) SPI kommer att användas som gränssnitt mellan FLASH-minnet och processorn. Det är seriellt, asynkront samt full-duplext. Nedan nns en enkel bild av SPI. Master SCLK MOSI MISO SS Slave SCLK MOSI MISO SS 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. Om CPOL är låg och CPHA är låg, börjar klockan räkna med bit 0 och data tas emot vid positiv ank. Om CPOL är densamma men CPHA är hög, tas data emot vid negativ ank. Om CPOL däremot är hög och CPHA är låg, börjar klockan räkna med bit 1 och data tas emot vid negativ ank. Om CPOL förblir likadan men 6

7 CPHA är hög, tas data emot vid positiv ank. Dessa inställningar kallas för SPI:ns mode". Nedan nns en överskådlig tabell av hur mode ställs in. Mode CPOL CPHA Klockans startbit: 0, data tas emot vid positiv ank Klockans startbit: 0, data tas emot vid negativ ank Klockans startbit: 1, data tas emot vid negativ ank 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 MISO Seriellt PC-interface PC-interfacet kommer att vara seriell SCI (Serial Communication Interface). PC:n kommer alltsåatt kommunicera med HCS12 via detta Användargränssnitt Det kommer att behövas antingen en CLI eller GUI, för att användaren enkelt ska kunna använda samt mata in parametrar till HCS12. Det måste i alla fall nnas en enkel CLI som tillåter användaren att kommunicera med den. Om det blir tid över, bör den ersättas med en GUI. Mer specikt, kommer användaren att använda detta interface, för att styra den digitala signalbehandlingen samt hur länge samplingen ska ske till FLASHminnet. 7

8 5.3 Ö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: Ska först vara en CLI men bör ersättas med en GUI. PC mot HCS12: Ska vara SCI. HCS12 mot FLASH: Ska vara SPI. Bilden nedan ger en grask översikt av listan. : Enhet/Användare : : Gränssnitt Användare GUI/CLI SCI PC HCS12 SPI FLASH 6 Övergripande prestandakrav Denna lista över prestandakraven är mer kortfattad. För mer detaljer, läs del 5. Samplingsfrekvens: 20 khz. Signalspann: +-2 volt. Signalkorrigering: Sker elektroniskt. Typ av AD-omvandling: AD-omvandlare i HC12. Typ av DA-omvandling: PWM (Pulse Width Modulation) Minne: 1 Msampel FLASH Interface mellan användaren och systemet: Ska vara en CLI men bör vara en GUI i PC:n. Interface mellan PC:n och systemet: Seriellt. Interface mellan FLASH-minnet och systemet: SPI (Serial Peripheral Interface Bus). 8

9 7 Kvalitetskrav Här följer en lista innehållandes de krav man bör ha i åtanke när dokumentation, versionshantering och veriering genomförs. 7.1 Dokumentation Dokumentation skall koncist förklara hur en komponent (dvs. hårdvara el. mjukvara) beter sig, och att en gruppmedlem som är insatt i projektet som helhet enkelt kan börja använda komponenten efter att ha läst all dokumentation. Dessutom skall en person med kunskap i digitalteknik, språket c och ellära kunna utan svårigheter begripa och använda projektets slutprodukt efter att ha läst all dokumentation. C-funktioner: Funktioner bör ha namn som beskriver sin funktionalitet utöver funktionalitetsbeskrivning i kommentarer. Globala variabler bör ha namn som indikerar sin användning. Om en funktion har potentiellt farliga sidoeekter bör dessa noteras i kommentarer. En programmerare bör helst kunna säkert använda en funktion utan detaljerad kunskap om dess implementation. Hårdvarukomponenter: Efter att ha läst dess dokumentation bör en insatt gruppmedlem ha en intuitiv förståelse av komponentens funktion och bör även begripa hur man fysiskt integrerar den med annan hårdvara (vilken sladd som går vart) samt hur komponentens inställningar sätts. 7.2 Versionshantering Git kommer användas för versionshantering. Filträdet behöver vara välorganiserat, och när era personer arbetar i en l bör de kommunicera för att undvika att skriva över eller onödigt replikera kod. 7.3 Veriering Individuella komponenter bör i största möjliga mån verieras enskilt innan de integreras med andra. Hårdvarukomponenter speciellt behöver vara hårt testade i simulator innan de konstrueras, eftersom kostnaden av att göra fel i det skedet är mycket högre än när mjukvara assembleras. 9

10 Del II Projektplan 8 Resursplan 8.1 Kontaktinformation Namn Position Hannes Häggander hanhag@student.chalmers.se Projektledare Andreas Hagesjö hagesjo@student.chalmers.se Git-ansvarig/versionsansvarig Jan Qvick qvick@student.chalmers.se Granskningsansvarig Max Hansson hamax@student.chalmers.se verieringsansvarig William Hughes hughes@student.chalmers.se position antas vid behov Dzenan Bazdarevic dzenan@student.chalmers.se position antas vid behov Morhaf Alaraj morhaf@student.chalmers.se position antas vid behov Tobias Eliasson tobelia@student.chalmers.se position antas vid behov Daniel Moreau moreaud@student.chalmers.se Mentor 8.2 Kommunikation inom gruppen Kommunikation sker via gruppens SMS- och facebookgrupp. Om simpla och/eller generella frågor uppstår (frågor som inte behöver nämnas vid möten), kan de ställas i facebook- eller SMS-gruppen. Om gruppen inte har svar till frågan bör den ställas till mentor eller lärare. 8.3 Lokal Gruppens projektledare bokar lokal för regelbundna möten. Mötena är planerade att utspelas under 2 timmar. Om det planerade rummet 3207 är upptaget kommer information om ny lokal att nnas i loggboken samt SMS-gruppen. Andra arbeten som berör det samplade ljudsystemet är upp till det bestämda planeringsschemat där gruppens arbeten är upplagt för veckan. Lokaler Dag Klockan Syfte 3207 Onsdag 13:00 Regelbundna möten EDA4209 Valfri bokning Indelad grupp bestämmer Hårdvara/mjukvara EDA4211 Valfri bokning Indelad grupp bestämmer Hårdvara/mjukvara EDA4213 Valfri bokning Indelad grupp bestämmer Hårdvara/mjukvara EDA4215 Valfri bokning Indelad grupp bestämmer Hårdvara/mjukvara 10

11 8.4 Distans Distansarbete är möjligt om det inte berör samarbete med det samplade ljudsystemets hårdvara inne i Chalmers arbetsrum. Grupperna bestämmer själva vart de arbetar förutsatt att de arbetar produktivt och att deadline följs efter tidsplanering. OBS: En projektgrupp får enbart boka 2 stycken arbetsplatser under samma eftermiddag/förmiddag. 9 Milstolpar Nr. Beskrivning Datum 1 Projektspecikation inlämnad Grundsystemet är klar Tillägg 1 är klar Inlämning av tidig version av projektrapport till opposition Inlämning av oppositionsrapport Tillägg 2 är klar Demonstration Inlämning av projektrapport

12 10 Aktiviteter Nr Beskrivning Tidåtgång 1 Inläsning av dokumentation för HCS12-system 6 h 2 Framtagning av LaTeX-mallar 1 h 3 Möten 14 h 4 Arbete med hårdvara 25 h 5 Arbete med mjukvara 36 h 5 Systemintegration 10 h 6 Rapportskrivning 20 h 7 Veriering 5 h 8 Granskning 1 h 11 Tidsplan V september V. 37 V. 38 V. 39 V oktober V. 41 V V1 V2 V3 V4 V : Planering 4: Grundsystem 2: Projektspecifikation 5: Tillägg 1 3: Rapport 6: Tillägg 2 V1: Inlämning av projektspecifikation. V4: Demonstration. V2: Inlämning av tidig version av projektrapporten till opposition. V5: Inlämning av projektrapport. V3: Inlämning av oppositionsrapport. 12 Mötesplan Läsvecka Datum Tid Lokal* Syfte LV : Projektmöte LV : Projektmöte LV : Projektmöte LV : Projektmöte LV : Projektmöte LV : Projektmöte *Om lokalen är bokad kommer information om en ny lokal via SMS- eller facebookgruppen. Under projektmöten kommer gruppen se hur det går med de indelade grupparbeterna. Alla i gruppen har möjligehet att uppdatera sig om andras arbeten 12

13 och berätta om sitt eget ifall de behöver hjälp eller åsikter. OBS: Slutrapport Möte den kanske aldrig blir av om projektet är avslutat. 13 Kommunikationsplan Vad När Till Hur Utse gruppledare Lärarteam PingPong loggbok Välj projekt Lärarteam PingPong loggbok Möteskallelse Projektgrupp PingPong loggbok Mötesprotokoll Mentor PingPong loggbok Dela dagordning Projektgrupp PingPong loggbok Mötesprotokoll Mentor PingPong loggbok Dela basregler Projektgrupp PingPong loggbok Projektspec. inlämnad Lärarteam Git och Latex Mötesprotokoll Mentor PingPong loggbok Mötesprotokoll Mentor PingPong loggbok Mötesprotokoll Mentor PingPong loggbok Tidig projektrapport inlämnad Lärarteam Git och Latex Mötesprotokoll Mentor PingPong loggbok Oppositionsrapport inlämnad Lärarteam Git och Latex Demonstration (14-15) Lärarteam Muntligt Mötesprotokoll Mentor PingPong loggbok Rapport v. 1 inlämnad Lärarteam Git och Latex Mötesprotokoll Mentor PingPong loggbok Avslutning Kvalitetsplan 14.1 Versionshantering och dokumentgranskning För information om versionshantering se sektion 7.2. Dokumentgranskning koordineras av granskningsansvarig Uppförandekod för projektgruppen Sen ankomst till aktiviteter: Vid sen ankomst till möten eller andra aktiviteter kommer varning utdelas till personen i fråga. Om en oanmäld sen ankomst upprepas ytterligare en gång kommer gruppen först att försöka lösa problemet internt. Förklaringar ges via SMS-grupp, facebookgruppen, eller den gemensamma loggboken i pingpong. Vid ytterligare sen ankomst är den försenade skyldig att erbjuda ka till gruppen vid nästa möte. 13

14 Vägran att utföra tilldelat arbete: Om en gruppmedlem inte utför sitt antagna uppdrag och inte visar vilja att utföra arbetet kommer projektledaren att ta upp detta under kommande möten. Om ingen förbättring sker kommer händelsen att rapporteras till mentor/lärare och det outförda arbetet kommer att delas ut till en annan i gruppen. Detta gäller inte någon som tydligt gör ett försök att klara sin uppgift men har svårigheter Veriering och testning Testning av delsystem kommer först göras internt, inom undergruppen som utvecklar den. En komponent bör vara relativt välfungerande när utomstående lagmedlemmar kallas in för veriering och integrering: delen bör sakna större buggar och fungera mestadels felfritt. Om ett team ej lyckas klara det stadiet bör de kalla in hjälp från resten av gruppen. 14