Schönen Abend,
Der einfach Code unten macht mich Wahnsinnig, die USART0_Senden()
Funktion geht einwandfrei. Warum er mit USART_Str("Hallo") die Hallo
zwar ausgibt, aber dann einen Reset verursacht begreife ich nicht. Als
könnte das Programm nicht aus der USART_Str() zurückspringen?
Nutze einen Atmega128A mit einem USB-Serial Kontroller.
Irgendwo muss der Hund sein.
1
#include<avr/io.h>
2
#include<util/delay.h>
3
4
#ifndef F_CPU
5
#define F_CPU 8000000UL // Systemtakt in Hz - Definition als unsigned long beachten
6
#endif
7
8
#define BAUD 9600UL // Baudrate, muss in Hterm gleich eingestellt sein.
_delay_ms(1000);
Dir ist klar dass das nicht hinhaut? Die Delayfunktionen funktionieren
nur bis zu bestimmten Werten, siehe
http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html
Glaub aber eher nicht dass dein Problem damit zusammenhängt. Was
passiert, wenn du das const beim Parameter für USART_Str weglässt?
Thomas Bergmüller schrieb:> _delay_ms(1000);> Dir ist klar dass das nicht hinhaut? Die Delayfunktionen funktionieren> nur bis zu bestimmten Werten, siehe> http://www.nongnu.org/avr-libc/user-manual/group__...
hast du dir überhaupt mal durchgelese was dort steht, wenn du schon die
quelle angibst?
> When the user request delay which exceed the maximum possible one,> _delay_ms() provides a decreased resolution functionality. In this> mode _delay_ms() will work with a resolution of 1/10 ms, providing> delays up to 6.5535 seconds (independent from CPU frequency). The> user will not be informed about decreased resolution.
@Bruno In.
das delay ist ok.
Martin Wende schrieb:> Der Fehler ist revht einfach du hast den String nicht terminiert.
was soll denn das hier? Es geht um C - da ist jeder Sting der mit ""
geschrieben wird terminiert.
Martin Wende schrieb:> Sagt das meinem AVRGCC, als ich mit AVR Anfing habe ich das \0 auch> immer weggelassen und da stand dann aufm LCD der gesamte> Speicherinhalt...
dann war der Fehler woanders, der (AVR)GCC hat no nie diesen Fehler
gemacht.
Peter II schrieb:> dann war der Fehler woanders, der (AVR)GCC hat no nie diesen Fehler> gemacht.
Doch.
Das ist der hundertmillionste Compiler. Der hat diesen Fehler. Den kann
man gegen einen Goldbarren und einen funktionierenden eintauschen.
mfg.
Martin Wende schrieb:> Sagt das meinem AVRGCC, als ich mit AVR Anfing habe ich das \0 auch> immer weggelassen und da stand dann aufm LCD der gesamte> Speicherinhalt...
Du meinst nicht zufällig diese Art der Deklaration?
Thomas Eckmann schrieb:> Doch.> Das ist der hundertmillionste Compiler. Der hat diesen Fehler. Den kann> man gegen einen Goldbarren und einen funktionierenden eintauschen.>> mfg.
Hoffe das war ironisch gemeint?
Gruß Oliver
Peter II schrieb:> Martin Wende schrieb:>> Sagt das meinem AVRGCC, als ich mit AVR Anfing habe ich das \0 auch>> immer weggelassen und da stand dann aufm LCD der gesamte>> Speicherinhalt...> dann war der Fehler woanders, der (AVR)GCC hat no nie diesen Fehler> gemacht.
Jedenfalls wurde solch ein Fehler nie berichtet, und ich hab die avr-gcc
Fehler ziemlich genau im Blick.
Also Martin, her mit dem Testfall, der Compilerversion und den Optionen
:-)
ist das wirklich so, dass bei
while (*s){
und Inhalt = 0 die Schleife verlassen wird?
Davon abgesehen, das Programm hängt dann ewig in der schnarchlangsamen
UART-Routine fest bei der Programmausführung.
Es wär evtl. sinnvoll mal über den TXC Flag zum Einen und den
TXC-Interrupt im Besonderen nachzudenken.
Peter II schrieb:>> http://www.nongnu.org/avr-libc/user-manual/group__...> hast du dir überhaupt mal durchgelese was dort steht, wenn du schon die> quelle angibst?
Ich glaub ich muss mich entschuldigen, sehr peinlich... (wobei ich
solche langen Delays üblicherweise mit einem Timer lösen würde, dann
kann der Prozessor inzwischen was anderes tun (auch wenns hier im
Beispiel wenig Sinn machen wird))
Sorry, war den ganzen Tag auf dem Bau. Habe ja eine Flut von Antworten
erhalten. Super, Werde es sofort durchchecken.
Karl Heinz Buchegger schrieb:> Hast du die M103 Fuse abgeschaltet?
Nein. Werde ich sofort mal machen.
>_delay_ms(1000);
Die waren zum Testen, sonst resetet der so schnell.
>USART_Str("Hallo\0");
Auch schon versucht, gleiches Resultat.
>while (*s)
Hier habe ich schon getestet mit einem Aufruf ohne Pointer, genau
dasselbe.
Danke für die vielen Hinweise.
bjn
Das gibt's ja nicht, Du bist Super Karl Heinz.
> Karl Heinz Buchegger schrieb:>> Hast du die M103 Fuse abgeschaltet?
Das war's schon, die M103 Fuse. Habe das mal nachgeschlagen im
Datenblatt. Der wird ja mit dem Watchdog zusammen beschrieben. Steig
leider nicht ganz durch, mein Englisch ist schwach ;-{ .
Und was ich gar nicht begreife, was hat das mit einem Funktionsaufruf
zuntun.
Die Tiefen der Mikrokontroller.
Bruno In. schrieb:> Und was ich gar nicht begreife, was hat das mit einem Funktionsaufruf> zuntun.
überhaupt nichts.
> an ATmega103 compatibility mode can be selected by programming> the fuse M103C
damit hat er andere Register und Upcodes - der µC hat also eine eine
Sprache verstanden.
Bruno In. schrieb:> Und was ich gar nicht begreife, was hat das mit einem Funktionsaufruf> zuntun.
Der Compiler ist von einem Mega128 ausgegangen, und hat Code erzeugt,
der den Stack-Pointer auf das Ende des RAM des Mega128 initialisiert.
Der Controller ist aber in Wirklichkeit ein Mega103 (wegen der Fuse).
Bei dem endet das RAM eher (weil er weniger Register hat und daher das
RAM auch eher anfängt). Somit zeigt der Stack-Pointer auf eine Adresse,
an der gar kein RAM ist, und damit geht das erste ret mit ziemlicher
Sicherheit in die Hose.
