www.mikrocontroller.net

Forum: Compiler & IDEs Langes Programm: Fehlfunktion AVR ATmega32


Autor: Frank Goenninger (dg1sbg)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

mein kleines programm für meinen ATmega32 wurde nun doch etwas größer 
(siehe Datei anbei). Nach überschreiten einer für mich nicht fassbaren 
Größe, so scheint es, will das Ding nicht mehr. Soll heissen: Ich seh 
z.B. noch, dass das LCD initialisiert wird (clear screen), aber eine 
Ausgabe erfolgt schon nicht mehr...

Teste ich kleine Teile des Programms für sich, so funktionieren die 
einzelnen Teile wie gewünscht.

Ich habe einiges an Definitionen und Variablen-Vorbelegungen in der 
Datei controller.c ... Ich sehe allerdings in der Ausgabedatei 
psuctrl.lst nicht, welche Grenze ich überschritten hätte...

Umgebung hier: AVR-GCC 4.3.2, AVR libc 1.6.4, ATmega32 mit 8 MHz

Danke für Hinweise !!!!

Viele Grüße
   Frank

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ohne überhaupt reingeschaut zu haben...klingt nach Pufferüberlauf(der 
sich erst ab einer gewissen Größe auswirkt) oder nach Stack Problem..

Viele Erfolg beim Suchen

egberto

Autor: UBoot-Stocki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

oder aber wie bei meinem Projekt, dass "der RAM" einfach voll ist. Du 
könntest jetzt tunen oder aber einfach auf einen Mega32 umsteigen ...

Gruß

Andreas

Autor: UBoot-Stocki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups - Mega644 meinte ich ...

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
section             size
.text              19748
.data               1376
.bss                1387

Du benutzt mehr RAM, als du eigentlich hast.
Ein kurzer Blick in den Sourcecode offenbart jede Menge Strings, die 
unnötigerweise im RAM liegen.

Autor: UBoot-Stocki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ein Beispiel für Strings im RAM:

Beitrag "Komfortable Rolladensteuerung V1.0"

Gruß

Andreas

Autor: Frank Goenninger (dg1sbg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

vielen Dank (!!!) für Eure Antworten - mal wieder klasse, was man hier 
an Support bekommt.

Aber:

Stefan Ernst wrote:
> section             size
> .text              19748
> .data               1376
> .bss                1387
>
> Du benutzt mehr RAM, als du eigentlich hast.

Hmm -

SRAM = .bss = 1387 bytes, und damit < 2 kb und damit i.O.
RAM  = .text + .data = 21124 bytes, und damit < 32 kb (ATmega32) und 
damit i.O.
?? Wo liegt denn mein Denk-/Rechenfehler ?

> Ein kurzer Blick in den Sourcecode offenbart jede Menge Strings, die
> unnötigerweise im RAM liegen.

Ok. Also alles PSTRs ...

Danke!! - Zurück zum Coding ...

Gruß,
   Frank

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Goenninger wrote:

> SRAM = .bss = 1387 bytes, und damit < 2 kb und damit i.O.

SRAM = .bss + .data (+ Heap) + Stack

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Ernst wrote:
> .bss                1387

Also da ist noch reichlich Luft bis 2048 Byte, am SRAM kanns also nicht 
liegen.
Da müßte man schon richtige Schweinereien machen (Rekursive Funktionen), 
damit der Stack überquillt.

Du solltest vielleicht Dein Programm strukturieren (in kleinere 
zusammengehörende Objekte unterteilen) und kommentieren, dann kann man 
mal weiter sehen.
Es fehlen außerdem noch 2 Files, um es mal compilieren zu können.

Es ist zwar löblich, atomare Zugriffe zu beachten, aber Du scheinst es 
mir zu übertreiben.
Fast alles ist ja atomar, ich bin mir daher nicht sicher, ob dann auch 
die Interrupts oft genug zum Zuge kommen.

Vielleicht solltest Du die Interrupts etwas verschlanken und nicht allen 
Tod und Teufel darin machen (Du machst da was mit Funktionspointern 
rum).

Das Main würde bestimmt auch gerne einiges machen und darin hat man dann 
ne klare Ausführungsfolge (nichts unterbricht sich selber).
Das erleichtert auch das Verstehen ungemein.


Da Du viel mit I2C rummachst, würde ich nen I2C-Interrupt aufsetzen, der 
im Hintergrund die I2C-Sachen (PCF8574?) macht. Dazu legst Du quasi 
IO-Ports im SRAM an und der Interrupt updated die zyklisch.
D.h. alle Statemachines arbeiten direkt auf diesem Pseudo-IO SRAM.

Ich benutze diese Technik mit SPI IO-Erweiterungen (74HC165, 74HC595), 
dadurch wird das Programm sehr übersichtlich und klein (keine tausend 
Funktionsaufrufe, sondern direkte Variablenzugriffe).
Der AVG-GCC kann ja komfortabel Bitvariablen definieren.


Peter

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
>> .bss                1387
>
> Also da ist noch reichlich Luft bis 2048 Byte, am SRAM kanns also nicht
> liegen.

Du vergisst das .data-Segment. Das kommt noch dazu.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan Ernst wrote:
> Du vergisst das .data-Segment. Das kommt noch dazu.

Stimmt, hast recht.
Woher hast Du diese Angaben?

Ich laß mir das mit AVR-Size ausgeben, aber ich konnte es nicht 
compilieren (libgaul.a, gaul.h fehlt).

Die Konstanten hat er aber hübsch im Code versteckt, sah garnicht soviel 
aus.


Peter

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das im Archiv vorhandene elf-File genommen.

Autor: Frank Goenninger (dg1sbg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:

> Du solltest vielleicht Dein Programm strukturieren (in kleinere
> zusammengehörende Objekte unterteilen) und kommentieren, dann kann man
> mal weiter sehen.

Ok. Kritik angekommen. ;-)

> Es ist zwar löblich, atomare Zugriffe zu beachten, aber Du scheinst es
> mir zu übertreiben.
> Fast alles ist ja atomar, ich bin mir daher nicht sicher, ob dann auch
> die Interrupts oft genug zum Zuge kommen.

> Vielleicht solltest Du die Interrupts etwas verschlanken und nicht allen
> Tod und Teufel darin machen (Du machst da was mit Funktionspointern
> rum).

Huch! Danke für den Rat, aber ich muss sagen, dass ich nicht den 
Eindruck hatte, dass da so viel drin passiert.

> Das Main würde bestimmt auch gerne einiges machen und darin hat man dann
> ne klare Ausführungsfolge (nichts unterbricht sich selber).
> Das erleichtert auch das Verstehen ungemein.

Mein MAIN macht die Hauptarbeit: Die Statusmaschinerie, die das ganze 
treibt. Aber ich bin nun dabei, noch mehr in MAIN zu verlagern.

> Da Du viel mit I2C rummachst, würde ich nen I2C-Interrupt aufsetzen, der
> im Hintergrund die I2C-Sachen (PCF8574?) macht. Dazu legst Du quasi
> IO-Ports im SRAM an und der Interrupt updated die zyklisch.
> D.h. alle Statemachines arbeiten direkt auf diesem Pseudo-IO SRAM.

Wäre schön, das machen zu können. Hardware ist aber vorgebenen, und ich 
muss damit leben (das Mini-Mega-Board aus Elektor). Trotzdem: Kann die 
Idee verwenden und werde alle I/Os auf Bits legen, die dann per Timer 
Interrupt an die Komponenten ausgegeben werden.

> Peter

Vielen Dank für die Hinweise !

Gruß,
  Frank

Autor: Frank Goenninger (dg1sbg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So .... Nach Restrukturierung und neuem Ansatz zur I2C Nutzung über 
"Ports gespiegelt im SRAM" habe ich nun folgende Größen:
psuctrl.elf :
section                      size         addr
.text                      17232              0
.data                         316   8388704
.bss                         1432   8389020
....
Total                      89128

Funzen tut's aber immer noch nicht.... Sollte aber nun reichen, oder? 
Ich habe kein malloc o.ä. verwendet.

Ich habe folgendes Idiom verwendet:
   printf( strcpy_P( (char *) &acBuffer[0], PSTR( "Hello !" )));

Ist dies so ok ?

Soll ich den Source nochmals posten?

Danke für weitere Hilfe...

Frank

Autor: Frank Goenninger (dg1sbg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Melde Vollzug. Musste noch weiter .bss reduzieren. Nun funkts wieder.
Das tut ja soooo gut - nach einer Woche debuggen und einem "Major 
Rewrite" ... ;-)

Viele Grüße

   Frank

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Goenninger wrote:

> Ich habe folgendes Idiom verwendet:
>
>
>    printf( strcpy_P( (char *) &acBuffer[0], PSTR( "Hello !" )));
> 

Häh!?

Vielleicht beschreibst du ja mal, was du tun willst...

Du suchst nicht etwa einfach nur
printf_P(PSTR("Hello!"));

oder?

Autor: Frank Goenninger (dg1sbg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Frank Goenninger wrote:
>
>> Ich habe folgendes Idiom verwendet:
>>
>>
>>    printf( strcpy_P( (char *) &acBuffer[0], PSTR( "Hello !" )));
>> 
>
> Häh!?

;-) Hallo Jörg!
>
> Vielleicht beschreibst du ja mal, was du tun willst...
>
> Du suchst nicht etwa einfach nur
>
>
> printf_P(PSTR("Hello!"));
> 
>
> oder?

Nein. Ich wollte sichergehen, dass es keine elegantere Lösung gibt, um 
einen im PROGMEM befindlichen String in einen temporären Buffer zu 
kopieren und den Zeiger auf den Buffer an eine Funktion zu übergeben.

Aber printf_P hatte ich auch noch nicht genutzt. Danke für den Hinweis 
...

73, Frank DG1SBG

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.