Andreas Nordbek & Kristoffer Skude Jensen DMX Styring 31-05-2010 Side 1 af 15
Indholdsfortegnelse 1 Indledning... 3 2 DMX... 4 3 Arkitektur... 5 4 Hardware design... 6 4.1 SPI... 9 5 Software... 10 5.1 Tahoe-II software... 10 5.2 Tahoe-II software klasser... 10 5.2.1 SequenceDmxController... 10 5.2.2 Sequence... 11 5.2.3 Scene... 12 5.2.4 SequenceData... 12 5.2.5 Fixture... 13 5.3 Mega32 software... 13 6 Diskussion... 14 6.1 Resultater... 14 6.2 Problemer... 14 6.3 Forbedringer... 15 7 Konklusion... 15
1 Indledning Vi har til WEM1 projektet stillet os selv den opgave at kunne styre en RGB lampe via DMX som skal generes af Tahoe-II Development boardet. Det var fra starten planen, at vi udelukkende ville benytte Tahoe-II boardet til at lave DMX signalet. Men da.net frameworket sætter visse begrænsninger for hvor hardware nært man kan kode, så har det været nødvendigt for os, at sætte en Mega32 micro controller ind som mellemled. Vi vil i denne rapport beskrive projektforløbet, hvad der er gået godt og hvad der er gået mindre godt. Ydermere vil vi gå lidt i dybden med de specifikke tekniske løsninger vi har valgt. Desuden er projektet udviklet i.net Micro framework et og opfylder kravene stillet i Projektkrav.pdf. DMX er en protokol der bruges i lys industrien, til at kommunikere mellem lyscontrollere og lamper. Når man er til koncert med sit yndlingsband, eller når man sidder derhjemme foran fjernsynet og ser sit yndlings program fredag aften. Så er alt lyset med meget stor sandsynlighed styret via DMX.
2 DMX En DMX pakke kan indeholde optil 512 kanaler, som hver er 8 bit. Når vi siger optil, så betyder det bare at man ikke behøver sende samtlige 512 kanaler hvis ikke de bliver brugt. En DMX pakke består af følgende: Figur 1 - viser strukturen af en DMX pakke DMX signalet skal sendes ud med en baudrate på 250k, hvilket giver 4 µs. mellem hver bit. Se bilag for mere detaljeret timing. Man forbinder lamperne i en kæde, hvor den første lampe er forbundet til kontrolleren, og den sidste lampe har en terminator på 120ohm. Hver lampe er konfigureret til at reagere på bestemte kanaler, således at det er muligt at styre lamperne individuelt. Det er muligt at forbinde optil 32 lamper i en kæde uden brug af repeatere. Figur 2 - viser typisk opsætning af et DMX system
3 Arkitektur Figur 3 Systemoversigt Den overordnede system arkitektur er vist ovenfor på Figur 1. Figur 4 - klasse diagram
4 Hardware design Hardware mæssigt har vi benyttet os af Tahoe-II boardet, en mega32 og en RGB lampe med DMX input. Figur 5 Tahoe-II med simpelt inferface. Tahoe-II boardet er den platform som vi har arbejdet med i WEM forløbet, og derfor var det et naturligt valg for os at benytte den i vores projekt. Desuden er det ganske underholdende at arbejde med et touch display som interface, det har dog også givet grund til nogle designmæssige overvejelser igennem forløbet, og i sidste ende viste det sig at vores touch funktioner var begrænsede. Figur 6 - Tahoe-II Blockdiagram
Vi har forbundet Mega32 eren via SPI bussen på Tahoe-II expansion connector 1 (EXP1). Figur 7 - Tabel over EXP1 pins Vi har benyttet os af følgende pins: SPI-MISO(pin 7) Master in slave out. SPI-MOSI(pin 11) Master out slave in. SPI-SS (pin13) Slave select. SPI-CLK(pin15) Clock. GPIO4(pin21) Benyttes til at genere et interrupt på mega32. Derudover har vi brugt pin 5 som ground. SPI-MISO(pin 7)er forbundet til MISO(pin6) på mega32. SPI-MOSI(pin 11) er forbundet til MOSI(pin7) på mega32. SPI-SS (pin13) er forbundet til SS(pin5) på mega32. SPI-CLK (pin13) er forbundet til SCK(pin8) på mega32. GPIO4(pin21) er forbundet til INT1(pin17) på mega32. GND(pin5) er forbundet til GND(pin11) på mega32.
Figur 8 - Tabel over Mega32 pins Figur 9 - RS232 til RS485 konverter De tre signaler DMX+, DMX- og GND bliver sendt til vores RGB lampe.
4.1 SPI SPI bussen fungere ved at en master, i vores tilfælde Tahoe-II boardet, udsender et signal for at konfigurere den clock frekvens systemet skal køre med. Det skal være en frekvens der er lavere end den max frekvens som diverse tilsluttede slaver kan operere ved. Efter clockfrekvens er blevet sat, vælger masteren hvilken slave den vil kommunikere med. Da vi kun har en enkelt slave i vores system er der ikke andre valgmuligheder end mega32, som modtager et low signal fra Tahoe-II boardet på dens slave select. Slave select er aktiv lav og mega32 er hermed valgt i vores system. Master begynder nu at sende data ud på MOSI linjen og slaven modtager på MOSI, dette forgår med 1bit per clockcycle indtil 8bit er overført. Herefter hentes eventuelle nye data ind i masterens register fra et shiftregister. Der bliver også overført data fra slave til master via MISO pins på begge devices. Vi benytter os dog ikke af denne funktionalitet. Figur 10 - SPI Bussen
5 Software 5.1 Tahoe-II software På tahoe-ii kortet var målet, at man skal være i stand til at afvikle nogle forud bestemte lysshow sekvenser. Hver Sekvens skal indeholder nogle scener som hver i sær, indeholder information omkring scene tid, fade tid, og værdierne på alle DMX kanalerne der bliver brugt. Når en sekvens startes skal hver scene afvikles, og værdierne på DMX outputtet skal tælles op. Da kanalerne i hver sekvens kan have meget forskellige værdier, f.eks. kan kanal 1 gå fra 60 til 128, mens kanal 4 kan gå fra 0 til 255. Selvom der er forskel i differencen mellem de to værdier, så skal det stadig tage samme tid at tælle op eller ned. Derfor startes der en ny tråd til hver kanal som så sørger for at tælle op eller ned, i det rigtige tids interval. 5.2 Tahoe-II software klasser 5.2.1 SequenceDmxController Denne klasse indeholder 4 private medlemsvariabler: private Thread _dmxsenderthread; private SPI _spi; private OutputPort PackageStart; private byte[] Refbytes; Disse initieres i constructoren: public SequenceDmxController(ref byte[] refbytes) Refbytes = refbytes; PackageStart = new OutputPort(Meridian.Pins.GPIO4, false); _dmxsenderthread = new Thread(new ThreadStart(Sender_Routine)); _dmxsenderthread.priority = ThreadPriority.Normal; _spi = new SPI(new SPI.Configuration(Meridian.Pins.SPI_SS, false, 0, 0, false,true, 100, SPI.SPI_module.SPI1)); PackageStart er en output port der bruges til at genere et interrupt på Mega32 lige inden en ny pakke sendes. Det er en meget simpel måde, at få synkroniseret komunikationen mellem de 2 enheder. _spi indeholder et SPI af SPI klassen som bruges til at sende pakken med de 512 DMX kanalværdier over til mega32. Tahoe-II er sat op som master, og mega32 som slave. _dmxsenderthread er tråden der bruges til at sende data i. RefBytes er et byte array som bliver sat til at pege på det byte array som indeholder de bytes der skal sendes. Klassen indeholder derudover 2 public funktioner som bruges til at starte og stoppe _dmxsendertread tråden, samt den private Sender_routine() som kører i tråden.
5.2.2 Sequence Sequence klassen indeholder 4 medlemsvariable : public ArrayList Scenes get; set; public string Name get; private set; private Thread sequencethread; private byte[] refbytes; Disse initieres i constructoren: public sequence(string name, ref byte[] tmpbytes) refbytes = tmpbytes; Scenes = new ArrayList(); Name = name; sequencethread = new Thread(new ThreadStart(RunSequence)); sequencethread.priority = ThreadPriority.Normal; Scenes er en liste som indeholder de scene objecter der skal afvikles i sekvensen. sequencethread er tråden hvori sekvensen afvikles. refbytes er et array der peger på de bytes der bliver sendt af controller klassen. Klassen indeholder 2 public funtkioner til at starte og stoppe sequencethread tråden. Der er en privat finktion som er den funktion der afvikles i tråden: void RunSequence() while (true) foreach (scene scene in Scenes) for (int i = 0; i < scene.channelused; i++) sequencedata tmp = new sequencedata(i, scene.channelvalues[i], ref refbytes, scene.fadetime, scene.snap); ThreadStart starter = delegate worker(tmp); ; Thread t = new Thread(starter) Priority = ThreadPriority.Highest; t.start(); Thread.Sleep(scene.SceneTime); I denne funktionen bliver hver enkelt scene i sekvensen afviklet. Og får hver kanal i scene oprettes der en ny tråd som står for at tælle de enkelte kanaler op og ned. Denne måde at afvikle sekvenser på er en kende ressource krævene, og måske ikke helt optimal til en processor af den størrelse vi har tilrådighed på
tahoeboardet. Vi kan udfra talrige test se at koden bliver afviklet meget langsommere end når vi har testet på en alm pc, hvor koden virkede perfekt. Trådene som bliver oprettet afvikler følgende kode: private void worker(object o) sequencedata sd = (sequencedata)o; if (!sd.snap) //hvis værdierne ikke skal snappe direkte int sleepvalue = 0; int diff = System.Math.Abs(sD.OldBytes[sD.ChannelNumber] - sd.channelvalue); if (diff > 0) sleepvalue = (sd.fadetime - 1000)/diff; int counter = 0; while (counter++ < diff) if (sd.oldbytes[sd.channelnumber] > sd.channelvalue) sd.oldbytes[sd.channelnumber]--; if (sd.oldbytes[sd.channelnumber] < sd.channelvalue) sd.oldbytes[sd.channelnumber]++; Thread.Sleep(sleepValue); Else //hvis værdierne skal snappe direkte over. sd.oldbytes[sd.channelnumber] = (byte)sd.channelvalue; Funktionen får et object med af typen SequenceData. 5.2.3 Scene Scene klassen indeholder data som for hver enkelt scene: public bool Snap get; set; public byte[] ChannelValues get; set; public int SceneTime get; set; public int FadeTime get; set; public int ChannelUsed get; set; 5.2.4 SequenceData SequenceData indeholder næsten samme data som Scene klassen, bortset fra at der er tilføjet en reference til det byte array som der arbejdes på. public bool Snap get; set; public int ChannelNumber get; set; public int ChannelValue get; set; public int FadeTime get; set; public byte[] OldBytes get; set;
5.2.5 Fixture Fixture klassen indeholder data om hver enkelt lampe som bruges af systemet: public string Name get; private set; public byte[] ChannelValues get; set; public int StartAdress get; set; public Fixture(int numberofchannels, string name, int startadress) ChannelValues = numberofchannels > 0? new byte[numberofchannels] : new byte[1]; Name = name; StartAdress = startadress; Det var oprindeligt planen at fixture klassen skulle bruges, når man skulle programmere sine sekvenser og scener. Således at man kunne vælge den lampe man vil ændre på. 5.3 Mega32 software Softwaren der ligger på Mega32 er skrevet i C og compilet med CodeVision. Der er lavet en Spi interrupt rutine som, hver gang der modtages en ny byte, lægger denne ned i et array og tæller en tæller op. Derudover er der implementeret en interrupt rutine som trigger på et eksternt interrupt. Denne rutine nulstiller tælleren. Tahoe-II trigger denne rutine hver gang en ny pakke startes. De 2 vigtigste funktioner er selvfølgelig funktionerne som generer selve DMX signalet: void sendpackaged() int i = 0; TXD = 0; delay_us(breaktime); TXD = 1; delay_us(markafterbreak); sendchar(0x00); for(i = 0;i<512;i++) sendchar(dmx_values[i]); delay_us(interframetime); Disse 2 funktioner bit banger dmx signalet ud på Mega32 s PORTA.0 pin. De er lavet udfra informationerne vi har tilegenet os om DMX timingen. void sendchar(char data) unsigned int i; unsigned char temp; temp = data; #asm ("cli") TXD = 0; delay_us(betweenbits); for(i = 0; i<8;i++) TXD = temp & 0b00000001; temp = temp >> 1; delay_us(betweenbits); TXD = 1; delay_us(betweenbits); TXD = 1; delay_us(betweenbits); #asm ("sei")
6 Diskussion 6.1 Resultater Udsending af signal via SPI til Mega32, og generering af DMX fungerer rigtig godt. Tahoe-II boardet performer rigtig godt, når der ikke er tale om at DMX værdierne skal tælles op eller ned, dvs. at farverne f.eks. kan fade ind mellem hinanden på lampen. Når vi har sat fade tid på de scener vi vil have afviklet, så kører det rigtig langsomt. Men med lidt mere optimering, så vil det nok kunne lykkes. Vi kan via en RGB palet på displayet vælge hvilken farve en lampe skal lyse med. Det fungerer blot ved at man trykker på displayet, på den farve man ønsker lampen skal lyse med. 6.2 Problemer Da vi startede projektet op havde vi en ide om at man skulle kunne betjene flere lamper og scener på én gang. Vi nåede endda så langt at vi fik lavet den første del af et interface til denne løsning: Figur 11 - Interface til opgivet løsning Det viste sig dog at vores forhåbninger til projektet og hvad der var tid til ikke stemte over ens. Desuden havde vi nogle problemer med at ramme tasterne når vores ikoner var så små som det ses på figuren ovenfor. Vores første mål var at få generet et DMX signal direkte fra Tahoe-II boardet på en output pin. Men.net frameworket tillod desværre ikke, at vi kunne skrive vores egen UART. Vi testede også en anden læsning, hvor man benytte den indbyggede UART. Men det kræver at man kan sætte baudraten til en meget lav værdi for at sende det første 88µs break, og så sætte den til 250k lige bagefter. Dette fik.net til at chrashe endnu en gang...
6.3 Forbedringer En ting der helt sikkert skal forbedres i kommende versioner, er den måde som scener med fade tid afvikles. Der skal laves en metode som ikke bruger så mange ressourcer. Der skal også laves et interface så brugeren kan programmere nye scener og sætte dem sammen i sekvenser, samtidig med at DMX signalet bliver sendt ud, således at man kan se hvad man laver. 7 Konklusion Vi kan konkludere at vi ikke har nået alle de ting vi gerne ville have nået, og vi kan også konkludere at vi ikke fik Tahoe-II boardet til at sende DMX signal ud. Til trods for dette, så har vi fået lavet et system som kan afvikle sekvenser med forprogrammerede scener, og sendekanal værdierne ud på SPI bussen. Så med lidt modifikationer under vejs, har vi opnået et resultat vi selv er tilfredse med, og som kan det meste af det vi havde sat os som mål. Vi har undervejs i projektet opnået en stor erfaring i at bruge og programmere en embedded enhed med begrænsede system ressourcer. Det var en stor udfordring, at kode i c# og.net, mens man hele tiden skulle tænke på hvordan systemet ville præstere.