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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
IMG_20241204_190325_313.jpg
(140 KB)
