[SOLVED] Quellcode bingt Verzweiflung.

[Tux12Fun]

Hallo

hier ist der komplette code meiner aktuellen main.c

#include <avr/io.h>
#include <avr/interrupt.h>
#include <string.h>
#define MCU = AVR_ATmega32 
#define F_CPU  16000000         // Quarz 20 Mhz-CPU
#include <util/delay.h> 
#define BIT_COUNT_DELEY   1000  //Basiseinheit für Counter
#define BIT_GND_DURATION	 20*BIT_COUNT_DELEY
#define BIT_0_DURATION		 5*BIT_COUNT_DELEY
#define BIT_1_DURATION      10*BIT_COUNT_DELEY
int main(void){
	DDRC=0xff;
	PORTC=0xff;  
	DDRA=0x00;
	PORTA=0xff;
	PORTC &= ~(1<<PC2);		//ON                <<hier funktionierts
	_delay_ms(1000);
	PORTC |= (1<<PC2);		//OFF
	_delay_ms(1000);
	while (1){
    	PORTC &= ~(1<<PC0); 	//ON
    	PORTC &= ~(1<<PC2);	    //ON                 << hier nicht mehr
    	_delay_ms(BIT_1_DURATION);
    	PORTC |= (1<<PC0);		//OFF
    	PORTC |= (1<<PC2);		//OFF
    	_delay_ms(BIT_GND_DURATION);
	}
}

Mit diesem Code bin ich gerade am tesen. Jedoch ohne erfolg.

Wenn ich die Zeile ON / OFF bei hier funktionierts auch noch rausnehme. Bleibt die LED für immer aus. Aber eigentlich müsste die doch unten auch getriggert werden.

[robocat]

_delay_ms(x) geht nicht beliebig lange. ich weiss allerdings auch nicht genau, wie lange man warten kann. 1000ms funktioniert definitiv noch, bei deinen 10/20 sekunden bin ich fast sicher, dass es nicht mehr gehen wird. da dann besser eine for schleife und ein dafür kürzeres delay verwenden.

gruesse

[McJenso]

Hallo,

#include <avr/io.h> 
#define MCU = AVR_ATmega32
#define F_CPU  16000000         

int main() {
   DDRC = (1<<PC2);
   while (1){ 
   }
return 0;
}

bitte ohne Optimierung kompilieren und testen.
Leuchtet die LED?
Wenn nicht gib uns bitte deine aktuellen(!) Fusebiteinstellungen.
Verweise nicht auf ein altes Bild, schaue nach und berichte.

Gruß

Jens

Edit: Hab jetzt nich im DB nach geschaut. Aber du hast Avcc angeschlossen, ja?

[Tux12Fun]

Also laut Pony Prog sind folgende Fuses gesetzt:
BODLEVEL = 0
CKSEL0 = 0
Der Rest ist 1
(gerade frisch ausgelesen)
Der Code mit 0 Optimierung im Makefile brachte keinen Unterschied.

Jetzt habe ich den Code in einen anderen ATMEGA32 geschossen.
und habe das gleiche Ergebnis.

Avcc war nicht angeschlossen. Jedoch kein unterschied, als ich Avcc versorgt habe.

Die Hex File wird euch auch nichts bringen oder ?

[Tux12Fun]

Ich glaube ich habe den Fehler eben gefunden. Bricht folgt soweit ich weiß ob es das wirklich war.

[McJenso]

Hallo,

das sieht mir jetzt nach Hardware Fehler aus. Wenn du den AtMega 32 raus ziehst und an den Sockel (PC2) eine Brücke nach GND steckst müsste die LED ja leuchten. Ich habe durch deinen vorherigen Code angenommen, dass du GND schaltest und die andere Seite der LED an Vcc angeschlossen hast. Das ist wohl richtig.
Wenn du mit dem AVR Studio arbeitest, hast du den richtigen Controller unter Projekt eingestellt?

Gruß

Jens

[Tux12Fun]

Also der Fehler lag auf dem Steckbrett auf dem ich experimentiert habe. Anscheinend hat die 2. LED nur stom bekommen, wenn die erste aus war. Genau kann ich gar nicht mehr sagen, wie ich die Konstelation hinbekommen habe.

Auf jeden Fall danke an alle, die mit hier weitergeholfen haben. Finde das echt Klasse von euch. Gerade, wenn man erst anfängt mit dem Microcontrollern zu arbeiten gibts halt so viele Stellen wo etwas schief laufen kann.

[oberallgeier]

Hi, alle

Bin erst jetzt wieder zurück "am Boden/der Tatsachen". Mittlerweile ist der Fehler wohl gefunden und die Softwarefehlersuche hat einen Hardwaremangel als Schuldigen erkannt (ich habe keine Ahnung, wie oft mir das schon passiert ist *brrrrrrrrr*).

... bitte ohne Optimierung kompilieren und testen ...

Das würde evtl. eine Fehlermeldung erzeugen, weil in der delay.h steht:

#ifndef __OPTIMIZE__
# warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed"
#endif

Ich habe aus verschiedenen Gründen (m)eine eigene delay irgendwo "gefunden":

// =================================================================================
// ### Programm pausieren lassen  !! Der Pausenwert ist nur experimentell !

void waitms(uint16_t ms) 
{ 
   for(; ms>0; ms--) 
   { 
      uint16_t __c = 4000; 
      __asm__ volatile ( 
         "1: sbiw %0,1" "\n\t" 
         "brne 1b" 
         : "=w" (__c) 
         : "0" (__c) 
      ); 
   } 
} 
// =================================================================================

Da habe ich eindeutig uint_16 - seeeehr praktisch. Die delay.h operiert dagegen mit "_delay_ms(double __ms)" - und ich glaube bei double und AVRGCC gibts gelegentlich Probleme . . . . hat ja schon robocat angemerkt.

... Hinweis: z.Zt. existiert im avr-gcc kein "echtes" double, intern wird immer mit "einfacher Genauigkeit" ...

[McJenso]

Hallo,

ohne Optimierung bezog sich nur auf meinen ultraeasykurzundschmerzlosen Testcode.

Gruß

Jens