avr-g++ mehrere .cpp Dateien -> Fehler(AVR freeze)

Da wirst du wohl irgendeinen Fehler in deinem Code haben.
Ich tippe mal auf Zeile 42

Karl heinz Buchegger wrote:
> Da wirst du wohl irgendeinen Fehler in deinem Code haben.
> Ich tippe mal auf Zeile 42

nah dran glaub es ist 43 ;)
ne mal im ernst irgendwie glaub ich weniger, dass es die sources sind.
häng sie trotzdem mal an, inzwischen hab ich äußerst merkwürdige fehler, 
so nach dem motto "1ne zeile mehr, die nichts macht => controller 
freeze"...

Du hast recht.
Die Sourcen sind grundsätzlich in Ordnung.
Dürfte wirklich in irgendeiner Compiler- oder Linker-Einstellung liegen. 
Hab allerdings noch nie den avr-g++ benutzt.
Mal warten bis Jörg online kommt, der kennt sich da besser aus.

Kannst du mit LED einschalten feststellen, wo das Problem liegt?

(Ein µC kann nicht freezen. Irgendwas macht der immer. Die Frage ist nur 
was :-)

Aber noch ein paar Tipps.

String String::operator= (char* s) {

hat den falschen Returntyp. Der op= returniert eine Referenz

String& String::operator= ( const char* s ) {

Wenn du C++ arbeitest, gewöhn dir von Anfang an an, const korrekt zu 
arbeiten. Du willst einen konstanten String mittels op= an den String 
binden. Dazu sollte das Argment auch const sein (dein ein String Literal 
ist grundsätzlich const. Lediglich aus Abwärtskompatibilitätsgründen zu 
altem C, wird es ausnahmsweise toleriert einen const char* an einen 
char* zuzuweisen.)


In grundsätzlich jedem Konstruktur solltest du darauf achten, dass alle 
Member Variablen initialisiert werden. Pointer auf NULL setzen!


Meine persönliche Meinung: Wenn in Memberfunktionen der this Pointer 
benötigt wird, um kenntlich zu machen, dass man auf eine Membervariable 
zugreift, dann sollte man sein Benamungsschema für Variablen überdenken.


Das deine String Klasse, sagen wir mal zweifelhaft ist, weisst du 
wahrscheinlich selber. So wie sie zur Zeit ist, eignet sie sich nur 
dazu, konstante Strings (also String Literale) zu verwalten.


In C++ benötigt eine Funktion genauso wie in C kein abschliessendes ;
char String::getChar(int index){
  return (char) *(this->s+index);
};     <----- dieses ';' ist überflüssig


Aber alles das kann den Hänger nicht erklären.

habs mit den leds jetzt noch nicht konkret ausprobiert, nur gemerkt, 
dass sie auf einmal nichtmehr blinken^^

was auchnoch sehr komisch ist, ist zB wenn man der USART class als 
parameter 1 übergibt, sobald er dann in das if statement geht und die 
zeile fürs setzen der register da ist (in den sources drinnen) taucht 
der gleiche effekt auf. ist die zeile weg ists ok und die leds blinken 
(sources der usart class in der main.cpp).
und das beste: fehler solcher art gibt es äußerst viele umso mehr ich 
versuche...

wollte eigentlich ein wenig mehr highlevel proggn nur ich glaube, dass 
das irgendwie garnicht geht.. :(



edit: ja ich weiss, dass die sources bes***** sind atm ;)
lerne gerade mal c, c++ ... wenn man das der java, php ecke kommt ists 
eine echte umgewöhnung..^^ daher bin ich auch das this gewöhnt..^^
sobald ich vernünftig arbeiten könnte an den sources (ohne "freeze") 
mach ich die in vernünftig^^

Karl heinz Buchegger wrote:

> Mal warten bis Jörg online kommt, der kennt sich da besser aus.

Ich würde vermutlich den Debugger anschmeißen und gucken, wo er
hängt.  Wollte es gerade mal bauen, hmm, kein Makefile dabei.
Hab' mir eins gezimmert, und den ganzen Kladderadatsch in den
Simulator geschickt.  (Der simuliert einen ATmega128, aber der
ATmega64-Code sollte dazu ja binärkompatibel sein.)  Das Teil
tut, ich komme regelmäßig an den beiden PORTB=-Anweisungen vorbei.

Damit stellt sich die Frage, welche Compilerversion benutzt worden
ist.

hm strange..

gcc version 4.3.2 (WinAVR 20081205)
mit eclipse CDT, also autogenerated makefile

hab mal den generierten release branch angehängt

> gcc version 4.3.2 (WinAVR 20081205)

Dann nimm mal bitte das aktuelle WinAVR, da sind noch einige Bugfixes
in den Compiler reingekommen.

so hab jetzt mal die neue version genommen, mit dem atmega64 geht es 
immernochnicht.

hab spaßes halber mal nen at90can128 genommen und siehe da es geht alles 
?!
kann mir das mal jemand erklären ?

Sach mal, du hast aber die M103C-Fuse nicht noch zufällig eingeschaltet?

... mich aufn kopf hau
diese blöde fuse war per factory default gesetzt.....


jetzt läufts auch aufm atmega64....
danke für den tipp :=)

Andi D. wrote:
> ... *mich aufn kopf hau*
> diese blöde fuse war per factory default gesetzt.....

Ja, ich weiß.  Daher bin ich ja dann auch auf die Idee gekommen.