[EiP] 96x48 monochroom LED-display

[Sprite_tm]

Zoals jullie in de kroeg wel konden lezen, heb ik bij Baco tien led-boards gekocht. Het idee is om daarmee een monochroom LED-display van 96x48 pixels te maken wat realtime bestuurd kan worden door de PC.

De borden

De borden van Baco zijn blijkbaar uit een bestaand LED-display-iets; de naam 'comfuture ltd.' staat erop te lezen. Verder is er niet zo heel veel over bekend. Nou, dat word dus reverse-engineeren

Het lijkt erop dat het board bedoeld is om in serie met z'n maatjes geschakeld te worden: zowel J1 als J2 lijken data te vervoeren. J1 doet dat echter naar de electronica toe, terwijl J2 meer van de electronica af vervoert. Na wat zoeken kwam ik uit op deze pinout:

nc	15	16	GND
LDAT	13	14	GND
nc	11	12	GND
UDAT	9	10	GND
A2	7	8	GND
A1	5	6	/OE
A0	3	4	STROBE
CLK	1	2	GND

Aansturen

Ok, hoe stuur je nu zo'n bord aan? Het kreng zelf is niet intelligent om zelf z'n beeld te behouden, wat betekent dat we een microcontroller nodig hebben om het beeld er tientallen of zelfs honderden keren per seconde heen te sturen. Hoe gebeurt dat? Ten eerste moet je weten dat het bord is onderverdeeld in een bovenste en een onderste helft. Deze twee helften hebben twee aparte data-ingangen, namelijk LDAT en UDAT. Het idee is dat daar ism CLK de regel die je wil weergeven ingeklokt word. In pseudo-code, geoptimaliseerd voor leesbaarheid, maak je zo een compleet beeld:

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 hoog
  wacht een tijd, afhankelijk van de gewenste refreshrate
 }
}

Grijstinten

of eigenlijk roodtinten... Da's allemaal leuk als je wat tekst wil weergeven, maar wat nou als je verschillende intensiteiten wilt weergeven? Als je naar de hardware kijkt, zou je zeggen dat dat onmogelijk is: we kunnen alleen maar een led aan- of uitzetten. Door een smerig truukje is het toch mogelijk: als we het display niet honderd, maar bijvoorbeeld tienduizend keer per seconde verversen, kunnen we de LEDs gaan PWMmen. Het nadeel is wel dat dit redelijk opvalt: als een compleet bord met 50Hz naar je staat te knipperen, valt dat wel op. Daar is echter omheen te werken: als we ervoor zorgen dat elke pixel 90 graden uit fase knippert met z'n dichtbijzijnde buurman, valt het ineens een heel stuk minder op dat alles aan het knipperen is. Voor implementatiedetails, zie de sourcecode later in deze post.

Hardware

Theorie is leuk natuurlijk, maar hoe gaat dat nou in de praktijk werken? Ten eerste is er een microcontroller nodig. Omdat we een redelijke snelheid willen halen ivm het grijstintenverhaal, is enkele tientallen mips aan processing-power toch wel gewenst. Ook zou meer dan een halve K aan RAM practisch zijn: op die manier kunnen we het huidige beeld gewoon in een array zetten waar de display-routine weer uit kan lezen. Al met al ben ik uitgekomen op een ATMega88: met z'n 1K aan SRAM is er genoeg geheugen voor een displaybuffer en met 20MHz (a ongeveer 1 mips per MHz) moet 'ie toch redelijk rap pixels uit kunnen spugen.

Uiteindelijk heb ik een leuk klein printje gemaakt. Een schema ga ik hier niet posten, de belangrijkste connecties staan in de code. Een pic kan je wel van me krijgen:

Het ding is zo gemaakt dat het direct op de header past. De kabel die je ziet is voor het programmeren van de AVR.

Resultaat

De theorie die hierboven staat is omgezet in een net C-programmaatje en met avr-gcc geprogrammeerd. Naast de display-routine zit er een plaatje in en een plasma-functie die geleend is uit mijn demo voor het HD44780-microcontest.

De code ervan is downloadbaar en gelicenseerd onder de GPLv3.

ToDo

• Intensiteit exponentieel maken. Door een eigenschap van het menselijk oog lijkt er veel verschil tussen de lagere intensiteiten te zitten en veel minder verschil tussen de hogere.
• Connectie met de PC maken. Voor 1 board kan dat nog wel een standaard serieele verbinding zijn, maar 96px*48px*8bit*25fps=~1mbit aan data.
• Meerdere uCboards maken voor de andere 8 led-boards
• Spul fysiek aan elkaar vastmaken
• Plugin voor MPlayer of een andere video-afspeel-unit maken

[Verwijderd]

Zou je geen PWM signaal naar de leds kunnen sturen als toch de display continu moet refreshen? Op die manier kun je misschien wel 2 of 3 'kleuren' implementeren

Doh, dat had je zelf al verzonnen, najah het is laat zullen we maar zeggen

[ Voor 19% gewijzigd door Verwijderd op 18-04-2008 01:47 ]

[Sprite_tm]

Heb je het filmpje bekeken? Het is me al gelukt om iig 5-bit grijstinten goed werkend te krijgen

[Verwijderd]

Filmpje werkt hier niet helaas, zit op een console met beperkte beveiligingsinstellingen (en gelukkig kan ik via via wel op GoT )

[mace]

Ik hoop die van mij morgen te mogen ontvangen, dan kan ik ook aan de slag.

Leuk projectje ook om op hackaday te submitten.

[Sprite_tm]

Ik ben nou toch aan het twijfelen... Het oorspronkelijke plan om de 9 LED-displays die in het geheel zitten aan te sturen, was om elk board te voorzien van een eigen ATMega88 om dan de display-data via een serieele lijn aan alle ATMega's door te sturen. Leuk en extendible, maar het betekent 9 keer een printje inelkaarsolderen, toch een paar tientjes aan AVRs e.d, plus het schrijven of aanpassen van een bootloader om te voorkomen dat alle AVRs apart via ISP geprogrammeerd moeten worden.

Het alternatief is om met zwaar geschut te komen. Een LPC2103 draait op 70MHz ipv 20MHz, het is een 32-bitter (waar misbruik van gemaakt kan worden door bijvoorbeeld vier pixels tegelijkertijd te processen) en heeft ook RAM genoeg om het hele display in op te slaan. Het nadeel is dat het een tqfp-dingetje is, wat betekent dat het ontwerp lastig na te bouwen is, en dat het niet extendible is: het idee met de AVRs is uitbreidbaar door stomweg nog een AVR aan het geheel te knopen.

Waar zouden jullie voor gaan? 1 brute ARM, of 9 kleine AVRretjes?

[mace]

Voor die tqfp is wel een adapter te krijgen natuurlijk.
http://www.futurlec.com/SMD_Adapters.shtml

Misschien kun je uiteindelijk wel wat met niels regelen en een inkoopactie organiseren.

Ik ben zelf eerder geneigd om met meerdere AVR's te werken want dan is het gewoon modulair, zodat de persoon met 1 schermpje en de persoon met 10 gewoon de hardware erop kan aanpassen.

Is een FPGA geen optie overigens?

[ Voor 36% gewijzigd door mace op 18-04-2008 16:15 ]

[Sprite_tm]

Het nadeel van een fpga is dat het vaak nog slechter te solderen en te verkrijgen is dan een uC. In principe zou een fpga zelfs iets beter zijn voor dit doel, maar in de praktijk houd ik het dus op een uC.

[mace]

Spartans kan je nog krijgen in PLCC geloof ik. Een simpele spartan moet toch genoeg zijn?
Of ben je meer van de Altera's ?

En is een 68HC11 een optie? Zijn die snel genoeg?
Je kan ze makkelijk krijgen en in een hele rits packages.

[ Voor 31% gewijzigd door mace op 18-04-2008 17:45 ]

[Sprite_tm]

68hc11 is afaik niet zo snel; iirc haalt een AVR ze zo in. Spartans in PLCC, is daar ook een beetje aan te komen dan?

Ik ben nog ff mplayer wezen hacken en de non-lineaire led-uitsturing wezen implementeren. Meteen maar eens een leuk testfilmpje gepakt en dit is het resultaat:

Niet slecht voor hardware die slechts 0,1% van de originele video-info kan weergeven

[Verwijderd]

Ik blijf versteld staan van die dingen die jij bouwt Sprite, keep op the good work

[Xiphalon]

Heb je nou een dode pixel (10e regel, 6e kolom?)

offtopic:
tiete!!!!oneone

[Sprite_tm]

Yep; da's 1 van de redenen dat ik 10 boards voor een display van 9 boards gehaald heb.

[Sprite_tm]

Woei, in de afgelopen uren heb ik de datarate weten te verhogen naar een halve MBit en nog 3 led-modules opgebouwd. Het resultaat van het vele prutsen:

In andere woorden: ik ga toch voor ATMega88'en; de boards zijn redelijk simpel op te bouwen en de bitrate houden ze zelfs icm het processor-intensieve PWMmen best goed bij.

Puntje 3: De 5 andere boards opbouwen... daar zal ik eerst onderdelen voor moeten halen; 5 ATMega88s heb ik niet meer en ik heb nu al wat printen moeten slopen om de IC-voetjes te halen...

Wat trouwens niet te zien is is dat ik een bootloader die ik al een tijd terug geschreven heb, aangepast heb voor deze situatie. Werkt prima: je reset het display en je hebt 3 seconden om een nieuwe firmware-upload te starten. Een paar seconden later draait je nieuwe programma. Allemaal via dezelfde lijn als waardoor de beeld-data ook komt.

Wat verder opvalt is dat ik naast een board met een falende pixel, ook een board heb waar het een of ander op ingebrand is. (In de video het board rechtsonder.) Ik hoop maar dat dat de enige is; het stoort best wel...

ToDo: de 5 andere borden fixen, hopen dat de halve MBit snel genoeg is om 9 boards te voorzien van data.

[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.