[EiP] 96x48 monochroom LED-display

[tafkaw]

Vet! Het beeld word in een keer veel duidelijker wanneer je meerdere displays naast elkaar plakt. Zal wel komen door de grote vervoudiging van het aantal "pixels". Erg cool!

[Kaj.]

Erg cool inderdaad.
Wat ik trouwens niet zo snel kon achterhalen; waar zijn J3 en J4 voor bedoeld? Ze zijn zo te zien verbonden met de voeding en de 74HC244's op de print, om precies te zijn naar een van de data inputs.

[ Voor 4% gewijzigd door Kaj. op 19-04-2008 08:01 ]

[mace]

Sprite_tm schreef op zaterdag 19 april 2008 @ 01:46:
-verhaal en filmpje-

Die verticale strepen komen door de grijswaardensimulatie i.c.m. de camera?

[Sprite_tm]

Kaj: Geen idee. Ik zal es kijken of ik het na kan zoeken. Atm vermoed ik dat er een fan opgehangen kan worden ofzo.

mace: Da's moiré.

[Kaj.]

Een ventilator is niet logisch. Ansluitingen komen wel overeen, maar ik zou het niet logisch vinden.

[mux]

spi/i2c aansluiting?

[Verwijderd]

ssj3gohan schreef op zaterdag 19 april 2008 @ 11:44:
spi/i2c aansluiting?

Op een bord waar alleen maar wat cmos logic rommel zit?

Anyway, heb er ook 2 binnen Geen kapotte pixels, wel gigantisch ingebrand, vooral als je er met een zonnebril naar kijkt
Zag op ebay een zaak die die 8x8 dingen verkocht, 10 voor 9 dollar.

[mace]

Ik heb ze nu ook binnen, 4 stuks, maar ik kan ze ff niet testen want ik heb alleen PICjes.

Ik denk dat ik een soort testroutine ga schrijven waarmee die dingen te controleren zijn, voor als ik er nog meer ga kopen.

Misschien kan ik er wel een muur mee behangen, net zoals terw_dan met zijn mobo's maar dan een hele videowall.

[ Voor 4% gewijzigd door mace op 19-04-2008 18:59 ]

[Phalox]

The Simpsons;) nice nice!
Mooi verzorgd werk dit volg ik nog even

[Zjosh]

Die van mij zijn inmiddels ook binnen! Ben benieuwd wat ik er vanavond nog van aan de praat kan krijgen, eerst maar eens iets bouwen wat een ledje laat knipperen, daarna kijk ik wel verder. Ik hoop niet dat die van mij rot zijn btw!

Edit: Sprite_tm, over je voorbeeld code, ik vraag me af wat er precies wordt bedoeld met A0..A2 naar Y zetten. Ik neem aan dat dat betekend dat je daarmee de actieve regels kan selecteren (LDAT&UDAT) dus, als daar binar 111 op gezet wordt gaat de 8e van boven en de onderste regel branden.

Edit2 : Ja dus

[ Voor 39% gewijzigd door Zjosh op 20-04-2008 15:38 ]

[mace]

Sprite_tm schreef op zaterdag 19 april 2008 @ 09:37:
Kaj: Geen idee. Ik zal es kijken of ik het na kan zoeken. Atm vermoed ik dat er een fan opgehangen kan worden ofzo.

De middelste pin van j4 hangt aan de GND, en de linker hangt aan pin 11 van de 244 die boven j1 zit, dus dat lijkt me niet voor een fan? Overigens zie ik niet waar pin 9 (2A3) aan hangt, de corresponderende uitgang van 11 (2Y3).

[ Voor 14% gewijzigd door mace op 19-04-2008 19:32 ]

[dj_dysaster]

Ik heb ook maar 4 van die scherpjes besteld, om een projectje te starten icm picmicro`s. T idee is erg leuk moet ik zeggen!

[Zjosh]

Nou, het is gelukt, de schermpjes zijn aan de praat, ze zijn echt fel! Heb ook geen dooie pixels, waar ik wel weer redelijk tevreden om mag zijn. Ik ga nu maar eens kijken hoe hard ik dat ding kan pwmen...

@Sprite_tm misschien is het een beetje overbodig om te zeggen, maar ik heb in je code een paar stukjes gezien die misschien wel wat sneller kunnen (in je leds.c in de interupt zou je bijvoorbeeld het clearen en setten van bitjes allemaal tegelijk kunnen doen, waar het bij jou soms in 2 of 3 stappen gaat).

[Sprite_tm]

Zjosh: Op de AVR is het bij 2 bitsets/clears goedkoper om ze apart te doen dan samen. Individuele bitsets worden namelijk vertaald naar een sbi port,bit-instructie, terwijl meerdere vertaald worden naar een in reg,port; or reg,val; out port,reg-iets. Twee sbis zijn dus goedkoper dan de 3 instructies die een gecombineerd iets oplevert.

De Wijze Les Van de Dag: Check altijd de code die je compiler uitspuugt als je denkt iets te optimaliseren; compilers zijn slim maar niet alwetend. Ze weten verder ook niet wat je precies probeert te doen: feitelijk geeft een gecombineerde instructie een ander resultaat (pinnen worden tegelijk hoog) dan 2 aparte (waarbij eerst de ene en dan de andere pin hoog word). In dit geval boeit dat verschil niets, maar de compiler kan dat onmogelijk ruiken.

[ Voor 5% gewijzigd door Sprite_tm op 20-04-2008 16:04 ]

[Zjosh]

Hmm, maar eens kijken wat mijn compiler er van bakt dan...

Mijn compiler maakt van een PORTC = row; iets wat 2 instructies kost, en van een individueel bitje zetten maakt hij ook iets wat 1 instructie kost. Weer wat geleerd vandaag...

[ Voor 60% gewijzigd door Zjosh op 20-04-2008 16:15 ]

[Verwijderd]

jeuj ik kan tekst printen

op 1 bord

op 2 borden

Klein beetje ingebrand

die 2 heldere lijnen zijn overigens niet kapot, die leds blijven aan tot de volgende update. Bij een hogere update frequentie (nu 50hz) zie je haast ze niet meer.

[ Voor 25% gewijzigd door Verwijderd op 20-04-2008 17:32 ]

[ThinkPad]

Hmmm ik vraag me af waar die borden voor gebruikt zijn, dat ze zo zijn ingebrand.

Ik wist trouwens niet dat LED's konden inbranden

[Zjosh]

Ik heb maar 1 board waar een paar ledjes van ingebrand zijn, de rest is allemaal perfect! Ben inmiddels maar begonnen met het pwmen van de leds, ik ga voor 4 bit pwm aangezien de µC het niet zo leuk vind om nog sneller te gaan rennen

Wat voor refresh rate moet dit wel niet op, met 7khz interupt en 3 bit pwm zie ik hem nog knipperen maar eens checken of hij wel echt op 48 mhz draait, want dit is natuurlijk niet cool

edit... handig, vergeetje je pll aan te doen...

[ Voor 34% gewijzigd door Zjosh op 20-04-2008 19:09 ]

[mace]

ThinkPadd schreef op zondag 20 april 2008 @ 17:33:
Hmmm ik vraag me af waar die borden voor gebruikt zijn, dat ze zo zijn ingebrand.

Ze hebben 10 jaar in een display gehangen op een busstation. (Zie thread @ CO)

[Verwijderd]

ThinkPadd schreef op zondag 20 april 2008 @ 17:33:
Hmmm ik vraag me af waar die borden voor gebruikt zijn, dat ze zo zijn ingebrand.

Als je goed kijkt lijkt het alsof er 89 Artis staat... Dus zal wel bus verbinding zijn, alhoewel ik geen bus 89 naar Artis kan vinden

<edit>
Hmm niet goed gekeken er staat dus 09 en dat is inderdaad de tram naar artis , check artis webiste.
</edit>

[ Voor 21% gewijzigd door Verwijderd op 20-04-2008 21:59 ]

[Zjosh]

Vandaag maar weer verder gegaan, heb er inmiddels 4 bit pwm in zitten waarbij ik het scherm ververs op ~58.6 Hz. Ik heb een timer interupt die 1441 instructies duurt( 1409 inmiddels ), waarbij 2 lijnen worden aangestuurd, deze wordt 7500x per seconde aangeroepen, wat uitkomt op dat ongeveer 90% van de tijd de µC daar mee bezig is... Dus als iemand nog een snelle manier op de planken heeft liggen om een array in PIC's uit te lezen, graag . Ik maak nu gebruik van dit:

C:

 
    if (*uled > cmp) UDAT = 1;
    if (*lled > cmp) LDAT = 1;
 

waarbij uled en lled pointers zijn naar arrays van bytes met daarin de dim waarde en UDAT en LDAT pinnen zijn. 1 zo'n commando kost al 12 instructies, en aangezien dat 32x per interupt wordt uitgevoerd, en de interupts op 7500x per seconde staan, zou het heel handig zijn als dit wat korter werd:P. Dit is wat hij er van maakt:

C:

MOVFF 0x6c, 0xfe9
NOP
MOVFF 0x6d, 0xfea
NOP
MOVFF 0xfef, 0x2
NOP
MOVLB 0
MOVF 0x6b, W, BANKED
BSF 0xfd8, 0, ACCESS
SUBFWB 0x2, W, ACCESS
BC 0x244
BSF 0xf81, 0x1, ACCESS

De nopjes achter de MOVFF instructies horen bij de MOVFF instructies, anders was het wel heel makkelijk optimaliseren Ik ga maar eens kijken of ik zelf wat kan verzinnen met asm... want dit moet toch korter kunnen.

Edit: Ik heb vandaag een beetje zitten code bedenken in de bus, en mijn interupt is van 1409 instructies naar 617 gegaan! Nu nog maar eens kijken naar de for loop die er in zit, want volgens mij hoeft dat ook geen 9 instructies te kosten. Hij vind het blijkbaar nodig om 3 keer de zelfde bank te selecteren, en ik vind dat dat niet hoeft

[ Voor 14% gewijzigd door Zjosh op 22-04-2008 20:45 ]

[Zjosh]

Heeft 1 van jullie ook last van pixels die mee gaan gloeien als je een andere aan zet? Ik weet wel ongeveer waar het vandaan komt, uit het verwisselen van rijen, maar wat er aan te doen... misschien dat onze trouwe transistors een beetje te traag zijn ofzo... maar weer eens uitzoeken.

[Sprite_tm]

Gebruik de /oe slim Als je het hele display uitzet dmv /oe als je de shiftregisters latcht, heb je er een heel stuk minder last van dat gloeien.

[mux]

YES! ze zijn binnen. Ik ga maar eens kijken of ik ze misschien tijdelijk even met een seriele/parallelle poort kan aansturen, heb nog geen uC's binnen

[Sprite_tm]

Niet stabiel (that is, onder standaard OSsen) omdat je de timings nooit echt goed kan krijgen. Je kan een poging wagen, maar verwacht niet iets kijkbaars te krijgen.

[mace]

Dan moet je VxWorks of RTlinux gaan draaien ofzo.

[ Voor 3% gewijzigd door mace op 23-04-2008 19:14 ]

[mux]

Op zich is technisch gezien de parallelle poort wel 16 Mbit/s, daar gebruik ik 2 ipv 8 pinnen van dus ik haal 4 Mbit/s. Als ik nou echt helemaal gek ga doen en één schermpje op 10 fps laat lopen zou ik toch wel een beetje goed uit moeten komen met de timing? Of is dat ook hopeloos. Misschien kan ik ergens nog shiftregisters vinden om een beetje te bufferen?

offtopic:
Zie ook de totale nutteloosheid hiervan, ik wil persé vandaag die dingen werkend zien maar krijg morgen waarschijnlijk al mn microcontrollers binnen :-P blijft leuk om te proberen

Edit: feestje voorbij, geen parallelle kabels meer en ook geen serieel->parallel chippie om hem op serieel te proberen. Nu maar helemaal wachten tot morgen

[ Voor 34% gewijzigd door mux op 23-04-2008 21:02 ]

[flux_w42]

mace schreef op woensdag 23 april 2008 @ 19:13:
Dan moet je VxWorks of RTlinux gaan draaien ofzo.

Of een bootdisk gebruiken met je "in-assembler-zelfgeschreven-display-aansturende-bootsector"
Parralele poort aansturen in assembler (zonder OS) is immers gewoon de juiste data op een bepaalde 'geheugenplaats' wegschrijven. 'k heb mij daar vroeger nog mee bezig gehouden (voor de seriele poort dan)

[SA007]

Heb de mijne nu ook een paar dagen binnen (vanaf maandag) en ben ze 's gaan testen.

Op mijn stk500 met veel bedraingsmeuk en een lelijk proggie wat gewoon alle prxels aanzet.

Heb iig geen dode pixels en de inbranding is virj beperkt en iig niet leesbaar of herkenbaar als tekst.

Dus heb ik best geluk als ik de rest zie

4 stuks zonder ernstige defecten, alleen een sloot kromme pinnen.

[mace]

Ik heb geen tijd om die van mij te testen, maar ik hoop dat ze niet ingebrand zijn.
Ik heb nog 6x 16f628a liggen dus die gebruik ik dan mooi als testgeval, maar dan moet ik wel tijd hebben om naar de elektronicahandel te fietsen om connectors te halen.

[mux]

[voelt zich een totale programmeer-noob] ik heb net java aan de praat gekregen (tijdje geleden dat ik met java heb gewerkt en c++ wil hier niet echt lukken) met de parallelle poort, ga nu solderen aan een matrixscherm en ik verwacht wel dat ik vrij snel iets zichtbaars erop moet kunnen krijgen...

[edit] WHOO! het werkt! 1-0 voor de parallelle poort! Timing is waardeloos (het flikkert best wel) maar je kunt er leesbare meukmeuk op krijgen en de refresh rate is ridicuul hoog.

[ Voor 23% gewijzigd door mux op 24-04-2008 22:28 ]

[mux]

Als ik een lijn inklok en ik strobe langzaam (dwz, lijn wordt in 1ms ingeklokt, daarna wordt er 200 ms gewacht tot de volgende lijn wordt ingeklokt) dan flitsen de LEDs alsnog elke keer een beetje na op de 'vorige' lijn. Ik snap niet helemaal waarom, hoe kan ik dat fixen?

edit: clk.... laat maar

[ Voor 5% gewijzigd door mux op 25-04-2008 07:57 ]

[mux]

Sprite_tm schreef op woensdag 23 april 2008 @ 01:49:
Gebruik de /oe slim Als je het hele display uitzet dmv /oe als je de shiftregisters latcht, heb je er een heel stuk minder last van dat gloeien.

Kun je een heel klein beetje meer hierover zeggen? kheb bijzonder veel last van het nagloeien.

Disclaimer: dit project is de eerste keer dat ik persoonlijk een avr werkend heb gekregen, dus noob. Ik programmeer dus ook in c, niet asm...

[Verwijderd]

Zie je code er letterlijk zo uit als in de ts? Dat werkt prima iig. Geen delays gebruiken, die tijd heb je hard nodig om andere dingen te doen.

edit:

code:

while(1) {
 for y=0 to 8 {
  for x=0 to 32 {
   maak LDAT hoog als je op (x,y+8) een pixel wilt weergeven
   maak UDAT hoog als je op (x,y) een pixel wilt weergeven
   maak CLK laag
   maak CLK hoog
  }
  maak OE hoog (dit zet alle LEDs tijdelijk uit)
  maak STROBE laag
  maak STROBE hoog
  zet [A2..0] naar y
  maak OE LAAG     << NIET HOOG
  wacht een tijd, afhankelijk van de gewenste refreshrate
 }
}

foutje gespot in code

[ Voor 62% gewijzigd door Verwijderd op 27-04-2008 15:05 ]

[mux]

Als ik een verticale lijn op een wit (rood) vlak wil laten zien gloeit het zwarte gebied even hard na als dat het rode aanstaat... Als ik dan een delay inbouw wordt het beter.

Edit: ik begrijp hem al (beter). Het gloeit al een stuk minder na als ik het scherm uitzet vóór ik pixels ga tekenen

[ Voor 26% gewijzigd door mux op 27-04-2008 15:58 ]

[mux]

Whieieieie

http://www.youtube.com/v/eOFIvk9vrNY

[ Voor 65% gewijzigd door mux op 27-04-2008 23:28 ]

[mace]

Klasse!
Die tearing, is dat IRL minder?

Heh, ik doe ook altijd een rietje in een 1,5L pak.

[mux]

LOL!!! Sorry, meestal sla ik niet zulke breezahtaal uit maar het getuigt maar weer van een uiterst scherp zicht om het rietje in de ijsthee te spotten.

De tearing is IRL meer een vervelend geknipper, de AVR loopt op 128 kHz of 1 Mhz (ben er nog niet helemaal uit, ik snap de klok nog niet helemaal...) en heeft nogal wat te doen op de eerste helft (iets met signed integers) dus daar is de refresh rate wat lager.

[mace]

ssj3gohan schreef op maandag 28 april 2008 @ 00:02:
LOL!!! Sorry, meestal sla ik niet zulke breezahtaal uit maar het getuigt maar weer van een uiterst scherp zicht om het rietje in de ijsthee te spotten.

Dat soort dingen zie ik altijd.

[ Voor 3% gewijzigd door mace op 28-04-2008 00:04 ]

[Verwijderd]

Ik wil al "jaren" (sinds 2002/2003 ofzo) een groot dot matrix scherm bouwen, de nieuwprijs van ledjes/overige apparatuur was echter te hoog. Ik heb nou 8 van deze panels besteld bij Baco, over een "tijd" zal ik het ding wel aansturen, eerst andere projecten nog afronden. Ik wil de schermpjes niet mislopen, dat zou zonde zijn (voor dit geld althans).

[Sprite_tm]

ssj3gohan schreef op maandag 28 april 2008 @ 00:02:
De tearing is IRL meer een vervelend geknipper, de AVR loopt op 128 kHz of 1 Mhz (ben er nog niet helemaal uit, ik snap de klok nog niet helemaal...) en heeft nogal wat te doen op de eerste helft (iets met signed integers) dus daar is de refresh rate wat lager.

Prolly 1MHz als je 'm op z'n standaard-fuses hebt. Om andere fuses te berekenen is dit een goed tooltje, mss heb je er iets aan.

[ Voor 32% gewijzigd door Sprite_tm op 28-04-2008 01:20 ]

[mux]

Is wel handig maar voor de avrnoob is het nog eventjes iets te cryptisch wat alle vinkjes en afkortingen betekenen ik ga me er vanavond nog wel in verdiepen.

[DaWaN]

Jahah als pure AVR en C n00b heb de dotmatrices werkend
Unit1:

Unit2:

Helaas had ik eerst de volgorde van de floppy kabel verkeerd

Toen ging die draad een beetje roken...
Helaas heeft ook er 1 ook een dode pixel..

Als kloppend hart een ATTiny2313 die op 8MHz loopt ! zonder ! de clockdivider
En hij heeft de kortsluiting overleeft


De code is extreem rommelig, maarja je moet ergens beginnen
Ik denk dat vooral op het gebied van de rijen het een stuk beter kan

code:

#include <avr/io.h>

//Aliassen voor de pinnen
#define DMUDAT PB0
#define DMLDAT PB1
#define DMCLK PB2
#define DMOE PB3
#define DMSTROBE PB4
#define DMA0 PB5
#define DMA1 PB6
#define DMA2 PB7

const unsigned char row[7] = {
(1 << PB5)|(1 << DMSTROBE),
(1 << PB6)|(1 << DMSTROBE),
(1 << PB6) | (1 << PB5)|(1 << DMSTROBE),
(1 << PB7)|(1 << DMSTROBE),
(1 << PB7) | (1 << PB5)|(1 << DMSTROBE),
(1 << PB7) | (1 << PB6)|(1 << DMSTROBE),
(1 << PB7) | (1 << PB6) | (1 << PB5)|(1 << DMSTROBE),
};

unsigned char r = 1;
unsigned char max = 31;
unsigned char t = 0;

void init()
{
  DDRB = 0xff; // PORTD PB0-PB7 als uitgang
  PORTB = 0x13; //PORTB STROBE en UDATA en LDATA hoog

}

void nextrow()
{
  PORTB |= (1 << DMOE);
  PORTB &= ~(1 << DMSTROBE);
  PORTB |= (1 << DMSTROBE);
  PORTB &= ~(1 << DMA0);
  PORTB &= ~(1 << DMA1);
  PORTB &= ~(1 << DMA2);    
  if(r>0){
  PORTB = row[r-1];}
  PORTB &= ~(1 << DMOE);
  t = 0;
  r++;
  if( r > 7 ){
      r = 0;}
}

int main()
{
    init();
  
  // oneindige lus
  while(1)
  {
  PORTB |= (1 << DMUDAT);
  PORTB |= (1 << DMLDAT);
  PORTB |= (1 << DMCLK);
  PORTB &= ~(1 << DMCLK);
if ( t > 31){
nextrow();}
else{
t++;}
  }
  
  return 0;
}

Op naar plaatjes tekenen, alleen even kijken hoe ik dat ga doen met die ATTiny, zoveel geheugen heeft hij niet

[ Voor 13% gewijzigd door DaWaN op 02-05-2008 13:13 ]

[mux]

En nu de belangrijkste vraag: welke halte en welke bus?

[Verwijderd]

Scorebord voor Live For Speed

[ Voor 4% gewijzigd door Verwijderd op 01-05-2008 17:47 ]

[mace]

Hoe heb je dat font zo gekregen eigenlijk?

[Verwijderd]

mace schreef op donderdag 01 mei 2008 @ 18:01:
Hoe heb je dat font zo gekregen eigenlijk?

By Procyon AVRlib zit een header file met een 5x7 font. Elke letter is een bitmap van 5 bytes.

[mux]

En ik maar zelf een font bouwen....

[Corn]

Even productief geweest met bordjes en aluminium: (klikbaar)


Heb bij wijze van test de boel aan de gang gekregen met een 8515, maar ik kom nu echt geheugen te kort. 4 borden ging nog, (256 byte grote 1-bit framebuffer), maar 8 gaat er echt niet meer in passen.
Eigenlijk wilde ik ook wel 8-bit grayscale proberen, maar dan zit ik al aan een 4kbyte grote framebuffer. Een mega640 met 8k zou dan genoeg zijn, maar zou ik aan één 16Mhz AVR genoeg hebben om 8 borden te PWM'en?

[mux]

AAVRS.nl verkoopt voor 4,95 ARM's met 16k geheugen. Volgens mij is dat een beter idee voor >4 bordjes.

[Corn]

Nog mensen verder gegaan met deze mooie displaytjes? Ik ben inmiddels weer verder gegaan met het een en ander programmeren, en krijg nu 4 bordjes met 1 AVR aangestuurd... Link naar de computer is helaas nog wel erg traag.

Ben er ondertussen achter gekomen dat het heel gemakkelijk is om de bordjes te linken, gewoon doorgaan met pixels er stroben en ze komen vanzelf bij hun buurman terecht.

_klik!

[mux]

Ik heb inmiddels atmega8515's en 64k srams binnen, over een week komen accelerometers binnen en zodra mn tentamens afgelopen zijn wordt het dan één groot feest met die matrixborden.

[Stoney3K]

[b][message=30293052,noline]Ben er ondertussen achter gekomen dat het heel gemakkelijk is om de bordjes te linken, gewoon doorgaan met pixels er stroben en ze komen vanzelf bij hun buurman terecht.
[afbeelding] _klik!

Dat is ook waarschijnlijk de reden dat J1 met de inputs aan één kant zit en J2 met de outputs aan de andere kant... Flatkabeltje ertussen en doorlinken die hap.

Ik ben trouwens benieuwd wanneer we deze schermpjes voor het eerst in één van de Tweaker-gerunde disco-shows terug zullen zien.

[Corn]

Vorderingen: Dedicated controllertje is af, heeft ook wat leuke standalone-functies (kan screens uit ROM dumpen, naar EEPROM opslaan en weer dumpen)

_klik!

Beetje brak filmpje, met GSM genomen:

[mace]

Corn schreef op woensdag 25 juni 2008 @ 11:39:
Vorderingen: Dedicated controllertje is af, heeft ook wat leuke standalone-functies (kan screens uit ROM dumpen, naar EEPROM opslaan en weer dumpen)

[afbeelding]_klik!

Beetje brak filmpje, met GSM genomen:
[video]

Gebruikt die ook dat logaritmische helderheidsverloop wat sprite ook gebruikt?

[Corn]

Nee... Heb ook geen idee hoe señor Sprite_tm dat gedaan heeft

Huu, widescreen!
_klik!

De oplettende kijkert zal opgemerkt hebben dat in de 8x8 linksbovenin een aantal rijen en colommen niet werkte; dit kwam door een aantal kapotte pinnen aan het matrix. Voorzichtig gedesoldeerd, en met losse draadjes gerepareerd.

_klik!

Waarschijnlijk is het bordje gevallen, op een hoek terecht gekomen, en was daardoor gesneuveld. Maar misschien is het ook raadzaam om bij een bord-constructie hier rekening mee te houden, door de constructie aan de achterkant te maken ipv zijkant/onderkant/bovenkant. De PCB kan het gewicht van de matrices makkelijk hebben, maar andersom is het misschien minder gezond.

[ Voor 60% gewijzigd door Corn op 26-06-2008 01:29 ]

[Corn]

Af! Frame in elkaar gezet met Alu profieltjes. Enkel USB kabeltje naar de computer (intern zit een USB-Hub met twee USB-Serieel convertertjes. De convertertjes zijn gehacked voor TTL ipv RS232. Nu nog toepassingen voor dit ding bedenken...


_klik!

[MrNGm]

Hmm, even het topic doorgelezen en ik moet zeggen dat het wel geinige bordjes zijn. Enige nadeel is dat ik geen AVR/PIC prog ervaring heb.
Iemand heeft al wat geprobeerd met de parallelle poort, maar is daar nog wat nuttigs uitgekomen? Zou je zo'n bordje met de parallelle/seriele poort kunnen aansturen?

Het lijkt me zeker leuk om dit soort bordjes aan te kunnen sturen, met de apparatuur die ik reeds heb.

[DaWaN]

MrNGm schreef op donderdag 03 juli 2008 @ 23:54:
Hmm, even het topic doorgelezen en ik moet zeggen dat het wel geinige bordjes zijn. Enige nadeel is dat ik geen AVR/PIC prog ervaring heb.
Iemand heeft al wat geprobeerd met de parallelle poort, maar is daar nog wat nuttigs uitgekomen? Zou je zo'n bordje met de parallelle/seriele poort kunnen aansturen?

Het lijkt me zeker leuk om dit soort bordjes aan te kunnen sturen, met de apparatuur die ik reeds heb.

Leuke manier om AVR/PIC programmeren te leren zou ik zeggen.
Het lijkt me niet echt handig om dit via een paralelle poort te doen

[Verwijderd]

@Corn. Hoe heb je de boardjes onderling aan elkaar verbonden?

[mace]

Verwijderd schreef op maandag 21 juli 2008 @ 11:36:
@Corn. Hoe heb je de boardjes onderling aan elkaar verbonden?

Je kan ze doorlussen, J2 aan J1.

[mux]

MrNGm schreef op donderdag 03 juli 2008 @ 23:54:
Hmm, even het topic doorgelezen en ik moet zeggen dat het wel geinige bordjes zijn. Enige nadeel is dat ik geen AVR/PIC prog ervaring heb.
Iemand heeft al wat geprobeerd met de parallelle poort, maar is daar nog wat nuttigs uitgekomen? Zou je zo'n bordje met de parallelle/seriele poort kunnen aansturen?

Het lijkt me zeker leuk om dit soort bordjes aan te kunnen sturen, met de apparatuur die ik reeds heb.

I tried and I failed - de parallelle poort zendt bovendien brakke flanken uit, dus je zult sowieso veel hebben aan een buffer. En gezien je dan toch al aan het uitgebreidere soldeerwerk begint loont het eigenlijk gelijk wel om een microcontroller aan te schaffen en een parallelle-poort-programmer te knutselen (brian dean's programmer). Werkelijk, bij elkaar misschien een uurtje werk, en je opent er een miljoen keer meer mogelijkheden mee.

[Verwijderd]

mace schreef op maandag 21 juli 2008 @ 11:47:
[...]

Je kan ze doorlussen, J2 aan J1.

Sorry, ik bedoel mechanisch. Corn heeft ze zo mooi in een alu frame gemonteerd maar ik wil graag weten hoe hij die displays mechanisch vast heeft gezet.

Ik stuur ze btw aan met een Virtex-IIp in een combinatie van VHDL met een PowerPC core. Deze boarden zijn leuk in een VHDL practicum.

[Corn]

Ik heb de borden aan elkaar gezet met epoxy en kleine stukjes alu hoekprofiel. Eerst de bordjes aan de randen opgeschuurd met de dremel tot ik het glasvezel zag zitten (natuurlijk wel uitgekeken voor de printspoortjes). Daarna ingesmeerd met epoxy, en een opgeschuurd stukje hoekprofiel erop gezet. daarna uit laten harden, en nog meer epoxy erop





Deze constructie zorgt ervoor dat het plastic met de matrices ontlast wordt, en daar dus geen rare stress op komt

[Verwijderd]

Thx Corn voor de heldere plaatjes. Lijmen is dus de truuk.

[Verwijderd]

met welk stukje software wordt de AVR vanuit de pc aangestuurd sprite?
Ik heb ook 10 bordjes besteld.
gebruiken jullie over het algemeen maar 1 AVR voor meerdere borden?

[kloas_wokkel]

Hallo,
Ik heb ook van die bordjes besteld. en ik gebruik ik de volgende code (dit is een deel)

code:

A2 = 0 : A1 = 0 : A0 = 0

SHout data_up,Clock,MSBFirst,[%01000101,%11110100,%01000000,%00000000]
enable_ = 0
Pulsout Strobe,1 ' latch to output register
delayus delay
enable_ = 1

A2 = 1 : A1 = 1 : A0 = 1
SHout data_up,Clock,MSBFirst,[%11000101,%11110100,%11000000,%10000000]
enable_ = 0
Pulsout Strobe,1 ' latch to output register
delayus delay
enable_ = 1

maar dit werkt niet lekker. ziet iemand waar het fout gaat in de code ? of heeft iemand een voorbeeldje in picbasic die ik mag gebruiken ?
Alvast bedankt !

[Theuno]

kloas_wokkel schreef op dinsdag 22 juli 2008 @ 11:34:
Hallo,
Ik heb ook van die bordjes besteld. en ik gebruik ik de volgende code (dit is een deel)

code:

A2 = 0 : A1 = 0 : A0 = 0

SHout data_up,Clock,MSBFirst,[%01000101,%11110100,%01000000,%00000000]
enable_ = 0
Pulsout Strobe,1 ' latch to output register
delayus delay
enable_ = 1

A2 = 1 : A1 = 1 : A0 = 1
SHout data_up,Clock,MSBFirst,[%11000101,%11110100,%11000000,%10000000]
enable_ = 0
Pulsout Strobe,1 ' latch to output register
delayus delay
enable_ = 1

maar dit werkt niet lekker. ziet iemand waar het fout gaat in de code ? of heeft iemand een voorbeeldje in picbasic die ik mag gebruiken ?
Alvast bedankt !

Wat probeer je hier precies te doen, en wat gebeurt er ?
Zoals ik het zie aan dit stukje code zullen er maar 2 regels code oplichten ?

[kloas_wokkel]

dat klopt maar als ik dan dit stukje blijf herhalen gaan er allemaal andere pixels oplichten

[Theuno]

Ik heb mijn bordjes ook binnen, dat ging zeer snel moet ik zeggen!

Gisteravond even aan het klussen geweest zodat ik ze in elk geval allemaal even kan testen:


Dit doe ik met een PIC32 van Microchip, zo'n beetje de voorbeeldcode van Sprite gebruikt
Nu nog iets goeds bedenken om dadelijk 10 - 12 van die borden tegelijk aan te sturen.

Heeft iemand trouwens al gemeten wat 1 zo'n bord volledig aan verbruikt ? Kan ik daar de voeding een beetje op uitzoeken.

[mux]

Het enige wat ik me nog kon herinneren was dat hij op één li-ion cel ongeveer 6 uur werkte (aangestuurd door een atmega88)

[DaWaN]

Het verbruik van die dingen is vrij fors, naar mijn weten was het iets van 2A per bordje.

[mace]

Aan de andere kant, dat is maar 10 watt voor al die leds, dat valt dan toch wel mee?

[mux]

Dat klopt niet met mijn operating time, volgens mij is het nooit 2A. Een li-ion cel heeft 2300 mAh @ 4V dus niet veel meer dan 9 Wh, en daar draai ik urenlang op. Misschien dat hij zuiniger wordt als je dichter bij de spanningsval van de leds zit...

[DaWaN]

ssj3gohan schreef op vrijdag 25 juli 2008 @ 14:14:
Dat klopt niet met mijn operating time, volgens mij is het nooit 2A. Een li-ion cel heeft 2300 mAh @ 4V dus niet veel meer dan 9 Wh, en daar draai ik urenlang op. Misschien dat hij zuiniger wordt als je dichter bij de spanningsval van de leds zit...

Die darlingtons worden toch wel iets warmer dan handwarm bij mij en ik had het gemeten wanneer alle LED's aanstonden. En het was inderdaad gemeten met een 5,12V spanningsbron.

[mux]

Het kan er natuurlijk mee te maken hebben dat ik alleen tekst liet zien Wat is dat, 1/4 van de leds? minder?

[mux]

Zo, ik heb nu een proof-of-concept gemaakt met de wonderlijke combinatie Freescale MMA7260+atmega8L+dotmatrix, met andere woorden een balletje dat over het scherm beweegt naar gelang de xy-acceleratie die de aan het scherm bevestigde accelerometer voelt.

Met andere woorden: balanceerspelletje ;-) Pics volgen zodra ik geslapen heb.

[kloas_wokkel]

Heeft iemand toevallig zo'n programmatje in basic ?
ik ben nu al een paar middagen aan het aankloten en het wil maar niet lukken.
Alvast bedankt

[Theuno]

Hier gaat het nu niet helemaal lekker met mijn bordjes. Ik heb er voor de test 2 aan elkaar doorgelust.
Als ik vol gas die dingen volklok (dat zal iets van 40 Mhz tops zijn) gaat er toch het een en ander mis:


Helemaal linksonder zie je daar op het onderste 8x8 block 2 rijen die niet branden. Terwijl dit wel zou moeten.
Als ik nu alles tergend langzaam erin klok, door te debug steppen gaan ze wel aan:



Het volgende probleem is dat het enorm knipperd aan alle kanten (je ziet de lijnen gewoon hard scrollen).

Ik doe dit nu met een dsPIC 33F (ging iets beter met programmen en debuggen, 32 bitter lijkt gaar ).
De code die ik gebruik:

code:

#include <p33Fxxxx.h>
#include "stdio.h"

// Easy defines for BIT Operations
#define BIT64(x) ((unsigned long long)0x0000000000000001 << (x))

#define dataLow LATAbits.LATA0 // PORTAbits.RA0 //LATAbits.LATA0
#define dataUp  LATAbits.LATA1 // PORTAbits.RA1 //LATAbits.LATA1 
#define Clock   LATAbits.LATA2 // PORTAbits.RA2 
#define OE      LATAbits.LATA3
#define Strobe  LATAbits.LATA4 // PORTAbits.RA4 // LATAbits.LATA4 //PORTAbits.RA4 

// Global counter
int i = 0; 

// Buffers
unsigned long long buffUp[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
unsigned long long buffLow[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };


// Clock the clock
void Clk()
{
    Clock = 1; // Make A2 high (CLK)
    for(i = 0; i < 25; i++);    
    Clock = 0; // Make A2 low  (CLK)    
}


// Main loop
int main() {
#if defined(__PIC24HJ256GP610__) || defined(__dsPIC33FJ256GP710__)
    //The settings below set up the oscillator and PLL for 40 MIPS
    
    OSCCONbits.COSC = 3;        /* Primary oscilator with PLL, XT is 8Mhz */
    
    CLKDIVbits.ROI = 0;         /* Interrupts have no effect on the DOZEN bit   */
    CLKDIVbits.DOZE = 0;        /* Device clock is cpu clock                    */
    CLKDIVbits.DOZEN = 0;       /* Device clock is cpu clock                    */
    CLKDIVbits.FRCDIV = 0;      /* Don't care since external clock              */
    CLKDIVbits.PLLPOST = 2 - 2; /* 8 Mhz crystal goes to 4 Mhz                  */
    CLKDIVbits.PLLPRE  = 2 - 2; /* 160 Mhz goes to 80 Mhz gives 40 MIPS         */
    
    PLLFBDbits.PLLDIV = 40 - 2; /* 4 Mhz goes to 160 Mhz                        */
#endif  
    
    // Init of ports
    TRISA = 0;      // all PORTA as output
    ODCA = 1;       // Enable open drain on PORTA
    
    // Variable init
    int line = 0;
    int row = 0;
      
    for(row = 0; row < 8; row++)
    {
        if(row == 0 || row == 1)
        {
            buffLow[row] |= 0xFFFFFFFFFFFFFFF;
        } 
        else
        {
            buffLow[row] |= 0xFF;
            buffLow[row] <<= 16;
            buffLow[row] |= 0xFF;
            buffLow[row] <<= 16;
            buffLow[row] |= 0xFF;
            buffLow[row] <<= 16; 
            buffLow[row] |= 0xFF;
        }           
    } 
    
    // Main loop
    while(1)
    {   
        for(line = 0; line < 8; line++)
        {
            // Disable display
            OE = 1; // Make A2 high (OE)        
            
            //Set address   
            LATAbits.LATA5 = line&0x01;
            LATAbits.LATA6 = !!(line&0x02);
            LATAbits.LATA7 = !!(line&0x04);             
            for(i = 0; i < 25; i++); 
                    
            // Stuff the row with the correct bits
            for(row = 0; row < 64; row++)
            {   
                dataUp = bit_get(buffUp[line], BIT64(row)) ? 1 : 0;         
                dataLow = bit_get(buffLow[line], BIT64(row)) ? 1 : 0;
                Clk();
            }   

            Strobe = 0; // Make A2 low  (Strobe)
            for(i = 0; i < 25; i++); 
            Strobe = 1; // Make A2 high (Strobe)                

            // Enable display
            OE = 0;     

            for(i = 0; i < 500; i++);                       
        }
    }

    return 0;
}

In buffup heb ik de tekst Theuno geklokt.
Iemand een idee hoe ik dat geknipper kan beperken, en op wat voor snelheid ik hem maximaal aan mag sturen ?

[Zjosh]

Bij mij was het geknipper verdwenen toen ik met een 75 Hz het beeld ververste. Dus ik denk dat jij daar ook naar toe moet proberen te werken ( meer kan ook wel, bij mij werkten de schermen op 150 Hz nogsteeds wel ), en dan werk ik met 4 bit pwm, dus eigenlijk knal ik 75 x 16 x 8 ( 75 hz, 16 keer per frame voor de pwm, en 8 voor de rijen ) het scherm vol. Bij mij functioneerde dat.

Enige waar ik nog naar op zoek ben is een manier om interessante data van de computer weer te geven. Ik zie namelijk allemaal mensen die hebben hun mediaplayer aangepast zodat hij kan outputten naar de microcontrollers. Ik ben wel benieuwd hoe je dat moet doen zegmaar

[Verwijderd]

Meer images:

• http://kingofdos.com/ledboard/1.jpg
• http://kingofdos.com/ledboard/3.jpg
• http://kingofdos.com/ledboard/4.jpg
• http://kingofdos.com/ledboard/5.jpg
• http://kingofdos.com/ledboard/6.jpg

Zoals je op de foto's kan zien gebruik ik plugjes om de schermen op hun plaatst te houden. Dit doe ik dmv een 5mm plugje in een 4mm gat te stoppen. Achter de inkepingen van de pluggen blijft de print hangen, hij wordt min of meer vastgeklikt. Ik maak een plug "gebruiksklaar" dmv de volgende stappen: 1) Stukje van de punt afsnijden zodat hij niet te diep het gat in gaat. 2) Stukje van zijkanten afsnijden, zodat hij ietsjes (0.5mm ofzo) smaller is.
Na het plaatsen van de plugjes kan ik zonder verdere constructie/lijm de print optillen aan de geplaatste pluggen. Achteraf lijm ik de pluggen voor de zekerheid vast met hotglue (na het schuren van de print, oplettende op printbanen).

Van de week ga ik verder met het monteren van de ledboards op de constructie. Gaatjes boren waar ik koperdraad doorheen steek om zo de boards te vergrendelen (op hun plaats houden doen de L profieltjes). Deze methode werkt vrij simpel als je werkt met een ledboard van slechts 1 regel hoog, bij 2 boards wordt deze constructie al wat lastiger.

[edit]
Hij hangt nou aan z'n ophangbeugels en de ledboards zitten allemaal vast. Eerst hier opruimen en dan ga ik binnenkort verder met de PIC. Ik heb nog nooit met PIC's (of andere uC's) gewerkt, dus ik ben benieuwd hoe het gaat. Ik heb gelukkig wel een progger (MPLAB ICD2 kloon) gekocht, dus dat is geen probleem meer.

Nou moet ik nog dingen gaan lezen/proberen met de PIC's. Ik las iets over bootloaders ergens? Om dat allemaal uit te vissen is de taak voor komende week(en).

[ Voor 15% gewijzigd door Verwijderd op 20-08-2008 15:03 ]

[DaWaN]

Theuno schreef op dinsdag 12 augustus 2008 @ 20:25:
Hier gaat het nu niet helemaal lekker met mijn bordjes. Ik heb er voor de test 2 aan elkaar doorgelust.
Als ik vol gas die dingen volklok (dat zal iets van 40 Mhz tops zijn) gaat er toch het een en ander mis.

Iemand een idee hoe ik dat geknipper kan beperken, en op wat voor snelheid ik hem maximaal aan mag sturen ?

Hoeveel mA kunnen die pinnen van die PIC sourcen / sinken. Je zou eens je scope eraan moeten hangen om te kijken of hij die ingangcapaciteit ver genoeg kan opladen.
Ander puntje wat je ook kunt doen is de datasheet van de schuifregisters opzoeken.

[djneo-nl]

Rare vraag kan dit met de juiste controller,Iets als een rss feed kan laten zien een soort letterbox (als dat zo heet).

heb al ideeën voor opstart filmpjes en screensaver

[ Voor 18% gewijzigd door djneo-nl op 22-08-2008 17:16 ]

[Verwijderd]

Ja dat is zeker mogelijk, als je daar een pc programmaatje voor hebt die die rss info weer doorgeeft aan de controller.

Ik vraag me ook nog steeds af hoe Sprite_TM zijn media speler data doorgeeft naar diverse led panels? Heb je hier wat uitleg van sprite?

[Theuno]

DaWaN schreef op woensdag 20 augustus 2008 @ 10:06:
[...]

Hoeveel mA kunnen die pinnen van die PIC sourcen / sinken. Je zou eens je scope eraan moeten hangen om te kijken of hij die ingangcapaciteit ver genoeg kan opladen.
Ander puntje wat je ook kunt doen is de datasheet van de schuifregisters opzoeken.

De pinnen van de PIC kunnen ongeveer 4 mA zo geven, maar dat is op 3.3v. De schuifregisters willen volgens mij ook iets van 4mA maar als ik het goed is 5 volt.
Hier had ik eerst pullup weerstanden tussenzitten, maar die bleken ietwat aan de hoge kan te zijn.
Nu vervangen voor 8.2k. Dit gaat beter, de leds gaan aan die aan moeten gaan, en ik hoef niet meer te wachten tussen clock pulsen. En dus staat uiteindelijk het beeld ook mooi stil

[Verwijderd]

Ik vraag me, als PIC-n00b af wat voor soort PIC ik hiervoor het beste kan gebruiken. Ik heb hier liggen:
• PIC16F876-20/SP
• PIC18LF4685-I/P
En verder kan ik natuurlijk ook nog PIC's bestellen.

Ik heb wel wat elektronica ervaring, leren werken met PIC's staat nog op mijn todo lijst. Dus ik had al een MP-LAB ICD2 (kloon) gekocht om me hierbij te helpen. Nou is dus mijn vraag aan m'n mede-tweakers, welke PIC raden jullie aan om te gebruiken voor "beperkte" mogelijkheden van zo'n board (het hoeft geen streaming video te zijn, enkel teksten (in verschillende lettertype's) verplaatsen over het scherm (lichtkrant/rss/etc). Er moet dus wel aardig wat geheugen/flash/etc aanwezig zijn om genoeg effecten (lichtkrant links, omhoog, omlaag, rechts, knipperen, etc) te programmeren. Ik wil vanaf een seriele poort (UART poort op een Fonera) de data pushen, welke direct wordt weergegeven. Custom chars/graphics wil ik opslaan in een stukje flashgeheugen, zodat ik deze ook live kan aanpassen. De PIC zou dus commando's krijgen over "effect" (en settings) icm "tekst", en op 1 (of 2) lichtsterktes moeten kunnen weergeven (fel bij daglicht, minder fel bij nacht), welke ik wil uitlezen met een lichtsensor.

[Springuin]

Neem de PIC18LF4685-I/P, die heeft een betere core dan de pic16 en veel meer programma en datamemory. Daarnaast is er een C compiler voor (http://www.microchip.com/...Id=1406&dDocName=en010014).

[Verwijderd]

Springuin schreef op maandag 25 augustus 2008 @ 08:44:
Neem de PIC18LF4685-I/P, die heeft een betere core dan de pic16 en veel meer programma en datamemory. Daarnaast is er een C compiler voor (http://www.microchip.com/...Id=1406&dDocName=en010014).

Ik zat te denken om iets met JAL of dergelijke gaan doen, maar om C te leren om het aan te sturen is ook een mogelijkheid. Ik ben eigenlijk webdeveloper, dus dan doe ik niet zoveel met C. Stuk php/vb/js (en vele andere scripttalen) zijn geen probleem, dus het leren van C zal me wel wat tijd kosten, maar dan spreek ik over dagen (gok ik).

[Sprite_tm]

Verwijderd schreef op vrijdag 22 augustus 2008 @ 10:44:
[...]
Ik vraag me ook nog steeds af hoe Sprite_TM zijn media speler data doorgeeft naar diverse led panels? Heb je hier wat uitleg van sprite?

Ik heb MPlayer gepakt en daar een output-driver voor geschreven die de video-data omzet naar grayscale en in een bepaald (vrij simpel) formaat naar een serieele poort toe kan schoppen. Die poort is fysiek geimplementeerd als een FT232 USB-naar-serieel-converter die op maar liefst 1MBit ttl-nivo rs-232 naar buiten spuugt. Deze lijn is gelinked naar de uC achter het eerste board. Die parset genoeg bytes om zijn buffer te vullen met een frame en geeft daarna alle bytes door aan de volgende uC. Die doet weer hetzelfde en als 'ie klaar is geeft 'ie de data door naar de volgende, enzovoort.

[Theuno]

Verwijderd schreef op maandag 25 augustus 2008 @ 10:04:
[...]

Ik zat te denken om iets met JAL of dergelijke gaan doen, maar om C te leren om het aan te sturen is ook een mogelijkheid. Ik ben eigenlijk webdeveloper, dus dan doe ik niet zoveel met C. Stuk php/vb/js (en vele andere scripttalen) zijn geen probleem, dus het leren van C zal me wel wat tijd kosten, maar dan spreek ik over dagen (gok ik).

C leren zal het grootste probleem niet zijn vermoed ik dan.
[sarcasme]
Echter de enorme bult datasheets die microchip zo netjes geordend heeft met duidelijke voorbeelden zullen het probleem worden.
[/sarcasme]
Ik vind ze dus niet duidelijk geordend, niet duidelijk te vinden, en de voorbeelden zijn voor sommige mogelijkheden niet aanwezig. Daarom is mijn progress ook heel langzaam naar mijn zin. Ik gebruik dan ook wel iets dikkere PIC's, dus misschien dat het daarbij iets erger is.

[swets]

zet [A2..0] naar y


wat betekend dat? kan iemand dat uitleggen...

A0
A1
A2 en daar dan binair de waarde van y inschuiven ofzo?

[jerbro]

swets schreef op dinsdag 14 oktober 2008 @ 16:05:
zet [A2..0] naar y
wat betekend dat?

Dat je de waarde van Y in A0, A1 en A2 moet zetten. Aangezien elke helft 8 rijen heeft past dit dus precies in 3 bits.
Dus inderdaad, de waarde van y binair in a[2..0] zetten.

[swets]

sorry 2x het zelfde...

[ Voor 95% gewijzigd door swets op 24-10-2008 14:29 ]

[swets]

Sprite_tm schreef op maandag 25 augustus 2008 @ 10:23:
[...]


Ik heb MPlayer gepakt en daar een output-driver voor geschreven die de video-data omzet naar grayscale en in een bepaald (vrij simpel) formaat naar een serieele poort toe kan schoppen. Die poort is fysiek geimplementeerd als een FT232 USB-naar-serieel-converter die op maar liefst 1MBit ttl-nivo rs-232 naar buiten spuugt. Deze lijn is gelinked naar de uC achter het eerste board. Die parset genoeg bytes om zijn buffer te vullen met een frame en geeft daarna alle bytes door aan de volgende uC. Die doet weer hetzelfde en als 'ie klaar is geeft 'ie de data door naar de volgende, enzovoort.

ik heb echt geen idee wat ik allemaal moet downloaden voor die Mplayer?
dus een outputdriver schrijven zal ook wel niet zomaar ff gaan?

misschien een paar tips?

[Sprite_tm]

http://www.mplayerhq.hu
Zodra ik ergens in een hoekje mijn jerrycan met vrije tijd teruggevonden heb, zal ik die es gebruiken om een mooi artikeltje voor mijn site te schrijven, inclusief software en patches voor MPlayer enzo.

[swets]

Nog mensen bezig met de displays?

[dj_dysaster]

Toevallig van de week een aantal van deze displays gebruikt om een "imageviewer" te maken. Klein C# appje die de pixel values van een plaatje serieel naar een atmega trapt om ze te plotten op de displays.

Ben momenteel ook bezig met een equalizer appje, als toevoeging op mn diy ambilight

[Sprite_tm]

Het kreng ligt bij mij in de kast en word zo nu en dan ingezet. Laatst nog voor de Joti een appje gemaakt die twitters met een bepaalde hashtag naar het display stuurt, was wel leuk.

[Kaj.]

Die van mij zet ik regelmatig in als reclamekrant op festivals voor Stichting J-POP.
Recent nog een paar panelen over kunnen nemen van SA007; nu alleen nog even de tijd nemen om het bestaande bord daarmee uit te breiden.

Hier een shotje van mijn lichtkrant; wel op een frame, maar nog niet in z'n uiteindelijke behuizing, heb ik even geen shots van online staan:



Ik houd mij nog aanbevolen voor extra panelen, overigens.

[Verwijderd]

Ik wil zelf een aantal LED panelen (liefst 96x192px) aansturen realtime vanaf de computer. Het doel is om met een groen vlak te creëren (van 96x40 px) en deze met een bepaalde snelheid over het display te laten lopen.

Zelf zou ik graag de hardware kopen en de besturing zelf doen. Iemand enig idee waar deze hardware verkrijgbaar is en waar ik op zou moeten letten.

Het wiel moet ik uitvinden dus alle hulp is meegenomen.

Thx