Komischer UART

[Schorsch (Gast)]

Hallo,

ich programmiere gerade meinen ersten mega64. Der UART verhält sich 
komisch.

kann mit

int uart_putc(unsigned char c)
{
    while (!(UCSR0A & (1<<UDRE0)))  /* warten bis Senden moeglich */
    {
    }                             
 
    UDR0 = c;                      /* sende Zeichen */
    return 0;
}

einzelne Zeichen verschicken

strings hingegen gehen nicht:

void uart_puts (char *s)
{
    while (*s)
    {   /* so lange *s != '\0' also ungleich dem "String-Endezeichen" */
        uart_putc(*s);
        s++;
    }
}

wenn ich so was in main stehen habe

int main(void)
{
  UART_init();
  sei();
  uart_putc('A');
    for(;;){
      //uart_putc('T');
      uart_puts("Huhu\r\n");
      _delay_ms(1000);
    }
    return 0;  
}

ist meine screen-Ausgabe

AHuhu
AHuhu
AHuhu
AHuhu
...

die Sekunde sind auch bei weitem nicht eingehalten. Packe ich nur ein 
char in den loop ist alles gut. da sag ich nur ---hä?---

Any hint?

Georg

[Achim M. (minifloat)]

Ist der Watchdog an? Dann resettet der Prozessor brav, wenn er im 
delay() Rechenzeit verheizt. Nur so erklärt sich, dass da immer wieder 
auch das 'A' raus kommt...
mfg mf

[Olek (Gast)]

wann soll den "while(*s)" kontrolliert false werden?

[Schorsch (Gast)]

Hi,

Die Theorie mit dem Watchdog hatte ich auch schon, habe aber nicht 
bewußt etwas umgestellt.

Habe gerade mal das delay rausgeschmissen und immernoch das gleiche

interessant ist auch folgende Codeveränderung

void uart_puts (char *s)
{
    while (*s)
    {   /* so lange *s != '\0' also ungleich dem "String-Endezeichen" */
        uart_putc(*s);
        s++;
    }
    uart_putc('X');
}

bewirkt keinerlei Änderung in der Ausgabe.

das \0 ist nicht als false erkannt

Schorsch

[Schorsch (Gast)]

Olek schrieb:
> wann soll den "while(*s)" kontrolliert false werden?

Hi,

habe den Code für einen mega8 schon 100mal benutzt, da geht er,


*s != \0  identisch zu *s

Schorsch

[Olek (Gast)]

Ich meine mal das *s ein pointer ist und aus der while gehts nur raus 
wenn der mal zufällig auf die 0 kommt und damit meine ich nicht die 
ascii 0 sondern 0x00.

für so sachen ist meiner meinung nach die strlen(string) geschrieben 
worden.

[troll (Gast)]

Olek schrieb:
> Ich meine mal das *s ein pointer ist
und ich meine du hast keine Ahnung. *s ist ein char, das while-Konstrukt 
wird millionenfach verwendet und passt so. RTFK&R :-)

[Olek (Gast)]

wie wäre es mal \0 zu setzen?

wenn du schon keinen debugger hast könntest dir mal einen counter in die 
schleife packen...

[troll (Gast)]

Olek schrieb:
> wie wäre es mal \0 zu setzen?
Hö? \0 wird automatisch an jeden String gehängt, das macht der Compiler 
schon richtig. Grundlagen.

[HalloHallo (Gast)]

Probiers mal so aus:

void uart_puts (char *s)
{
    uint8_t i = 0;

    while (s[i])
    {
        uart_putc(s[i]);
        i++;
    }
    uart_putc('X');
}

[Stefan E. (sternst)]

M103C-Fuse deaktivieren.

[amateur (Gast)]

Ist es möglich, dass Du irgendwo eine ungewollte Rekursion eingebaut 
hast?
Die Namen Deiner Funktionen kommen mir so schrecklich bekannt vor.

[Uwe (Gast)]

>     return 0;
Wohin denn ?

[Stefan (Gast)]

Uwe schrieb:
>>     return 0;
> Wohin denn ?

Von der int main wird eine Rückgabe erwartet, auch wenn sie diese 
Codestelle nie erreicht. Das ist vollkommen richtig so.

Auch alles andere schaut für mich richtig aus / ist millionenfach 
bewährter Code. Ich würde den Fehler wirklich in der Konfiguration / der 
Hardware suchen. Da auch das 'A' immer wieder gesendet wird, sieht es 
für mich so aus, als würde der Controller reseten. Probier mal, ob eine 
längere Zeichenkette abgeschnitten wird.
Was ist das für eine Schaltung? Eval. Board oder Eigenbau?
Wie ist der Reset beschaltet? Kann dir da was rein spucken?
Hast du ein Oszi, mit dem du mal auf die Versorgungsspannung schauen 
kannst?

[Wilhelm F. (Gast)]

Auch mal ins Assembler-Listing schauen, was der Compiler für einen Code 
fabrizierte.

[Uwe (Gast)]

> als würde der Controller reseten.
bzw. der Stack ist kaputt oder wurde falsch initialisiert (z.B. durch 
falsche CPU definition. Watchdog in den Fuses aktiviert ?
Hast schon recht war nur ein passendes Fehlerbild.

[Bronco (Gast)]

Schorsch schrieb:
> ich programmiere gerade meinen ersten mega64. Der UART verhält sich
> komisch.

Schorsch schrieb:
> habe den Code für einen mega8 schon 100mal benutzt, da geht er,

Wenn sich der gleiche Code auf einem Mega8 korrekt verhält, auf einem 
Mega64 aber nicht, dann mußt Du die Unterschiede prüfen:
- Quarz?
- Fuses? Wichtig!!!
- Register richtig konfiguriert?
- Hardware drumherum?

[Sascha W. (sascha-w)]

@Schorsch
was wird in uart_init() alles eingeschaltet? Auch RX und RXIE? Dann 
liegts an der nicht vorhandenen ISR für den uart-rx-int.
Schmeiß mal das sei() raus, für den Test brauchst du das nicht.

Sascha

[Schorsch (Gast)]

Hallo,
sorry, das ich mich erst jetzt melde, musste den Tag über arbeiten...

ich versuche mal die meisten Fragen zu beantworten:

die Fuses stehen so

avrdude: Device signature = 0x1e9602
avrdude: safemode: lfuse reads as E0
avrdude: safemode: hfuse reads as 99
avrdude: safemode: efuse reads as FD

mit dem d in der e-fuse müsste der 103c-mode aus und der watchdog 
eigentlich an sein (p293 im Manual)

meine init-routine sieht so aus:

UBRR0H = (unsigned char)(UBRR_VAL>>8); 
UBRR0L = (unsigned char)UBRR_VAL; 
  
UCSR0B = (1<<RXEN0)|(1<<TXEN0);

wobei UBBR_VAL so definiert ist

#define F_CPU 14745600UL 
#define BAUD 115200UL 
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)
 
#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
  #error Systematischer Fehler der Baudrate gršsser 1% und damit zu hoch! 
#endif

Die Frage nach den Fuses und den Registern sollte hinreichend 
beantwortet sein.

Zum Board: siehe hier:
Beitrag "Atmega64 PDI/O und RXD/TXD gleichzeitig"

Zusammenfassend, durch einen Flüchtigkeitsfehler werden PDI/O und 
RXD/TXD bei mir doppelt verwendet, das ließ sich beheben, indem ich 4.7k 
in die RXD-Leitung gehängt habe.

Das der UART nun grundsätzlich funktioniert sollte hinreichend gezeigt 
worden sein. Das selbstständige resetten (Wechselwirkung UART in den 
Programmer ???) kann man ausschließen, da das gleiche Problem auch 
auftritt, wenn ich den Programmer abziehe


ah, nochwas

void uart_puts (char *s)
{
  uint8_t n = 0;
    while (*s)
    {   /* so lange *s != '\0' also ungleich dem "String-Endezeichen" */
        //uart_putc(*s);
        uart_putc(s[n]);
        s++;
    }
    uart_putc('X');
}

liefert mir immnoch die selbe Ausgabe. Laienhaft ausgedrückt, es scheint 
als zeit ein Pointer ins Nirvana und der Programmcode fängt wieder von 
vorn an. Ist das ein gcc-bug?


Schorsch

[Schorsch (Gast)]

addendum:

wenn ich das sei weglasse ändert sich die Ausgabe

XAHuhu
XAHuhu
...

[Wusel D. (stefanfrings_de)]

Wie ruft Du uart_puts(char* s) auf? Auf was zeigt s?

[Stefan E. (sternst)]

Schorsch schrieb:
> mit dem d in der e-fuse müsste der 103c-mode aus und der watchdog
> eigentlich an sein (p293 im Manual)

Nein, umgekehrt. Also, wie ich bereits sagte, M103C-Fuse deaktivieren.

PS: Aber auch die Watchdog-Fuse wäre verheerend für dein Programm.

[Schorsch (Gast)]

Ja es geht,

ganz, ganz großes Danke schön


ich war natürlich zu doof das Datenblatt zu lesen. efuse auf ff heißt, 
watchdog aus, 103c mode aus

avrdude: safemode: lfuse reads as E0
avrdude: safemode: hfuse reads as 99
avrdude: safemode: efuse reads as FF

Warum ist dieses Programm verherend mit einem Watchdog?

[Stefan E. (sternst)]

Schorsch schrieb:
> Warum ist dieses Programm verherend mit einem Watchdog?

Weil du ihn nirgendwo im Programm zurücksetzt, und er daher den 
Controller unweigerlich nach seinem Ablauf resettet.