Mega8- uart_putc BLOCKT den AVR

[Chris (Gast)]

Hallo,
ich verwende folgenden Code:
http://www.rn-wissen.de/index.php/UART_mit_avr-gcc#Variante_2:_Mit_Interrupts

nun kann ich mein UART initialisiert aber er blockt alles nachdem ich 
etwas sende.

//geht nicht
uart_putc('c');

//hier hin kommt er nie

hat einer eine Idee woran das liegen kann?

Bei einen atmega32 geht der gleiche Code ohne Probleme

[Achim M. (minifloat)]

Chris schrieb:
> Bei einen atmega32 geht der gleiche Code ohne Probleme

Welchen Prozessor verwendest du gerade?
mfg mf

[Chris (Gast)]

wie es im Titel steht ein atmega8

[Achim M. (minifloat)]

Haben die Fifos genug Platz? Verwendest du Funktionen, die viele lokale 
Variablen initialisieren? Ich hatte neulich auf einem 2313 das Problem, 
dass mir der Stack in den Heap rein gewachsen ist, weil eine Funktion so 
um die 10-12 uint32_t Variablen benutzt hat. Hab das aber dann anders 
lösen können.
Ich hatte mich zuerst gewundert, warum die USART-RX-Fifo nur noch Müll 
enthielt, nachdem ich diese Funktion aufgerufen hatte. War mir dann aber 
klar.
Jetzt sind es nur noch 68Byte, das sind die die static oder global 
Variablen, die auf dem Heap liegen. Die Funktionen nehmen sich maximal 
zwei uint32_t, und so hat man noch Platz fürn Stack.

mfg mf

[holger (Gast)]

>Bei einen atmega32 geht der gleiche Code ohne Probleme

Und das Programm wurde auch für einen ATMega8 compiliert?
Du brennst doch da nicht die HEX Datei für einen ATMega32 rein?

[Vlad T. (vlad_tepesch)]

Mini Float schrieb:
> dass mir der Stack in den Heap rein gewachsen ist

du hast einen Heap auf einem tiny2313?

[Chris (Gast)]

die main besteht probeweise nur aus 4 Anweisungen.

es wurde für einen atmega8 comp.

hat noch einer eine idee?

[holger (Gast)]

>die main besteht probeweise nur aus 4 Anweisungen.

Zeigen.

[Achim M. (minifloat)]

Vlad Tepesch schrieb:
> du hast einen Heap auf einem tiny2313?

Nein, wenn einer einen Haufen macht, vielleicht mein Hund!?

Im Ernst:
Statische Variablen liegen nun mal auf dem Haufen. Gerade wenn sie als 
volatile markiert sind, wäre der Zugriff darauf auch recht schmerzhaft, 
würden sie auf dem Stapel liegen.
Wenn ich nun übermäßig anfange, in einer Funktion lokalen Speicher zu 
verlangen, werden diese Sachen (wie auch sonst?) in umgekehrter 
Reihenfolge zu den Zeitpunkten, zu denen sie benutzt werden sollen, auf 
den Stapel gelegt. Wächst nun der Stapel aufgrund dieser Aktion weiter, 
weiter, weiter nach unten, kratzt er am oberen Ende vom Haufen. Dort lag 
wohl mein char-Array und die Zählvariablen für den Ringpuffer des UART. 
Plötzlich musste sich der arme Käfer dem Exorzismus widmen. Sah 
jedenfalls auf dem Terminal sehr witzig aus :)

mfg mf

[Stefan E. (sternst)]

Mini Float schrieb:
> Statische Variablen liegen nun mal auf dem Haufen.

Nein. Der Heap ist das, wo malloc & Co werkeln.

[Achim M. (minifloat)]

Wo malloc & Co. werkeln.
Es handelt sich also um Speicher, der zur Laufzeit allokiert und ggf. 
mit Startwerten für folgende Aktionen vorbelegt wird.
Genau das tun die Lader, die vor der main() laufen und die globalen und 
static Variablen belegen. Hängt euch jetzt bitte daran auf, was "zur 
Laufzeit" ist und was nicht. Ich interessiere micht nicht dafür, wann 
ein Pointer ein Pointer oder noch eine Zahl ist.
mfg mf

[Achim M. (minifloat)]

Der einzige Unterschied ist:
Beim einen Mal ist ein Pointer zu dem Datenbereich bereits zur 
Compile-Zeit bekannt, das andere Mal bekäme man einen Pointer zu diesem 
Datenbereich von einer Funktion.
Beide Speicherklassen liegen am unteren Ende vom RAM. Auf Beide wird bei 
den Atmels per Pointer zugegriffen. Beide können bei einem übermäßigen 
herunterwachsen des Stacks korrumpiert werden.
Sch***e, seid ihr kniefieselig.

BTT: Chris, kannst du uns mal deinen Quellcode zeigen? den kann man 
hier wie Bilder an das Posting anhängen(bitte nicht als Text einfügen, 
wenn nur so max. 10-Zeilige Schnipsel).

mfg mf

[Chris (Gast)]

#include <avr/interrupt.h> //UART
#include <avr/io.h>
#include <stdlib.h>
#include <stdint.h>
#include "test.h"
#include <inttypes.h>
#include <util/delay.h>
#include "uart.h"

int main(void)
{
    uart_init();

    sei();

    DDRB=0xFF;
    setportbon(0);

    _delay_ms(1000);

    uart_putc('c');

    uint16_t i = 0;
    while(1)
    {
        if (i < 500)
        {
            setportbon(1);
            _delay_ms(1);
            setportboff(1);
            i++;
        }
        _delay_ms(1);
    }
}

bitteschön

[Achim M. (minifloat)]

Chris schrieb:
> #include "test.h"

Chris schrieb:
> #include "uart.h"

Und die .c Dateien dazu hätt ich auch gern gesehen.

und zu "sei();" ist der RX-Interrupt oder der TX-Interrupt Enable an? 
Wenn der Vektor fehlt oder falsch ist, kann dir der µC auch anhalten 
oder unvorhersagbares abarbeiten.

60% der Fehler in Embedded Software sind handwerkliche Fehler.

Beliebtester Fehler sind wohl Schleifen mit Fehlerhafter 
Schleifenbedingung.
Sowas hatte ich die letzten Tage auch, wunderte mich wieso der Prozessor 
auf der Seriellen wie wild los ballerte. Mit splint (Statisches 
Codeanalysetool, Freeware) hab ichs erst gesehen. Kann ich dir sehr 
empfehlen, das Tool.

mfg mf