Svenska ElektronikForumet

Hejsan!

Jag söker efter bästa möjliga lösning att uppnå 4st PWM utgångar med 16-bitars upplösning på minsta möjliga utrymme.
Endast DIL-kapslat.

Frågan kan tyckas enkel, men med uppsatta kriterier har det visat sig väldigt svårt.

Lite bakgrund:

Systemet jag använder idag är byggt på endast en enkel 8-pinnars PIC-krets.
Denna krets tar via seriellt gränssnitt emot ett litet paket bestående av ett synktecken följt av värden för tre pwm-kanaler.
Med den inbyggda oscillatorn på 4MHz och utan UART har jag lyckats uppnå ca 200Hz med 8-bitars upplösning.
Hade det inte varit för att kretsen alltid måste vara redo att ta emot data, utan att störa/förändra utsignalerna så mycket som med en enda instruktionscykels fördröjning så hade jag säkert kunnat uppnå högre hastighet och/eller upplösning.

Nu måste jag dock uppnå 12bitars (eller mer) upplösning med ytterligare en kanal.

Funderingar:

Det optimala hade varit om jag kunde hitta en mikrokontroller med max 16 pinnar som kan leverera 4x PWM med 12+ bitars upplösning. Nästan lika bra vore två mikrokontrollers med två utgångar vardera. Tyvärr räcker inte PIC-kretsarnas 10bitar riktigt till...

Alternativt hade jag även kunnat lägga till en extern PWM generator med fyra utgångar (även denna med max 16 pinnar), som då måste gå att styra med I2C eller SPI (med en extern krets har jag näml inte längre plats till mer än en 8-pinnars mcu vilket inte är tillräckligt för en parallel bus)

Slutligen har jag funderat på att ersätta mikrokontrollern med programmerbar logik. Tycker inte att det borde vara så svårt att implementera en 12-bitars timer med fyra komparatorer mot fyra register som latchas in från ett shift-register. Denna i kombination med en liten pic hade varit en utmärkt lösning. Problemet här är att jag är helt novis på programmerbar logik och eftersom det är svårt att hitta information för hemmapularen om tillgängliga kretsar, utvecklingsmiljöer och programmerare så blir det en alltför dyr lösning - ett komplett utvecklingskit lär ju kosta mig en månadslön eller två, men kanske någon här vet bättre?

Alla tips och ideer är hjärtligt välkomna!

16 bitars PWM. D.v.s ett steg om ca 0.0015 % per bit.
Jag tror att många är nyfikna på vad utsignalen ska styra...
Hur ser formatet ut på värderna som kommer via serieinterfacet ?

Beroende på exakt hur PWM-blocken är konstruerade kanske det är möjligt att utöka upplösningen på PWM i en uC med mjukvara? Om du kan uppdatera PWM-värdet exakt en gång per cykel och det är möjligt att uppnå både 0% och 100% duty cycle...

Om du t.ex. vill utöka med två extra bitar så behöver du mata med fyra värden, först 0-2 cykler med 100% duty (beroende på värdet av de högsta bitarna), sen en cykel med duty som motsvarar de lägsta bitarna, och så resterande värden = 0.

Alternativt kan man använda dither för att öka upplösningen, använd de högsta bitarna och lägg till ett "ibland" (beroende på värdet av de lägsta bitarna).

Vet inte om det är genomförbart, har aldrig försökt eller läst om någon som implementerat det...

Skapa PWM är enkelt i programmerbar logik, och det behövs inte någon dyr utrustning. Dock så är DIP och 16 pinnar bara att glömma.

Kanske titta på AVR uC, jag använder oftast någon lite större krets tex atmega168 den ger två st 16bitars PWM så då får det bli dubbla kretsar, just denna har dock alldeles för många ben. Men kanske en Atiny44 skulle passa, en snabb titt verkar ge att även den fixar 2 16bitars PWM, finns i 14 pinnars DIL.

se http://www.atmel.com/dyn/resources/prod ... oc8006.pdf

Vad är det för PIC? Vad finns för hårdvara att tillgå? Finns det någon form av timersystem med capture/compare så kan det användas för seriekommunikationen. 18-pinnars PIC (16F628/16F648) finns iallafall med både UART och timer i hårdvara. Visserligen inte 16 pinnar, men rätt nära.

Jag är också nyfiken på vad du skall ha så jädrans hög upplösning till.

Ett tips är ALTERA....
En EPM240T100 skulle klara jobbet utan problem (max II familjen)
Du kan rita ett schema direkt i utvecklingsmiljön. Det finns färdiga 74xx kretsar
Utvecklingsmiljön är gratis, Programmeraren är billig

XILINX har samma saker, har provat båda men upplever XILINX som mycket långsammare då man
kompilerar....

Swech

sodjan:

Nu har jag visserligen klantat till det lite grann och skrivit 12bitar på vissa ställen, 16 på andra. Jag *behöver* 12bitar. Men 16 är nog troligare att det landar på...

Upplösningen behöver jag för att styra belysningen i mitt hem. Man kanske kan undra hur fanken det är möjligt att man behöver mer än 8-bitar till en lampa =) Jag byggde får något år sedan datorstyrd RGB belysning till vårt vardagsrum med totalt 30watt i LED. Som säkert är bekant uppfattar ögat inte ljusstyrka linjärt, vilket resulterar i att skildnaden mellan 0-1 (8bitar) uppfattas som *enorm* i ett system med denna ljusstyrka medan 254-255 är helt omärkbar. Värdena korrigeras i datorn enligt ögats ljusuppfattningskurva för varje färg för att kompensera men då jag använder systemet för att visualisera musik eller film (a'la philips ambilight - fast i hela rummet) så blir resultatet av tysta partier och mörka scener ett mycket irriterade flimmrande då värdena hoppar mellan 1 och 0 på de tre (rgb) kanalerna. Dessutom har jag flera olika lampor som styrs separat vilket ytterligare spär på denna irriterande effekt.

Efter lite experimenterande för ett tag sedan så kom jag fram till att 10bitar räcker, dock med nöd och näppe. Flimmer uppfattas knappt sålänge man inte tittar direkt på lamporna. Dock får jag färgstick eftersom färgerna inte kan representeras exakt då stegen fortfarande är för stora vi de lägsta ljusstyrkorna.

...nu ska systemet utökas till 120watt med ultraviolett som fjärde kanal för dagljussimulering, partyeffekt, och som lite extra "punch" för lila färger vid filmkikande. Med denna effekt kommer problemet att bli ännu tydligare - varför jag inte alls längre klarar mig med 10bitar. Gissningsvis räcker 12, men för att vara på den säkra sidan och lämna öppet för ytterligare utökning så hade det inte varit fel med 16.

Utrymmeskravet kommer sig utav att jag måste bygga in alltihop i takplafonder där utrymmet är närmast obefintligt.

Formatet på värdena som kommer via serieinterfacet är idag startbit, 24 databitar (8/rgb), stoppbit vid ca 6000bps. Det finns dock inga hinder att ändra varken format eller hastighet. Begränsningen är dock att det måste vara asynkront! Har inte möjlighet att dra in klocksignaler eller flödesreglering.


cyr:

Visst borde det vara möjligt. Kikade nyligen på ett datablad för en 8-bitars PWM-generator som gav en 10bitars pseudo-upplösning genom att alternera värden mellan cyklerna. Det hade kunnat fungerat även här, men förutsättningen är att det är möjligt med hårdvaru/mjukvarulösningen som jag landar på och detta har jag inte bestämt ännu. Ska dock hålla det i tankarna - tack!


gimbal:

ATTiny44 ser faktiskt lovande ut. Dessutom är det på tiden att jag köper hem och börjar leka med AVR's familjer (Har hitentills endast använt PIC-kretsar till mina privata projekt, medan vi kör motorola och zilog på jobb). Tyvärr är den lite större än jag hade hoppats på då jag kommer behöva två stycken - men det är inte omöjligt att det går att lösa!


vfr:

Spelar ingen större roll vilken PIC, sålänge den inte är för stor. Jag har så gott som hela sortimentet utav 8-bitare upp till 16 ben hemma. Väntar just nu på "värstingen" 16F688 från sodjan för dom få tillfällen programminnet inte riktigt räcker till =) Har aldrig funderat över att capture/compare kan användas för seriekommunikation och jag tror inte att jag förstår riktigt hur det ska gå till, men jag skull verkligen uppskatta en förklaring =) Är dock kraftigt begränsad i att jag inte kan använda interrupts, såvida jag inte har PWM i hårdvara eftersom dessa stör mjukvarubaserad PWM för mycket.


Swech:

Tack för tipset! Har själv funderat på denna eftersom vi kör just exakt EPM240T100 i våra produkter på jobb. Därmed har jag också tillgång till programmerare (dock inte utvecklingsmiljön då programmering hyrts in av SAE AB i sthlm). Tyvärr är det inte särskilt aktuellt med ytmonterat när det gäller mina privata projekt. Jag hade hoppats på att någon kände till lite om DIL-kapslad programmerbar logik. Det enda jag hittat som jag möjligtvis (förmodligen inte) skulle kunna klämma in med vaselin är http://www.farnell.com/datasheets/7379.pdf. Deras IDE verkar också vara gratis, programmerare verkar svårare. Några tankar kring denna krets?

OK, så du behöver alltså igentligen inte 2^16 *olika* nivåer utan
kommer att ha en skala med olika steg så att de rellativa stegen blir
mer eller mindre lika. Eller så fixar man det efter själva PWM signalen.
Hur många olika ljustyrkor behöver du, tror du ? Det är tveksamt
om man kan uppfatta så värst många fler steg än 1000...

Att köra ytmonterat som hemmapulare är inget större problem...
Har du tillgång till ALTERAn på jobbet.. så go for it
Har själv etsat ett hemmakort med just EPM240T100 . Gick bra

Swech

P.s. Den som du länkade till... glöm den... den är för klen

Digitalkameror har 12/14-bitars sensorer och ändå har de lägre dynamiskt omfång än ögat. Så jag förstår att mer än 8 bitar behövs.

Jag tror det finns AVRer med två 16-bitars timers med två PWM per timer, en sån borde ju duga.

Bearing, du talar om något helt annat...

Jag tror jag förstår vad det handlar om, men jag kanske inte lyckades förmedla vad jag menade. Jag menade att ögat har mer än 14 "stopp"/"oktaver"/"bitar" dynamiskt omfång. Om ljusstyrkan i dessa LED ska täcka ögats dynamiska omfång och dessutom med flera nivåer per "stopp" tror jag att nära 16 bitar behövs. Jag har själv dimmat LED och tyckt att de mörkaste "stoppen" är grova med 8-bitars PWM.

sodjan:

Exakt så - Jag behöver egentligen inte alls så många bitar. Hade jag lyckats få utsignalen att följa ögats ljusperceptionskurva så tror jag att det hade räckt med 8... kanske 10 bitar. På en skärm duger det ju urmärkt med 256 nivåer per kanal men då pratar vi ju naturligtvis mycket lägre ljusstyrkor. Jag vet att de HDR-skärmar (mycket hög ljusstyrka - prototyper) jag har läst om använder sig utav 16-bitar och jag antar att anledningen är att dom behöver komma runt samma problem där. Jag har läst flera källor som menar att den här "omvandlingen" (linjär->perceptionskurva) utförs i alla skärmar såväl digitala som crt, men hur - ingen aning (har *verkligen* försökt få tag på information kring detta)...

I vilket fall så gör jag det hellre i datorn med högre upplösning i systemet då detta ger mig andra fördelar. Eftersom olika färger uppfattas väldigt olika av ögat måste jag begränsa både den röda och blåa kanalen kraftigt för att få rätt vitbalans. Tidigare har jag gjort detta genom strömbegränsning i sista steget innan dioderna men i det nya systemet vill jag kunna utnyttja samtliga kanaler till max och istället ställa vitbalansen i mitt program på datorn. Bygger jag in omvandlingen i hårdvaran blir det svårare eftersom kurvan bara stämmer då varje kanal på max motsvarar vitt ljus. Konstantströmsdrivarna som sitter som sista steg kan bara ta emot "ren" PWM, altså inte en analog signal. Hade gärna behållt dessa (även om det inte är ett måste) vilket låter svårt om signalen ska "fixas efter PWM'n". En annan fördel med att göra det i datorn är att jag *exakt* kan matcha ögats perceptionskurva (sånär som jag kunnat hitta data för denna). Tyvärr är den varken logaritmisk eller, som den ofta benämns, "inverse-square" utan oregelbunden men log-liknanade. (se http://hyperphysics.phy-astr.gsu.edu/Hb ... perbri.gif). Även om båda log och exp duger så trivs jag bäst med perfektionism om inte för att det märks någon skildnad så bara för att *jag* vet att det är rätt gjort - men åter igen, det är inget måste!

Så om du har ideer (det låter nästan så) så är jag idel öra =)


Swech:

Nej jag vet - har lödat en hel del ytmonterat under åren, fast det handlar inte om lathet - jag äger varken skrivare, uv-box eller etsbad - annars hade jag gärna kört på alteran - speciellt när jag kan få dom gratis! Nej, hos mig byggs allt på experimentkort med fördragna kopparbanor. Jag veeet, det är pinsamt =) Min far pratade i många år om att skaffa sig en mini-cnc vars programvara gärna svalde gerbers och fräste direkt på mönsterkort. Planerna verkar nu nerlagda så det är väl bara att få fingrarna loss och göra en investering... men jag har byggt på likadana kort i 20 år, det är svårt att släppa gamla vanor!

Tack för att du sänkte GAL16V8'n. Då behöver jag inte fundera mer kring den!

Jag är som sagt helt novis på programmerbar logik - har du några tips på var jag kan läsa och lära mig något av språken som passar till alteran? Gärna online, böcker har jag svårt för att... hantera... :F Oavsett om det blir denna lösning eller ej så har jag velat lära mig mer om pld-programmering länge.

Nej, jag har inga ideer, försöker bara förstå vad det faktiska problemt är...
Du sa ju ingenting om vad PWM signalen skulle användas till från början.

Så i princip skulle du kunna få (bara för att ta ett exempel) 1000 (eller 1024)
olika nivåer på den seriella linan som sedan mappas till 1024 olika 16-bitars
värden som då ger den önskade *upplevda* skalan av ljusstyrkor. Ett enkelt
sätt kan vara att bara räkna fram de 1024 värden på en 16-bitars skala
som ger samma rellativa förränding (d.v.s en geometrisk serie till skillnad
mot en aritmetisk serie där skillnaden är konstant).

Om detta sen mappar bra mot ögats ljusskänslighet vet jag inte, men det blir
i alla fall mycket bättre vid just låga nivåer då ju de stora rellativa stegen
ger ett flimmer. Principen är den samma i alla fall.

Sodjan:

Nej, jag gjorde ju inte det. Jag är så van vid att prata med människor där elektronik endast är ett yrke, inte ett intresse. Då är en ingående förklaring oftast både oönskad och överflödig har jag märkt... själv hade jag naturligtvis också velat veta vad det handlar om! =) Kika här för en mer... bildlig beskrivning:

Sådär ser det iofs inte alls ut idag, det där är från min gamla lägenhet. Byggde om systemet en del när vi flyttade ud po lanned - konceptet är ju detsamma och såhär ser det ut idag (takplafonderna, samt bakom duken - dock släckt): http://www.minhembio.com/bilder/bild/?pic_id=254241.jpg

Yes, visst hade man kunnat göra så! Överföringshastigheten till systemet är dock inget problem så att låta en tabellen ligga i processorn vore egentligen onödigt. Låter jag datorn utföra alla beräkningar så ger det mig dessutom möjlighet att laborera med olika kurvor. Vi pratar om tre lampor, med tre kanaler som ska uppdateras max 100ggr/sekund vilket ju utan problem går att pumpa iväg från exempelvis en serieport. Idag är möget usb-anslutet via ett usb chip från ftdi (seriell i/o, samma som sitter i deras rs232/usb donglar) till en centraldosa som "splittar" datan och sänder den vidare simultant (så att uppdatering sker samtidigt) på en utgång för varje lampa. Den totala överföringshastigheten i det nya systemet kommer att landa på ganska exakt 25kbps. Tanken är att köra standard 28.8kbps mot centralenheten.

Eftersom systemet även används för allmänbelysning kommer jag dock ändå tvingas ha en sådan tabell (8 linjär -> 16 perceptionskorrigerad) i centralenheten så att denna ska kunna utföra snygg dimmning utan att datorn är startad.