AVRGCC malloc spinnt ?

[Kahn (Gast)]

Hallo,

ich habe mit mit malloc Speicher geholt. Diesen Speicher beschreibe ich 
und gebe selbigen über die UART aus.

Das komische ist nun dass in der ersten Schleife wie erwartet die 
Zeichen 0x80 bis 0xB1 gesendet werden, aber in der 2. Schleife nur 50 
mal 0x00. Könnte mir das jemand erklären ?

Gruß
Kahn

#include <avr/io.h>
#include <stdlib.h>

int main(void)
{
  UCSR0B = 1<<TXEN | 1<<RXEN | 1<<RXCIE;
  UCSR0C = 1<<UCSZ1 | 1<<UCSZ0;
  UBRR0H = 0;
  UBRR0L = 7;
  
  volatile uint32_t d = 0;
  
  uint8_t *test = (uint8_t *) malloc(50);
  uint8_t i;
  
  for (i=0; i<50; i++)
  {
    test[i] = i + 0x80;
    UDR0 = test[i];
    for (d=0; d<10000; d++);
  }
  
  for (i=0; i<50; i++)
  {
    UDR0 = test[i];
    for (d=0; d<10000; d++);
  }
  
  while (1);
}

[Karl H. (kbuchegg)]

Das nächste mal frag bitte die UART ab, ob sie schon
bereit ist ein Zeichen entgegen zu nehmen oder noch
mit dem Versenden des letzten Zeichens beschäftigt ist.

Deine Warteschleifen kannst du dir in die Haare schmieren.
Die wird der Compiler wegoptimieren.


Wie man die UART befrägt ob sie fertig ist, findest du im
AVR Tutorial.


(Da in der ersten Schleife noch zusätzlich etwas passiert,
was etwas Rechnerei erfordert, ist es durchaus möglich,
dass genau diese zusätzliche Rechnerei den Unterschied
ausmacht zwischen: die UART ist bereits fertig bzw. die
UART ist noch nicht fertig)

[Kahn (Gast)]

Moin,

ich weiß wie man die UART fragt ob sie fertig ist, aber wenn ich nur mal 
"gschwind" was zum Debuggen ausgeben möchte bin ich so schneller als 
jedesmal im Datenblatt das Register nachzuschlagen.
Wie auch immer, auch mit vernünftigen auf-Uart-warten-abfragen ist das 
Symptom das gleiche...

Kahn

[Kahn (Gast)]

P.S.

Die Warteschleifen wird der Compiler nicht wegoptimieren, weil ich die 
Zählervariable genau aus diesem Grund als volatile deklariert habe.

[Jörg W. (dl8dtl) (Moderator)]

Kahn wrote:

> ich weiß wie man die UART fragt ob sie fertig ist, aber wenn ich nur mal
> "gschwind" was zum Debuggen ausgeben möchte bin ich so schneller als
> jedesmal im Datenblatt das Register nachzuschlagen.

Nach dem dritten Mal brauchst du kein Datenblatt mehr, um UDRE0 zu
kennen. ;-)

Aber wenn schon Warteschleifen, dann nimm die aus <util/delay.h>
bzw. <util/delay_basic.h>.  Die haben den Vorteil, eine definierte
Wartezeit zu ergeben.

> Wie auch immer, auch mit vernünftigen auf-Uart-warten-abfragen ist das
> Symptom das gleiche...

http://www.programmersheaven.com/download/16023/download.aspx

Das Original liegt eigentlich unter:

http://www.darwinsys.com/history/canthappen.html

aber die DNS-Server für darwinsys.com haben gerade ein Problem.

Nachdem du das gelesen hast, weißt du ja vielleicht, dass man den
Rückkehrwert von malloc() auch testen sollte...

[Karl H. (kbuchegg)]

Kahn wrote:
> P.S.
>
> Die Warteschleifen wird der Compiler nicht wegoptimieren, weil ich die
> Zählervariable genau aus diesem Grund als volatile deklariert habe.


Ja, ich hab das volatile zu spät gesehen.

Trotzdem denke ich immer noch, dass dein Problem nichts
mit malloc zu tun hat sondern sehr viel mit der UART.

[Kahn (Gast)]

Aaaaalso,

>Nach dem dritten Mal brauchst du kein Datenblatt mehr, um UDRE0 zu
kennen. ;-)

Und in welchem Register ? :-) Nein, ich in meiner Eigenschaft als 
Gashirnbesitzer muss das fast immer nachschlagen, und bei delay müsste 
ich jetzt auch erst ausprobieren ob's _delay, delay, _delayms, 
_delay_ms, oder sonst wie war, oder nachsehen... Naja, jeder wie er mag, 
jeder wie er kann.

Lustiges Dokument übrigens!

>Trotzdem denke ich immer noch, dass dein Problem nichts
mit malloc

Hab's nun gefunden. Liegt natürlich wieder mal am Gashirn :-(
Da ich nicht nur ein Gashirn habe sondern auch faul bin, habe ich das 
makefile eines andere Designs übernommen, in dem folgendes steht:

EXTMEMOPTS = 
-Wl,--defsym=__heap_start=0x801100,--defsym=__heap_end=0x80fffa

Tja, logisch dass da malloc nicht will, dieses Design hat halt keinen 
externen SRAM...