'Times square' op je bureau

Op 16 juni 2005 21:08:09 schreef Willie Worteltje:
Als je schakelt (PWM) dan krijg je denk ik hele smalle lijntjes Rood Groen Blauw of de andere combinatie's te zien. Misschien dat dit op een afstand wel weer wegvloeit.

Stel dat je een arm hebt van 10 cm, omtrek is dan ~62,8cm, dan zouden in het ergste geval (1 van de 4 aan) de led pulsen (62,8/150/22)*4 = 0,07 cm uit elkaar liggen. Bijna een millimeter dus. Zou je dat nog zien op zeg een meter afstand?

Je zou de pulsen nog wel kunnen shiften per ronde zodat ze gelijkmatiger verdeeld worden maar dat is ook niet zo eenvoudig en of het echt een goed resultaat geeft...

Waar ik ook aan heb gedacht is om de snelheid te 4 voudigen en dan door middel van het ronde nummer toch een soort van PWM toe te passen. Maar ja die snelheid he. Of de RGB LEDs 4x uitvoeren en elk op een kwart zetten, Maar ja dan heb je ook veel hardware en nog dure(RGB leds) ook.

Ik heb wel nog een duitse post ergens gevonden die volgens mij beide methodes noemt, helaas is de site niet erg bereikbaar: http://www.mikrocontroller.net/forum/read-1-193417.html, google cache ( http://66.102.9.104/search?q=cache:eI264HqiACoJ:www.mikrocontroller.ne… ) doet het nog wel redelijk. Daar staat een post van 'Hagen', maar ik kan niet alles van het duits evengoed volgen.

edit: Die site is hopeloos traag, ik copypaste het stuk wel hier:

Re: LEDs dimmen ohne PWM
Autor: Hagen
Datum: 08.06.2005 14:24

analog zum normalen Fernseher würden 50Hz pro LED reichen um ein
stabiles "Leuchten" zu erreichen. Angenommen du kommst auf 200Hz
Wiederholrate dann kannst du die Helligkeit der LED's bildweise
erzeugen. Zb. 4 nachfolgende Bilder ergeben pro LED dann 5
unterschiedliche Helligkeiten. Je nach Helligkeit werden die LED's
also jeweils auf 4 nachfolgende Bilder ein/aus geschaltet. So kommst du
wieder effektiv auf 50Hz Bildrate.

Für meine Clock habe ich einen leicht anderen Weg beschritten, der
ähnlich einer PWM funktioniert. Ich habe 512 Pixelspalten pro Umdrehung
mit 50Hz. Jede Pixelspalte wird gemultiplext in 3 Farben zerlegt, RGB.
Jede dieser Farbspalten wird 312 Takte a 31.25ns angesteuert. Da ich
pro Farbe in einem Pixel 2 Bit an Information habe wandle ich diesen 2
Bit Wert in eine 3 Bit breite Pulssequenz um.

Farbe = Pulse
00 = 000
01 = 010
10 = 101
11 = 111

Das könnte man als PWM bezeichnen wenn man es zb. so kodieren würde:

Farbe = PWM
00 = 000
01 = 100
10 = 110
11 = 111

Um aber ein Flackern zu vermeiden benutze ich eben die erstere
Konvertierung und pulse die LED's je nach Helligkeit.

Bei 32Mhz Pixelspaltentakt und 312 verfügbaren Takten pro Farbspalte
macht das 312/3 = 104 Takte pro LED Impulse/Zeitscheibe = 104 * 32.25ns
= 3.354µs die eine LED Leuchtphase dauert. Das liegt noch absolut im
Bereich der möglichen Pulsfrequenz heutiger LED's. Normale LED's
können ohne Probleme mit bis zu 1 Mhz gepulst werden. Allerdings sollte
man die Kapazität der LED's nicht unberücksichtigt lassen !

Ergo: ich würde dir anraten die LED's per PWM, bzw. genauer gesagt
gepulst, zu betreiben und dann durch das Verhältnis der On/off-Zeiten
die Helligkeit zu regeln.

Elektrisch benutze ich eine Matrix mit 16*12 Zeilen/Spalten, macht 64
RGB LED's. Die 16 Zeilen steuern die RGB LED's mit gemeinsammer
Kathode über eine PNP Konstantstromquelle an. Die 12 Spalten werden
durch N-Channel MOSFETs durchgeschaltet. Diese 12 Spalten sind
gruppiert in 4 * 3 Farben.

Die 512 Pixelspalten werden also pro Sekunde zerlegt in 50 * 512 * 4 *
3 * 104 ~ 32.000.000 Einzelschritte -> ergo Pixeltakt ist 32Mhz. Die
einzelnen 12 Spalten werden nun nach jeder Umdrehung der Clock um einen
Schritt versetzt zeitlich verschoben angesteuert. Das bedeutet das bei
der 1. Umdrehung 3*Rot 3*Grün 3*Blau 3*Dunkel angesteuert wird. Bei der
2. Umdrehung aber 2*Rot 3*Grün 3*Blau 1*Rot 3*Dunkel, bei der 3.
Umdrehung 1*Rot 3*Grün 3*Blau 2*Rot 3*dunkel usw. usw. D.h. die
Farbliche Ansteuerung der Pixel rotiert reihum pro Pixelspalte und
somit wird nach 12 Umdrehungen des Rotors alle anfallenden Farbscheiben
pro Pixel gleichmäßig verteilt. Erreicht wird dies indem im zeitlichen
Takt pro Umdrehung einfach 1 virtuelle Zeitscheibe mehr als nötigt
eingefügt wird.

Wie oben geschrieben dauert eine Farbspalte 3*104 Takte a 32.25ns.
Diese dauer von 104 Takten muß aber nicht für die R,G,B,D Phase immer
gleich sein. Ich benutze 4 globale Variablen die die Anzahl der Takte
pro Farbphase enthalten. Normalerweise eben 104,104,104,104 Takte.
Ändert man das aber zb. in 52,52,52,260 so würden also R,G,B Phasen nur
52 Takte lang sein und die Dunkelphase aber 260 Takte, ergo die
Gesamthelligkeit des Displays ist dunkler. Man kann also über diese 4
Taktanzahlen sowohl die Helligkeit als auch den Farbkontrast des
Displays im Gesammten regulieren.

Insgesamt komme ich so auf 6Bit Farbinformation pro Pixel = 64 Farben.
Ein Pixel belegt somit 1Byte an Speicher. Die restlichen 2 Bits werden
für andere Aufgaben benutzt. Angenommen der Pixel hat den Farbwert von

0b00101101 -> R = 10, G = 11, B = 01 dann sieht die Pulsesequenz so aus
101 111 010, und jeder Puls = Leuchtphase dauert ca. 104 Takte a
32.25ns. Eine Rotor-Umdrehung später würde dieses Pulsmuster um 1 Bit
rotiert angezeigt, also 01 111 010 1, eine Umdrehung später dann 1 111
010 10 usw. usw. Somit wurden nach exakt 12 Umdrehungen des Rotors alle
drei Farben -> rot,grün,blau örtlich pro Pixelspalte gleichmäßig
verteilt angezeigt.

Dein Problem mit dem gepulsten Flackern der LED's, bzw. der
ungleichmäßigen Verteilung der Farbintensitäten pro Pixel wäre damit
dann erledigt, da das menschliche Auge die Summe der Leuchtpulse pro
Pixel von selber glättet.

Gruß Hagen

[Bericht gewijzigd door madwizard op donderdag 16 juni 2005 22:07:26 ]

Hoe werkt de synchronisatie nu? 1 maal per 360 graden worden de leds gesynchroniseerd? Krijg je dan niet een ontzettend verloop aangezien je het overspringen van de leds moet timen?

Een rotary encoder zou hiervoor prima geschikt zijn.

/EDIT: Is het zo dat de toeren van de motor iedere keer bepaald wordt wanneer de diode geschakeld wordt? Op deze manier weet je dan de plek van de led op ieder punt in de tijd. Zoiets?

[Bericht gewijzigd door Xander2K op donderdag 16 juni 2005 22:43:26 ]

Op 16 juni 2005 22:20:16 schreef Xander2K:
Hoe werkt de synchronisatie nu? 1 maal per 360 graden worden de leds gesynchroniseerd? Krijg je dan niet een ontzettend verloop aangezien je het overspringen van de leds moet timen?

Een rotary encoder zou hiervoor prima geschikt zijn.

/EDIT: Is het zo dat de toeren van de motor iedere keer bepaald wordt wanneer de diode geschakeld wordt? Op deze manier weet je dan de plek van de led op ieder punt in de tijd. Zoiets?

Ik denk dat als de motor eenmaal draait deze wel een redelijk vast aantal toeren maakt dus als je gewoon 1 keer per ronde met een lichtsluis oid de timing regelt zal het wel goed gaan.

Wat zou trouwens beter werken voor zo'n ding? Heldere of diffuse LEDs? Als ik zo wat klokken e.d. bekijk lijken de heldere wat feller maar wat minder regelmatig qua helderheid, maar foto's geven niet altijd een goed beeld van dit soort dingen.

Bij futurlec hebben ze redelijk goedkope RGB LEDs zag ik ($0.50) ik heb gevraag wat voor type het is en het is een 4-pin common anode (stond er niet bij).

Op 21 juni 2005 13:32:16 schreef madwizard:
Ik denk dat als de motor eenmaal draait deze wel een redelijk vast aantal toeren maakt dus als je gewoon 1 keer per ronde met een lichtsluis oid de timing regelt zal het wel goed gaan.

Helemaal mee eens. Zo doe ik het ook. Als tie optoert zie ik het plaatje ook steeds breder worden tot maximaal toerental is bereikt.

Op 21 juni 2005 13:32:16 schreef madwizard:
Wat zou trouwens beter werken voor zo'n ding? Heldere of diffuse LEDs? Als ik zo wat klokken e.d. bekijk lijken de heldere wat feller maar wat minder regelmatig qua helderheid, maar foto's geven niet altijd een goed beeld van dit soort dingen.

diffuse LED's. (Denk ik).
En foto en video wordt al snel slecht belicht door het schijneffect van de leds.

Op 21 juni 2005 13:32:16 schreef madwizard:
[...]
Ik denk dat als de motor eenmaal draait deze wel een redelijk vast aantal toeren maakt dus als je gewoon 1 keer per ronde met een lichtsluis oid de timing regelt zal het wel goed gaan.

ja kijk eens bij de klok van Bastiaan Steenbergen, deze werkt ook met een lichtsluis meen ik

Toch nog even geprobeerd te PWM-en met een 16F628 en verbazingwekkend maar toch gelukt 4x RGB leds te dimmen. Met 8 bits aansturing kan ik met 1 pic 4 leds in matrix bedienen 2 bits rood,2 bits blauw, 2 bits groen en 2 bits om de led aan te geven. 30% van de tijd staan de leds altijd uit en zijn dan per kleur in 4 gradaties op te lichten: 0% aan, 23% aan, 47% aan en 70% aan. Dit lukt me al binnen een cyclus van 208 uSec en de 'uit' tijd gebruik ik om data in te lezen.
De controle Pic en Memory moeten echter wel sneller kunnen schakelen: 150 leds (x) X 30 omwentelingen per sec x 32 leds = 6 uSec schakeltijd maximaal! De 18F242 lijkt me trouwens perfect voor deze job: 10MIPS moet voldoende zijn. Of toch niet? Weet iemand een eenvoudige schakeling om deze 18F.. te programmeren. (Net zoals voor de 16F84 en 16F628 hier op de site te vinden is.)

Op 21 juni 2005 17:31:36 schreef Effeen:
De controle Pic en Memory moeten echter wel sneller kunnen schakelen: 150 leds (x) X 30 omwentelingen per sec x 32 leds = 6 uSec schakeltijd maximaal! De 18F242 lijkt me trouwens perfect voor deze job: 10MIPS moet voldoende zijn. Of toch niet?

Zou dit dan met 8 PICs zijn of met 1? Welk ontwerp gebruik je nu?

Op 21 juni 2005 19:03:22 schreef madwizard:
[...]
Zou dit dan met 8 PICs zijn of met 1? Welk ontwerp gebruik je nu?

Idee is nu om 8x 16F628 als leddriver te mis/ge bruiken, dit om continue 4 leds te PWM-en. (Met lookup tabellen kan snelheidswinst gemaakt worden). Inlezen van data gebeurt on the fly met een 29F040 flashgeheugen van AMD. Ontwerp:
(Hopelijk is ie goed zichtbaar)
Iemand een idee of er een simpele programmer te bouwen is voor de 18F242 ?

Op zich heb je dus eigenlijk alleen de 16F628s die heel snel moeten schakelen maar het inlezen van het geheugen hoeft niet zo snel lijkt me, je leest per kolom de nodige gegevens in, en vervolgens worden die gedurende een bepaalde periode gePWM't door de PICs, die paar bytes kunnen ze wel onthouden.

Toch vind ik het nog een hoop (ingewikkelde) hardware voor zoiets, ik denk dat je de 8 PICs wel kunt vervangen door goedkope schuifregisters met wat slimme aansturing (zoals mijn eerdere idee). Die 595s kunnen geloof ik tot 30Mhz geschakeld worden en geheugen kan in enkele honderden ns gelezen worden, dus dat zal de bottleneck niet zijn.

ik zou dat in een gate array stoppen.
je laadt je bitmap in ene ram. de fpga scant de ram en verzorgt de sync met de rotatiesnelheid.
door daar een interleave te zetten kan je dimmen. ( gebruik ene interliniering systeem zoals bij tv. bijvoorbeeld eerst even pixels , bij volgende omwenteling oneven pixels, overder dimmen. is bij eerste toer pixels 1,4,7... tweede toer pixels 2,5,8... derde toer pixels 3,6,9 .. en zo voort.

klein alteratje kan dat.zet daar ene i2c bus op. kan je de data erin schuiven en dan heb je maar 2 contacten nodig voor datatransport.
je kan d eram meesyntetiseren in de fpga.
de scanning logica kan zo gemaakt worden dattie zelfstandg de ram scant.
door de ram start en stoppointers te gaan shiften kan je links - rechts scrollen.

[Bericht gewijzigd door free_electron op dinsdag 21 juni 2005 20:28:59 ]

@free_elektron
In iedergeval boven mijn pet(fpga).

Ik zou voor de RAM een SD card of MMC card nemen(SPI interface). Goed verkrijgbaar in grote geheugens(256MB) en tot 20x sneller als een i2c.

@Effeen
Ik denk dat de simpele pic programmer icm ic-prog het wel kan. In versie 1.05D staat de 18F242 er tussen.

Op 21 juni 2005 23:08:09 schreef Willie Worteltje:

Ik zou voor de RAM een SD card of MMC card nemen(SPI interface). Goed verkrijgbaar in grote geheugens(256MB) en tot 20x sneller als een i2c.

@Effeen
Ik denk dat de simpele pic programmer icm ic-prog het wel kan. In versie 1.05D staat de 18F242 er tussen.

Ik zag dat je in het Magic Ball ontwerp ook gebruik maakt van SD. Ben benieuwd of je de SPI interface redelijk eenvoudig kan opbouwen met een stukje pic software. (Adressering serieel scheelt enorm veel IO poorten)
Volgens mij kun je deze geheugens ook razendsnel serieel uitlezen als ik mij niet vergis.

Op 21 juni 2005 23:16:29 schreef Effeen:
[...]

Ik zag dat je in het Magic Ball ontwerp ook gebruik maakt van SD. Ben benieuwd of je de SPI interface redelijk eenvoudig kan opbouwen met een stukje pic software. (Adressering serieel scheelt enorm veel IO poorten)
Volgens mij kun je deze geheugens ook razendsnel serieel uitlezen als ik mij niet vergis.

SPI is nog veel simpeler als I2C(bidirectioneel) als je het op een software manier wilt schrijven. Sommige uC hebben hardware i2c. Dan heb je daar geen zorgen over.

Ik gebruik een MMC(7 pins). SPI interface kan tot 20Mhz. Met pic op 20Mhz. draai je 5MIPS en kan je maximaal 2,5Mhz halen. Hoog/laag zijn 2 instructies.

Ik ben benieuwd of de PWM zich goed houdt bij hoge rotatie snelheden. De schakeltijden moeten erg kort zijn, anders ga je kleurstreepjes krijgen.

Op 21 juni 2005 23:25:13 schreef Willie Worteltje:
[...]

SPI is nog veel simpeler als I2C(bidirectioneel) als je het op een software manier wilt schrijven. Sommige uC hebben hardware i2c. Dan heb je daar geen zorgen over.

Ik gebruik een MMC(7 pins). SPI interface kan tot 20Mhz. Met pic op 20Mhz. draai je 5MIPS en kan je maximaal 2,5Mhz halen. Hoog/laag zijn 2 instructies.

Ik ben benieuwd of de PWM zich goed houdt bij hoge rotatie snelheden. De schakeltijden moeten erg kort zijn, anders ga je kleurstreepjes krijgen.

Ik ben net klaar met de software voor de PIC controllers. De PWM gaat fantastisch op hoge snelheden. Dit komt doordat de kleuren in 1 klokpuls geschakeld worden.
Middels een Tabel worden de kleurwaarden 1 op 1 vertaald naar Poortwaarden. Simpeler en sneller kan volgens mij niet. Wel zit er tijdsverschil in PWM en dat kan in het ergste geval wel zichtbaar worden. Door de rotatiesnelheid en het random oproepen van de dutycycleroutines verwacht ik in de praktijk weinig problemen. Maar je heb gelijk, eerst zien!

Ik zat naar het PIC-RGB-PWM schema te kijken. Je stuurt de 12 leds aan met een 4x3 matrix. Klopt het dat de leds een aan/uit verhouding van 1 op 4 hebben? Hierdoor verlies je misschien veel lichtsterkte.

Op 21 juni 2005 23:53:56 schreef Willie Worteltje:
Ik zat naar het PIC-RGB-PWM schema te kijken. Je stuurt de 12 leds aan met een 4x3 matrix. Klopt het dat de leds een aan/uit verhouding van 1 op 4 hebben? Hierdoor verlies je misschien veel lichtsterkte.

Geweldige site heb je trouwens, dit heeft me al aardig op weg geholpen. Klopt. In theorie verlies je redelijk wat lichtsterkte. Echter zijn de leds dermate fel dat je er niet rechtreeks in mag kijken binnen een meter (8000mcd).
Sterker nog, om een beter dimeffect te krijgen zet ik direct na het aanzetten van Led, met eerstvolgend commando de poort weer uit. Ik zal proberen een foto te posten.

Op 21 juni 2005 23:43:43 schreef Effeen:
De PWM gaat fantastisch op hoge snelheden. Dit komt doordat de kleuren in 1 klokpuls geschakeld worden.

Maar je heb gelijk, eerst zien!

Heb je PWM nou ook al in rotatie getest of gewoon stilstaand? Ik ben ook wel benieuwd of PWM werkt in rotatie. Voordeel van die PICs is dat het idd binnen 1 clockcycle gebeurt, met schuifregisters ben je al minstens een factor 8 trager.

Als je het een beetje werkend hebt en het is niet te veel werk, zou je dan eens de PICs een factor 10 langzamer willen laten schakelen (met een delay tussen de outputs oid) om te kijken of je dan idd lijntjes krijgt?

@Willie Worteltje:
Wat ik me nog afvroeg over jouw RGB project is dat je op je site hebt staan dat de 595 de stroom begrenst op 35mA. Nou is dit idd de maximum stroom maar mag je ook zomaar aannemen dat dit begrenst wordt? Ik kon hier niets over vinden in het datasheet en sommige ICs fikken gewoon door als je teveel stroom trekt. En is 35mA niet wat veel voor die LEDs? De RGB LEDs die ik tegengekomen ben hebben een max van 20 meestal. Als laatste nog: waar heb je die SD/MMC connector vandaan?

Je hebt gelijk. Ik heb dit ook gegokt uit ervaringen met andere IC's waarbij er niet meer stroom loopt als de max uit de datasheet. Dus ik heb geluk dat de IC's niet uitfikken. Maar het scheelt wel 96 weerstandjes plaatsen. De 35ma is wel teveel maar ervan uitgaande dat de led meer uit is als aan, heb ik ook bewust dit risico genomen. De gemiddelde stroomopname per led ligt ruim onder de 20mA.

Op 25 juni 2005 10:54:20 schreef Willie Worteltje:
Je hebt gelijk. Ik heb dit ook gegokt uit ervaringen met andere IC's waarbij er niet meer stroom loopt als de max uit de datasheet. Dus ik heb geluk dat de IC's niet uitfikken.

Hoeveel chips heb jij al opgeblazen ? Want volgens mij is dit een kwestie van puur geluk. Als ik een 1A diode zoals de 1N4007 op een 12 V auto accu aansluit loopt er echt niet 1A maar heb ik een kapotte diode. En behalve onderdelen waarbij aangegeven dat de waarde begrensd wordt, zoals bij regulatoren, is het toch echt de waarde waarboven ze stuk gaan. (OK, d'r zit altijd wat marge, maar begrenzen is wat anders dan een "max" specificatie). Zo heb ik nog wel een piccie liggen waarbij 2 pinnetjes het niet meer doen

Met de 16F84 kwam ik er achter dat deze een interne weerstand heeft van 100Ohm. De spanning over de led daalt voldoende om te begrenzen op 30mA. (zelfs 2 leds parallel gezet om het lot helemaal te tarten!)
Ook ik hang mijn Leds dus direct achter de PIC uitgang en tot noch toe geen enkel probleem.

@ Jowi
0 chips opgeblazen. Dus het gaat gewoon goed.

@Effeen
Dit doe ik ook met LED's op de 16F628. Geen problemen.

De bouw gaat lekker. 2 plexiglas kokers geregeld, ledjes gemonteerd. Op gaatjesprint dit ontwerp bouwen is eenvoudig maar een enorme klus! De 628's geprogt als Led controllers en getest. Inlezen van kleurdata zal per pic om en om moeten gebeuren, om de 6 uSec (6 klokpulsen) zal de data ingelezen moeten zijn nl. Mocht je interesse hebben de code ff te reviewen en wellicht wat te optimaliseren graag!! Laat ff weten dan post ik het.
Als controller gebruik ik een 18F242 welke volgens specs tot 40Mhz geklokt zou moeten kunnen worden. Echter hierover is niet terug te vinden in de datasheets bij de oscillatorconfiguratie (-hmm-). Heeft iemand ervaring met deze 18F242 op 40 Mhz ?

Op 25 juni 2005 23:50:46 schreef Effeen:
Als controller gebruik ik een 18F242 welke volgens specs tot 40Mhz geklokt zou moeten kunnen worden. Echter hierover is niet terug te vinden in de datasheets bij de oscillatorconfiguratie (-hmm-). Heeft iemand ervaring met deze 18F242 op 40 Mhz ?

Heb verder geen ervaring met PICs (alleen AVRs) maar volgens mij staan bij de AC (Timing) characteristics wel maximale clockrates voor de verschillende oscillatoren.

@Willie Worteltje:
Ik denk dat ik er dan maar gewoon weerstanden bij doe, op zich werkt het waarschijnlijk wel maar voor de zekerheid. Wat ik ook nog vroeg (waar je misschien overheen gelezen hebt) is waar je die MMC/SD connector vandaan had?

Ook zit ik nog een beetje met de voeding, met 16 leds zit je al op 16x3x20mA=960mA, plus wat er nog bij komt voor de ICs en controller. Een 7805 gaat dan wel een hoop van je voeding verstoken dus een wat efficientere switcher zoals de LM2576 oid leek me wel een idee, alleen het vinden/maken van de benodigde spoel daarvoor staat me een beetje tegen (heb daar ook weinig ervaring mee).

Op 25 juni 2005 23:50:46 schreef Effeen:
Als controller gebruik ik een 18F242 welke volgens specs tot 40Mhz geklokt zou moeten kunnen worden. Echter hierover is niet terug te vinden in de datasheets bij de oscillatorconfiguratie (-hmm-). Heeft iemand ervaring met deze 18F242 op 40 Mhz ?

Dan zou ik nog maar even goed in het datasheet kijken. Je gebruikt de HSPLL * 4 oscillator optie met een 10 MHz kristal. Hij draait dan op 40 MHz. Ik gebruik de 18F252 (broertje met meer geheugen) en met een 12 MHz kristal (48 MHz) gaat het ook nog goed.
edit: Met 48 MHz doet ie precies 12 MIPS, anders werd mijn timing zo'n rekenwerk...