attiny2313 UART bzw. Speicher Initialisierung

[rotrau (Gast)]

Guten Abend,

ich versuche auf einem attiny2313 per UART Strings zu verschicken.
Das funktioniert auch, solange ich das ganze char für char mache,
allerdings nicht auf zusammenhängendes im Speicher.

#include <avr/io.h> 

#define F_CPU 3686400L
#include <util/delay.h>

void usart_init(unsigned int baud) {
    /* Set baud rate */
    UBRRH = (unsigned char)(baud>>8);
    UBRRL = (unsigned char)baud;
    /* Enable receiver and transmitter */
    UCSRB = (1<<TXEN);
    /* Set frame format: 8data, 1stop bit */
    UCSRC = (1 << UCSZ1) | (1 << UCSZ0);
}

void usart_transmit(unsigned char data) {
    /* Wait for empty transmit buffer */
    while(!(UCSRA & (1<<UDRE)))
        ;
    /* Put data into buffer, sends the data */
    UDR = data;
}

int main() {
    char text[] = "hallo welt";
    int j = 0;
    usart_init(1);

    while(1) {
        _delay_ms(1000);
        usart_transmit('a');
        for(j = 0; j < sizeof(text); j++) {
            usart_transmit('a'+text[j]);
        }

    }
    while(1) {}
}

Führt zur Ausgabe von a```````````a```````````a```````````a```````````.
Das lässt mich schließen, dass der Speicher nicht initialisiert wird, 
aber warum sollte das so sein?
Compiler ist avr-gcc 4.7.2

Viele Grüße
rot

[Ben (Gast)]

Grundlagen anschauen: Strings in C

[geier99 (Gast)]

rotrau schrieb:
> usart_transmit('a'+text[j]);

dann schreib mal das:

usart_transmit(text[j]);

[rotrau (Gast)]

Hi,

vielen Dank für die Antworten.
Die Tipps ändern nichts an meinen Strings die nicht intialisiert sind,
'a' ist ja nur ein konstanter Offset des Wertes.

[Andreas W. (geier99)]

rotrau schrieb:
> Hi,
>
> vielen Dank für die Antworten.
> Die Tipps ändern nichts an meinen Strings die nicht intialisiert sind,
> 'a' ist ja nur ein konstanter Offset des Wertes.

Vielleicht liegt es an dem:
(unsigned char data)

, da Dein Text ein char ist. Mach mal aus dem Text auch ein unsigned 
char.

[batman (Gast)]

'a' als Offset zu 'h'? Macht das einen Sinn?

[Karl H. (kbuchegg)]

rotrau schrieb:


> Führt zur Ausgabe von a```````````a```````````a```````````a```````````.
> Das lässt mich schließen, dass der Speicher nicht initialisiert wird,

Nö.
das lässt mich schliessen, dass die Addition des ASCII-Codes von a (0x61 
oder dez 97= zum ASCII Code von 'h' (0x68 oder dez 104) zu einem Code 
führt (dez 201), der von deinem Terminal nicht bzw. mit einem 
Sonderzeichen dargestellt wird, weil es im Original ASCII Code kein 
dafür vorgesehenes dafrstellbares Zeichen gibt.

Was versprichst du dir von

     'a' + text[j]

> aber warum sollte das so sein?

Ganz genau. Warum sollte das wohl so sein und warum ist das bisher noch 
keinem anderen ausser dir aufgefallen? Hmmmm.
Und warum gibst du den Text nicht erst mal so aus wie er ist, um zu 
sehen, was da rauskommt?
Fragen über Fragen.

[STK500-Besitzer (Gast)]

Karl Heinz Buchegger schrieb:
> Was versprichst du dir von
>
>      'a' + text[j]

Das dürfte die eine vergewaltiget Umwandlung von Dezimalzahlen in 
ASCII-Code sein.

[rotrau (Gast)]

#include <avr/io.h>   
 
#define F_CPU 3686400L
#include <util/delay.h>

void usart_init(unsigned int baud) {
    /* Set baud rate */
    UBRRH = (unsigned char)(baud>>8);
    UBRRL = (unsigned char)baud;
    /* Enable receiver and transmitter */
    UCSRB = (1<<TXEN);
    /* Set frame format: 8data, 1stop bit */
    UCSRC = (1 << UCSZ1) | (1 << UCSZ0);
}

void usart_transmit(char data) {
    /* Wait for empty transmit buffer */
    while(!(UCSRA & (1<<UDRE)))
        ;
    /* Put data into buffer, sends the data */
    UDR = data;
}

int main() {
    volatile char text[] = "hallo";
    int j = 0;
    usart_init(1);

    while(1) {
        _delay_ms(1000);
        for(j = 0; j < sizeof(text); j++) {
            usart_transmit(text[j]);
        }
        text[0] = 'h';
        text[1] = 'a';
        text[2] = 'l';
        text[3] = 'l';
        text[4] = 'o';
        text[5] = 0;


    }
    while(1) {}
}

Nochmal ein Beispiel, hier sehe ich auf dem Terminal einmal Mist und 
danach  den String hallo:
???????hallohallohallohallohallohallohallohallohallohallohallohallohallo 
hallohallohallohallohallohallohallohallohallo

Deshalb meine Ueberlegung ob der Speicher nicht initialisiert wird.

[Georg G. (df2au)]

rotrau schrieb:
> void usart_init(unsigned int baud) {
[...]
>     usart_init(1);

welche Baurate erwartest du da eigentlich?

[Dietrich L. (dietrichl)]

rotrau schrieb:
> usart_init(1);

Das kommt mir sehr komisch vor. Damit wird
       UBRRH = 0 und UBRRL = 1
Das kann doch keine sinnvolle Einstellung der Baudrate sein !?!

Gruß Dietrich

Edit: zu spät ;-(

[Karl H. (kbuchegg)]

rotrau schrieb:

> Nochmal ein Beispiel, hier sehe ich auf dem Terminal einmal Mist und
> danach  den String hallo:
> ???????

Dann lass dir halt mal die Hex-Werte der Character ausgeben.

> Deshalb meine Ueberlegung ob der Speicher nicht initialisiert wird.

unwahrscheinlich.
Viel eher, dass in deinem Projekt was nicht stimmt. Den richtigen µC 
hast du eingestellt?

[rotrau (Gast)]

Karl Heinz Buchegger schrieb:
> Viel eher, dass in deinem Projekt was nicht stimmt. Den richtigen µC
> hast du eingestellt?

Denke ich doch:
avr-gcc -Os -std=gnu99 -Wa,-adhlns=foo.lst -mmcu=attiny2313 
-mmcu=attiny2313 -Wall -g -gstabs -I./ -o crap.out foo.c

avr-objcopy -j .text -O ihex crap.out crap.hex

avrdude -p t2313 -c stk500v2 -P /dev/ttyUSB0 -e -U flash:w:crap.hex

Uebersehe ich etwas?

Erwartete Baudrate ist 115200, das funktioniert auch.

Wertausgabe ergibt 0xff fuer alle Bytes.

[Karl H. (kbuchegg)]

Hast du auf der Empfangsseite irgendwelche Framing-Errors?

Mach mal folgendes:
Gib 1 einzelnes Zeichen aus, dann ein wenig Warten (ein paar 
Millisekunden reichen) und erst danach den Text.


Alternativ:
Hast du schon mal im Simulator nachgesehen, was tatsächlich im Array 
steht?
Das da überall 0xFF drinnen steht, ist mehr als ungewöhnlich.


Sollte es sich tatsächlich wahrhaftig um einen Compilerbug handeln? Auch 
wenn es unwahrscheinlich ist, ausschliessen kann man es zu 100% auch 
nicht. Schon mal eine andere Compilerversion probiert?

[Karl H. (kbuchegg)]

> avr-objcopy -j .text -O ihex crap.out crap.hex

Hab grad im 4-er Studio nachgesehen. Da wird objcopy so eingesetzt

avr-objcopy -O ihex -R .eeprom  CTC.elf CTC.hex
(CTC ist das Projekt)


das ".text" da in der Command-Line macht mich nervös
und auch avr-objdump gibt bei der Speicherübersicht beim Flash die 
Sektionen .text + .data + .bootloader an.

bootloader ist für dich irrelevant. Aber .data scheint nicht irrelevant 
zu sein. Das würde sich auch mit deinen 0xFF decken, welches der 
Defaultwert eines nicht programmierten Flash darstellt.

[rotrau (Gast)]

Karl Heinz Buchegger schrieb:
> avr-objcopy -O ihex -R .eeprom  CTC.elf CTC.hex
>
>
> das ".text" da in der Command-Line macht mich nervös

Das wars wohl, danke!

[avr (Gast)]

Versuchs mal so, dann weiss der Kompiler wie groß das
array ist.

volatile char text[6] = "hallo";

avr

[Karl H. (kbuchegg)]

avr schrieb:
> Versuchs mal so, dann weiss der Kompiler wie groß das
> array ist.

Das weiß er auch so. Die Zeichen eines Initialisierstrings abzuzählen 
ist für deine eine leichte Übung.


Das Problem hat sich geklärt. Er hat seine Toolchain falsch benutzt. 
Wenn der String, mit dem initialisiert werden soll nie im Flash landet, 
dann müht sich der Initialisiercode vergebens ab und kopiert halt das, 
was im Flash steht: lauter 0xFF

[Georg G. (df2au)]

Initialisierte Variable stehen nicht im .text Segment sondern in .data.
Du hast aber nur das .text Segment in das HEX File überführt.

> avr-objcopy -j .text -O ihex crap.out crap.hex