Probleme mit Stringlänge

[Ingo L. (corrtexx)]

Hallo,
ich habe folgende Funktion:

void EA_DOGM163_String( const char *Data )
{
    while( *Data != '\0' ){
      EA_DOGM163_Write_Data ( *Data++ , DATA );
    }
}

Folgendes geht und geht nicht, ich lande im Reset_Handler meines 
STM32F030 in Coocox wenn es nicht geht:
EA_DOGM163_String( "1" ); // geht
EA_DOGM163_String( "12" ); // geht nicht
EA_DOGM163_String( "123" ); // geht nicht
EA_DOGM163_String( "1234" ); // geht nicht
EA_DOGM163_String( "12345" ); // geht
...6 // geht nicht
...7 // geht nicht
...8 // geht nicht
...9 // geht

Es scheint irgendwas mit der Pointergröße zu tun zu haben? kann mir 
jemand helfen, komme absolut nicht weiter...

Viele Grüße,
Ingo

[Ingo L. (corrtexx)]

Hier noch:

void EA_DOGM163_Write_Data ( uint8_t Data, int RS )
{
  if ( RS ) {
     GPIOB->ODR |= GPIO_Pin_0;
  }else {
    GPIOB->ODR &= ~GPIO_Pin_0;
  }
  /* ChipSelect low */
  GPIOA->ODR &= ~ GPIO_Pin_6;
  SPI_SendData8( SPI1 , Data );
  MyDelayUS( LCD_WRITEDATA_US );
  /* ChipSelect high */
  GPIOA->ODR |= GPIO_Pin_6;
}

[Walter T. (nicolas)]

Ingo L. schrieb:
> SPI_SendData8( SPI1 , Data );

Das prüft selbstständig, ob der vorhergehende Transfer abgeschlossen 
ist?

[Mitlesa (Gast)]

Walter T. schrieb:
> Das prüft selbstständig, ob der vorhergehende Transfer abgeschlossen
> ist?

Das wird nicht reichen.

Die selbstgebaute MyDelayUS ist ein protentieller Fehlerbringer.

Ausserdem wird bei zwei aufeinanderfolgenden Zeichen der
Chipselect so schnell wieder betätigt dass ein Display
eventuell noch zu beschäftigt ist.

CS:   ~~~~~~\__________/~\__________/~~~~
(hier ------------------^----------------

[Ingo Less (Gast)]

Wenn ich die Funktion ...WriteData händisch aufrufen und mit einem 
Zeichen versehe und das ganze n mal, gibts keine Probleme. Das MyDelayUS 
hatte ich garnicht auf dem Schirm, die dürfte aber tendenziell viel zu 
lange dauern, da sie 1:1 von einem 168MHz F4 übernommen wurde und noch 
nicht angepasst wurde (schäm). Wenn das natürlich nicht passt oder es 
sogar weg optimiert wird, wäre ein ResetHandler nur logisch. An der 
Funktion an sich kann es nicht liegen? Ich kann es leider erst morgen 
früh wieder an der Hardware testen...

[Ingo Less (Gast)]

Was jedoch etwas unlogisch ist, ist das 1,5,9 usw. Zeichen im String 
funktionieren. Das spricht gegen die These eines zu knappen Delays oder?

[Ingo Less (Gast)]

Keiner weitere Ideen?

[eagle user (Gast)]

1, 5, 9 spricht für ein Alignment-Problem. Der M0 ist dabei 
anspruchsvoller als der M4.

[Ingo Less (Gast)]

Kannst du das näher ausführen?

[eagle user (Gast)]

Die Cortex-M haben 32 Bit breite Register. Wenn man eine möglichst 
einfache CPU bauen will, kann die nur 32 Bit am Stück verarbeiten und 
speichern. Um ein einzelnes Zeichen (char, uint8_t, 8 Bit) aus dem 
Speicher in ein Register zu laden, sind zusätzliche Befehle und 
Multiplexer nötig. Die hat der M0 zwar auch, aber Flash, RAM und 
Peripherie-Register müssen das auch unterstützen.

Der Compiler muss für jede Zeile C wissen, ob da ein 32-Bit Befehl 
funktioniert oder ob er vier 8-Bit Befehle einbauen muss. Optimal wäre 
natürlich ein einzelner Befehl, aber das geht eben nicht immer mit jeder 
CPU.

Soviel zur Theorie. Praktisch habe ich nur eine doofe Idee, was bei dir 
faul sein könnte: du übersetzt das Programm für einen F4 (=M4) statt für 
deinen F030 (=M0).

[Ingo L. (corrtexx)]

Ich habe einfach mal die 4.8 Toolchain benutzt und dann ging es. 
Komischerweise, als ich dann wieder auf die 6.2017.q1 zurück bin, ging 
es dann auch dort. Jetzt bin ich zwar glücklich das es geht, aber es ist 
unbefriedigend nicht zu wissen warum.

[Frank M. (ukw) (Moderator)]

Ingo L. schrieb:
> EA_DOGM163_Write_Data ( *Data++ , DATA );

Wenn EA_DOGM163_Write_Data() ein Makro ist, welches den ersten Parameter 
mehrfach verwendet, geht das in die Hose. Dann wird nämlich der 
Inkrement, den Du da eingebaut hast, mehrfach ausgeführt. Das hätte dann 
zur Folge, dass gar nichts oder nur ein Teil des Strings ausgegeben 
wird.

Bevor man da als Programmierer in den include-Dateien stundenlang 
rumsucht, ob das denn nun ein Macro oder eine richtige Funktion ist, 
kann ich Dir nur den Tipp geben: Lass das mit dem Increment von 
Makro-/Funktionsparametern. Vor 30 Jahren war das vielleicht noch ein 
Hinweis an den Compiler, dass er hier irgendein Register optimieren 
kann, heutzutage ist das komplett irrelevant.

Schreibe also:

  EA_DOGM163_Write_Data ( *Data , DATA );
  Data++;

und Du lebst wesentlich stressfreier.

[Dirk B. (dirkb2)]

Frank M. schrieb:
> Wenn EA_DOGM163_Write_Data() ein Makro ist,

Im zweiten Post steht doch die gesamte Funktion.

[Frank M. (ukw) (Moderator)]

Dirk B. schrieb:
> Im zweiten Post steht doch die gesamte Funktion.

Upps, das habe ich tatsächlich übersehen. :-)

[Ingo L. (corrtexx)]

Also den konkreten Fehler konnte ich nicht finden. Wie gesagt: einmal 
mit einer anderen Toolchain "gebuildet" und es lief und dann auch mit 
der, die vorher nutzte. Ich bin jetzt aber insgesamt auf EmBitz 
umgestiegen, nur Theater mit Atollic gehabt:
Beitrag "Re: SPL und Atollic"

Coocox ist auch cool, aber leider wird es nicht mehr gepflegt und neue 
Controller nicht eingebaut.

[Markus F. (mfro)]

Das ist einigermassen unwahrscheinlich; meine Compiler machen mit den 
gleichen Quellen immer dasselbe, egal wie oft ich es probiere (auch wenn 
ich bei manchen Problemen gern was anderes glauben möchte).

Du hast (wahrscheinlich unbeabsichtigt) was anderes verändert. Aber das 
wird man jetzt wohl nicht mehr nachvollziehen können.