mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Merkwuerdiges Verhalten von SDCC mit STM8


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
Ich bin schier am Verzweifeln:

Ich bastle immer noch (oder immer wieder) an Softwaremodulen für STM8 
unter SDCC (weil Linux).

So... war ich am Anfang noch freudig überrascht dass das relativ einfach 
funktionierte, wächst nun der Frust und ich glaube SDCC ist dafür 
verantwortlich.

Ich kann schwierig an Codebeispielen erklären was nicht so recht 
funktioniert, aber mich beschleicht langsam das Gefühl, dass die RAM und 
Stack - Verwaltung des SDCC's in Verbindung mit STM8 buggy ist.

Schreibe ich eine Codesequenz, die funktioniert und lagere ich diese in 
eine Funktion aus, funktioniert sie plötzlich nicht mehr (obwohl ich sie 
mittels Copy und Paste aus meiner eigenen Main dorthin verfrachtet hab.) 
Ich weiß sehr wohl, dass ein Funktionsaufruf den Stack belastet.

Erweitere ich ein Programm, bleibt manchmal dieses weit vor Erreichen 
des neuen Programmteils hängen. Dann funktioniert manchmal ein
volatile char dummy;

dummy= 5;
dummy= dummy;

oder ähnlicher nutzloser Programmcode, der nichts sinnvolles ausführt, 
vor einem neuen Programmteil und der Code funktioniert wieder.

Ich habe mittlerweile Codeanalyse der erzeugten ASM und MAP-Dateien 
betrieben und durchschaue einiges, aber nicht alles.

Am Schlimmsten ist wohl, dass ich nirgendwo, das Ende des Stacks 
initalisieren kann und ich (ich bin wieder am Lesen des Datenblatts) 
schlicht davon ausgehe, dass der Stackpointer auf das Ende des RAMS nach 
dem Einschalten liegt.

Im Datenblatt steht:

In the default stack model this pointer is initialized to the
RAM end address.

Sind die Resetwerte der STM8 - Serie tatsächlich so, dass der 
Stackpointer auf das Ende des Rams zeigt und mit Verwendung dem 
RAM-Anfang (in dem Variable abgelegt sind) entgegen wächst?

Kann ich mich darauf verlassen ... oder liegt mein Fehler irgendwo 
anderst in bspw. der Initialisierung?
/* ------------------------------------------------------
                     sysclock_init
      stellt den Taktgeber fuer den Controller ein.
      Bei Verwendung des internen Oszillators werden
      16MHz eingestellt

      (Xtal enable) xtalen = 1  => externer Quarz
                           = 0  => interner RC-Oszillator

      Anmerkung:
         soll der MCU mit externem Quarz laufen, ist
         zuerst ein Aufruf

            sysclock_init(0);

         gefolgt von einem Aufruf

            sysclock_init(1);

         zu erfolgen !
   ------------------------------------------------------ */
void sysclock_init(char xtalen)
{
  if (xtalen)
  {
    CLK_ICKR = 0;                                  //  Reset Register interner clock
    CLK_ECKR = HSEEN;

    while ((CLK_ECKR & HSERDY) == 0);              //  warten bis Quarz eingeschwungen ist;

    CLK_SWR = 0xb4;                                //  int. Generator als Taktquelle
    CLK_SWCR = SWEN;                               //  Enable switching.

    CLK_CKDIVR = 0;                                //  Taktteiler auf volle Geschwindigkeit
    CLK_PCKENR1 = 0xff;                            //  alle Peripherietakte an
    CLK_PCKENR2 = 0xff;                            //  dto.
  }
  else
  {
    CLK_ICKR = 0;                                  //  Reset Register interner clock
    CLK_ECKR = 0;                                  //  Reset Register externer clock (ext. clock disable)

    CLK_ICKR =  HSIEN;                             //  Interner clock enable
    while ((CLK_ICKR & (HSIRDY)) == 0);            //  warten bis int. Takt eingeschwungen ist


    CLK_CKDIVR = 0;                                //  Taktteiler auf volle Geschwindigkeit
    CLK_PCKENR1 = 0xff;                            //  alle Peripherietakte an
    CLK_PCKENR2 = 0xff;                            //  dto.

    CLK_CCOR = 0;                                  //  CCO aus
    CLK_HSITRIMR = 0;                              //  keine Taktjustierung
    CLK_SWIMCCR = 0;                               //  SWIM = clock / 2.
    CLK_SWR = 0xe1;                                //  int. Generator als Taktquelle
    CLK_SWCR = 0;                                  //  Reset clock switch control register.
    CLK_SWCR = SWEN;                               //  Enable switching.
    while ((CLK_SWCR &  SWBSY) != 0);              //  warten bis Peripherietakt stabil
  }
}


Das war bisher meine Initialisierung (es werden keine anderen 
Initialisierungen vorgenommen) und hat bei den bisherigen kurzen 
Programmen (mit wenig RAM - Verwendung und ca. 5 Stackebenen) auch gut 
funktioniert, aber schön langsam ist der Wurm drin ...

Kann man an den RAM Einstellungen in Verbindung mit STM8 etwas 
einstellen?

In meiner Not bin ich sogar hergegangen, hab (im jetzigen Programm) das 
Hardware I2C absichtlich nicht verwendet, eine softe I2C - 
Implementierung geschrieben und das ganze Programm so geschrieben, dass 
es bis auf das Bitbanging der Ports und das Initialisieren eines Timers 
identisch für einen AT89S52 ist ... und siehe da, auf diesem MCU macht 
der SDCC keine Mucken, nur für den STM8.

Der Timerinterrupt verwendet keine 16-Bit Variable, nur uint8_t Typen 
(weil ich mir erst überlegte, ob ein Interrupt mir vllt. zwischen einer 
soften 16-Bit Rechenoperation dazwischen spuckt und nach dem Interrupt 
die Register nicht mehr ihre Inhalte aufweisen).

Hey, ihr könnt mir gerne die Rübe abhauen ... aber bitte von 
Beleidigungen abstand nehmen.

Die Dinge hab ich für MCS-51, für AVR und (nach langer Kleinarbeit) auch 
für STM32 und LPC hinbekommen ...

Weiß irgendjemand etwas über Bugs vom SDCC ganz im Speziellen mit der 
Speicherverwaltung ?

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
0 lesenswert
nicht lesenswert
Was für ein STM8 ist es denn? Welche Version von SDCC?
Zu Problemen mit dem Stackzeiger fällt mir nur das ein:
http://wiki.chibios.org/dokuwiki/doku.php?id=chibios:articles:stm8_stack
allerdings war ich bisher noch nicht von dem Problem betroffen.

Zur Zeit gibt es in SDCC keine offenen STM8-spezifischen Bugs.

Philipp

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
0 lesenswert
nicht lesenswert

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
... ich habs jetzt analysiert .... uuuuund der Fehler liegt 
ausnahmsweise nicht bei mir (denn bei mir such ich immer zuerst) . Aus 
irgendeinem Grund räumt der SDCC in bestimmten Konstellationen nach 
einem CALL manchmal den Stack nicht auf, was heißt ein abschließendes 
POP fehlt im Assemblercode... Nachdem ich Programm weitergeschrieben 
hab, kann ich den Fehler noch nicht einmal mehr reproduzieren... leider. 
Sonst hätte ich das Programm zu Analyse eingereicht. Aber danke für 
deine Rückmeldung.

von Bernd K. (prof7bit)


Bewertung
1 lesenswert
nicht lesenswert
Ralph S. schrieb:
> Nachdem ich Programm weitergeschrieben
> hab, kann ich den Fehler noch nicht einmal mehr reproduzieren...

Ein Wort: Versionsverwaltung.

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
Bersionsverwaltung.... bin ich (leider) sowas von schlampig.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.