DMX512 interface (rs485/422, usb, gpio)

[tlvb]

Har roat mig lite med att planera ett kort för att kunna styra DMX512-enheter
(i stort sett scenbelysning). Alternativt kan kortet sättas som lyssnare och
styras.

På kortet sitter en atmega164 som spindeln i nätet med diverse io-pinnar utdragna
så att de kan kopplas in till vad man nu vill koppla in dem till...
mikrokontrollerns två usarts är kopplade till en FT232RL för usb-interface mot en dator
respektive en MAX491 mot DMX-bussen. Kopplingen mot DMX är isolerad med en
Si8641 och drivspänningen isolerad med en nätt DC/DC-omvandlare (Recom 0505 S/H).

Rent generellt skulle kortet kunna användas då man behöver ett datorinterface mot
en rs485/rs422 buss/enhet, eller ett antal digitala i/o som kontrolleras via usb/rs485/422.

Schema:

Kort ovanifrån:

Underifrån:

projektsida

[superx]

Ser intressant ut! Det här tänker jag följa.

Har skissat på en liknande grej, men tänkte då kunna använda den för att antingen konvertera MIDI till DMX, eller köra USB till DMX. Tänkte koppla USB direkt till AVR:en med V-USB http://www.obdev.at/products/vusb/index.html

Har själv ritat in optokopplare för isoleringen, men den där Si-kretsen ser ut att vara ett bra alternativ!

[MiaM]

Bonusfråga: kan inte en såndär FTDI-krets skrämmas upp till 250000bps rakt av?
(Visst, det blir en tråkigare DMX-sändare som kräver konstant data från datorn och att datorn själv har hygglig koll på timingen)


(Det här med DMX var mycket enklare på Amigatiden, det var bara att nivåkonvertera RS232->RS485 och ställa inbyggda UART'en till 250000bps och köra... Synd dock att sändningen i princip var tvunget att göra i en busy-wait-loop som tog så mycket tid att man helst bara sände så många tecken man verkligen behövde, d.v.s. man skickade bara 100 istället för 512 kanaler om man inte behövde fler kanaler... Å andra sidan vill man väl egentligen ändå inte sända alla 512 kanalerna för om jag inte minns fel så kan man då inte sända oftare än typ 48 gånger per sekund och ska man styra dimmers är 50 gånger per sekund en bra idé)

[tlvb]

MiaM: Anledningen till att jag inte vill skrika ut dmx-signalerna direkt från ft232-kretsen beror på
1) Jag vill ha möjlighet att använda kortet till andra grejer än strikt dator<->dmx och
2) Jag vill kunna köra dmx-kommunikationen på lite hårdare realtids-manér än vad man
generellt garanterar med usb-seriell-adaptrar och vanliga skrivbordsoperativsystem.

...ja och så då nr 3) Jag har roligare om det sitter en microcontroller på som jag kan pilla med.

[esrange]

MiaM: Att köra direkt ut från en dator idag belastar datorn lite väl mycket med bara DMX-kommunikationen, det finns företag som säljer produkter som är utformade så men de fungerar allt annat än bra när datorn måste jobba på med att trycka ut DMX hela tiden, det är också väldigt farligt, vad händer om datorn hänger sig? Då slutar den ju skicka DMX.

Att separera ut hanteringen av DMX-sidan till något annat än datorn är det man vill för att få bra stabilitet och bra stabilitet kombinerat med hög tillförlitlighet är ett måste på utrustning av det här slaget.

[MiaM]

Det är väl antagligen rätt olika hur hårt olika serieportar lastar datorn. Lite off-topic men jag minns att när man körde 230400bps, eller om det till och med var 460800bps, på comtrols rocketport på en pentium-II 400MHz, så gick det fint att köra fyra portar samtidigt men när man började mata ut data för fullt på den femte så drog drivrutinen plötsligt massor av cpu-kraft varpå hela datorn blev superseg. (Det kan ju ha varit nåt med drivrutinen åxå, det var på NT4-tiden, W2000 hade väl precis börjat komma men kördes inte på stället jag minns detta från).


Bonusfråga: hur brukar komersiella DMX-mottagare reagera om signalen dör? Det enda jag gjort med DMX var med hembyggda mottagare, med 8051(-kompatibla) mikrokontrollers, och där la vi inte in nån speciell hantering av signalbortfall utan behöll bara senast mottagna data i all evighet. (Dessutom tror jag inte vi orkade fixa nån reset-rensning heller, däremot hade hårdvaran i sig uppstartsfördröjning såpass lång att mikrokontrollern garanterat hunnit starta och ta emot data innan hårdvaran tillät några styrsignaler att faktiskt gå vidare till det som skulle styras).


Jag håller helt med om att det är roligare med en mikrokontroller mellan, speciellt på dagens moderna OS som faktiskt är sämre till sånthär än t.ex. hur Amigan var, vars OS i stort sett var ett realtids-OS så när som på att Commodore inte specade några garanterade tider (eftersom de berodde på vad man körde för mjukvaror och skillnader mellan OS-versionerna).

[esrange]

En bra produkt håller senast mottagna värde på den specifika kanalen om den tappar kommunikationen, däremot är långt från alla produkter på marknaden bra vilket både jag och tlvb har sett vid ett antal tillfällen där allt bara dör om kommunikationen försvinner.

Ser fram emot att se ett färdigt kort och testa vad det går för.

[tlvb]

Layouten med några silkscreenjusteringar är nu skickad på tillverkning och komponenter anlände för cirkus en vecka sedan.

[tlvb]

Första kortet byggt och konstaterat vid liv:




Edit: Håller på att skriva lite blandade testprogram för att kontrollera att allt sitter ihop som det ska och beter sig som jag planerade, inga överraskningar än så länge i alla fall.

...Och lysdioderna lyser lagom starkt—jag minns ett kort jag sommarjobbade på där statuslysdioderna som vi beställde var så bländande att man hade problem att se vilken som lös, i fullt dagsljus...

uppdatering:
...Jaha, där rök visst strömmen till servern i tio minuter, och datorn startar inte automatiskt efter det, så ni får klara er utan bilderna så länge...

[tlvb]

Nu kan man kanske säga att det har hänt lite saker;
Jag har kommit ganska långt på de olika delmomenten,
knappar och lysdioder har fått vettiga kod-interface och
kanske viktigare, interfacet mot usb är byggt och kör i
1.25Mbd med rts/cts flödeskontroll och ringbuffrar i
båda riktningarna.
Att se att jag skickade ut rätt saker på DMX-sidan vart
lite svårare, så jag byggde ett andra kort och skrev
en assemblerloop som mycket exakt samplar ingången
var 40:e klockcykel, trycker in denna bit i ena änden på
en byte och efter åtta samples skickar ut byten på
usb, så att datorn kan spara en dump som sen kan
plottas. Efter vissa missöden ser signalen i plottarna
(plotten) ganska lovande ut, jag har grovt lokaliserat
starten av varje paket genom att detektera SFB, klippt
ut paketen och tagit medelvärdet för att sedan exportera
till och plotta i gnuplot:

dmx_annotated.jpg

Att göra nu är att hitta på ett lämpligt protokoll för att styra
vad som skickas ut, implementera och testa att detta fungerar,
och skriva något lämpligt program att styra med på datorsidan.
Inte så "bara", har inte jobbat mycket med användarinterface
tidigare...

[esrange]

Ser ju väldigt fint ut för att kunna testa på riktigt sen i höst med lite riktiga prylar.
Vad är det för skärm i bakgrunden som visar trafiken? Känner inte igen den.

[tlvb]

Esrange:
Det är en halvkass plattv med vga-ingång, har ju suttit och byggt hemma
hos föräldrarna i sommar och hade redan tillräckligt att bära på med
lödutrustning och komponenter för att det inte skulle vara särskilt attraktivt
att släpa med en skärm och dator också.

Uppdatering av projektet då:
Har sedan sist suttit och knappat ihop lite gui-kod, fy katten vad
omständigt om man ska göra det ordentligt, och det har jag
antagligen inte gjort heller. Men jag har för närvarande kod
klarar av att rita upp knappar och reglar och ett händelse-system
som ser till att rätt knapp får veta när muspekaren glider över,
klickar och så vidare. Man kan dessutom registrera godtyckliga
tangenttryckningar som intressanta för att antingen knyta som en
"hotkey" till en viss grafisk knapp, eller till en annan kodsnutt.

Det jag avslutade kvällen (natten) med var att programmera ett litet
enkanals ljusbord med tillhörande styrd belysning, det vill säga
jag kan nu justera en regel på skärmen och få en lysdiodstapel
på kortet (nåja, i den mån tre lysdioder är en stapel) att motsvara
rörelsen.

[tlvb]

Ytterligare en uppdatering:
Idag har jag skrivit lite kod för att avkoda inkommande dmx-signaler,
så nu kan jag sitta och knappa på det virtuella ljusbordet, skicka ut
kanaldata till ena kortet, omvandla till dmx, skicka dmx-signalen
till andra kortet omvandla tillbaka, skicka in i datorn igen och se
kanalvärdena dumpas i terminalfönstret bredvid ljusbordet.
(Warum etwas einfach machen... som man säger)

...Alternativt så har jag uppfunnit och implementerat ett helt eget
protokoll, jag har ju för tillfället inte tillgång till någon pryl som
garanterat pratar dmx som jag kan verifiera mot.

[superx]

Inspirerad av det här projektet så ändrade jag lite på mitt kort också, för att använd SI-isolatorn istället för en optokopplare. Kortet är nu färdigbyggt och verkar funka, så jag får tacka för inspirationen! Har inte testat det än med någon riktig DMX-mottagare, men vågformen ser bra ut, och så enkelt som protokollet är så borde det ju funka när det ser rätt ut. Bifogar en bild på kortet också, som alltså konverterar MIDI Controller Change till DMX. MIDI-aktiviteten visas per controller (de 16 lägsta) på 16 lysdioder.

Nu tar det enbart ström från USB-kontakten, men tanken är att man ska kunna använda samma kort för ett USB-DMX-interface också, men det har jag inget behov av för tillfället, så den mjukvaran har jag inte orkat skriva än.

[tlvb]

Nice kort, hur lödde du U5? Jag funderade på att strömförsörja allt via USB, men jag fick intrycket att man måste klara av power-down och jag tror att mitt kort äter för mycket.

Kopplade för övrigt in mitt eget kort till en liten sexkanalig dimmer, jag hade inte tid att pressa den, men kunde i alla fall blinka lite och konstatera att jag verkar ha lyckats implementera protokollet korrekt.

Jag upptäckte också tidigare vid test av kort-dator-kommunikationen att linux då och då tappade anslutningen (/dev/ttyUSB0 försvann och jag fick plugga ur och in enheten igen) det verkar mest ha hänt när jag använde python+pyserial och inte C och ioctl/tcsetattr, men det kan skevas av att jag skrivit mer testkod i python.
Hur som helst verkar problemen ha minskat efter att jag sänkte kommunikationshastigheten från 1.25Mb/s till 250kb/s vilket gör att den teoretiskt maximala uppdateringshastigheten blir lite drygt halva dmx-hastigheten (datorn skickar två bytes: kanal/värde, men dmx använder dubbla stoppbitar och byten i början av paketen är alltid 0x00).