touchpad ili9341 will nicht wie es soll

[Karl K. (leluno)]

hallo,

versuche mich gerade am Umstieg WIN-avr auf stm-cube.

Probleme habe ich mit dem ili-touchpad.

Egal wo man drückt - es gibt immer eine Punktwolke in der rechten 
unteren Ecke. Die Schreib- und Lesefunktion scheint o.k. zu sein. Die 
auf dem tft angezeigten Werte raw_x/raw_y schwanken zwischen hoch und 
niedrig ohne dass ein Bezug zum gedrückten Bereich festzustellen ist.

Harware- oder Software-Problem?

Danke für Unterstützung

[Harald K. (kirnbichler)]

war da nicht was, daß man resistive Touchpanels kalibrieren muss? Denn 
das ist das Ding, resistiv.

[Karl K. (leluno)]

Harald K. schrieb:
> kalibrieren

Im code ist eine Kalibrierung drin. Die raw-Werte - vor der Kalibrierung 
- müssten sich aber entsprechend der gedrückten Position verändern - tun 
sie aber nicht.

[Hmmm (hmmm)]

Karl K. schrieb:
> Die raw-Werte - vor der Kalibrierung
> - müssten sich aber entsprechend der gedrückten Position verändern - tun
> sie aber nicht.

Wenn das oben die Raw-Werte sind, schreien die nach einem Fehler beim 
Einlesen oder Verarbeiten der Daten, das sind 0x5fff und 0xff.

[Wastl (hartundweichware)]

Karl K. schrieb:
> Harware- oder Software-Problem?

Hast du berücksichtigt dass die SPI-Clockrate passend niedrig
eingestellt sein muss? Die wichtigsten Werte für Clock Zyklus
sind für Low und High jeweils 200 nsec, ergibt schon mal einen
Maximalwert von ca. 2.5 MHz für die Taktrate.

[Karl K. (leluno)]

Wastl schrieb:
> 200 nsec,

               TP_CLK_PORT->BSRR=TP_CLK_PIN;
                _delay_us(50);
               TP_CLK_PORT->BSRR=TP_CLK_PIN<<16;
               _delay_us(50);

Danke, das probier ich aus.

[Wastl (hartundweichware)]

Karl K. schrieb:
> _delay_us(50);

Ist das dein Ernst? Das ist unnötig lang .....

Meine Bemerkung zum Taktzyklus sind die Werte für die minimale
Periodendauer, natürlich dürfen die länger sein.

Ausserdem blockierst du deinen Controller unnötig lang mit
deinen Delays. Nutze doch einen SPI Controller zum
Kommunizieren mit dem XPT2046.

[Wastl (hartundweichware)]

Karl K. schrieb:
> versuche mich gerade am Umstieg WIN-avr auf stm-cube

Von CubeMx kann ich in deinen Sourcen aber nichts erkennen.

[Karl K. (leluno)]

Wastl schrieb:
> Nutze doch einen SPI Controller zum
> Kommunizieren mit dem XPT2046.

Ich hab die pins für spi5 angeschlossen. Nachdem das nicht ging hab ich 
auf den software-spi umgestellt. Der software-spi ist ausweislich des 
Osci wohl ok. Es wird gesendet und empfangen. Nur was empfangen wird ist 
leider Mist.

Es geht jetzt erst mal um Fehlersuche - auf hw-spi kann ich umstellen 
wenn es mit dem sw-spi geklappt hat.


Wastl schrieb:
> Von CubeMx kann ich in deinen Sourcen aber nichts erkennen.

Ich versuche registernah zu programmieren.

[Wastl (hartundweichware)]

Karl K. schrieb:
> Ich versuche registernah zu programmieren.

Das funktioniert auch prächtig mit den Low-Level-Libraries.
Wenn du deren Makros benutzt bist du weitgehend unabhängig
von der Art des STM32-Controllers.

Karl K. schrieb:
> Nachdem das nicht ging hab ich
> auf den software-spi umgestellt.

Das umgeht man indem man einfach die Hardware in CubeMx
initialisieren lässt. Dort beim Code-Generieren immer die
LL Libraries, nicht die HAL Libraries verwenden, dann kann
man sehr registernah Programmieren ohne ein einziges
Register mit Namen zu kennen.

[Wastl (hartundweichware)]

Karl K. schrieb:
> versuche mich gerade am Umstieg WIN-avr auf stm-cube

Du verwendest - dem Foto nach zu urteilen - ein Blackpill
Modul. Ist es ein F401 oder ein F411? Man könnte sich mit
CubeMX sehr schnell ein funktionsfähiges Gerüst aufbauen.

[Harry L. (mysth)]

Wastl schrieb:
> nicht die HAL Libraries verwenden, dann kann
> man sehr registernah Programmieren ohne ein einziges
> Register mit Namen zu kennen.

Sowas Triviales kann man deutlich komfortabler mit HAL erschlagen.
LL hat natürlich seine Berechtigung, aber ganz sicher nicht in diesem 
Fall.

Auch mit HAL kommt man direkt an die Register - was aber in den meisten 
Fällen gar nicht erforderlich ist, wenn man das von Anfang an in CubeMX 
korrekt definiert.

[Wastl (hartundweichware)]

Harry L. schrieb:
> Sowas Triviales kann man deutlich komfortabler mit HAL erschlagen.
> LL hat natürlich seine Berechtigung, aber ganz sicher nicht in diesem
> Fall.

Vielleicht möchte der TO das aber nicht?

Karl K. schrieb:
> Ich versuche registernah zu programmieren.

[Harry L. (mysth)]

Wastl schrieb:
> Harry L. schrieb:
>> Sowas Triviales kann man deutlich komfortabler mit HAL erschlagen.
>> LL hat natürlich seine Berechtigung, aber ganz sicher nicht in diesem
>> Fall.
>
> Vielleicht möchte der TO das aber nicht?
>
> Karl K. schrieb:
>> Ich versuche registernah zu programmieren.

Ja...typisch Anfänger.
Die haben irgendwo aufgeschnappt, daß man als Profi jedes Bit mit 
Vornamen kennen muß, und deshalb ist es ja total cool, das Rad jeden Tag 
neu zu erfinden.

[Karl K. (leluno)]

Wastl schrieb:
> Man könnte sich mit
> CubeMX sehr schnell ein funktionsfähiges Gerüst aufbauen.

Naja - sehr schnell ist relativ. Bis das ili9341 lief, das war für mich 
schon grenzwertige Quälerei. Ich denke aber auch, wenn die 
Grundfunktionen erst mal funktionieren ist das ein tolles System. 
Blackpill F411 ist auch eine andere Hausnummer wie der M328Nano - und 
das ganze für rund 6€.

Habe mir jetzt das Datenblatt für den xpt2046 heruntergeladen. Man kann 
da noch bisschen was beim Schreibbefehl einstellen. Das werde ich morgen 
mal ausprobieren.

[Harry L. (mysth)]

Karl K. schrieb:
> Habe mir jetzt das Datenblatt für den xpt2046 heruntergeladen.

Wie hat du denn vorher überhaupt Code dafür geschrieben? kopfschüttel

Normalerweise besorgt man sich das Datenblatt bevor man die erste 
Zeile Code schreibt.

[Karl K. (leluno)]

Harry L. schrieb:
> Wie hat du denn vorher überhaupt Code dafür geschrieben? kopfschüttel

Arbeit macht man sich nur wenn man muss. Wenn es fertigen Code im I-net 
gibt, probiert man den aus. Wenn es klappt ist gut, braucht man kein 
Datenblatt. Wenn es nicht klappt, muss man den Fehler suchen, dann ist 
ein Datasheet hilfreich. Ich habe noch mehr vor und hätte den Aufwand 
mit dem tp gern gering gehalten.

[Harry L. (mysth)]

Karl K. schrieb:
> Harry L. schrieb:
>> Wie hat du denn vorher überhaupt Code dafür geschrieben? kopfschüttel
>
> Arbeit macht man sich nur wenn man muss. Wenn es fertigen Code im I-net
> gibt, probiert man den aus. Wenn es klappt ist gut, braucht man kein
> Datenblatt. Wenn es nicht klappt, muss man den Fehler suchen, dann ist
> ein Datasheet hilfreich. Ich habe noch mehr vor und hätte den Aufwand
> mit dem tp gern gering gehalten.


Karl K. schrieb:
> Ich versuche registernah zu programmieren.

Aha!
Und das ohne Datenblatt!? - Respekt!

Merkste selbst oder?

Bei so einer Herangehensweise empfehle ich dir dringend, dir ein anderes 
Hobby zu suchen!

[Karl K. (leluno)]

clk und Miso -
man sieht, dass bei jedem zweiten Durchgang keine Daten gesendet werden. 
Habe jetzt die Zeiten in den Nano-Bereich geändert und verschiedene Modi 
ausprobiert -
TP_Writex(READ_Y|(1<<6)|(1<<2));
-
bringt alles nichts. Ich lass das mit dem TP wohl erst mal sein.

[Cyblord -. (cyblord)]

Karl K. schrieb:
> versuche mich gerade am Umstieg WIN-avr auf stm-cube.

Irgendwie klingt dein Problem so gar nicht als wäre es auf einen Wechsel 
der Entwicklungsumgebung zurückzuführen.

Ist es nicht eher so dass du damit auch einen komplett anderen 
Controller verwendest?

[Wastl (hartundweichware)]

Hier mal ein Design-Vorschlag wie ich das machen würde.
Alle Low-Level (Register-) Zugriffe über die LL Libraries.
Kein HAL und kein einziger Register-Name wird verwendet,
ausser bei den (optimierten) SPI-Zugriffen.
Trotzdem schnell und effizient, "man" versteht es sogar,
was man bei HAL Aufrufen nicht immer behaupten kann.

SPI1 für TFT, SPI2 für Touch Controller.

Das ist ein Atollic Studio Projekt, kann leicht in die
CubeIDE importiert werden.

[Wastl (hartundweichware)]

Karl K. schrieb:
> man sieht, dass bei jedem zweiten Durchgang keine Daten gesendet werden.

Man sieht dass man nichts sieht, da du nicht zeigst bzw. erklärst
was genau du machst. Es liegt in der Natur der Sache dass man von
einem SPI Slave erst etwas bekommt wenn man ihm sagt was er tun
soll. Soviel zu der unklaren Aussage "jeder zweite Durchgang".

Karl K. schrieb:
> Habe jetzt die Zeiten in den Nano-Bereich geändert

Wastl schrieb:
> Meine Bemerkung zum Taktzyklus sind die Werte für die minimale
> Periodendauer, natürlich dürfen die länger sein.

[Karl K. (leluno)]

Wastl schrieb:
> Man sieht dass man nichts sieht,

Man sieht einzelne 24-bit cyclen, die durch ein längeres delay 
abgegrenzt sind.

cyclus 1,2,4 und 6 sind ok: 8cyclen Mosi werden nicht dargestellt das 
das oszi nur 2Kanäle hat, dann kommen 16cyclen Miso. Bei cyclen 3,5,7 
kommt auf Miso gar nichts.

Wastl schrieb:
> Hier mal ein Design-Vorschlag

Ich versuche ja, einheitlich mit dem avr zu programmieren. Bei mir sieht 
das zur Zeit so aus:

#define GLUE(a, b) a##b
#define GPIO(x) GLUE(GPIO,x)
#define reg_dir_out(port,pin) \
  {GPIO(port)->MODER&=~(0b11<<(pin*2)); \
  GPIO(port)->MODER|= (0b01<<(pin*2)); \
  GPIO(port)->PUPDR&=~(0b11<<(pin*2)); \
  GPIO(port)->OTYPER&=~(1<<pin); \
  GPIO(port)->OSPEEDR&=~(0b11<<pin);}
#define reg_dir_in(port,pin,pullup) \
  {/* 0b00no 0b01pu 0b10pd */ \
  GPIO(port)->MODER&=~(0b11<<(pin*2)); \
  GPIO(port)->PUPDR&=~(0b11<<(pin*2)); \
  GPIO(port)->PUPDR|= (pullup<<(pin*2));}


#define pinset(x,y)  GPIO(x)->BSRR|=(1<<y)
#define pinclr(x,y)  GPIO(x)->BSRR|=(1<<(y+16))
#define pinget(x,y)  (GPIO(x)->IDR & (1<<(y)))

#define led1_port     C
#define led1_pin      13

#define led1_tog  GPIO(led1_port)->ODR ^=(1<<led1_pin)
#define led1_on   GPIO(led1_port)->BSRR|=(1<<led1_pin)
#define led1_off  GPIO(led1_port)->BSRR|=(1<<(led1_pin+16))

aus
HAL_GPIO_WritePin(GPIOC, GPIO_PIN_13, GPIO_PIN_RESET);
wird dann
pinclr(C,13);


Aber das ist zur Zeit noch nicht die Baustelle. Im Prinzip möchte ich 
aber von
dem Code-Mischmasch
 /* USER CODE BEGIN USART2_Init 2 */

  /* USER CODE END USART2_Init 2 */
zwischen eigenem Code und Cube-generiertem Code weg. Nur die 
Grundeinstellungen von Cube und den Rest in eigenen Code-files.