ATMEGA 8515 -- SREG nicht definiert -- AVR Studio 7

[André D. (dufman)]

Ich hatte hier mal danach gesucht, wie man das EEPROM eines ATMEGA mit 
irgendwelchen Werten beschreiben kann, weil ich irgendwie das Problem 
hatte, dass der Wert nie gespeichert wurde. Ich las dann etwas über 
Interrupts deaktivieren und Statusregister usw....

Hier fand ich dann folgendes Programmierbeispiel:
https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Interrupts_mit_avr-gcc

#include <avr/io.h>
#include <avr/interrupt.h>
#include <inttypes.h>
 
//...
 
void NichtUnterbrechenBitte(void)
{
   uint8_t tmp_sreg;  // temporaerer Speicher fuer das Statusregister
 
   tmp_sreg = SREG;   // Statusregister (also auch das I-Flag darin) sichern
   cli();             // Interrupts global deaktivieren
 
   /* hier "unterbrechnungsfreier" Code */
 
   /* Beispiel Anfang
     JTAG-Interface eines ATmega16 per Software deaktivieren 
     und damit die JTAG-Pins an PORTC für "general I/O" nutzbar machen
     ohne die JTAG-Fuse-Bit zu aendern. Dazu ist eine "timed sequence"
     einzuhalten (vgl Datenblatt ATmega16, Stand 10/04, S. 229): 
     Das JTD-Bit muss zweimal innerhalb von 4 Taktzyklen geschrieben 
     werden. Ein Interrupt zwischen den beiden Schreibzugriffen wuerde 
     die erforderliche Sequenz "brechen", das JTAG-Interface bliebe
     weiterhin aktiv und die IO-Pins weiterhin für JTAG reserviert. */
 
   MCUCSR |= (1<<JTD);
   MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr Information
 
   /* Beispiel Ende */
 
   SREG = tmp_sreg;     // Status-Register wieder herstellen 
                      // somit auch das I-Flag auf gesicherten Zustand setzen
}

Soweit, so gut...
Nur sah ich dann, dass die Variable bzw. das Register SREG nicht 
vordefiniert ist. Wenn ich andere "Kürzel" verwende, schlägt mir AVR 
Studio eigentlich immer die bereits definierten Sachen vor.

Aber SREG kennt das Programm irgendwie nicht.
Habe in der iom8515.h nachgesehen....  und tatsächlich ist da nichts 
definiert, wie im folgenden Auszug der iom8515.h zu sehen ist:

/* Timer/Counter Interrupt MaSK register */
#define TIMSK   _SFR_IO8(0x39)

/* General Interrupt Flag Register */
#define GIFR    _SFR_IO8(0x3A)

/* General Interrupt Control Register */
#define GICR    _SFR_IO8(0x3B)

/* 0x3D..0x3E SP */

/* 0x3F SREG */     <------------- nichts definiert !!

/* Interrupt vectors */

/* External Interrupt Request 0 */
#define INT0_vect_num    1
#define INT0_vect      _VECTOR(1)
#define SIG_INTERRUPT0      _VECTOR(1)

Habe ich eine falsche Version der iom8515.h oder muss ich selbst was 
definieren ?

Muss ich vielleicht noch  eine zusätzliche Datei inkludieren ?

Und warum ist bei den Definitionen in der iom8515.h der Adresswert von 
irgendeinem Port/Register oder was auch immer....   immer um 0x20 
niedriger als es mir im I/O-View des AVR-Studio angezeigt wird ???
(z.B. OCR1A = 0x2A in iom und 0x4A im AVR Studio)

Vielen Dank schonmal im Voraus...

Grüße
André

[Johann L. (gjlayde)]

SREG wird in avr/common.h definiert, das wiederum von avr/io.h 
includiert wird.

Um dir die Stelle der Definition anzeigen zu lassen, compiliere mit -g3 
-save-temps und schaue ins .i File (C) bzw. ins .ii File (C++).

[Johann L. (gjlayde)]

...hier noch wein kleines Testprogramm

#include <avr/io.h>

uint8_t sreg (void)
{
    return SREG;
}

Mit avr-gcc-5.2.1 (.s File mit -save-temps):

...
__SREG__ = 0x3f
...
sreg:
  in r24,__SREG__
  ret

[André D. (dufman)]

Ja, danke erst mal, Johann....
Aber ich fürchte, das geht etwas über meinen Horizont hinaus...
Ich habe mit AVR-Studio immer nur den Build-Button betätigt und 
fertig...

Mit diesen ganzen Parameterangaben habe ich mich noch nie beschäftigt... 
sieht für mich irgendwie alles nach DOS aus...   oder ist das auch 
Bestandteil des AVR-Studio ??

[Johann L. (gjlayde)]

André D. schrieb:
> Ich habe mit AVR-Studio immer nur den Build-Button betätigt und
> fertig...

Das einzige, was ich mit AVR-Studio gemacht hab, war den Klops wieder zu 
entsporgen.  VOn daher kann ich dir da nicht weiterhelfen.  Die IDE ist 
u.a. eine Overfläche für den Compiler (avr-gcc).  Wie der bedient wird 
hat mit dem Studio nix zu tun.

André D. schrieb:
> Und warum ist bei den Definitionen in der iom8515.h der Adresswert von
> irgendeinem Port/Register oder was auch immer....   immer um 0x20
> niedriger als es mir im I/O-View des AVR-Studio angezeigt wird ???
> (z.B. OCR1A = 0x2A in iom und 0x4A im AVR Studio)

Keine Ahnung das der Klops anzeigt.  Nicht-Xmega habe unterschiedliche 
Adressen für IN / OUT bzw. LDS / STS.  Adresse 0x0 für IN entspricht 
z.B. Adresse 0x20 für LDS.

Um diese unterschiedlichen Offsets brauchst du dich aber nicht zu 
kümmern, das wird alles vom Compiler erledigt.  Diese Offsets musst du 
nur bei (Inline-)Assembler beachten.

>      JTAG-Interface eines ATmega16 per Software deaktivieren


Im Datebnblatt steht:

MCU Control and Status Register - MCUCSR

· Bit 7 - JTD: JTAG Interface Disable

When this bit is zero, the JTAG interface is enabled if the JTAGEN
Fuse is programmed. If this bit is one, the JTAG interface is disabled.
In order to avoid unintentional disabling or enabling of the JTAG
interface, a timed sequence must be followed when changing this bit:
The application software must write this bit to the desired value twice
within four cycles to change its value.

>    MCUCSR |= (1<<JTD);
>    MCUCSR |= (1<<JTD); // 2 mal in Folge ,vgl. Datenblatt fuer mehr

Mögliches Problem entsteht wenn der erzeugte Code länger als 4 Ticks 
braucht, was z.B. bei deaktivierter Optimierung passieren könnte.  Daher 
würd ich da ne eigene Funktion machen, die das erledigt und eine 
bestimmte Sequenz garantiert.  Beispiel:

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

static inline void jtag_disable (void)
{
    ATOMIC_BLOCK (ATOMIC_RESTORESTATE)
    {
#if defined (__AVR_ATmega16__)
        uint8_t jtd = 1u << JTD;
        __asm volatile ("sts %a0, %1"  "\n\t"
                        "sts %a0, %1"
                        :: "n" (& MCUCSR), "r" (jtd): "memory");
#else
#error Fix jtag_disable for MCU!
#endif
    } // atomic block
}

Außerdem würd ich auf keinen Fall eine 1 auf-odern, weil das Probleme 
gibt falls das JTRF Flag gesetzt ist.

Falls der Wert von MCUCSR früh (vor main) gelesen werden soll, um die 
Reset-Ursache (WatchDog, PowerDown, External, ...) zu erfahren, ist 
nochmal anderer Code notwendig.

[André D. (dufman)]

Danke nochmal Johann...

Aber ganz ehrlich ?...   Ich arbeite lieber mit so nem "Klops" als mich 
durch die Eingabe von Kommandozeilen um 30 Jahre zurückversetzt zu 
fühlen, ich habe für Nostalgie nicht viel übrig.....

Das Programmbeispiel, zu dem Du so viel geschrieben hattest...   also, 
es ging mir lediglich darum, zu zeigen, dass hier geschrieben wurde, wie 
man das mit dem Statusregister und dem cli / sei managed....
Der Kram mit dem JTAG-Gedönse kannste Dir eigentlich wegdenken, da steht 
stattdessen irgendwas mit EEPROM schreiben / lesen.....

Aber das Hauptproblem war ja bei mir, dass "SREG" gar nicht bekannt 
(definiert) ist.

Ich weiß Deine Bemühungen zu schätzen, jedoch werde ich mit meinen 47 
Jahren nicht noch anfangen, mir den ganzen Kommandozeilenkram nochmal 
anzugucken, das ist eher was für Leute, die damit ihr ganzes Leben lang 
zu tun hatten, für mich wäre das eher eine Lebensaufgabe....

Grüße aus Bochum....
André

[Peter D. (peda)]

Laß das mit dem SREG, nimm die atomic.h.