[EiP] 96x48 monochroom LED-display

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!

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

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.

Sprite_tm wijzigde dit bericht 20-04-2008 16:04 (5%)

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

Zjosh wijzigde dit bericht 20-04-2008 16:15 (60%)

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.

real_FireFly wijzigde dit bericht 20-04-2008 17:32 (25%)

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

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

Zjosh wijzigde dit bericht 20-04-2008 19:09 (34%)

quote:

ThinkPad 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)

quote:

ThinkPad 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>

surge_me wijzigde dit bericht 20-04-2008 21:59 (21%)

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:

1 2	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:

1 2 3 4 5 6 7 8 9 10 11 12

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

Zjosh wijzigde dit bericht 22-04-2008 20:45 (14%)

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.

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.

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

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.

Dan moet je VxWorks of RTlinux gaan draaien ofzo.

mace wijzigde dit bericht 23-04-2008 19:14 (3%)

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

ssj3gohan wijzigde dit bericht 23-04-2008 21:02 (34%)

quote:

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)

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.

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.

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

ssj3gohan wijzigde dit bericht 24-04-2008 22:28 (23%)

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

ssj3gohan wijzigde dit bericht 25-04-2008 07:57 (5%)

quote:

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

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

real_FireFly wijzigde dit bericht 27-04-2008 15:05 (62%)

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

ssj3gohan wijzigde dit bericht 27-04-2008 15:58 (26%)

Whieieieie

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

ssj3gohan wijzigde dit bericht 27-04-2008 23:28 (65%)