Fehler in C Code ?

Jochen Kuehner schrieb:
> Doch in der Profibus.h ist sd1

Vielleicht eher SD1?

> mit 0x10 definiert, daher hätte er doch gar nicht default springen
> dürfen, oder?

Der ist sicher diesmal auch gar nicht dahin gesprungen.  Du hast
nämlich vergessen, bei allen gültigen Auswertungen dort noch den
irgendwann einmal ausgegebenen Wert wieder zu "löschen".

Das ist zumindest das, was meine Glaskugel anhand der spärlichen
Informationen so ausgespuckt hat...

Welchen Wert soll ich ablöschen?

Ich bin mittlerweile aber soweit das Ich nicht mal mehr damit:

unsigned long aa=0;

int main (void)
{
  DDRD |= (1<<PIN6);
  DDRD |= (1<<PIN5);
  PORTD |= (1<<PIN5);
  while(TRUE)
  {
    aa++;
    if (aa>100000000)
    {
      aa=0;
      PORTD ^= (1<<PIN6);
    }
  }
}

PD6 zum blinken bekomme (16Mhz Quartz, Atmega32)

aber PD5 und PD6 Leds gehen mit dem Code an!

Ich glaube Ich mache irgendwas Grundlegendes falsch...

Das Programm ist ein Beispiel, wie Du es besser nicht machst.

Mit Optimierung kompiliert, wird es die Zählschleife wegoptimieren. 
Dann blinkt es schon, nur eben so schnell, dass Du es nur auf dem Scope 
sehen kannst.  Abhilfe: aa volatile machen.

Ohne Optimierung wird es ebenfalls blinken, aber dank der 100.000.000 
Inkremente so langsam, dass Du getrost eine oder mehrere Tassen Kaffee 
dazwischen trinken kannst, denn Du bekommst eine mindestens 3stellige 
(in Sekunden, grob geschätzt) Periode.

Schau Dir am besten den erzeugten Assembler-Code an für weitere 
Informationen.

Jo nun geht wenigstens das wieder....

Jetzt kann Ich mich wieder der ursprünglichen Problem widmen....

Peter schrieb:
> die schleife kann nicht wegoptimiert werden, weil dort eine
> portzuweisung enthalten ist, da darf er nicht optimieren weil es ja das
> verhalten ändern würde.

Nein.  Das Inkrementieren von aa auf 100.000.000 ist die Schleife, 
danach erfolgt die Portzuweisung.  So kann die Logik nach der „as 
if“-Rule problemlos gesehen werden.  Erst NACH der Schleife erfolgt die 
Portzuweisung, und die wird ja nicht wegoptimiert, wohl aber das 
Hochzählen.

Wenn Du's nicht glaubst: schau den erzeugten Assemblercode an, wie ich 
bereits schrieb.

Gut Ich hab jetzt die Compiler Optimierungen aus.

Dachte nun Ich könnte im Programm eeprom_write_byte zum debugging 
verwenden.

Doch nichts da, es wurde nichts ins eprom geschrieben.

Doch selbst wenn ich meine Main so gestallte (wie unten), steht nur FF 
im Eprom (mit PonyProg ausgelesen).

Aber die LED blink...


int main (void)
{
  DDRD |= (1<<PIN6); //Port D Pin 6, Status LED Output
   eeprom_write_byte(0,'A');
   eeprom_write_byte(1,'B');

  while(TRUE)
  {
    aa++;
    if (aa>100000)
    {
      aa=0;
      PORTD ^= (1<<PIN6);
    }
  }
}

Jochen Kuehner schrieb:
> Gut Ich hab jetzt die Compiler Optimierungen aus.

Falscher Weg.

Machs richtig und du hast weniger Probleme.
Es hat keinen Sinn wenn du dich um Programmierfehler dadurch 
rumschummelst, dass du den Optimierer ausschaltest.

Karl heinz Buchegger schrieb:
> Jochen Kuehner schrieb:
>> Gut Ich hab jetzt die Compiler Optimierungen aus.
>
> Falscher Weg.
>
> Machs richtig und du hast weniger Probleme.
> Es hat keinen Sinn wenn du dich um Programmierfehler dadurch
> rumschummelst, dass du den Optimierer ausschaltest.

Das bliken welches Ich über den Zaehler gemacht habe, fliegt ja auch 
wieder raus. Und die Optimierungen kommen dann wieder rein.

Bin grad nur erst auf der Suche nach meinem eigendlichen Problem, und 
dazu wollte Ich die Eprom Funktionen nutzem um mir debuginfos zu 
speichern, doch das klappt nicht...

Jochen Kuehner schrieb:
> Ich die Eprom Funktionen nutzem um mir debuginfos zu
> speichern,

brrr viel zu langsam das schreiben, nimm lieber einen uart (wenn schon 
belgt einen per Software)

Die Geschwindigkeit ist mir gleich, fliegt ja eh alles wieder raus. Und 
habe nicht wirklich PINs frei. Ist den an Meinem benutzen der Eeprom 
Routinen was falsch, so das es nicht funktionieren sollte??