-
@skg-rob
Die Reihenfolge ist ja erstmal LCD->Mega8 oder sonstwas zum ansteuern des LCD und von dort aus auf das TWI also an dein Board. Das Touchscreen und das LCD gehen nur auf den Mega8 ,Du kannst natürlich allerlei mögliche Spielereien einprogrammieren wo die Daten für ein Bild auf dem Display herkommen ,grundsätzlich würde ich es aber erstma auf den Mega8 oder 32 oder ... belassen.Für das Touch gabs damals ein super Appnote was die 4 Wire Tech. erläutert und auch Schaltungs und Ansteuerungsbeispiele bereithielt.
Ah hier isses ja :http://www.atmel.com/dyn/resources/p...ts/doc8091.pdf
MFG Hellsing
-
Wie komme ich dann von dem Mega 8 auf das Board?
Hab leider null Ahnung.
-
Das Display wird von dem Mega8 oder wie vorne verwendet ein Mega32 angesteuert . der Mega8 oder 32 stellt aber auch gleichzeitig den TWI bereit, wodurch du auf dein Board gehen kannst.
MFG Hellsing
-
Mann bin ich blöd...
Kann ich das Display auch über das hier ansteuern?
http://qfix-shop.de/cgi/websale6.cgi...c951615%2fmd5}
-
Hat ja im Prinzip auch einen TWI bus drinne also sollte es gehen ,musst blos wegen den PullUp Widerständen schauen wo die sind und ob sie schon eingebaut sind sonst müssen die noch dazu. Vorne im Thread gibts nen schaltplan von Flashover da wurden blos die TWI Pins des Mega32 fürs LCD benutzt (nicht so dolle) ,also muss da was umgemoddelt werden was zur folge hat wenn du die hier herausgegebenen Sources nutzen willst auch da etwas ändern musst.
MFG Hellsing
-
Dann kann ich auch gelich einen Mega 8 nehmen.
Danke, den rest werde ich dann hinkriegen.
-
Naja Mega8 ist sehr schnell Voll von den Pins und auch vom Speicher. So teuer ist ja ein Mega32 oder 644P nicht und am Ende biste froh mehr Speicher zu haben
MFG Hellsing
-
Hmm ja einen einzelnen kannich natürlich auch nehmen. Aber es geht mehr um den Aufwand: Wenn ich noch alles zusätzlich umschreiben muss großteils dann wird es zu aufwändig.
Trozdem Danke.
-
Naja vorne im Thread wurde ja ein Mega32 verwendet. Es ging beim umschreiben eher um die zurzeit benutzen TWI Pins damit du Sie für den TWI Bus nutzen kannst.
MFG Hellsing
-
Dann ist es noch besser, dann versuch ich es direkt mit dem BobbyBoard.
-
schau aber nach den PullUp Widerstanden für den TWI Bus sonst gehts nid wenn sie nicht da sind ;)
MFG Hellsing
-
Also ich kann dir sagen das das auslesen von Sonars und das Qfix display gehen. Kannst du daraus ersehen ob sie da sind?
-
Naja sinn würde es machen wenn die PullUps auf dem Mainboard sind wenn das TWI mit den anderen Sachen läuft schauts doch schonmal gut aus
MFG Hellsing
-
Also da ich selbst vor habe das Display über TWI an meinen Roboter anzuschließen, kann ich gerne sobald ich es geschaft habe schaltplan und Libary online zu stellen. Ich denke bis Ende der Woche sollte ich erste Erfolge haben. Je nach dem ob ich meine Teile schnell zugeschickt bekomme.
-
-
Hallo,
habe mein Display (das GLCD mit Touch von Pollin) mittlerweile auch soweit, dass ich mit dem Touchpad malen kann. Allerdings werden häufig Pixel völlig fehlplatziert, was vermutlich an dem empfindlichen Touchpad liegt.
Wollte mal nachfragen wie ihr das entprellen umgesetzt habt. Habt ihr da Tipps (theoretische Tipps reichen mir schon, will keinen Code, will ja selber noch etwas basteln ;-))? Ansonsten ist das GLCD ein super Teil, nur zu empfehlen.
Edit:
Ich sollte evtl. noch dazu sagen, dass ich den ADC bei jedem zeichnen 16x auslese und dann davon den Mittelwert erstelle und dementsprechend zeichne. Das Prellen wurde dadurch aber auch nicht vermindert
-
entprellen geht meist am bessten mit ner kleinen warteschleife nach dem Auslesen und dem nächsten auslesen. So wird theoretisch die Prellphase nicht berücksichtigt. Ich hoffe es klappt so. Bei Tastern funktioniert es.
Leider ist mein Touch kaputt und nur das Display geht. Schade
-
Hallo,
hat sich schon erledigt! Habs hinbekommen.
Ich hab den alten x und y Wert gespeichert und mit den neuen verglichen. Wenn die Differenz größer als 3px ist wird der Pixel nicht gezeichnet (natürlich noch mit ein paar mehr Abfragen, da es ja sonst nicht so klappen würde ;))
Aber das Touchscreen kann man doch mit einem Bügeleisen reparieren, ist doch meist nur der Folienleiter locker, oder?
Grüße
-
Klingt gut hab noch extra zu festellung der aktuellen X und Y Position eine Mittelwertbildung eingebaut die 100 mal misst und den daraus entstehenden Mittelwert nimmt, da ich im terminal schon manchmal einige ausreiser hatte.
Was noch ein problem meines Aufbaus war , durch die Huckpack anordnung gabs eine nette Einstreuung des Quarzes vom LCD auf die leitungen des Touch , sah im Oszi lustig aus war es aber leider in der praxis nicht ^^ ein paar Kondis in der leitung schafften abhilfe :)
MFG Hellsing
-
Hier mal ein Foto von meinem GLCD. Das Entprellen klappt leider noch nicht so wie ich mir das vorstell, da werden Pixel gezeichnet, wo sie eigentlich garnicht gezeichnet werden dürften (klar durch eine if-Abfrage festgelegt!). Muss ich mal gucken wo da der Hund begraben liegt.
Im Anhang das Bild.
Das Schreiben auf Touchpads ist irgendwie ungewohnt, deshalb sieht's so hingekritzelt aus. Oben in der Menüleiste läuft eine Uhr (32,786kHz Quarz an TOSC1 und TOSC2 vom Atmega32) und zusätzlich wird die Temperatur der Umgebung durch einen DS1820 angezeigt.
Auch sieht man die Streupixel um die Schrift herum und die oberhalb des Striches der die Menüleiste abtrennt, dort sollte normal kein Pixel mehr erscheinen (if(y>15) { zeichnePixel(x,y); } so ungefähr)
@ Hellsing:
ja, ich messe die ADC-Werte 16x und berechne dann den Mittelwert.
Grüße
Edit: das mit dem Anhängen klappt wohl nicht so, da mein Attachement angeblich zu groß sei (70kb). Naja, dann machen wir's eben so:
Bild hier
-
sieht doch schick aus, das bringt einen auf ideen ^^
lass dir doch mal die gemessenen werte am PC ausgeben (iwie ne rs232 verbindung dazufummeln) und werte die koordinaten mal grafisch aus! vielleicht hast du nen fehler in deiner pixelformel, vielleicht aber auch eine störung elektrischer natur beim schreiben an das display, da kannst du dir die bilddaten auch mal an den PC senden lassen und kontrollieren ob die normal aussehen während auf dem display wieder "kleckse" sind
extreme pixelkleckse die irgendwo rumstreunen kann man zur not sofern die rechenzeit es zulässt auch einfach mit der 8er nachbarschaft einzelne pixel ausschliessen, erst wenn ein pixel in seiner 8er umgebnug noch einen pixel hat, wird er dargestellt sonst nicht
kannst ja mal versuchen ob du nich irgendwann nen ADS7843 einsetzen kannst, spart sicher unmengen rechenzeit wenn du die cursordaten nurnoch per SPI auslesen musst und ich geh mal davon aus, dass der die positionsdaten vernünftig "entprellt" wenn das der wahre grund für deine kleckse sein sollte
-
Spessi versuch mal mehr Werte (hab sogar 200 bei mir),das ist scheinbar das Problem was ich auch hatte , andererseits existiert sowas in der Art immernoch wenn man "zuviel" rumklickt aber sehr marginal(vernachlässigbar). Benutze da zum überprüfen ein UART-> PC Diagramm Programm wo man schön den verlauf der jeweiligen X oder Y Werte nach der Zeit ablesen kann und ausreiser sofort erkennt.
MFG Hellsing
-
Zuerst mal der Codeabschnitt:
Code:
unsigned char x, x_old, y, y_old, new_touch;
void glcd_touch_draw() {
uint16_t adc_x, adc_y; // garantiert immer mit den gleichen adc werten arbeiten
adc_x = glcd_touch_read_x();
adc_y = glcd_touch_read_y();
if(adc_x<13600) { /* Wenn Touchpad berührt dann */
/* x = (adc_x - adc_min_x) / ((adc_max_x-adc_min_x) / auflösung x); */
x = (adc_x - 220*16) / (((850-220)*16) / 160);
y = 80-((adc_y - 280*16) / (((770-280)*16) / 80));
if(y>15) { /* 15px Leiste oben (nicht zu bezeichnen) */
if(new_touch==1) { /* wenn stift neu aufsetzt ist alter x-wert ungültig */
glcd_plot_pixel(x,y, PIXEL_ON);
}
else { /* entprellen */
if(((x-x_old)<3) && ((x-x_old)>-3))
if(((y-y_old)<3) && ((y-y_old)>-3))
glcd_plot_pixel(x,y, PIXEL_ON);
}
}
x_old=x;
y_old=y;
glcd_touch_collision(x,y); /* Buttons abfragen */
new_touch=0;
}
else {
new_touch=1;
}
}
Durch das if(y>15) { sollte eigentlich garantiert sein, dass NIE gezeichnet wird, wenn der y-Wert kleiner als 15 ist.. dennoch werden teilweise Pixel viel weiter oben gezeichnet. Erklären kann ich mir das nicht. Vielleicht verbessert es sich, wenn ich die ADC Werte öfter einlese, aber dennoch würde ich gerne verstehen, weshalb er auf die Idee kommt plötzlich Pixel oberhalb der y=15 zu zeichnen
Edit: Wenn ich das Programm lange genug laufen lasse verschwinden teilweise sogar Pixel vom Rechteck oben (das in dem "Clr" steht)... Erklären kann ich mir das nun beim besten Willen nicht
Hier noch die plot Funktion:
Code:
void glcd_plot_pixel(unsigned int x, unsigned int y, unsigned char state) {
unsigned char pos;
if(glcd_mode==GLCD_GRAPHIC) {
glcd_moveto(x, y);
pos = x%8;
if (state == PIXEL_ON)
glcd_write(GLCD_CMD_SET_BIT, pos);
else
glcd_write(GLCD_CMD_CLEAR_BIT, pos);
}
}
Grüße
-
Ka ob das vielleicht ein Problem ist aber schau mal bei deiner Auflösungsümrechnung du schreibst da
x = (adc_x - 220*16) / (((850-220)*16) / 160);
würde mir sorgen machen wo der was zwischenspeichert wenn man Quasi als adc_x 13600 im max. annimmt und das noch mit 16 multipliziert = 217600 vielleicht läuft ja irgendwo was über?
MFG Hellsing
-
Hallo, ich multipliziere doch das adc_x nicht mit 16, sondern die 220 (punkt vor strich).
Im Auslesevorgang lese ich den ADC 16 Mal aus und addiere die Ergebnisse zusammen. Pro Auslesegang hab ich max. 850. 850*16 = 13600 < 65535
-
ahjo das passiert wenn man nur halbschief draufschaut hast recht ^^
zurzeit blick ich hier noch nicht ganz durch :
else { /* entprellen */
if(((x-x_old)<3) && ((x-x_old)>-3))
if(((y-y_old)<3) && ((y-y_old)>-3))
glcd_plot_pixel(x,y, PIXEL_ON);
du sagst doch wenn die Koordinatenabweichung jeweils -3<x<3 ist dann plote , was passiert wenn du kurz unterm 15px bereich bist und dann in die Verknüpfung kommst ? würde er dann nicht auch zeichnen ? als Beispiel du bist bei y=16 dann wirkt die If(y>15) dann wenn du weiter höher gehst um 2 px jeweils würdest du doch langsam in den bereich kommen?
MFG Hellsing
-
Naja, du musst ja bedenken dass ich in der komplette Funktion von oben ab mit den gleichen y-Werten arbeite.
Sprich: wenn ich bei y=16 bin, dann zeichnet er ganz normal und sobald ich höher komme filtert beim nächsten Durchlauf automatisch die if-Abfrage die ungültigen Werte raus, sprich: er zeichnet nicht mehr.
Ich werde morgen mal was anderes ausprobieren: zur Zeit messe ich den x-Wert 16x hintereinander und anschließend den y-Wert 16x hintereinander.
Ich probiere mal aus immer nacheinander zu messen, also xyxyxy....(usw.). Evtl. wird dadurch das prellen etwas mehr entschärft...
-
Ahh ja jetzt seh ich das zweite if dadrin hab gedacht das else gehört mit zur if(y>15)...
Naja das abwechselnd Messen könntest du versuchen ,habs zwar auch nicht gemacht, will es aber auch mal mit einfliessen lassen, vielleicht erhöht es ja bei mir auch noch ein weng die Genauigkeit. Hab aber jetzt noch 7 h an der FH zu tun , heute nachmittag werd ichs mal mit einbauen.
MFG Hellsing
-
Hallo, hab den Fehler gefunden!
Das ganze lag daran, dass ich in der main Funktion eine While-Schleife hatte und gleichzeitig Interrupts hatte, die die Uhrzeit und Temperatur ausgeben. Dadurch wurde die While-Schleife unterbrochen und es kam zu so komischen Ergebnissen.
Das heißt ich musste in der While Funktion am Anfang ein cli(); und am Ende ein sei(); machen und schon gings.
-
na super !!
naja bei mir waren es nun aus 7h an der FH 11h geworden..., werd mich jetzt noch ein wenig an das lcd wagen um die sd card weiter zu implementieren.
MFG Hellsing
-
Hi!
Habe mir jetzt auch diese Display zuglegt und würde mir dafür gern ne Platine ätzen. Allerdings hat mein Touch diesen Graphit-Folienleiter, an den man nichts ranlöten kann... Deshalb würde mich mal interessieren, was für eine Buchse man da für Platinen nehmen kann. Das sah bei Hellsing auf der Platine schon gut aus, aber wo finde ich sowas, z.B. bei Reichelt?
-
Moin
Also ich hab das ganze ohne irgendwelche Spezialteile gelöst.
Ich hab so eine Pin/Stiftleiste genommen und das Plastikzeug was da unten dran ist, dünner gefeilt.
Auf der Platine gibts dann unten 4 Leiterbahnen auf die die Stifleiste aufelötet wird.
Dann kann man den Folienleiter einfach zwischen Stiftleiste und Leiterbahn einklemmen.
Bild hier
Bild hier
Das funktioniert ziemlich gut und hält auch einigermaßen fest zusammen.
Sebastian
-
Total genial!
Das ist ein SUPER Tipp!!
Vielen Dank!!
-
Das ist wirklich ne tolle und vor allem kreative Lösung :wink:
Aber auf ner geätzten Platine, die "hübsch" (so gut das für eine Platine möglich ist) aussehen soll, ist es eher doch keine Lösung...
-
Das Anschließen des Touchpads hab' ich anders gelöst.
Beim Ausschlachten eines alten Telefons (Tastatur als Matrix mit Folienleiter)
fand sich ein perfektes Gegenstück. Geht prima. (google-suche >telefon grün<)
Außerdem noch zwei Widerstände à 560 k-Ohm zwischen den
Analogeingängen, die eingelesen werden und +5 Volt. Sonst "malt" das
Display von selbst. :-k
-
ich hab n problem mit meinem display, ich hab mir paar routinen für pixelschreiben und vektorgrafik zusammengeschustert, mein problem, was wenn 2 "drawline" zum beispiel ihre pixel im selben spaltenbyte haben .. meine idee, byte aus dem display lesen und mit dem neuen pixelbyte verodern .. idee klase, aber irgendwie bekomm cih nur mist wenn ich versuche ein byte aus dem display zu lesen ... zur schaltung, ich hab die datenleitungen über 1k auf GND gelegt, weil ich um kurzschlüsse zu vermeiden den datenport grundsätzlich auf high z lasse
-
@krtv_stsc:
Also es kommt drauf an, wenn man etwas sauberer arbeiten würde, (nicht wie ich irgenwann mitten in der Nacht) könnte ich damit Leben.
Design follows function.
Zumal ich ja noch keine (einfach irgendwo bestellbare) Alternative gefunden hab.
@BMS:
Ja klar das es von selbst matl, die ADCs in deinem AVR sind relativ empfindlich und hochohmig und in dem Moment wo das Display nicht berührt wird, hängt der quasi in der Luft.
Da bekommst du von überall her schöne Einstreuungen.
Deshalb überprüfe ich bevor ich Koordinaten auslese immer erst ob sich die X und die Y Folie überhaupt berühren.
Code:
uint8_t touch_is_pressed() {
TOUCH_DDR |= (1 << TOUCH_X1);
TOUCH_DDR |= (1 << TOUCH_Y1);
TOUCH_DDR &= ~(1 << TOUCH_X2);
TOUCH_PORT &= ~(1 << TOUCH_Y1);
TOUCH_PORT |= (1 << TOUCH_X1);
if(readADC(TOUCH_X2) < TOUCH_PRESSED_LEVEL) {
return 1;
}
else {
return 0;
}
}
Ohne Berührung liegen da am ADC so ziemlich die vollen 5V an.
Wird das Display berührt zieht die Y-Folie das mehr oder weniger auf Masse.
Jetzt muss man nur noch rumprobieren bis man einen Passenden Grenzwert hat und gut is.
@Ceos:
Lies mal im Datasheet für den lc7891 nach.
Da steht das wenn man Daten aus dem Memory lesen will, muss man erst ein dummy readout machen.
D.h. erst beim zweiten mal lesen hast du sinnvolle Daten. Der erste Readout is Müll.
Code:
uint8_t lcd_read_byte() {
uint8_t i,data;
for(i = 0; i < 2; i++) {
_delay_us(1);
lcd_rw_low();
lcd_rs_high();
LCD_DATA = 0x0D;
_delay_us(1);
lcd_en_high();
LCD_DATA_DDR = 0x00;
lcd_rs_low();
lcd_rw_high();
_delay_us(1);
data = (uint8_t) LCD_DATA_PIN;
lcd_en_low();
LCD_DATA_DDR = 0xFF;
}
return data;
}
Sebastian
-
ich weis zwar nicht ob wir beide vom selben controller reden (kann ich erst morgen anchprüfen) aber das datenblatt ist VERDAMMT MAGER, danke für den tip (steht wirklich nix in der form drinne, nur die hand voll befehle und wie die bytes dargestellt werden) meld mich morgen nachmittag nochmal
... sowas lästiges aber auch, könnte ich mir nich irgendwie mit nem zwischenspeicher aushelfen ? mein gedanke geht in richtung ram zwischen controller und display
in den ram schreib ich (wesentlich schneller als mit den schlechten timings des LCD) die daten rein und über nen mux und nen takt vom controller schieb ich dann die daten parallel zum prozessor in das LCD
hat vielleicht jemand ein paar eingebungen ?
-
Moin
Also sooo mager ist das ja auch nicht, für mich hats mit ein bischen rumprobieren gereicht.
Ich red über das Datasheet : http://www.datasheetcatalog.org/data...f_e/LC7981.pdf
Das mit dem dummy Readout steht Seite 13 in der Mitte unter 11) Reading display data.
Gruß
Sebastian
-
danke für den tip, hat 95% der lesefehler beseitigt ... aber in meinem datenblatt stands trotzdem nicht (LCD12864C)... fehler sind immernoch paar kleine da und performant iss was anderes, ich werd wohl in den sauren apfel beissen und das display im RAM vorrausberechnen und dann regelmäßig komplett auf das display shcreiben
ausserdem werd ich mir per uart bzw. SPI ein protokoll basteln so von wegen #dl,1,1,20,20 für drawline usw. damit ich das display mit nem M8 austattten und über einen M32 oder direkt vom PC aus ansteuern kann und übern eeprom vielleicht ne nen einprogrammierbares menü bauen .. ich will eigentlich nur alle knöpfe und regler für lüfter, an/aus, reset am PC ersetzen, vll. noch nen kapazitiven sensor rein, dmit das display angeht sobald man mit der hand in die nähe kommt
Update:
hab meins jetzt auch zum laufen bekommen, nachdem ich meinen touch-controller gegrillt hab (vergessen die widerstände zwischen display und controller zu tun) hab ichs jetzt auch mit µC-ADC gemacht
also ich mess nur einmal den wert und bekomm kaum sprünge, wie sieht dein schaltplan aus ?
würde mich mal interessieren, hab mit dem oszi ein paar faszinierende enteckungen gemacht was kapazitives verhalten der touchfolie angeht und wie bescheiden die werte sind und wie einfach man sich abhelfen kann
alles was aus linien aufgebaut ist kann ich jetzt mit ein paar drawlineanweisungen statt pixelkoordinaten darstelen .... aber die performanz iss bescheiden weil ich direkt aus dem display-ram lese ...
