Fehler beim Compilieren?

[Axel Beierlein (Gast)]

Habe versucht mal die I/O Funktionen am 8515 zu programmieren und bin 
auf folgende Merkwürdigkeit gestossen.
gemäß folgendem Code bringt die Betätigung der Taster ein Leuchten der 
LED´s hervor. Obwohl die Variable "taster" die den Wert des I/O 
registers D des Einganges nicht mit dem Ausgang PORTB in Verbindung 
gebracht wird.
Initialisiere ich aber "set" mit dem Wert 0xff dann leuchtet nichts mehr 
beim Tasten.

WARUM ?

Ich nutze übrigens das STK200.

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

void main (void)
   {

   unsigned char set,taster;

   DDRB = 0xfe; // PORTB Ausgang komplett
   DDRD = 0x00; // alle Eingänge an PORTD

   while(1){
   taster = inb(PIND);
   PORTB = set;
   }
 }

[Johannes (Gast)]

Hi!

Du hast leider vergessen, die Variablen zu definieren!

Also eine Zeile wie

int taster, set;

So wird halt auf irgendeine Speicherstelle zugegriffen, offenbar die 
gleiche. Normalerweise führt sowas zum Absturz bzw. einem 
Compilerfehler!

[Axel Beierlein (Gast)]

???

Das sehe ich anders. Jede definierte Variable bekommt ihren 
Speicherplatz zugewiesen. Unabhängig ob sie initialisiert ist oder 
nicht. Ich glaube Du verwechselst da etwas.

Ausserem heisst definieren etwas einen Namen geben und initialisieren 
etwas einen Wert zuweisen.

Zum Absturz führt es nur wenn ich mit nicht initialisierten Pointern 
arbeite. Das ist hier aber nicht der Fall.

ciao

[BAB (Kai K.) (Gast)]

#include <avr/io.h>

int main (void)
   {

   DDRB = 0xff;
   DDRD = 0x00;

   while(1)
   {
   PORTB = PIND;
   }

   return (0);
 }

[Oryx (Gast)]

Hallo Axel,
mit dem definieren und initialisieren hast du recht. Was das 
Speicherplatzzuweisen angeht.
In Deinem Programm ist set aber eine lokale Variable. Die liegen auf dem 
Stack und sind somit nicht initialisiert. Haben also irgendeinen 
zufälligen Wert. Je nach Stackverlauf kannst Du halt auch den Inhalt 
deiner Tasteneingabe erhalten.

Versuch mal Deinem Kompiler beizubringen, bei nicht initialisierten 
Variablen eine Warnung auszugeben. Bei grossen Projekten ist so etwas 
schon wichtig. Da ist die Tücke nicht so leicht zu erkennen und vor 
allen Dingen nicht so reproduzierbar.

Oryx

[Johannes Raschke (Gast)]

@Axel
Hoppla, hatte doch glatt übersehen, daß Du de Variablen sehr wohl 
definiert hast... sorry.
Für mich sieht es auch so aus, als ob hier ein Fehler vorliegt... Was 
passiert denn, wenn Du die Variablen in umgekehrter Reihenfolge 
definierst? Oder eine weitere, unbenutzte dazwischen?

Ich kenne Deine Entwicklungstools ja nicht, aber gibt es vielleicht eine 
Möglichkeit, den C-Code erstmal in Assembler wandeln zu lassen? Dann 
könnte man immerhin sehen, ob die Variablen jetzt Register sind oder auf 
dem Stack, und man könnte das Programm mal im Debugger durchsteppen...


@Oryx
Ja, set ist nicht initialisiert, dürfte seinen Wert aber auch nicht 
durch einen Tastendruck ändern...

[Axel Beierlein (Gast)]

Also ich habe bis jetzt mit der 30 Tage Version von ICC gearbeitet mit 
der Win AVR Library.

Versuche aber wie bereits in einem Thread vorher mein WinAVR unter dem 
Compiler DevCpp zum laufen zu bringen, da ich mit diesem recht vertraut 
bin aber noch nicht genau weiss wie ich WinAVR in Ihm implementiere.

tschö Axel

[Axel Beierlein (Gast)]

Also ich habe mal den generierten Code hier reinkopiert den mein 
Compiler aus meinem Sourcecode in Assembler macht. Vielleicht hilft es 
ja weiter.

Danke Euch im Voraus.

Axel


  .module Tasteneingabe.c
  .area text(rom, con, rel)
  .dbfile E:\icc\examples.avr\Tasteneingabe.c
  .dbfunc e main _main fV
;            set -> R16
;         taster -> R16
  .even
_main::
  .dbline -1
  .dbline 5
; #include <io.h>
; #include <avr/io8515.h>
;
; void main (void)
;    {
  .dbline 9
;
;    unsigned char taster,set;
;
;    DDRB = 0xfe; // PORTB Ausgang komplett
  ldi R24,254
  out 0x17,R24
  .dbline 10
;    DDRD = 0x00; // alle Eingänge an PORTD
  clr R2
  out 0x11,R2
  rjmp L3
L2:
  .dbline 12
  .dbline 13
  in R16,0x10
  .dbline 14
  out 0x18,R16
  .dbline 15
L3:
  .dbline 12
  rjmp L2
X0:
  .dbline -2
  .dbline 16
;
;    while(1){
;    taster = inb(PIND);
;    PORTB = set;
;    }
;  }
L1:
  .dbline 0 ; func end
  ret
  .dbsym r set 16 c
  .dbsym r taster 16 c
  .dbend

[Johannes Raschke (Gast)]

; set -> R16
; taster -> R16


Da hat der doofe Compiler beiden Variablen wohl die gleiche 
Speicherstelle ugewiesen...


 in R16,0x10
 out 0x18,R16

Okay, hier wird also erst was nach R16 eingelesen und dann dieser Wert 
wieder zur Ausgabe benutzt... Ich kenne den Controller nicht weil ich 
bisher nur den 2313 programmiert habe, und auch nur in ASM, aber bei 
0x10 bzw. 0x18 dürften wohl die Ports liegen...

Ich frage mich grade, ob die Zuweisung

PORTB = set;

so funktioniert. Da gibt es doch auch noch outb(); Vielleicht geht das 
damit eher... Oder ist die nur für Konstanten?

Ändere obige Zeile doch mal in

outb(PORTB, set);

und schaue, was passiert... Und vor allem, ob und wie sich der 
Assembler-Code ändert!

[Axel Beierlein (Gast)]

Also das mit outb() habe ich auch probiert mit dem gleichen Ergebnis. 
Vielleicht sollte ich mal den Compiler wechseln.
Aber dann müsste ich jetzt mich auch noch auf das Makefile erstellen 
stürzen und da habe ich irgendwie keine Lust drauf.

tschö

Achso falls es jemanden interessiert ich nutze den ICC Compiler als 
Eval.version den Test hat sie also nicht bestanden.

Mal weiterschauen

[Axel Beierlein (Gast)]

So,

ich habe das ganze nach einigen Anlaufschwierigkeiten nun mit dem AVR 
GCC compiliert und siehe da... es funktioniert so wie ich es mir 
vorgestellt habe. Die Ausgänge werden nach den willkürlichen Inhalten 
der set Variablen geschaltet und die Eingänge haben auch nun überhaupt 
keinen Einfluss mehr auf den Ausgang.

Halt so wie es sein soll. Also kompilierproblem bei ICC.

Ich glaube der ICC Compiler hat nun ausgedient, nachdem ich mich so 
langsam mit dem AVRGCC angefreundet habe.

nur für alle die es interessiert.

Ciao Axel

[Johannes Raschke (Gast)]

Gut zu wissen!
Dürfte auch die Programmierer des Compilers interessieren, hehe :-)