ATMega8 "verfused" Kann man den noch retten

[Bumbum]

Hallo Hubert,

danke für die Erklärung der HV-Programmierung. Das Problem für mich war ja, dass der Controller auf nichts mehr reagiert hat, bzw. das ganze STK lahm gelegt hat sobald er gesteckt war. Ansonsten war nichts weiteres verkabelt. Es war lediglich das 6-polige ISP-Kabel auf dem STK gesteckt. Also war der Controller für mich eh für die Tonne. Da macht dann Beinchen biegen auch nichts mehr, hauptsache man kommt auf die Ursache und kann sie vielleicht das nächste mal vermeiden.

@HeXPloreR: Das STK500 ist gekauft und funktioniert seit Jahren einwandfrei. Und tut es ohne den komischen Mega8 auch. Ich habe heute damit mehrere verschiedene Schaltungen einwandfrei geflasht.
Klar hätte ich mir einen "Zwischensockel" bauen können, aber siehe meine Erklärung an Hubert.

Die Ursache ist für mich aber immer noch unlogisch. Ein "leeres" STK500, das einwandfrei funktioniert. Alle Jumper in der Standard-Stellung bis auf den OSCEL für den Quarz. Nur ein Mega8 im grünen Sockel und das 6-polige ISP-Kabel entsprechend gesteckt. Und dann ca. 20 Zeilen Code zum initialisieren der Ports und Funktionen und dann habe ich plötzlich >6V Versorgungsspannung solange der Atmel steckt. Ich habe den Controller nur "aufgesetzt" und sobald ich ihn anhebe ist die Spannung des STK wieder auf 5V runter gegangen und ich konnte via AVR-Studio damit kommunizieren. Controller wieder aufgesetzt und die Spannung war >6V und das AVR-Studio meldet, dass kein STK angeschlossen ist. Durch hochbiegen von ARef und AVCC am Mega8 ist nun alles wieder in Ordnung und ich kann ohne Probleme flashen.

Ich versteh's nicht! Und zur Verwirrung hier noch mal der komplette Code:

#define AVRGCC

#include <avr/io.h>
#include <util/delay.h>
#include <compiler.h>

//F_CPU = 4000000

#define BAUD                    9600l
#define UBRRValue                (F_CPU / (BAUD * 16) - 1)

void sendMsg (char *Msg, bool addCR)
{
    while (*Msg != 0)
    {
        while ( !(UCSRA & (1<<UDRE)));
        UDR = *Msg++;
    }

    if (addCR)
        sendMsg ("\r\n", FALSE);
}

int main (void)
{
    DDRB =  0b11111111;
    PORTB = 0b00000000;
    
    DDRD =  0b00000000;
    PORTD = 0b00000000;

    DDRC =  0b00000000;
    PORTC = 0b00000000;
    
    UCSRB = (1<<RXCIE) | (1<<TXEN);
    UCSRC = (1<<UCSZ1) | (1<<UCSZ0);
    UBRRH = (U8)(UBRRValue>>8);
    UBRRL = (U8)UBRRValue;

    ADMUX = (1<<REFS1) |(1<<REFS0);
    ADCSRA = (1<<ADEN) | (1<<ADPS2) | (1<<ADPS1) | (1<<ADPS0);

    sendMsg ("Start", TRUE);
        
    while (1)
    {
    }

    return (0);
}

Viele Grüße
Andreas

[HeXPloreR]

#define AVRGCC

#include <avr/io.h>
#include <util/delay.h>
#include <compiler.h>

//F_CPU = 4000000

#define BAUD                  9600l
#define UBRRValue                (F_CPU / (BAUD * 16) - 1)

void sendMsg (char *Msg, bool addCR)
{
    while (*Msg != 0)
    {
        while ( !(UCSRA & (1<<UDRE)));
        UDR = *Msg++;
    }

    if (addCR)
        sendMsg ("\r\n", FALSE);
}

int main (void)
{
    DDRB =  0b11111111;
    PORTB = 0b00000000;
    
    DDRD =  0b00000000;
    PORTD = 0b00000000;

    DDRC =  0b00000000;
    PORTC = 0b00000000;
    
    UCSRB = (1<<RXCIE) | (1<<TXEN);
    UCSRC = (1<<UCSZ1) | (1<<UCSZ0);
    UBRRH = (U8)(UBRRValue>>8);
    UBRRL = (U8)UBRRValue;

    ADMUX = (1<<REFS1) |(1<<REFS0);
    ADCSRA = (1<<ADEN) | (1<<ADPS2) | (1<<ADPS1) | (1<<ADPS0);

    sendMsg ("Start", TRUE);
        
    while (1)
    {
    }

    return (0);
}

Das Format der eingefügten Codes ist echt mies ( Hallo, Admin). Eine 1(bei 9600l ) ist ist es nämlich nicht. Was macht dieses Zeichen dort?

Und auf wieviel MHz soll der laufen?

[Bumbum]

Was findest du denn Mies daran? Das L ist nötig, damit der Compiler die Formel in der nächsten Zeile überhaupt berechnet. Ich glaube es weißt auf einen Long hin. Ohne diesen Buchstaben bringt der Compiler einen Überlauffehler.

[HeXPloreR]

hmm, kommt der Fehler denn wirklich vom 9600 (ohne L - denn wenn, dann großgeschrieben, auch weil besser lesbar).

Oder eher daher das F-CPU auskommentiert wurde - und dadurch mit F_CPU nicht gerechnet werden kann?

[Bumbum]

F_CPU ist in den Projekt-Eigentschaften bereits hinterlegt. Das steht im Code nur als Erinnerungshilfe. (Deswegen übrigens auch ohne #define)
Wenn es nicht stimmen würde, wäre keine RS232-Kommunikation möglich. Das geht nicht mal ohne Quarz vernünftig.

Warum probierst du es nicht einfach mal? Es gibt aber keinen Fehler wie von mir geschrieben sondern nur eine Warnung (integer overflow in expression). Ob der Code trotz der Warnung funktioniert weiß ich jetzt leider nicht aus dem Stegreif.

Und mit einem großen L gehts auch.

[HeXPloreR]

Warum ich es nicht probiere ist schnell gesagt: Mein einziger bisher funktionierender selbst abgeänderter Code in C lief bisher nur mit WinAVR2010 auf einem m128 mit 16Mhz und RS232 Kommunikation (nur Terminalempfang).


Okay, ich bin wieder still...