'Times square' op je bureau

Hallo allemaal, al een tijdje worstel ik met een idee die maar niet uit mijn soldeerbout kan komen:
Een roterend display op een doorzichtige cylinder met RGB-leds. Naief als ik was dacht ik dat zoiets nog niet bestond en praktisch onmogelijk te bouwen te zijn. Indrukwekkend is de 'Magic Ball' op deze link: http://home.versatel.nl/edithenwilliam/william.htm
Idee is om dergelijk project te bouwen met de mogelijkheid om de hele cylinder te gebruiken als display met >=256 kleuren. Eerste idee is dat dit bestaat uit een RS232 interface (voor de programmering), controller (PIC16F628), geheugen (fictief ongeveer 150 leds breed, 32 hoog= ongeveer 48kbyte per frame. > 4Mb totaal lijkt me wel nodig) en RGB leds (32 lijkt wel voldoende) op een cylinder van plexiglas.
Voedingsspanning van het draaiende display+sturing kan deels via de motor (-) en via een lager op de bovenzijde (+) doorgegeven worden.
De frames kunnen zichzelf herhalen of naar elkaar 'verwijzen' door middel van een extra paar bytes.

Hebben jullie een idee wat voor geheugen het best gebruikt zou kunnen worden en hoe deze te adresseren met een PIC?

Het idee met schuifregisters is volgens mij onvermijdelijk zoals William in zijn project gedaan heeft. Of is hiervoor niet een kant een klaar IC te krijgen (aansturen van meerdere RGB-Leds wellicht dmv PWM aansturing.)

Ideeen..........Graag!

Het gaat volgens mij niet lukken om PWM te combineren met
het ronddraaiende concept. Je hebt voor elke positie op de cylinder een "virtuele" led, geen echte led! (Dus een LED is aan of uit)
Je geheugenberekening klopt volgens mij niet: per frame 32 * 150 = 4.8 kilobit, voor RGB dus 14.4 kilobit, 1800 bytes.
Dus hoe kom je aan 48 kilobit ?

Tenzij je pwm't op een zeer hoge frequentie, minstens een tiental kilohertz. Maar dat wordt softwarematig al zeer moeilijk en onmogelijk met schuifregisters.

Rotatiesnelheid is ongeveer 30omw/sec * 150 leds = 4500 x schakelen per seconde bij aan/uit. Dat betekent een schakeltijd van 220 uS. Da's inderdaad krap om rechtstreeks te schakelen uit een 16F628. Zeker als je uitgaat van PWM. Iemand een idee of er een pic op de markt is die per cyclus sneller schakelt dan 1us? Het is mij uit de datasheet niet helemaal duidelijk of de 20Mhz versie nu aanzienlijk sneller schakelt.

Op 7 juni 2005 21:54:14 schreef JoWi:
Het gaat volgens mij niet lukken om PWM te combineren met
het ronddraaiende concept. Je hebt voor elke positie op de cylinder een "virtuele" led, geen echte led! (Dus een LED is aan of uit)
Je geheugenberekening klopt volgens mij niet: per frame 32 * 150 = 4.8 kilobit, voor RGB dus 14.4 kilobit, 1800 bytes.
Dus hoe kom je aan 48 kilobit ?

Idee was: 32*150 Leds = 4.8 kbyte. Als je uitgaat van 1 byte per kleur (256 kleuren). Voor 8byte per kleur (in theorie 16,7miljoen kleuren) ben je inderdaad 14.4Kbyte kwijt per frame.

Zoals je uitgerekend hebt brandt een "virtuele" led op een positie slechts 1/150 van de totale tijd, die tijd is 220 microseconden.
Dus het plaatje wordt al zwak !!! Denk eraan dat de lichtopbrengst over de hele cylinder uitgesmeerd wordt.
En dan wil je nog 8 bit PWM om die 220 usec te varieren, dan heb je of sub-micro seconden timing of je gebruikt enkele omwentelingen (maar dat gaat heel gauw flikkeren) en dan nog redt je dat nooit met je micro, de tijden zijn veel te kort.

Ik ben me ook bezig met pic's, is een pic uit de
18F serie misschien een idee?

Op 8 juni 2005 12:55:09 schreef liverpool:
Ik ben me ook bezig met pic's, is een pic uit de
18F serie misschien een idee?

Voordelen :

  • 18F is 2* zo snel als 16F
  • Vaak meer RAM, FLASH en EE
  • Uitgebreidere instructieset
  • Memory banking is handiger

Nadelen :

  • Wat duurder dan de 16F serie
  • Code moet herschreven worden bij migratie van 16F naar 18F
  • Uitgebreidere instructieset (dus iets meer leerwerk by assembly)

Met mijn assembly proggramma's heb ik gemerkt dat na een port ze meestal 4 maal zo snel zijn. Ik gebruik hem alleen wanneer ik deze 'performance" nodig heb. Het hierboven vermelde PWM verhaal gaat echter niet lukken.

PWM met een roterend display werkt prima. Mijn 1e propellerklok heeft een LDR op de arm zitten en past de brandduur voor elk pixelframe aan aan het omgevingslicht in 16 stappen. PWM-frequentie is dus het zelfde als de framerate. Werkt prima. Zeker als je ook nog eens "centreert". Ik heb helaas geen filmpje om het te demonstreren.

Op 8 juni 2005 14:28:44 schreef Fuzzbass:
PWM met een roterend display werkt prima. Mijn 1e propellerklok heeft een LDR op de arm zitten en past de brandduur voor elk pixelframe aan aan het omgevingslicht in 16 stappen.

Maar dit zijn 16 stappen en je gebruikt dezelfde intensiteit voor alle ledjes ?
Voor 256 stappen moet dus de klok 16* zo hoog zijn en als het dan per ledje onafhankelijk wil hebben (32 in de kolom) red je het volgens mij niet met een 5 MIPS pic.

Ik bedoelde te zeggen dat PWM op zich wel werkt op een persistence-of-vision display. Dat 150 onafhankelijke 8-bit helderheidswaardes veel te hoog gegerepen is voor een PIC, ben ik volledig met je eens.

PWM met 256 intervallen is een beetje ambitieus, 16 intervallen is al wel gelukt single colour, hmmm, stof tot nadenken/experimenteren dus...mooi!
Ander probleem is het inlezen van data (frames) via RS232 en deze inladen in een extern (flash)geheugen. Op het gebied van adressering en controlling van zo'n geheugen zit ik nog op niveau 'Eprom uitlezen met een een Z80'. Ben benieuwd of iemand die hier praktische artikelen over weet te vinden of al wat praktijkervaring mee heeft?

RS232 controlled met een PIC heb ik al iets over gevonden op: http://www.oz1bxm.dk/PIC/628uart.htm

Ok, inmiddels begonnen met het ontwerp. Ik heb er voor gekozen om de PIC16F84A te gebruiken als PWM driver voor 4 leds dus 8 pics in totaal voor 32 leds. Deze worden voorzien van data rechtstreeks uit een 29F040 Flash Eprom.
Data wordt gebufferd in de Leddrivers en on the fly ingelezen. (hell of a job qua timing trouwens)
Die Flash eprom wordt via een 16F84A met 3x74HCT595 geadresseerd. De data kan via RS232 worden ingelezen.

Ok we zijn er dus nog lang niet...Wordt vervolgd...

Deze worden voorzien van data rechtstreeks uit een 29F040 Flash Eprom.

Waarom gebruik je geen I2C eeprom, de 24LC512 bv 64K X 8 bit

Op 15 juni 2005 20:05:00 schreef Roland van Leusden:
[...]

Waarom gebruik je geen I2C eeprom, de 24LC512 bv 64K X 8 bit

Idee was dat de 29F040 parallel, dus sneller is uit te lezen. (timing heb ik nog niet scherp en wil het zekere voor het onzekere nemen)

Op 15 juni 2005 20:11:06 schreef Effeen:
[...]
Idee was dat de 29F040 parallel, dus sneller is uit te lezen. (timing heb ik nog niet scherp en wil het zekere voor het onzekere nemen)

Als je snelheid wil, gebruik je toch geen schuifregister? Dat vertraagt ook. En waarom kiezen voor een obsolete fossiel als de 16F84? Een pic uit de 18F-reeks is moderner en veel krachtiger. Of anders een 16F628A.

Op 15 juni 2005 20:39:16 schreef Thomas:
[...]
Als je snelheid wil, gebruik je toch geen schuifregister? Dat vertraagt ook. En waarom kiezen voor een obsolete fossiel als de 16F84? Een pic uit de 18F-reeks is moderner en veel krachtiger. Of anders een 16F628A.

Een schuifregister kost inderdaad voor 19 adresbits 19/3: minimaal 7 cyles eer je adres klaar staat. 0Wat is de snelheid van 18F.. en is er z'on type die rechtstreeks 19 bits kan adresseren ?

Op 15 juni 2005 20:53:56 schreef Effeen:
[...]
Een schuifregister kost inderdaad voor 19 adresbits 19/3: minimaal 7 cyles eer je adres klaar staat. 0Wat is de snelheid van 18F.. en is er z'on type die rechtstreeks 19 bits kan adresseren ?

Kijk eens op www.voti.nl. Daar staat een hoop informatie om een geschikte microcontroller te selecteren.

Ik las net ook dat je 8 pics tegelijkertijd wou gebruiken. Dan kies je toch beter voor één microcontroller die al het werk doet. Neem er dan meteen één met hardwarematige UART, anders heb je veel werk om RS232-communicatie compleet in software te schrijven.

Op 15 juni 2005 21:31:09 schreef Thomas:
[...]
Kijk eens op www.voti.nl. Daar staat een hoop informatie om een geschikte microcontroller te selecteren.

Ik las net ook dat je 8 pics tegelijkertijd wou gebruiken. Dan kies je toch beter voor één microcontroller die al het werk doet. Neem er dan meteen één met hardwarematige UART, anders heb je veel werk om RS232-communicatie compleet in software te schrijven.

Inderdaad! ik ben nu al een tijdje bezig een UART te schrijven (die werkt) voor die 16F84. Maar dat valt niet mee!

Ik heb zelf ook gedacht om de beperking van 8 kleuren te ontstijgen. Maar ik heb al ingezien dat dit niet met pic's en pwm te doen is. Het is toch wel met pic's te maken maar dan door je kleur intensie parallel te sturen. Het grote nadeel is het aantal aansluitingen en bergen 74HC595-en.

Als je voor elke kleur 4 bits diep wilt gaan heb je dus 16x16x16= 4096 kleuren. Je hebt dus per 8 RGB led's 12 x 74hc595 nodig en voor 32 rgb zelfs 48x 74hc595. De 4 kleur uitgangen sluit je aan middels een weerstand zodat er 1mA, 2mA, 4ma, 8ma door de led heen gaat. Hierdoor kan je minimaal 1mA sturen en maximaal 15mA en alles wat er tussen zit.

Met een pic uit de 16F serie kan je tot 5 MIPS.
Met een pic uit de 18F serie kan je tot 10 MIPS.
Met een Atmel kan je tot 16 MIPS.(Klopt toch?, heb geen ervaring met Atmel)
En er is/was ook zoiets als een Ubicom SX(lijkt veel op PIC) en die kan 50 MIPS.

Wil je toch gaan pwm-en. Dan heb je een processor nodig die 100+ MIPS kan. (ARM ofzoiets)

Lijkt me meer een klusje voor een DSP. Die kunnen bliksemsnel data verwerken en transporteren, sterker nog: ze zijn voor dat doel gemaakt. Veel DSP's hebben parallelle en seriële poorten te over. Bestuur die DSP met een PIC en klaar is kees. Neem bijv. een Freescale DSP56309.

Op 16 juni 2005 06:40:06 schreef Willie Worteltje:
Ik heb zelf ook gedacht om de beperking van 8 kleuren te ontstijgen. Maar ik heb al ingezien dat dit niet met pic's en pwm te doen is. Het is toch wel met pic's te maken maar dan door je kleur intensie parallel te sturen. Het grote nadeel is het aantal aansluitingen en bergen 74HC595-en.

Als je voor elke kleur 4 bits diep wilt gaan heb je dus 16x16x16= 4096 kleuren. Je hebt dus per 8 RGB led's 12 x 74hc595 nodig en voor 32 rgb zelfs 48x 74hc595. De 4 kleur uitgangen sluit je aan middels een weerstand zodat er 1mA, 2mA, 4ma, 8ma door de led heen gaat. Hierdoor kan je minimaal 1mA sturen en maximaal 15mA en alles wat er tussen zit.

Met een pic uit de 16F serie kan je tot 5 MIPS.
Met een pic uit de 18F serie kan je tot 10 MIPS.
Met een Atmel kan je tot 16 MIPS.(Klopt toch?, heb geen ervaring met Atmel)
En er is/was ook zoiets als een Ubicom SX(lijkt veel op PIC) en die kan 50 MIPS.

Wil je toch gaan pwm-en. Dan heb je een processor nodig die 100+ MIPS kan. (ARM ofzoiets)

Dat idee met PWM is erg lastig en zeker niet lineair ben ik net achtergekomen. Net een led aangesloten en geprobeerd de kleurniveaus gelijk te krijgen om bijvoorbeeld wit te maken. Net mijn leds (8000mcd=Behoorlijk fel btw.) binnengekregen van http://shop.dotlight.de/shop/product_info.php/products_id/210. Dat idee met die 595's als 4 bits DA omzetter lijkt me inderdaad dus meer haalbaar! Bedankt voor deze tip!

Op 16 juni 2005 06:40:06 schreef Willie Worteltje:
Met een pic uit de 16F serie kan je tot 5 MIPS.
Met een pic uit de 18F serie kan je tot 10 MIPS.
Met een Atmel kan je tot 16 MIPS.(Klopt toch?, heb geen ervaring met Atmel)

Atmel is de fabrikant, de controllers heten AVR (de meest populaire, Atmel maakt nml. meerdere families). Je hebt het immers ook over PIC i.p.v. Microchip.

AVR's voeren de meeste instructies uit in één clockcycle. Dat komt effectief neer op 1MHz = 1MIPS. De meeste standaard AVR's gaan tot 16 of 20MHz.

Ik zat toevallig gisteren ook aan zo'n project te denken toen ik deze post zag, alleen ik zat meer te denken aan iets als dit virtual game system, maar dan met RGB LEDs. Het idee is dan in bijvoorbeeld de tijd dat de LEDs aan de 'achterkant' staan een nieuw frame te berekenen en die dan tijdens de andere helft van de tijd te laten zien.

Ik heb ook nagedacht over hoe je toch wat helderheidniveau's zou kunnen maken. Mijn idee was een volledig frame al pulsgemoduleerd op te slaan in een geheugen (een SRAM bijvoorbeeld, als het maar snel is). Voor 4 niveaus kost dat al 4 bits per kleur per led dus het kost een hoop geheugen, maar 4 niveaus zou ook al aardig zijn.

Dan de outputs van het geheugen elk aan een 595 zetten, zodat je in 8 reads 8xhet aantal outputs (meestal dus 8x8=64) kunt instellen. De 595 is best snel en als elke 595 parallel wordt aangestuurd zou je volgens mij best in enkele uS een volledige rij nieuwe outputs kunnen neerzetten. Als dit ruim genomen 10uS zou duren kan je zelfs nog 220/10=22 keer een LED kunnen schakelen in de tijd van 1 kolom. Zou dat niet een redelijk beeld geven?

edit
Als toevoeging nog: De 4 bits die de PWM vormen voor een kolom worden dan uiteraard steeds herhaald, tot de volgende kolom. Bijvoorbeeld door de laatste 2 bits van het adres heel snel te wisselen en de rest van de bits slechts 1 keer per kolom. De processor hoeft dan alleen de hoge bits te regelen elke 220uS, de 2 laatste bits kunnen door een simpele teller met hoge frequentie.
/edit

Ik weet niet of dit uitvoerbaar is of goed werkt, maar dat kwam in me op. Het idee met een DAC achtig iets van Willie Worteltje is vast een stuk mooier maar daar heb je wel enorm veel 595s voor nodig.

[Bericht gewijzigd door madwizard op ]

@ Effeen
Lijkt mij idd ook goed haalbaar. Heb zelf momenteel de tijd er niet voor om het te maken. Maar ik ben erg benieuwd. Succes met de bouw.

@ madwizard
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. Ik denk (helaas veel werk) dat de DA uitvoering een mooier 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.

[Bericht gewijzigd door Willie Worteltje op ]