ATTiny24A AVR Simulator ändert die Ports nicht wie im Quelltext geschrieben!?

[kai (Gast)]

Hi.
Folgender Code:

#define F_CPU 128000UL  // 128 kHz

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

int main(void)
{
  //______________Initialisierung_____________________
  DDRA |= 0xFF;
  DDRB |= (1<<PINB0) | (1<<PINB1) | (1<<PINB2);
...

Das AVR Studio 5 ist auf Attiny24A eingestellt. Ich gehe den Code im AVR 
Simulator zeilenweise durch und schaue mir die Bits in DDRA und DDRB an. 
Aber bei DDRA |= 0xFF; und DDRB |= (1<<PINB0) | (1<<PINB1) | (1<<PINB2); 
ändert sich nichts. Auch wenn ich PORTA und PORTB schreibe, werden im 
Simulator keine Bits gesetzt....

Hab ich was falsch programmiert? Oder liegt es am Simulator? Würde der 
Code später auf meinem realen Chip laufen?

Grüße.

[Bernd (Gast)]

Kann mich mit dem Studio 5 nicht anfreunden und
arbeite bei µCs auch nicht mit C.

Probier doch mal die Initialisierung
nicht mit " |= ", sondern mit der simplen
Zuweisung " = ".

Sehr sinnvoll scheint mir das "ver-ODERn" von
Porteinstellungen nicht:

Entweder haben die für das ganze "Programmleben"
nur eine Aufgabe: Dann mit " = " zuweisen.

Oder ich will was ändern, dann bekomme ich mit "ODER"
aber keine vorher gesetzte "EINS" wieder auf "NULL"...

[Lehrmann M. (ubimbo)]

Bernd schrieb:
> und
> arbeite bei µCs auch nicht mit C.

So womit dann? Und sag bitte jetzt nicht Basic oder einem Basicdialekt.

Bernd schrieb:
> Probier doch mal die Initialisierung
Ich sehe aber keine Initialisierung im engeren Sinne - das sind 
Zuweisungen, auch wenn dies die erste Zuweisung im dargestellten Code 
sind.


Bernd schrieb:
> Sehr sinnvoll scheint mir das "ver-ODERn" von
> Porteinstellungen nicht:

Willst du uns hier verarschen? Diese Aussage muss man sich mal auf der 
Zunge zergehen lassen. Im hier gegebenen Beispiel sicherlich 
gleichwertig aber für alle anderen Fälle bin ich sprachlos.

Bernd schrieb:
> Oder ich will was ändern, dann bekomme ich mit "ODER"
> aber keine vorher gesetzte "EINS" wieder auf "NULL"...

Ich empfehle dir dich mit Grundlagen Bitmanipulation auseinanderzusetzen 
und dann wieder an dieser Diskussion Teil zu nehmen. Aber zu 
postulieren, dass OR-Verknüpfungen sinnlos sind deutet darauf hin, dass 
du nicht im entferntesten Verständnis von digitalen System, Hintergründe 
in Mikrocontrollerwissen oder Deresgleichen hast.

Zum Thema:

kai schrieb:
> DDRA |= 0xFF;

Das wandelt der Compiler sowieso sinngemäß in der Optimierung zu DDRA = 
0xFF um.

kai schrieb:
> DDRB |= (1<<PINB0) | (1<<PINB1) | (1<<PINB2);

Setzt mal zur Sicherheit Klammern

DDRB |= ((1<<PINB0) | (1<<PINB1) | (1<<PINB2));

es sollte eigentlich keinen Unterschied machen, da |= (Operatorpriorität 
2') gegenüber | (Operatorpriorität 6) vorrang haben sollte - 
vorrausgesetzt es ist ein ANSI-C-Compiler.

Ansonsten:

+ hast du eine Endlosschleife ?
+ wie geht dein Code weiter ?

[kai (Gast)]

Also mit Klammern ist es auch nicht besser.
Nach dem Codebeispiel kommt ne Endlosschleife also einfach:

 while(1)
    {
}
return 0;
}

[Johann L. (gjlayde)]

kai schrieb:

> Hab ich was falsch programmiert? Oder liegt es am Simulator?

Schau mal den erzeugte Assembler- oder Object-Code an. Dass siehst du 
zumindest mal of der Code richtig ist oder der Simulator spinnt oder die 
Generierungsumgebung, die bei Quelländerung nicht neu compiliert.

[Ernst B. (puravida)]

Hi!

Also ich habe das gerade im AVR-Studio 5 probiert, auch mit dem 
Attiny24A und Deinem Code

#define F_CPU 128000UL  // 128 kHz

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

int main(void)
{
  
    //______________Initialisierung_____________________
  DDRA |= 0xFF;
  DDRB |= (1<<PINB0) | (1<<PINB1) | (1<<PINB2);
  
    while(1)
    {
        //TODO:: Please write your application code 
    }
}

Und die Ports reagieren beide beim debuggen. Liegt also entweder an 
irgendwelchen Einstellungen oder an der Installation.

LG
Ernst

[Matthias (Gast)]

kai schrieb:
> Hab ich was falsch programmiert? Oder liegt es am Simulator? Würde der
> Code später auf meinem realen Chip laufen?

Da meint der Compiler, dass die Zeile DDRB |= ... überflüssig ist und 
optimiert die weg. Wenn du die Optimierung ausschaltest oder 
irgendwelchen sinnvollen Code dahinter schreibst (z.B. DDRB = 0x00; ), 
wird die Zeile auch in ausführbaren Code umgesetzt.

[Karl H. (kbuchegg)]

Matthias schrieb:
> kai schrieb:
>> Hab ich was falsch programmiert? Oder liegt es am Simulator? Würde der
>> Code später auf meinem realen Chip laufen?
>
> Da meint der Compiler, dass die Zeile DDRB |= ... überflüssig ist und
> optimiert die weg.

Wenn er das tut, dann wäre das ein schwerer Fehler im Compiler.

Was aber sein kann: Er hat die Optimierung eingeschaltet und der 
Debugger findet die Assembler-Entsprechung der Anweisung im C Code nicht 
mehr.

[Matthias (Gast)]

Karl Heinz Buchegger schrieb:
> Was aber sein kann: Er hat die Optimierung eingeschaltet und der
> Debugger findet die Assembler-Entsprechung der Anweisung im C Code nicht
> mehr.

Da scheinst du Recht zu haben. Zumindest mit AVR Studio 4 wird der 
Binärcode richtig erzeugt, aber der Simulator zeigt es das Ergebnis 
nicht richtig an.

000000ce <main>:
  ce:  8a b3         in   r24,  0x1a  ;  26
  d0:  8f ef         ldi  r24,  0xFF  ; 255
  d2:  8a bb         out  0x1a,  r24  ;  26
  d4:  87 b3         in   r24,  0x17  ;  23
  d6:  87 60         ori  r24,  0x07  ;   7
  d8:  87 bb         out  0x17,  r24  ;  23
  da:  ff cf         rjmp  .-2        ; 0xda <main+0xc>

[Ernst B. (puravida)]

Karl Heinz Buchegger schrieb:
> Matthias schrieb:
>> kai schrieb:
>>> Hab ich was falsch programmiert? Oder liegt es am Simulator? Würde der
>>> Code später auf meinem realen Chip laufen?
>>
>> Da meint der Compiler, dass die Zeile DDRB |= ... überflüssig ist und
>> optimiert die weg.
>
> Wenn er das tut, dann wäre das ein schwerer Fehler im Compiler.
>
> Was aber sein kann: Er hat die Optimierung eingeschaltet und der
> Debugger findet die Assembler-Entsprechung der Anweisung im C Code nicht
> mehr.

Das könnte der schlagende Hinweis sein. Mein funktionierender Test war 
ohne Optimierung. Bei -oS rennt der Debugger ins nirgendwo bei der Zeile 
DDRB |= ... Die erste Zeile funktioniert noch.

[Johann L. (gjlayde)]

Welches Debug-Format wird denn verwendet?
STABS? DWARF2? DWARF3? DWARF4?