Ik heb hier een GLCD 128*64 die net helemaal doet wat er verwacht word.
http://www.uploadarchief.net/files/download/glcd.jpg
Zoals je kan zien is de linker kan (controller0/CS0) ok, rechts is iets anders
Dit is mijn code (voor het resultaat wat op de foto te zien is): (C voor AVR-gcc)
int main(void){
sbi(DDRB, 0);
sbi(DDRB, 1);
sbi(PORTB, 0);
glcdInit();
u16 i;
u16 j;
u08 buff[3];
while(1){
glcdClr();
glcdSetAddress(1,LINE1);
glcdPutStr("Links=OK");
glcdSetAddress(50,LINE5);
glcdPutStr("Rechts=minder");
tbi(PORTB, 0);
_delay_ms(500);
}
return 1;
}
Ik dacht eerst dat er een fout zat in de software voor het aansturen van de 2e controller: dus heb ik CS0 & CS1 gewisselde zodat ik kon zien of het rechtse deel het nu wel goed deed: niet dus.
Bij een clear screen worden alle dots van de rechtse controller "geSet" en van de linkse (zoals het hoort) "geCleared". Maar ik kan wel met glcdClearDot(); dots uit doen in het rechtse deel, meer als met 2 for loops alles puntjes wil uit doen (fake-clear-screen dus) reset de controller zen eigen om de 10 lijnen. Dus: ik doe eerste 10 lijn uit, wanneer ik naar de 11e rij ga, springen alle dots van de eerste 10 rijen weer aan. En dit proces herhaalt z'n eigen om de 10 rijen.
Is de rechtse controller nu half rot ofzo?
RES
RES
Werk je met timing of busy flag polling? Neem aan dat je originele software gebruikt, of helemaal zelf geschreven?
Ik had zelfde problem ook ooit, toen ben ik overgestapt op busy flag polling. De timing is van groot belang, iets te snel en het mislukt.
Ik gebruik de originele library, en die werken via busyFlag.
Maar die functie is voor beide controllers hetzelfde, dus lijkt me raar dat daar het probleem zit.
http://nl.youtube.com/watch?v=8Ta_MWEoY3I
while(1){
glcdClr();
for(j=0; j<64; j++){
for(i=64; i<128; i++){
glcdClearDot(i,j);
_delay_ms(50);
}
}
tbi(PORTB, 0);
_delay_ms(500);
}
Dit is wat ik beschreef in de topic start post.
Die zijn juist, heb nogmaals gecontroleerd.
(en anders zou het andere deel toch ook niet werken?)
Heb je nog een 2e GLCD, zodat je de software kunt controleren ?
Helaas werk je met AVR's en ik met PIC's, anders had ik eventueel een progje liggen zodat je de GLCD kon testen...
Ik heb er maar 1.
En nog vergeten te melden: ik gebruik een mega16 in de test.
Ik denk dat men probleem toch wel eens de software kan zijn. Ik heb eens een test programma in bascom gemaakt, tis nog altijd niet goed (maar da zal wel aan bascom liggen, ik heb daar nog slechte ervaringen mee)
http://www.uploadarchief.net/files/download/glcd_.jpg
$regfile = "m16def.dat"
$crystal = 16000000
$lib "glcdKS108.lib"
config graphlcd=128*64sed, dataport=Portc, controlport=Portd, ce=3, ce2=4, cd=0, rd=1, reset=7, enable=2
setfont font6x8
$include "font6x8.font"
cls
do
wait 1
cls
lcdat 1, 1, "abcdefghijklmnopqrstuvwyz"
lcdat 2, 1, "01234567898765432101"
lcdat 3, 1, "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
loop
Ik zal eens gaan zoeken naar een andere glcd library (of heeft er misschien iemand 1?)
Ik ben niet thuis in AVR's, maar heb met een PIC samen met een GLCD wel eens problemen gehad als ik de progger op de PIC aangesloten liet zitten.
Dus als de progger continu aan de AVR hangt, haal deze dan eens even los...
Haalt niets uit (was te verwachten: MISO/MOSI/SCK waren niet gebruikt als LCD stuur pinnen)
Bij mij waren de datalijnen (D6 en D7) verbonden met de programmeer aansluitingen.
Ondanks dat de progger niet gebruikt werd, kreeg ik een raar scherm opbouw...
Opgelost.
Het lag dus wel aan de software.
ik heb nu een werkende library: http://www.scienceprog.com/controlling-graphical-128x64-lcd-based-on-k…
De hex voor het zelfde te doen met deze library is 2 maal groter! Maar het werkt... en zeer flexibel qua fonts enz