-
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
