Merkwürdiges Verhalten eines Atmega16 mit C++

Sebastian schrieb:
> Wenn ich nun einer Funktion, welche einen uint32t als Parameter
> verlangt, beispielsweise einen uint16t übergebe, ohne ihn zu casten,
> meckert erstens AtmelStudio 7 nicht und zweitens, ich bekomme sehr
> merkwürdige, fast zufällige Ausfallerscheinungen:

dann liegt der Fehler woanders. Das ist ein normales Verhalten und muss 
funktionieren.

> Nun ist es so, dass ich solche Fehler nur mit großem Aufwand
> finden kann, da ich keinen Debugger besitze und der Fehler
> im Simulator nicht auftaucht.
Ganz einfach: Debugger kaufen oder bauen. Du wirst Dich fragen, warum Du 
das nicht schon vor Langem getan hast.

Weitere Tipps kann man kaum geben, weil wir Dein Programm nicht kennen.
Evtl. bringen Debug-Ausgaben etwas, entweder über seriell oder I/O.
Kommt auch stark darauf an, ob zeitkritisch etc.

schmeiß mal -Wall an. Dann sollte der Compiler schon meckern.

nicht"Gast" schrieb:
> schmeiß mal -Wall an. Dann sollte der Compiler schon meckern.

nein sollte er nicht. Es gibt nicht den kleinsten Grund g
für eine Warnung.

Huch,
Da hast du Recht. Ich hab mich da verlesen. Ich dachte er schmeißt einen 
uint32  auf einen uint16 Parameter und hab mich schon gewundert, dass da 
kein Fehler kommen soll

Sebastian schrieb:
> Wenn ich nun einer Funktion, welche einen uint32t als Parameter
> verlangt, beispielsweise einen uint16t übergebe, ohne ihn zu casten,
> meckert erstens AtmelStudio 7 nicht
1. Es koennen maximal Compiler und Linker meckern
2. Warum glaubst du, dass da irgendwas meckern sollte?

Sebastian schrieb:
> fast zufällige Ausfallerscheinungen
Klingt nach Stack/Heap ueberlauf, und/oder einem wilden Pointer
bzw. Zugriffe auf nicht existente Arrayelemente, wodurch andere 
Variablen ueberschrieben werden.

Sebastian schrieb:
> wie man soetwas leichter finden
- Programmlogik und Zugriffe auf die Hardware sauber kapseln.
  Dann koenntest du deine Programmlogik recht einfach testen,
  z.B. durch Unittests.

- Debugger besorgen und debuggen.

Sebastian schrieb:
> oder sogar ganz vermeiden kann
Sich beim programmieren (noch besser davor!) Gedanken darueber machen, 
was man da eigentlich macht, und sauber arbeiten. Eine zweite Person 
drueber schauen lassen (Pair-Programming, Code-Review) koennte auch 
helfen.

Ansonsten Warnungen einschalten (-Wall -Wextra), Warnungen als Error 
behandeln (-Werror), damit du keine Warnung vergisst. Tools wie CppCheck 
helfen auch.

Hallo zusammen,

zunächst möchte ich sagen, dass ich mir durchaus VORHER Gedanken zu dem 
Projekt und dem Programm gemacht habe und da ich auch beruflich 
programmiere (C#) behaupte ich einfach mal, ich weiß schon in etwa, 
worauf es ankommt. :) Mikrocontroller (und auch ein bisschen C++) sind 
allerdings Neuland für mich und ich muss mich erst an die 
(Hardware-)Verhältnisse gewöhnen.

Nun zum Thema:
Ich vermute mittlerweile auch, dass es an einem Heap-/Stacküberlauf 
liegt, da alles einwandfrei läuft, wenn ich (zur Sicherheit 
verschiedene) andere, kleinere Programmteile auskommentiere und somit 
das Programm kleiner wird. Atmel Studio schreibt dazu:

Program Memory Usage   :  9910 bytes   60,5 % Full
Data Memory Usage   :  785 bytes   76,7 % Full
EEPROM Memory Usage   :  202 bytes   39,5 % Full

Ich habe jetzt mal nen Mega324PA bestellt und werde es dann dort testen.

Bin ich damit auf einem guten Weg, oder ist das eher Quatsch?

Nach etwas lesen (soll ja oft helfen ;-)) habe ich noch eine Frage:

Kann es hier eventuell helfen, wenn ich einige Variablen als "volatile" 
deklariere, und sie somit nicht mehr im Stack, sondern im 
Programmspeicher liegen?