Atmega88 Code kompiliert ohne Fehler und läuft nicht

[Udo F. (utm)]

Nabend zusammen,

habe endlich mein Mini-Beispiel für eine funktionierende USART 
Schnittstelle hinbekommen.

#include <avr/io.h>
#include <util/delay.h>

#define BAUD 9600UL
#define UBRR_VALUE ((F_CPU+BAUD*8)/(BAUD*16)-1)
#define BAUD_REAL (F_CPU/(16*(UBRR_VALUE+1)))
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)

int main( void ){
    if ((BAUD_REAL < 990)||(BAUD_ERROR > 1010)){
        DDRD |= (1<<PD6);
        PORTD |= (1<<PD6);
    }

    UBRR0H = (uint8_t)(UBRR_VALUE >> 8);
    UBRR0L = (uint8_t)UBRR_VALUE;
    UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);
    UCSR0B = (1<<RXEN0)|(1<<TXEN0);

    while(1){
        UDR0 = 'B';
        _delay_ms(2000);
    }   
}

Funktioniert und macht genau das was es soll. Ich verwende hier einen 
sh-u09c5 zum Lesen.

Jetzt wollte ich das Ganze natürlich erweitern auf Strings und habe 
folgende Funktionen hinzugefügt:

int uart_putc(unsigned char c);
void uart_puts(char *s);

int uart_putc(unsigned char c)
{
    return 0;
}

void uart_puts (char *s)
{
    while (*s)
    {
        uart_putc(*s);
        s++;
    }
}

Es kompiliert-ich bekomme per avrdude keine Fehler o.Ä. Aber es wird 
nichts mehr gesendet. Ich rufe beide Funktionen nicht einmal auf und 
dennoch macht es irgendwie alles kaputt.
Wenn ich die beiden Funktionen lösche und den Atmega erneut bespiele 
klappt alles wieder wunderbar. Ich kann es mir absolut nicht erklären. 
Ich hoffe ihr könnt mir einen Tipp geben.

[pnp (Gast)]

Schau dir mal genau an, was putc() macht :-)

[Udo F. (utm)]

pnp schrieb:
> Schau dir mal genau an, was putc() macht :-)

In meinem Fall macht es natürlich nichts außer direkt raus zu springen 
aber das ist ja nur dafür gedacht um zu zeigen, dass der eigentliche 
Code nicht mehr funktioniert obwohl doch die Funktionen nirgendwo 
aufgerufen werden.

Ich hatte das aus dem Tutorial: 
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART#Senden_einer_Zeichenkette_.28String.29 
und die Funktionen sahen vorher so aus:

int uart_putc(unsigned char c)
{
    while (!(UCSR0A & (1<<UDRE0))){}
    UDR0 = c;
    return 0;
}


void uart_puts (char *s)
{
    while (*s)
    {   
        uart_putc(*s);
        s++;
    }
}

Da dies aber zum selben Ergebnis führte - nämlich dass nichts mehr 
gesendet wird (obwohl beide Funktionen erneut nirgendwo aufgerufen 
wurden) - habe ich die while Schleife aus uart_putc entfernt. Ich 
dachte, dass ich irgendwas mit UCSR0A oder UDRE0 falsch mache und habs 
dann auf das nötigste reduziert.

[MaWin (Gast)]

Bitte komplettes Projekt geben. Im gezeigten Code ist kein Fehler. Er 
muss also woanders liegen.

[Udo F. (utm)]

Sehr gerne

#include <avr/io.h>
#include <util/delay.h>

#define BAUD 9600UL                  
#define UBRR_VALUE ((F_CPU+BAUD*8)/(BAUD*16)-1)
#define BAUD_REAL (F_CPU/(16*(UBRR_VALUE+1)))
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)
#define TX_BUFFER_SIZE 128
 
int uart_putc(unsigned char c);
void uaart_puts(char *s);

int main( void )
{
    if ((BAUD_REAL < 990)||(BAUD_ERROR > 1010)){
        DDRD |= (1<<PD6);
        PORTD |= (1<<PD6);
    }

    UBRR0H = (uint8_t)(UBRR_VALUE >> 8);       
    UBRR0L = (uint8_t)UBRR_VALUE;            
    UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);  
    UCSR0B = (1<<RXEN0)|(1<<TXEN0);

    while(1){
        UDR0 = 'B';
  _delay_ms(2000);
    }
    
}
int uart_putc(unsigned char c)
{
    return 0;
}

void uart_puts (char *s)
{
    while (*s)
    {
        uart_putc(*s);
        s++;
    }
}

Filename uart_verysimple.c

avr-gcc -mmcu=atmega88a -Wall -Os -DF_CPU=8000000UL -c uart_verysimple.c -o uart_verysimple.o;
avr-gcc uart_verysimple.o -o uart_verysimple.elf;
avr-objcopy -O ihex -j .text -j .data uart_verysimple.elf uart_verysimple.hex;
avrdude -c usbasp -pm88 -U flash:w:uart_verysimple.hex:a;

ckdiv8 Bit ist ausgeschaltet (auf 1 gesetzt)

[Thomas F. (igel)]

Vergleich mal Zeile 11 mit Zeile 36.

[Hugo H. (hugohurtig1)]

Thomas F. schrieb:
> Vergleich mal Zeile 11 mit Zeile 36.

Ja - und praktisch ist auch immer, wenn man Funktionen, die ausgeführt 
werden sollen, (aus MAIN heraus) aufruft :-)

Dann funktioniert das Beispiel auch ...

Nicht genutzter Code / Variablen werden nicht compiliert - macht ja auch 
wenig Sinn.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thomas F. schrieb:
> Vergleich mal Zeile 11 mit Zeile 36.
Im obigen Original war das noch anders.
Ja, da wäre es manchmal sinnvoller, einfach die *.c Datei anzuhängen...

Udo F. schrieb:
> Sehr gerne
Und was tut jetzt der Code? Oder was erwartest du dass der tut?

Udo F. schrieb:
> habe ich die while Schleife aus uart_putc entfernt. Ich dachte, dass ich
> irgendwas mit UCSR0A oder UDRE0 falsch mache und habs dann auf das nötigste
> reduziert.
Genau das, was du da entfernt hast, ist "das Nötigste", denn diese Zeile 
sorgt dafür, dass der UART nicht einfach überfahren, sondern die 
Übertragung jedes einzelnen Bytes abgewartet wird.
In dem ganz Code vom ersten Post übernimmt das Delay das Abwarten auf 
das Freiwerden des UART-TX-Registers.

[Udo F. (utm)]

Thomas F. schrieb:
> Vergleich mal Zeile 11 mit Zeile 36.

Sorry das ist nur ein Typo. Die Namen der Funktionen stimmen überein.

[Udo F. (utm)]

Hugo H. schrieb:
> Thomas F. schrieb:
>> Vergleich mal Zeile 11 mit Zeile 36.
>
> Ja - und praktisch ist auch immer, wenn man Funktionen, die ausgeführt
> werden sollen, (aus MAIN heraus) aufruft :-)
>
> Dann funktioniert das Beispiel auch ...
>
> Nicht genutzter Code / Variablen werden nicht compiliert - macht ja auch
> wenig Sinn.

Nein weil genau das will ich ja damit zeigen. Es gibt Funktionen, die 
eben nicht aufgerufen werden und es aber nicht mehr funktioniert.
Ich erwarte doch, dass wenn ich Code habe, der nicht aufgerufen wird, 
somit nicht compiliert wird, keine Änderung im Programm bewirkt.
Ohne die beiden uart Funktionen wird alle 2 Sekunden ein B geschrieben 
was ich auch mittels sh-u09c5 und hterm lesen/sehen kann.
Mit diesen Funktionen, die ja nichts machen und auch nicht aufgerufen 
werden wird nichts mehr vom Controller geschickt. Obwohl die main ja 
unangetastet ist.

[Hugo H. (hugohurtig1)]

Udo F. schrieb:
> Es gibt Funktionen, die
> eben nicht aufgerufen werden und es aber nicht mehr funktioniert.

Nach Änderung mit den unsinnigen Funktionen:

uart.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000000  00800100  00800100  000000d0  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  1 .text         0000007c  00000000  00000000  00000054  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .comment      00000030  00000000  00000000  000000d0  2**0
                  CONTENTS, READONLY
  3 .note.gnu.avr.deviceinfo 0000003c  00000000  00000000  00000100  2**2
                  CONTENTS, READONLY
  4 .debug_aranges 00000030  00000000  00000000  0000013c  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_info   00000764  00000000  00000000  0000016c  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_abbrev 000006b7  00000000  00000000  000008d0  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_line   0000029a  00000000  00000000  00000f87  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_frame  00000044  00000000  00000000  00001224  2**2
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_str    00000388  00000000  00000000  00001268  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_loc    00000056  00000000  00000000  000015f0  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_ranges 00000020  00000000  00000000  00001646  2**0
                  CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
   0:  19 c0         rjmp  .+50       ; 0x34 <__ctors_end>
   2:  20 c0         rjmp  .+64       ; 0x44 <__bad_interrupt>
   4:  1f c0         rjmp  .+62       ; 0x44 <__bad_interrupt>
   6:  1e c0         rjmp  .+60       ; 0x44 <__bad_interrupt>
   8:  1d c0         rjmp  .+58       ; 0x44 <__bad_interrupt>
   a:  1c c0         rjmp  .+56       ; 0x44 <__bad_interrupt>
   c:  1b c0         rjmp  .+54       ; 0x44 <__bad_interrupt>
   e:  1a c0         rjmp  .+52       ; 0x44 <__bad_interrupt>
  10:  19 c0         rjmp  .+50       ; 0x44 <__bad_interrupt>
  12:  18 c0         rjmp  .+48       ; 0x44 <__bad_interrupt>
  14:  17 c0         rjmp  .+46       ; 0x44 <__bad_interrupt>
  16:  16 c0         rjmp  .+44       ; 0x44 <__bad_interrupt>
  18:  15 c0         rjmp  .+42       ; 0x44 <__bad_interrupt>
  1a:  14 c0         rjmp  .+40       ; 0x44 <__bad_interrupt>
  1c:  13 c0         rjmp  .+38       ; 0x44 <__bad_interrupt>
  1e:  12 c0         rjmp  .+36       ; 0x44 <__bad_interrupt>
  20:  11 c0         rjmp  .+34       ; 0x44 <__bad_interrupt>
  22:  10 c0         rjmp  .+32       ; 0x44 <__bad_interrupt>
  24:  0f c0         rjmp  .+30       ; 0x44 <__bad_interrupt>
  26:  0e c0         rjmp  .+28       ; 0x44 <__bad_interrupt>
  28:  0d c0         rjmp  .+26       ; 0x44 <__bad_interrupt>
  2a:  0c c0         rjmp  .+24       ; 0x44 <__bad_interrupt>
  2c:  0b c0         rjmp  .+22       ; 0x44 <__bad_interrupt>
  2e:  0a c0         rjmp  .+20       ; 0x44 <__bad_interrupt>
  30:  09 c0         rjmp  .+18       ; 0x44 <__bad_interrupt>
  32:  08 c0         rjmp  .+16       ; 0x44 <__bad_interrupt>

00000034 <__ctors_end>:
  34:  11 24         eor  r1, r1
  36:  1f be         out  0x3f, r1  ; 63
  38:  cf ef         ldi  r28, 0xFF  ; 255
  3a:  d4 e0         ldi  r29, 0x04  ; 4
  3c:  de bf         out  0x3e, r29  ; 62
  3e:  cd bf         out  0x3d, r28  ; 61
  40:  02 d0         rcall  .+4        ; 0x46 <main>
  42:  1a c0         rjmp  .+52       ; 0x78 <_exit>

00000044 <__bad_interrupt>:
  44:  dd cf         rjmp  .-70       ; 0x0 <__vectors>

00000046 <main>:
{
  if ((BAUD_REAL < 990)||(BAUD_ERROR > 1010)){
    DDRD |= (1<<PD6);
    PORTD |= (1<<PD6);
  }
  UBRR0H = (uint8_t)(UBRR_VALUE >> 8);
  46:  10 92 c5 00   sts  0x00C5, r1  ; 0x8000c5 <__TEXT_REGION_LENGTH__+0x7fe0c5>
  UBRR0L = (uint8_t)UBRR_VALUE;
  4a:  83 e3         ldi  r24, 0x33  ; 51
  4c:  80 93 c4 00   sts  0x00C4, r24  ; 0x8000c4 <__TEXT_REGION_LENGTH__+0x7fe0c4>
  UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);
  50:  86 e0         ldi  r24, 0x06  ; 6
  52:  80 93 c2 00   sts  0x00C2, r24  ; 0x8000c2 <__TEXT_REGION_LENGTH__+0x7fe0c2>
  UCSR0B = (1<<RXEN0)|(1<<TXEN0);
  56:  88 e1         ldi  r24, 0x18  ; 24
  58:  80 93 c1 00   sts  0x00C1, r24  ; 0x8000c1 <__TEXT_REGION_LENGTH__+0x7fe0c1>
  while(1){
    UDR0 = 'B';
  5c:  e6 ec         ldi  r30, 0xC6  ; 198
  5e:  f0 e0         ldi  r31, 0x00  ; 0
  60:  82 e4         ldi  r24, 0x42  ; 66
  62:  80 83         st  Z, r24
  #else
    //round up by default
    __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
  #endif

  __builtin_avr_delay_cycles(__ticks_dc);
  64:  2f ef         ldi  r18, 0xFF  ; 255
  66:  33 ed         ldi  r19, 0xD3  ; 211
  68:  90 e3         ldi  r25, 0x30  ; 48
  6a:  21 50         subi  r18, 0x01  ; 1
  6c:  30 40         sbci  r19, 0x00  ; 0
  6e:  90 40         sbci  r25, 0x00  ; 0
  70:  e1 f7         brne  .-8        ; 0x6a <main+0x24>
  72:  00 c0         rjmp  .+0        ; 0x74 <main+0x2e>
  74:  00 00         nop
  76:  f5 cf         rjmp  .-22       ; 0x62 <main+0x1c>

00000078 <_exit>:
  78:  f8 94         cli

0000007a <__stop_program>:
  7a:  ff cf         rjmp  .-2        ; 0x7a <__stop_program>

Vor Änderung (die Funktionen entfernt):

uart.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000000  00800100  00800100  000000d0  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  1 .text         0000007c  00000000  00000000  00000054  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .comment      00000030  00000000  00000000  000000d0  2**0
                  CONTENTS, READONLY
  3 .note.gnu.avr.deviceinfo 0000003c  00000000  00000000  00000100  2**2
                  CONTENTS, READONLY
  4 .debug_aranges 00000020  00000000  00000000  0000013c  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_info   000006ff  00000000  00000000  0000015c  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_abbrev 00000667  00000000  00000000  0000085b  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_line   0000026e  00000000  00000000  00000ec2  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_frame  00000024  00000000  00000000  00001130  2**2
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_str    00000374  00000000  00000000  00001154  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_ranges 00000010  00000000  00000000  000014c8  2**0
                  CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
   0:  19 c0         rjmp  .+50       ; 0x34 <__ctors_end>
   2:  20 c0         rjmp  .+64       ; 0x44 <__bad_interrupt>
   4:  1f c0         rjmp  .+62       ; 0x44 <__bad_interrupt>
   6:  1e c0         rjmp  .+60       ; 0x44 <__bad_interrupt>
   8:  1d c0         rjmp  .+58       ; 0x44 <__bad_interrupt>
   a:  1c c0         rjmp  .+56       ; 0x44 <__bad_interrupt>
   c:  1b c0         rjmp  .+54       ; 0x44 <__bad_interrupt>
   e:  1a c0         rjmp  .+52       ; 0x44 <__bad_interrupt>
  10:  19 c0         rjmp  .+50       ; 0x44 <__bad_interrupt>
  12:  18 c0         rjmp  .+48       ; 0x44 <__bad_interrupt>
  14:  17 c0         rjmp  .+46       ; 0x44 <__bad_interrupt>
  16:  16 c0         rjmp  .+44       ; 0x44 <__bad_interrupt>
  18:  15 c0         rjmp  .+42       ; 0x44 <__bad_interrupt>
  1a:  14 c0         rjmp  .+40       ; 0x44 <__bad_interrupt>
  1c:  13 c0         rjmp  .+38       ; 0x44 <__bad_interrupt>
  1e:  12 c0         rjmp  .+36       ; 0x44 <__bad_interrupt>
  20:  11 c0         rjmp  .+34       ; 0x44 <__bad_interrupt>
  22:  10 c0         rjmp  .+32       ; 0x44 <__bad_interrupt>
  24:  0f c0         rjmp  .+30       ; 0x44 <__bad_interrupt>
  26:  0e c0         rjmp  .+28       ; 0x44 <__bad_interrupt>
  28:  0d c0         rjmp  .+26       ; 0x44 <__bad_interrupt>
  2a:  0c c0         rjmp  .+24       ; 0x44 <__bad_interrupt>
  2c:  0b c0         rjmp  .+22       ; 0x44 <__bad_interrupt>
  2e:  0a c0         rjmp  .+20       ; 0x44 <__bad_interrupt>
  30:  09 c0         rjmp  .+18       ; 0x44 <__bad_interrupt>
  32:  08 c0         rjmp  .+16       ; 0x44 <__bad_interrupt>

00000034 <__ctors_end>:
  34:  11 24         eor  r1, r1
  36:  1f be         out  0x3f, r1  ; 63
  38:  cf ef         ldi  r28, 0xFF  ; 255
  3a:  d4 e0         ldi  r29, 0x04  ; 4
  3c:  de bf         out  0x3e, r29  ; 62
  3e:  cd bf         out  0x3d, r28  ; 61
  40:  02 d0         rcall  .+4        ; 0x46 <main>
  42:  1a c0         rjmp  .+52       ; 0x78 <_exit>

00000044 <__bad_interrupt>:
  44:  dd cf         rjmp  .-70       ; 0x0 <__vectors>

00000046 <main>:
{
  if ((BAUD_REAL < 990)||(BAUD_ERROR > 1010)){
    DDRD |= (1<<PD6);
    PORTD |= (1<<PD6);
  }
  UBRR0H = (uint8_t)(UBRR_VALUE >> 8);
  46:  10 92 c5 00   sts  0x00C5, r1  ; 0x8000c5 <__TEXT_REGION_LENGTH__+0x7fe0c5>
  UBRR0L = (uint8_t)UBRR_VALUE;
  4a:  83 e3         ldi  r24, 0x33  ; 51
  4c:  80 93 c4 00   sts  0x00C4, r24  ; 0x8000c4 <__TEXT_REGION_LENGTH__+0x7fe0c4>
  UCSR0C = (1<<UCSZ01)|(1<<UCSZ00);
  50:  86 e0         ldi  r24, 0x06  ; 6
  52:  80 93 c2 00   sts  0x00C2, r24  ; 0x8000c2 <__TEXT_REGION_LENGTH__+0x7fe0c2>
  UCSR0B = (1<<RXEN0)|(1<<TXEN0);
  56:  88 e1         ldi  r24, 0x18  ; 24
  58:  80 93 c1 00   sts  0x00C1, r24  ; 0x8000c1 <__TEXT_REGION_LENGTH__+0x7fe0c1>
  while(1){
    UDR0 = 'B';
  5c:  e6 ec         ldi  r30, 0xC6  ; 198
  5e:  f0 e0         ldi  r31, 0x00  ; 0
  60:  82 e4         ldi  r24, 0x42  ; 66
  62:  80 83         st  Z, r24
  #else
    //round up by default
    __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
  #endif

  __builtin_avr_delay_cycles(__ticks_dc);
  64:  2f ef         ldi  r18, 0xFF  ; 255
  66:  33 ed         ldi  r19, 0xD3  ; 211
  68:  90 e3         ldi  r25, 0x30  ; 48
  6a:  21 50         subi  r18, 0x01  ; 1
  6c:  30 40         sbci  r19, 0x00  ; 0
  6e:  90 40         sbci  r25, 0x00  ; 0
  70:  e1 f7         brne  .-8        ; 0x6a <main+0x24>
  72:  00 c0         rjmp  .+0        ; 0x74 <main+0x2e>
  74:  00 00         nop
  76:  f5 cf         rjmp  .-22       ; 0x62 <main+0x1c>

00000078 <_exit>:
  78:  f8 94         cli

0000007a <__stop_program>:
  7a:  ff cf         rjmp  .-2        ; 0x7a <__stop_program>

Zeige mir bitte den Unterschied (außer den Debug-Angaben) - es gibt 
keinen. Du zeigst schlicht nicht alles und damit brauchst Du scheinbar 
auch keine Hilfe.

[Udo F. (utm)]

Stimmt. Ich verheimliche bei meinem geheimen, komplexen Programm teile 
damit ihr die bloß nicht seht.

Ich bin Anfänger in Mikrokontroller-Entwicklung und komme nicht weiter. 
Ich kenne mich mit höheren Sprachen wir Java etc. aus aber eben nicht 
mit so low level Programmierung. Und deshalb ist ja meine Verwunderung 
so groß, dass Funktionen, die nichts machen, nicht aufgerufen werden, 
dennoch alles kaputt machen.

Es gibt exakt eine c-Datei, die ihr inzwischen vollständig habt.
Dazu gibt es die 4 Zeilen, mit denen ich den Code auf den Atmega88A 
bespiele. Das wars. Mehr ist nicht.

Ich glaube dir ja, dass, nachdem du das File analysiert hast, es keine 
Unterschiede gibt, aber dann kannst du mir doch auch glauben, dass ich 
nichts "verstecke".

Meiner Meinung nach kann es ja dann nur am Atmega88 liegen. Ich habe 
hier nochmal den output von avrdude als Anhang mitgegeben. Keine Ahnung 
ob das weiter hilft.

[Hugo H. (hugohurtig1)]

Udo F. schrieb:
> Meiner Meinung nach kann es ja dann nur am Atmega88 liegen.

Meiner Meinung nach liegt es an Dir und Du nimmst Du das falsche 
Hex-File

"avrdude: writing flash (66 bytes)"

Wenn ich compiliere komme ich auf

"Program Memory Usage   :  124 bytes   1,5 % Full"

Mit _delay... kann es nicht so kurz (66 bytes) sein (Meiner Meinung 
nach).

[Udo F. (utm)]

Danke für den Hinweis. Werds heut Abend ausprobieren und hoffentlich 
etwas herausfinden.

[Stefan F. (Gast)]

Hugo H. schrieb:
> "Program Memory Usage   :  124 bytes   1,5 % Full"
> Mit _delay... kann es nicht so kurz (66 bytes) sein (Meiner Meinung
> nach).

Das Assembler Listing endet bei 0x7a (=122) mit 2 Bytes, kommt also hin. 
Da ist das delay auch drin. Die 124 sind alle belegt, da kann es nicht 
in Ordnung sein, dass er nur 66 Bytes davon in den Flash schreibt.

Ich würde da mal weiter nachforschen, bin ziemlich sicher dass Hugo es 
auf den Punkt gebracht hat.

Die Berechnung der Baudrate überlässt man normalerweise der AVR 
Bibliothek 
https://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html

[Andreas B. (bitverdreher)]

Stefan ⛄ F. schrieb:
> Ich würde da mal weiter nachforschen, bin ziemlich sicher dass Hugo es
> auf den Punkt gebracht hat.
Dazu wäre auch mal interessant wie das compiliert wurde.
Makefile?
Und auch wie avrdude aufgerufen wurde.
Da fehlt das Ganze drumherum.

[Udo F. (utm)]

Andreas B. schrieb:
> Dazu wäre auch mal interessant wie das compiliert wurde.
> Makefile?
> Und auch wie avrdude aufgerufen wurde.
> Da fehlt das Ganze drumherum.
Das hatte ich bereits geschrieben:

avr-gcc -mmcu=atmega88a -Wall -Os -DF_CPU=8000000UL -c uart_verysimple.c -o uart_verysimple.o;
avr-gcc uart_verysimple.o -o uart_verysimple.elf;
avr-objcopy -O ihex -j .text -j .data uart_verysimple.elf uart_verysimple.hex;
avrdude -c usbasp -pm88 -U flash:w:uart_verysimple.hex:a;

Das ganze ist in einem Bash-Skript und wird einfach mittels: 
./doStuff.sh ausgeführt. Es ist somit kein wirkliches Makefile

[Andreas B. (bitverdreher)]

Laß hier mal:
avrdude -c usbasp -pm88 -U flash:w:uart_verysimple.hex:a;
das :a am Schluß weg.

[Udo F. (utm)]

Andreas B. schrieb:
> Laß hier mal:
> avrdude -c usbasp -pm88 -U flash:w:uart_verysimple.hex:a;
> das :a am Schluß weg.

Hab ich. Leider selbes Ergebnis.

Bzgl. der Anzahl der Bytes (von weiter oben). Ich habe mal die beiden 
Funktionen entfernt und mit/ohne :a den Chip bespielt.
In beiden Fällen läuft der Code wie geplant und avrdude sagt mir, dass 
er 48 Bytes geschrieben hat. Mit den Funktionen sind es 66.

[Stefan F. (Gast)]

Udo F. schrieb:
> In beiden Fällen läuft der Code wie geplant und avrdude sagt mir, dass
> er 48 Bytes geschrieben hat. Mit den Funktionen sind es 66.

Dass der Maschinencode eine andere Größe hat als bei Hugo mag an den 
Compiler Optionen oder der Version liegen.

Bei dir werden die unbenutzten Funktionen offenbar nicht entfernt. Ich 
denke das liegt daran, dass du die sonst üblichen Compiler-und Linker 
Flags nicht verwendet hast. In meinem Makefile sind es diese

FLAGS += -ffunction-sections -fdata-sections
LDFLAGS += -Wl,--gc-sections

Das erklärt aber noch nicht, warum die größere Datei mit den ungenutzten 
Funktionen nicht funktioniert. Kannst du mal das Assembler-Listing 
zeigen, dass dein Rechner generiert (sie wie Hugo oben seins gezeigt 
hat)?

[Hugo H. (hugohurtig1)]

Udo F. schrieb:
> Mit den Funktionen sind es 66

Selbst wenn ich "Optimize most" einstelle - -O3 - sind es immer noch 122 
Bytes. Daher gehe ich immer noch davon aus, dass Du das falsche 
.HEX-File flasht.

Zeige doch bitte mal die Compiler-Meldungen und das .LSS-File.

[Udo F. (utm)]

Habe es so kompiliert:

avr-gcc -mmcu=atmega88a -Wall -Os -DF_CPU=8000000UL -c uart_verysimple.c -S

[Hugo H. (hugohurtig1)]

Udo F. schrieb:
> Habe es so kompiliert:

Und wo bitte sind die Compiler-Meldungen?

[Stefan F. (Gast)]

Hugo H. schrieb:
> Selbst wenn ich "Optimize most" einstelle - -O3 - sind es immer noch 122
> Bytes.

Kein Wunder. -O3 optimiert für maximale Performance auf Kosten der 
Programmgröße.

Wenn du es möglichst klein haben willst, musst du -Os verwenden, wie Udo 
es getan hat.

[Stefan F. (Gast)]

Udo F. schrieb:
> Habe es so kompiliert

Leider stehen in dem Listing nicht die Adressen. Aber ich sehe da 
ungefähr 25 Befehle. Die meisten brauchen 2 Bytes, dazu kommt noch die 
Interrupt-Tabelle. Da sind die 66 also schon plausibel.

Das bringt mich aber auf eine Idee: Woher weiß der Linker, wie viel 
Platz er für die Interrupt-Tabelle reservieren muss, obwohl sie nicht im 
Assember Listing enthalten ist?

Kann es sein, dass du beim Linken
> avr-gcc uart_verysimple.o -o uart_verysimple.elf;
den µC Typ angeben musst? Ich mache das jedenfalls immer in meinem 
Makefile.

Vielleicht profitierst du auch davon, ein erprobtes Makefile zu 
benutzen. Meine persönliche Kopiervorlage findest du dort: 
http://stefanfrings.de/avr_hello_world/index.html

[Hugo H. (hugohurtig1)]

Stefan ⛄ F. schrieb:
> Kein Wunder. -O3 optimiert für maximale Performance auf Kosten der
> Programmgröße.

Das spielt bei dem Mickey-Maus-Programm überhaupt keine Geige.

[Udo F. (utm)]

Stefan ⛄ F. schrieb:
> Vielleicht profitierst du auch davon, ein erprobtes Makefile zu
> benutzen. Meine persönliche Kopiervorlage findest du dort:
> http://stefanfrings.de/avr_hello_world/index.html

Genau die Idee kam mir vor 10 Min. auch und .... es funktioniert. Ich 
fass es nicht!!!

[Hugo H. (hugohurtig1)]

Stefan ⛄ F. schrieb:
> dazu kommt noch die
> Interrupt-Tabelle. Da sind die 66 also schon plausibel

Wie lang ist denn die Interrupt-Tabelle?

[Stefan F. (Gast)]

Hugo H. schrieb:
> Das spielt bei dem Mickey-Maus-Programm überhaupt keine Geige.

Dann ist es wohl fehlerhaft gelinkt worden.

[Stefan F. (Gast)]

Hugo H. schrieb:
> Wie lang ist denn die Interrupt-Tabelle?

Schau in dein eigenes Listing:

00000000 <__vectors>:
   0:  19 c0         rjmp  .+50       ; 0x34 <__ctors_end>
   2:  20 c0         rjmp  .+64       ; 0x44 <__bad_interrupt>
   ...
  32:  08 c0         rjmp  .+16       ; 0x44 <__bad_interrupt>

Sieht nach 64 Bytes aus.

[Hugo H. (hugohurtig1)]

Stefan ⛄ F. schrieb:
> Sieht nach 64 Bytes aus.

Stefan ⛄ F. schrieb:
> Da sind die 66 also schon plausibel

Gut dann ist in den verbliebenen 2 Bytes der komplette Code versteckt. 
Das möchte ich auch können - wie geht das?

[Stefan F. (Gast)]

Hugo H. schrieb:
> Gut dann ist in den verbliebenen 2 Bytes der komplette Code versteckt.
> Das möchte ich auch können - wie geht das?

Quatsch

Die Interrupt-Tabelle hat 64 Bytes.
Der Programmcode hat 66 Bytes.

macht zusammen ungefähr die 124 bytes, die bei dir als
> "Program Memory Usage   :  124 bytes   1,5 % Full"
gemeldet wurden.

[Hugo H. (hugohurtig1)]

Stefan ⛄ F. schrieb:
> Quatsch
>
> Die Interrupt-Tabelle hat 64 Bytes.
> Der Programmcode hat 66 Bytes.
>
> macht zusammen ungefähr die 124 bytes, die bei dir als
>> "Program Memory Usage   :  124 bytes   1,5 % Full"
> gemeldet wurden.

Und was schiebt AVR-Dude auf den Controller? Nur den Programmcode? 
Spielt die Interrupt-Tabelle keine Rolle? Erhält der MC diese intuitiv?

[Stefan F. (Gast)]

Hugo H. schrieb:
> Und was schiebt AVR-Dude auf den Controller? Nur den Programmcode?

Das komplette gelinkte Programm, samt Interrupt Tabelle und 
Initialisierungs-Daten für Variablen (falls vorhanden).

> Spielt die Interrupt-Tabelle keine Rolle?

Ich habe dir doch gerade vorgerechnet, dass der Programmcode + 
Interrupt-Tabelle zusammen die gesamt-Größe ausmachen, die in den Flash 
übertragen werden müssen.

[Hugo H. (hugohurtig1)]

Stefan ⛄ F. schrieb:
> Ich habe dir doch gerade vorgerechnet, dass der Programmcode +
> Interrupt-Tabelle zusammen die gesamt-Größe ausmachen, die in den Flash
> übertragen werden müssen.

Und warum sind dann die 66 übertragenen Bytes plausibel? Addieren ist 
Dir bekannt?

Du hättest Politiker werden sollen - vielleicht sucht Armin ja noch 
Helfer :-)

Ich glaube, Du wohnst sogar in der Ecke - oder? Dann passt es ja.

[Stefan F. (Gast)]

Hugo H. schrieb:
> Und warum sind dann die 66 übertragenen Bytes plausibel?

Weil er falsch (ohne Interrupt Vektoren) gelinkt hat. Ohne Interrupt 
Vektoren flasht er nur den Programmcode und der umfasst halt die 66 
Bytes.

[Hugo H. (hugohurtig1)]

Stefan ⛄ F. schrieb:
> Weil er falsch (ohne Interrupt Vektoren) gelinkt hat. Ohne Interrupt
> Vektoren flasht er nur den Programmcode und der umfasst halt die 66
> Bytes.

Ja - also nicht plausibel. Kannst Du es nicht zugeben, wenn Du Müll 
erzählt hast?

[Stefan F. (Gast)]

Hugo, ich weiß nicht was das werden soll. Entweder tust du so doof um 
mich zu ärgern, oder du versteht es wirklich nicht. Es hat keinen Sinn 
darauf weiter einzugehen.

[Hugo H. (hugohurtig1)]

Stefan ⛄ F. schrieb:
> Hugo, ich weiß nicht was das werden soll. Entweder tust du so doof um
> mich zu ärgern, oder du versteht es wirklich nicht. Es hat keinen Sinn
> darauf weiter einzugehen.

Lies bitte mal Deine Posts durch und reflektiere diese - das reicht 
schon.

[Rainer V. (a_zip)]

Nu schlagt euch doch nicht die Köpfe ein! Der To hat doch einen völligen 
Humbug gepostet!! Natürlich bin ich auch immer baff, wenn mein Programm 
nicht läuft. Neu ist die Variante, natürlich die hinterhältige Variante, 
dass das geniale Programm kompiliert werden kann und dennoch nicht 
läuft! Wenn das jetzt nicht mal dem Fass den Boden ausschlägt...anders 
herum gehts immer ganz einfach :-) aber sowas habe ich noch nicht 
erlebt!!!
Gruß Rainer

[Rainer V. (a_zip)]

Ich bleibe dabei...völliger Humbug!
Rainer

[c-hater (Gast)]

Rainer V. schrieb:
> Nu schlagt euch doch nicht die Köpfe ein! Der To hat doch einen völligen
> Humbug gepostet!! Natürlich bin ich auch immer baff, wenn mein Programm
> nicht läuft. Neu ist die Variante, natürlich die hinterhältige Variante,
> dass das geniale Programm kompiliert werden kann und dennoch nicht
> läuft! Wenn das jetzt nicht mal dem Fass den Boden ausschlägt...anders
> herum gehts immer ganz einfach :-) aber sowas habe ich noch nicht
> erlebt!!!

GRIN. Wenn's so einfach wäre, dass erfolgreiches Kompilieren schon 
sicher die Programmfunktion herstellen könnte: Wer bräuchte denn dann 
überhaupt noch Programmierer? Code kann man generieren lassen oder 
klauen.

Aber ja, ICH habe schon verstanden, dass dein Beitrag eher sarkastisch 
gemeint war.

[Rainer V. (a_zip)]

c-hater schrieb:
> Aber ja, ICH habe schon verstanden, dass dein Beitrag eher sarkastisch
> gemeint war.

ist doch aber wirklich kaum anders zu ertragen oder?? Endlich postet 
jemand einen Code, der anstandlos übersetzt wird...und er läuft nicht. 
Ich frage mich jetzt ernsthaft, wie ich das sagen soll...Ich sage "there 
is no understanding in the world" und das ist definitiv im Einklang mit 
den neusten Erkenntnissen von CERN über die wackelige 8te bis 12te 
Stelle im Welbild der momentan geltenden Physik. Ist doch Scheissegal, 
höre ich die Kandidaten schon schreien...aber ist es das wirklich...was 
wäre, wenn es einen Cetaur doch gegeben hätt? OK LG
Rainer

[Udo F. (utm)]

Ich finds ziemlich krass was hier aus diesem Post - Zitat 'Mikey Maus 
Code' (was er definitiv ist!) - am Ende passiert ist.
Ich wollte mich auf jeden Fall bei euch Allen für die Hilfe bedanken, da 
ich alleine nicht weiter gekommen wäre.
Ich muss zugeben, dass ich bis jetzt nicht weiß, warum das Makefile es 
am Ende gerockt hat. Ich habe definitiv nichts am Code verändert.
Auf jeden Fall werde ich jetzt immer das besagte Makefile nutzen, da ich 
dann zur Not auch alle Informationen wie z.B. das LSS File bekomme und 
es bei weiteren Fragen dann zur Hand habe.
Wie gesagt-ich bin Anfänger und muss noch dazu lernen.

[Stefan F. (Gast)]

Udo F. schrieb:
> Ich muss zugeben, dass ich bis jetzt nicht weiß, warum das Makefile es
> am Ende gerockt hat

Sorry, das habe ich wohl nicht deutlich genug erklärt.

Du hast versäumt, beim zweiten Aufruf des gccc (Linker) anzugeben, für 
welchen Mikrocontroller das *.elf File erzuegt werden soll. Deswegen 
fehlte dort die Interrupt-Vektor Tabelle, also dieser ganze Block:

00000000 <__vectors>:
   0:  19 c0         rjmp  .+50       ; 0x34 <__ctors_end>
   2:  20 c0         rjmp  .+64       ; 0x44 <__bad_interrupt>
   4:  1f c0         rjmp  .+62       ; 0x44 <__bad_interrupt>
   6:  1e c0         rjmp  .+60       ; 0x44 <__bad_interrupt>
   8:  1d c0         rjmp  .+58       ; 0x44 <__bad_interrupt>
   a:  1c c0         rjmp  .+56       ; 0x44 <__bad_interrupt>
   c:  1b c0         rjmp  .+54       ; 0x44 <__bad_interrupt>
   e:  1a c0         rjmp  .+52       ; 0x44 <__bad_interrupt>
  10:  19 c0         rjmp  .+50       ; 0x44 <__bad_interrupt>
  12:  18 c0         rjmp  .+48       ; 0x44 <__bad_interrupt>
  14:  17 c0         rjmp  .+46       ; 0x44 <__bad_interrupt>
  16:  16 c0         rjmp  .+44       ; 0x44 <__bad_interrupt>
  18:  15 c0         rjmp  .+42       ; 0x44 <__bad_interrupt>
  1a:  14 c0         rjmp  .+40       ; 0x44 <__bad_interrupt>
  1c:  13 c0         rjmp  .+38       ; 0x44 <__bad_interrupt>
  1e:  12 c0         rjmp  .+36       ; 0x44 <__bad_interrupt>
  20:  11 c0         rjmp  .+34       ; 0x44 <__bad_interrupt>
  22:  10 c0         rjmp  .+32       ; 0x44 <__bad_interrupt>
  24:  0f c0         rjmp  .+30       ; 0x44 <__bad_interrupt>
  26:  0e c0         rjmp  .+28       ; 0x44 <__bad_interrupt>
  28:  0d c0         rjmp  .+26       ; 0x44 <__bad_interrupt>
  2a:  0c c0         rjmp  .+24       ; 0x44 <__bad_interrupt>
  2c:  0b c0         rjmp  .+22       ; 0x44 <__bad_interrupt>
  2e:  0a c0         rjmp  .+20       ; 0x44 <__bad_interrupt>
  30:  09 c0         rjmp  .+18       ; 0x44 <__bad_interrupt>
  32:  08 c0         rjmp  .+16       ; 0x44 <__bad_interrupt>

Den siehst du in deinem C-Quelltext nicht, weil er eben vom Linker 
automatisch ergänzt wird. Aber nur, wen man dem Linker sagt, für welchen 
Mikrocontroller er das tun soll.