Attiny412 - String über USART

N. M. schrieb:
> Ich tippe Mal ins blaue und sag der Baudratenfehler ist bei 16MHz
> und
> 115200 zu groß.
> Versuch es Mal mit 9600.

Leider nein, das hatte ich bereits getestet (und jetzt gerade 
nocheinmal).

Hi

>Ich tippe Mal ins blaue und sag der Baudratenfehler ist bei 16MHz und
>115200 zu groß.

Ja, -3,5% sind schon ganz happig.

MfG Spess

an Mani und Spess:
Es handelt sich um einen ATtiny412, dieser verfügt über einen 
'fractional baud rate generator'.

spess53 schrieb:
> Ja, -3,5% sind schon ganz happig.

Hmm.. wie kommst du auf die 3.5%?

Ich komme auf 555.55.. als BAUD wert, aufgerundet auf 556.
Wenn ich das nun zurückrechne komme ich auf eine Baudrate von 115107 - 
was eine Abweichung von -0.07% gibt

Wenn ich auch "mal ins Blaue tippen" darf (als Assemblerprogrammierer): 
da nur der Aufruf in der Schleife nicht funktioniert, vermute ich ein 
Problem mit C, vielleicht dieses 'size_t'.

S. Landolt schrieb:
> Wenn ich auch "mal ins Blaue tippen" darf (als Assemblerprogrammierer):
> da nur der Aufruf in der Schleife nicht funktioniert, vermute ich ein
> Problem mit C, vielleicht dieses 'size_t'.

Dachte auch an ein Compiler Problem. Das 'size_t' hatte ich auch bereits 
ausgetauscht durch int und int16_t - was alles nichts genützt hat. Wenn 
ich 'i' über UART ausgebe mit 'USART0_sendChar((char) i + 48)' wird 
schön 0, 1, 2, 3 ausgegeben...

Es scheint mir, als ob das indexieren mit der Variable nicht richtig 
funktioniert (hello[i]).

Wenn ich die Schleife anpasse zu:

1

    for (size_t i = 0; hello[i] != '\0'; i++) {

2

      USART0_sendChar(hello[i]);

3

    }

wird sie gar nicht erst ausgeführt, sondern direkt übersprungen.

Neuling schrieb:
> wird sie gar nicht erst ausgeführt,

Ich tippe mal auf integer promotion, dann ist auch klar warum die nicht 
ausgeführt wird!

Ich habe mir abgewöhnt den Compiler als Schuldigen anzusehen, weil zu 
99.999% war ich immer der Dussel.

Neuling schrieb:

> Angehängt findet ihr noch das binary sowie ein lst file vom kompilierten
> C-Code.

Ich hab' mir nur das lst-File angeschaut. Mal abgesehen davon, dass der 
Optimizer da eine ziemlich ineffiziente Arbeit abliefert, ist der 
generierte Code ziemlich sicher sachlich korrekt.

Sprich: Das sollte eigentlich funktionieren. Keine Ahnung, warum's nicht 
tut.

Grob zur Erklärung, was da (in dem nicht funktionierenden Bereich) 
passiert:

Es wird auf dem Stack Platz für 5 Bytes geschaffen (4 Chars+NUL, also 
OK), dann wird die Stringkonstante aus dem Flash dorthin kopiert, 
allerdings über das SRAM-Mapping des Flash. Dann wird sie wieder 
zeichenweise vom Stack geholt und an die (offensichtlich ja 
funktionierende) Ausgaberoutine verfüttert.

Der Stack wurde zu Programmbegin auch korrekt initialisiert, zeigt also 
in's SRAM, wie es sich gehört.

Die einzige Unsicherheit besteht IMHO darin, ob die Stringkonstante 
tatsächlich an der erwarteten Stelle im SRAM-Mapping des Flash liegt. 
Von anderen XMega-Erben sind ja bereits Bugs genau bei dieser Sache 
bekannt...

Ein schöner Test wäre es, zwischen diesen beiden Zeilen

    char hello[] = "Hi\r\n";

    for (size_t i = 0; i < 4; i++) {

mal folgendes Stück Code einzufügen:

    hello[0]='O';
    hello[1]='o';
    hello[2]='p';
    hello[3]='s';

und sich dann die UART-Ausgabe anzuschauen.

Kommt das Oops, ist Mikrochip schuld.

Die Schleife ist korrekt und sollte so funktionieren.  Tut sie ja auch, 
sie sendet 4 Bytes, nur nicht die gewünschten.  Meine Vermutung: die 
Strings werden nicht korrekt ins RAM kopiert (falscher Startupcode?). 
Die folgenden Einzelausgaben (hello[0] etc) werden vom Compiler 
optimiert und benutzen den String gar nicht.

c-hater schrieb:
> Ein schöner Test wäre es, zwischen diesen beiden Zeilen
>
>     char hello[] = "Hi\r\n";
>
>     for (size_t i = 0; i < 4; i++) {
>
> mal folgendes Stück Code einzufügen:
>
>     hello[0]='O';
>     hello[1]='o';
>     hello[2]='p';
>     hello[3]='s';
>
> und sich dann die UART-Ausgabe anzuschauen.
>
> Kommt das Oops, ist Mikrochip schuld.

Tatsächlich, der Output ist dann:

1

$ cat /dev/ttyUSB0 | xxd -c 9 -g 1

2

00000000: 4f 6f 70 73 74 4f 6f 70 73  OopstOops

3

00000009: 4f 6f 70 73 74 4f 6f 70 73  OopstOops

4

00000012: 4f 6f 70 73 74 4f 6f 70 73  OopstOops

5

0000001b: 4f 6f 70 73 74 4f 6f 70 73  OopstOops

Was heisst das jetzt, respektive was genau läuft falsch?

Neuling schrieb:

> Was heisst das jetzt, respektive was genau läuft falsch?

Das heißt, das du einen Hardware-Bug im Tiny412 gefunden hast. Der 
allerdings in ähnlicher Form bereits vom AVR128DAxx bekannt ist...

c-hater schrieb:
> Das heißt, das du einen Hardware-Bug im Tiny412 gefunden hast. Der
> allerdings in ähnlicher Form bereits vom AVR128DAxx bekannt ist...

Erklär mal bitte für mich Doofi mehr. Ich weis nur, dass der AVR128 da 
ein Mapping Issue hat ...

c-hater schrieb:
> Das heißt, das du einen Hardware-Bug im Tiny412 gefunden hast. Der
> allerdings in ähnlicher Form bereits vom AVR128DAxx bekannt ist...

Na toll, hast du eine Idee wie der umgangen werden kann? Ich meine, das 
trifft dann ja auf alle Array's zu - nicht nur auf diesen String oder?

> Das heißt, das du einen Hardware-Bug im Tiny412 gefunden hast.

Das ist so früh aber eine mutige Behauptung - gibt noch genügend andere 
Möglichkeiten, z.B. unpassender Startupcode.

merciMerci schrieb:

> Erklär mal bitte für mich Doofi mehr. Ich weis nur, dass der AVR128 da
> ein Mapping Issue hat ...

Naja, und jetzt wissen wir, dass auch der Tiny412 ein solches hat. Was 
gibt es da noch groß zu erklären?

foobar schrieb:

> Das ist so früh aber eine mutige Behauptung - gibt noch genügend andere
> Möglichkeiten, z.B. unpassender Startupcode.

Der Startupcode ist im lst-File enthalten und macht alles richtig, 
nämlich rein garnix bezüglich des Mapping. Das Map-Fenster im 
SRAM-Bereich ist groß genug, dass es den gesamten Flash eines Tiny412 
abbilden kann. Es gibt also keinen Grund, irgendetwas am default Mapping 
zu ändern. Und übrigens auch keine Möglichkeit dafür (das ist der 
einzige Unterschied zur Sachlage bei den AVR128DAxx)...

c-hater schrieb:
> foobar schrieb:
>
>> Das ist so früh aber eine mutige Behauptung - gibt noch genügend andere
>> Möglichkeiten, z.B. unpassender Startupcode.
>
> Der Startupcode ist im lst-File enthalten und macht alles richtig,
> nämlich rein garnix bezüglich des Mapping. Das Map-Fenster im
> SRAM-Bereich ist groß genug, dass es den gesamten Flash eines Tiny412
> abbilden kann. Es gibt also keinen Grund, irgendetwas am default Mapping
> zu ändern. Und übrigens auch keine Möglichkeit dafür (das ist der
> einzige Unterschied zur Sachlage bei den AVR128DAxx)...

Hast du eine Idee, wie ich mit dem Fehler umgehen kann? Da ich mehrere 
attiny412 habe wäre es schade sie wegzuschmeissen. Wäre eine Möglichkeit 
immer wenn ich ein Array brauche, es mit

1

int arr[10];

2

for(int i=0; i<10; i++)

3

 arr[i] = 0;

zu initialisieren? Respektive überall wo möglich 'const int arr[] = { 
... };' zu verwenden?

Neuling schrieb:

> Na toll, hast du eine Idee wie der umgangen werden kann? Ich meine, das
> trifft dann ja auf alle Array's zu - nicht nur auf diesen String oder?

Frage1:
Ja, aber die wird dir nicht gefallen: Programmiere Assembler, denn 
kontrollierst du selber, wie du auf den Flash zugreifst...

Frage2:
Ja. Wird alle konstanten Daten betreffen, sofern der Compiler die 
Zugriffe nicht durch Rückgriff auf andere Codevarianten wegoptimiert, 
wie es ja bereits in deinem Originalcode passiert ist, bei dem zweiten 
Teil der Aufgabe hat er den Zugriff auf das bereits aufwendig im SRAM 
erzeugte Array durch ein paar immediate-loads ersetzt...

In dem geänderten Code konnte er das nicht mehr tun, weil wir an dem 
Array rumgepfuscht haben, deswegen gibt's auch im zweiten Teil der 
Ausgabe jetzt ein Oops...

>> Das ist so früh aber eine mutige Behauptung - gibt noch genügend andere
>> Möglichkeiten, z.B. unpassender Startupcode.
>
> Der Startupcode ist im lst-File enthalten und macht alles richtig,
> nämlich rein garnix bezüglich des Mapping.

Oh, sorry - hatte in das .lst gar nicht reingeschaut.  Sieht tatsächlich 
korrekt aus.  War mir noch einfällt, wäre, dass die .rodata-Section 
nicht nach 0x11e ins FLASH kopiert wurde (dann wäre aber FFs 
wahrscheinlicher als die 00s).  Das .hex könnte da Aufschluß geben. 
Wenn das auch korrekt ist, wird's eng ;-)

foobar schrieb:
> Das .hex könnte da Aufschluß geben.
> Wenn das auch korrekt ist, wird's eng ;-)

Hab das .hex angehängt. Danke für eure Hilfe :)

> Hab das .hex angehängt.

Bingo - die .rodata-Section fehlt, das Hex hört bei 0x11e auf.

Im AS7 Simulator sieht alles ok aus!

Neuling schrieb:
> foobar schrieb:
>> Das .hex könnte da Aufschluß geben.
>> Wenn das auch korrekt ist, wird's eng ;-)
>
> Hab das .hex angehängt. Danke für eure Hilfe :)

Das ist das Hex welches Programms? Des ursprünglichen oder das mit dem 
von mir vorgeschlagenen Testcode?

merciMerci schrieb:

> Im AS7 Simulator sieht alles ok aus!

Simulatoren kannst du nur so weit vertrauen, wie du ihre Funktion 
verifiziert hast...

Hier das mit dem aktuellen 'Atmel Studio 7' kompilierte Programm des 
TOs.
Der String "Hi\r\n" - der im obigen Hex-File fehlt - ist im Datensatz 
mit dem Sternchen.

1

:1000000019C020C01FC01EC01DC01CC01BC01AC00C

2

:1000100019C018C017C016C015C014C013C012C034

3

:1000200011C010C00FC00EC00DC00CC00BC00AC064

4

:1000300009C008C011241FBECFEFCDBFDFE3DEBF74

5

:100040000FD072C0DDCF9091040895FD06C0E0E0AE

6

:10005000F8E00000948195FFFCCF8093020808959A

7

:10006000CF93DF93CDB7DEB72597CDBFDEBF88ED49

8

:1000700084BFE0E6F0E081818E7F8183E0E0F4E000

9

:10008000808180648083A0E0B8E08CE292E01896E2

10

:100090008D939C93199716968C911697806416965B

11

:1000A0008C93808184608083C12C6894DD24D2F895

12

:1000B0007E0125E0E20EF11CF601848184608483D8

13

:1000C000FFEF23ED80E3F15020408040E1F700C0D6

14

:1000D000000085E0ECE2F1E8DE01119601900D925E

15

:1000E0008A95E1F78E010F5F1F4FF80181918F0113

16

:1000F000AADF0E151F05C9F784E7A5DF88E4A3DF93

17

:1001000089E6A1DF8DE09FDF8AE09DDFF601848133

18

:100110008B7F8483FFEF23ED80E3F150204080400C

19

:0C012000E1F700C00000C8CFF894FFCF4A

20

:05012C0048690D0A0006*

21

:00000001FF

Mit AS7 passt das schon ...

1

readelf -S attiny412_pintChar.elf

2

    There are 13 section headers, starting at offset 0x3a20:

3

    Section Headers:

4

      [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al

5

      [ 0]                   NULL            00000000 000000 000000 00      0   0  0

6

      [ 1] .data             PROGBITS        00803f00 00017b 000000 00  WA  0   0  1

7

      [ 2] .text             PROGBITS        00000000 000074 000102 00  AX  0   0  2

8

      [ 3] .rodata           PROGBITS        00008102 000176 000005 01 AMS  0   0  1

9

      [ 4] .comment          PROGBITS        00000000 00017b 000030 01  MS  0   0  1

10

      [ 5] .note.gnu.avr.dev NOTE            00000000 0001ac 00003c 00      0   0  4

11

      [ 6] .debug_info       PROGBITS        00000000 0001e8 001410 00      0   0  1

12

      [ 7] .debug_abbrev     PROGBITS        00000000 0015f8 0012fa 00      0   0  1

13

      [ 8] .debug_line       PROGBITS        00000000 0028f2 00001d 00      0   0  1

14

      [ 9] .debug_str        PROGBITS        00000000 00290f 00089e 00      0   0  1

15

      [10] .shstrtab         STRTAB          00000000 00399c 000082 00      0   0  1

16

      [11] .symtab           SYMTAB          00000000 0031b0 0004b0 10     12  22  4

17

      [12] .strtab           STRTAB          00000000 003660 00033c 00      0   0  1

18

    Key to Flags:

19

      W (write), A (alloc), X (execute), M (merge), S (strings)

20

      I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)

21

      O (extra OS processing required) o (OS specific), p (processor specific)

In seinem objcopy zum Erstellen des hex-Files fehlt wohl einfach nur das 
"-j .rodata":

1

# avr-objcopy -j .text -j .rodata -j .data -O ihex /tmp/main.bin /dev/stdout 

2

:1000000019C020C01FC01EC01DC01CC01BC01AC00C

3

:1000100019C018C017C016C015C014C013C012C034

4

:1000200011C010C00FC00EC00DC00CC00BC00AC064

5

:1000300009C008C011241FBECFEFCDBFDFE3DEBF74

6

:100040000BD06BC0DDCF9091040895FD02C000007D

7

:10005000FACF809302080895CF93DF93CDB7DEB730

8

:100060002597CDBFDEBF88ED84BF809161008E7F74

9

:1000700080936100809100048064809300048CE28E

10

:1000800092E08093080890930908809106088064A4

11

:1000900080930608809100048460809300047E01B0

12

:1000A00025E0E20EF11C8091040484608093040436

13

:1000B0008FEF93EDE0E381509040E040E1F700C026

14

:1000C000000085E0EEE1F1E8DE01119601900D926D

15

:1000D0008A95E1F78E010F5F1F4FF80181918F0123

16

:1000E000B2DF0E151F05C9F784E7ADDF88E4ABDF8B

17

:1000F00089E6A9DF8DE0A7DF8AE0A5DF809104040F

18

:100100008B7F80930404FFEF23ED80E3F1502040C8

19

:0E0110008040E1F700C00000C6CFF894FFCF9A

20

:05011E0048690D0A0014

21

:00000001FF

Ohne das "-j .rodata" kommt sein oben gepostetes fehlerhaftes .hex raus.

c-hater schrieb:
> Das ist das Hex welches Programms? Des ursprünglichen oder das mit dem
> von mir vorgeschlagenen Testcode?

War das hex des ursprünglichen.

foobar schrieb:
> In seinem objcopy zum Erstellen des hex-Files fehlt wohl einfach nur das
> "-j .rodata":

Ja, das wars :D Danke vielmals für eure super Hilfe :)

Neuling schrieb:

> foobar schrieb:
>> In seinem objcopy zum Erstellen des hex-Files fehlt wohl einfach nur das
>> "-j .rodata":
>
> Ja, das wars :D Danke vielmals für eure super Hilfe :)

OK, also doch kein Mikrochip-Bug, sondern nur eine Instanz von: Mit 
Hochsprachen-Compilern (und Linkern) kann man massenhaft Probleme lösen, 
die man ohne sie überhaupt nicht hätte...

c-hater schrieb:
> OK, also doch kein Mikrochip-Bug, sondern nur eine Instanz von: Mit
> Hochsprachen-Compilern (und Linkern) kann man massenhaft Probleme lösen,
> die man ohne sie überhaupt nicht hätte...

Ja, das ist absolut so. Allerdings vereinfachen sie - sobald die 
Environment stimmt - vieles. C mag ich dabei aber auch nicht besonders, 
da es einfach ist mühsam zu findende Fehler einzubauen. Da hab ich 
lieber Rust (ist aber für AVR nicht wirklich geeignet da LLVM fehlt).

Und die Frage wäre schnell beantwortet gewesen - hätte ich das ganze 
Makefile gepostet...

Neuling schrieb:

> Und die Frage wäre schnell beantwortet gewesen - hätte ich das ganze
> Makefile gepostet...

Da fällt mir noch was ein: der Linker hätte doch eigentlich furchtbar 
meckern müssen, ohne diese Sektion gibt es doch eine nicht auflösbare 
Referenz, oder?

Also mir scheint, das sich das Gewicht verlagert, das Thema aber noch 
nicht wirklich durch ist...

c-hater schrieb:
> Da fällt mir noch was ein: der Linker hätte doch eigentlich furchtbar
> meckern müssen, ohne diese Sektion gibt es doch eine nicht auflösbare
> Referenz, oder?

Naja, gelinkt wurde ja direkt beim kompilieren, und Meldungen/Warnungen 
gabs da keine...

Neuling schrieb:
> c-hater schrieb:
>> Da fällt mir noch was ein: der Linker hätte doch eigentlich furchtbar
>> meckern müssen, ohne diese Sektion gibt es doch eine nicht auflösbare
>> Referenz, oder?
>
> Naja, gelinkt wurde ja direkt beim kompilieren, und Meldungen/Warnungen
> gabs da keine...

Eben. Das genau ist das Problem, es hätte welche geben MÜSSEN...

Es kann ja schließlich nicht sein, dass irgendwas refenziert wird, was 
im Binary überhaupt nicht mehr enthalten ist.

Diese Situation muß ganz klar einen Fehler werfen. Wäre das passiert, 
würde möglicherweise dieser ganze Thread überhaupt nicht existieren...

c-hater schrieb:
> Es kann ja schließlich nicht sein, dass irgendwas refenziert wird, was
> im Binary überhaupt nicht mehr enthalten ist.

Im binary ist es ja enthalten, nur im hex nicht (die verwendeten 
optionen -j von avr-objcopy kopieren nur die angegebenen sections vom 
bin ins hex).