Svenska ElektronikForumet

U5 är alltså en ATMega88 i MLF(QFN)-kapsel. Jag ville testa hur knepigt det var att löda dessa, och gjorde samtidigt ett DMX-mottagarkort med två buck-LED-drivare, och där var det mer ont om plats.

Jag värmde kortet på en spisplatta och värmde bäst jag kunde med lödkolv på jordpinnarna för att få lodet under kapseln att smälta. Det var inte så svårt, men opraktiskt. Ska testa med en varmluftspistol nästa gång. Lodet på benen var lätt att få dit med lite bra flussmedel. Jag hade tänkt att exponera en jordyta på baksidan av kortet med lite vior upp till ovansidor, så man kunde värma på undersidan med lödkolven, men glömde helt enkelt lägga dit stoppmask.

Det stämmer att man inte får dra mycket ström i powerdown-läget i USB. Jag har valt en regulator med väldigt låg egenförbrukning av den anledningen, men nu använder jag en vanlig USB-laddare och då spelar det ingen roll. Jag tror man kan skippa den delen av USB-specen också, och klara sig rätt bra ändå om man inte tänkte sälja prylen på riktigt.

Hur skiljer du på kanal-byten och värde-byten i kommunikationen till kortet förresten?

Jo, det finns ju ganska gott om usb-fläktar muggvärmare och så vidare,
så det är ju möjligt att powerdown-läget inte påtvingas med full kraft i
annat fall än om det är nödvändigt. Jag kände helt enkelt att jag kan för
lite om detta och brukar försöka designa från ett utifallatt-perspektiv
ända sedan jag läste den där EMC-kursen. Hittade ett designdokument
från atmel där de rekommenderade en avkopplingskondensator per
matningspinne, dvs en per sida på tqfn-kapseln—istället för en per chip som jag lärt mig som tumregel—men då hade jag ju
så klart hunnit beställa kort...

---

Protokollet för datorn är hittils enklaste möjliga, när kortet startas lägger
det sig i initialläge och väntar på att en stor hög av X skickas, när tillräckligt
många har skickats ignorerar den allt tills en enda Y har skickats.
(X och Y är bestämda bytes med värden > antalet implementerade kanaler
och kan alltså inte förväxlas med kanaladresseringar senare.)
Efter det anses enheten vara synkroniserad och eventuellt skräp som
kanske registrerats på usarten under boot vara borta. Efterföljande
kommunikation är bara par med byte0 = kanal, byte1 = värde.

Skulle man skicka en oimplementerad kanal (f.n. 64 kanaler tror jag) så ställer
den sig i initialläge igen. Kanske lite dumt, eftersom ingen data
skickas från kortet till datorn och detta det är en av de saker som finns
på den något diffusa att-göra-listan.

---

dmx512: 250k 8N2, 1 statisk start-byte, 64 kanaler implementerade
dator: 250k 8N1, 64 kanaler = 64 lampor att addressera

Om jag tänkt rätt nu innebär detta att jag (idealt) kan skicka 1+1/64 bit
extra-information per lamp-data-byte. Alltså kan jag implementera
8st en-bytes-kommandon som uppdaterar lamporna i grupper om åtta
(kommando-byte, lampa0, lampa1, ... lampa7) och i värsta fall uppdatera
hela lampuppsättningen på det sättet och ändå vara klar innan ett helt
DMX-paket har skickats ut—och då har jag inte ens tagit med tiderna för
space for break och mark after break.

dmx-paket: (1+64)*8N2 = 650b
fullständig uppdatering i block om 8: 8*(1+8)*8N1 = 648b

Om man vill uppdatera alla lampor är det ju förstås rimligt att använda
kommandot för att uppdatera i block om 64 ((1+64)*8N1 = 585b).

Alla dessa beräkningar utgår så klart från att allt funkar som det ska och det
aldrig är något annat än kommunikationshastigheten som flaskhalsar.

superx skrev:Hur skiljer du på kanal-byten och värde-byten i kommunikationen till kortet förresten?

Frågan var inte ställd till mig men jag passar på att lägga näsan i blöt genom att komma med ett förslag:

Med 512 kanaler och 256 datavärden så blir det ändå mer än två bytes, och om man inte ska krångla med att betrakta datat som en bitström så blir det tre byte för att skicka över totalt 17 bitar, alltså 7 bitar kvar.

Då skulle man kunna ha ett enkelt protokoll där de två översta bitarna i varje byte säger vilken byte i ett "paket" som skickas, och de 6 lägre bitarna är data.

Alltså ungefär såhär

MSB...LSB:

0,0,d5,d4,d3,d2,d1,d0
0,1,k5,k4,k3,k2,k1,k0
1,0,0,k8,k7,k6,d7,d6

d0-d7 = databitarna, k0-k8 = kanalnummer. Fördelen med att skicka bit 0-5 i varsin byte är att man slipper åtminstone skifta de två byte'arna.

Lediga kombinationer blir då:
1,1,x,x,x,x,x,x
1,0,1,x,x,x,x,x

Förslagsvis kan en av dessa användas för reset+initialisering av antal aktiva kanaler, till exempel såhär:
0,1,k5,k4,k3,k2,k1,k0
1,0,1,k8,k7,k6,0,0
(de två sista nollorna i första byten kan innehålla valfri annan data). Den här instruktionen bör väl för övrigt för enkelhets skull bara ställa in antal kanaler som sänds, den behöver inte nollställa sänd data och dessutom är det kanske bäst att tillåta uppdatering av kanaldata för kanaler med högre nummer än vad som faktiskt sänds. Då kan man vid en reset skicka över att "noll kanaler" ska sändas, sen fylla i data för alla kanaler man vill köra, och sist skicka över kommandot som väljer antal sända kanaler. På så vis behövs inte så mycket kod i mikrokontrollern men man kan ändå göra en kontrollerad reset/uppstart. Det enda som behövs i mikrokontrollern är något som helt slår av sändningen om man ställer antal kanaler till 0, antar att det kanske inte är helt bra att bara skicka en break ideligen utan att faktiskt skicka data på DMX'en...

Ett tips här förresten är väl att kanske sända några fler kanaler än vad som faktiskt ska tas emot. Jag minns att jag för länge sen var med om att skriva en DMX-mottagargrej med en 8051-kompatibel mikrokontroller och vi sparade en del kod (både storlek och hastighet, tror jag) genom att "fuska" och använda kanalnummerräknaren som statemachine, och det fanns states efter att alla kanaler tagits emot av mikrokontrollern. Det behövdes alltså skickas några extra kanaler (med valfri data) efter sista kanalen som den burken "egentligen" lyssnade på. (Jag minns inte helt säkert men tror också att kanalräknaren agerade pekare för var i minnet data skulle skrivas vid mottagning, och delvis därför var det lite oväntade värden som den räknade mellan).

Mottagningen av data görs förslagsvis så att varje byte som tas emot avkodas och mottagna bit'ar skickas in i en 9-bitars kanalvariabel och en 8-bitars datavariabel, och när en "kommandobyte" (1,0,x,x,x,x,x,x) tagits emot så skrivs först dess bitar in i variablerna och därefter utförs själva kommandot.

Då kan man dessutom lägga in viss komprimering i utsändningen från datorn, varje gång flera kanaler ska uppdateras men d0-d5 är lika för flera kanaler så kan man skippa den byte som innerhåller 0,0,d5...d0. Detta hanteras då helt i den sändande datorn, ingen extra kod behövs i DMX-interfacet. Ja, givetvis kan ju datorns sändarkod hålla reda på att inte uppdatera sådant som inte behöver uppdateras.

P.S. nån som har koll på de mikrokontrollers ni använder kan säkert säga nåt bra om vad som är optimala sättet att skicka in datat. Det kanske finns instruktioner för att byta plats på övre och nedre halvan av bitarna i en byte och som tar mindre tid att köra än skiftning/rotering ett par steg. Eller så finns det inte det.