|
Anzeige
|
Mega8- uart_putc BLOCKT den AVR
Gast
#2515342
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 Chris schrieb: > Bei einen atmega32 geht der gleiche Code ohne Probleme Welchen Prozessor verwendest du gerade? mfg mf
Gast
#2515443
wie es im Titel steht ein atmega8 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
Gast
#2515470
>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?
Mini Float schrieb: > dass mir der Stack in den Heap rein gewachsen ist du hast einen Heap auf einem tiny2313?
Gast
#2515513
die main besteht probeweise nur aus 4 Anweisungen. es wurde für einen atmega8 comp. hat noch einer eine idee?
Gast
#2515535
>die main besteht probeweise nur aus 4 Anweisungen.
Zeigen.
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 Mini Float schrieb: > Statische Variablen liegen nun mal auf dem Haufen. Nein. Der Heap ist das, wo malloc & Co werkeln. 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 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
Gast
#2516783
#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
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 Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
