goto im avr gcc

Wenn Du an den Anfang von main(...) springst, dann ist das kein
Neustart. Vor main wird nämlich noch der Startup-Code ausgeführt. Die
saubere Lösung für einen Reset wäre, den Watchdog einzuschalten und in
einer Endlosschleife zu verharren, bis der Watchdog auslöst.

OK, das ist die Alternative, die ich aber momentan aus diversen gründen
nicht gehen will.
Gibt es dann noch ne andere Möglichkeit, und warum geht mein goto
nicht?

Wenn Du umbedingt zur Adresse 0 springen willst, ginge ein

1

  void (*gotozero)(void) = NULL;

2

  gotozero();

Zu Deinem goto. Solange Du nicht mehr Code und/oder die Fehlermeldung
postest, kann ich Dir nicht helfen.

Also mehr code ist kein Problem, wobei obrige Lösung mir schon sehr
gefällt, mal noch testen...

...

SIGNAL(SIG_COMPARATOR)
// signal handler for analog comperator
{
     goto RESTART;    // Zeile : 127
}

...

int main(void)
{
RESTART:             // Zeile 140
...


-----------------------------------------------------

Fehlermeldung:
prog.c: In function `__vector_18':
prog.c:127: error: parse error before numeric constant
prog.c: In function `main':
prog.c:140: warning: label `RESTART' defined but not used
make: *** [prog.o] Error 1

So weit ich weiß, kann man in C mit goto ("das ist böse, BÖSE!") nicht
zwischen zwei Funktionen hin- und herspringen. Das wird so also nix. An
die Adresse für den Resetvektor (normalerweise 0) kämst Du außerdem je
nach AVR auch mit

1

  asm volatile ("jmp __vectors"::);

oder (bei kleineren Modelle)

1

  asm volatile ("rjmp __vectors"::);

oder ganz einfach:
asm volatile ("jmp 0");

Kleine AVRs haben keinen jmp-Befehl nur rjmp. Und "rjmp 0"
funktioniert - im Gegensatz zu "jmp 0" - nicht im gewünschten Sinne
(d.h. es springt zur ersten Codezeile in der aktuellen Datei, bei mir
oft ein Interrupt-Handler). Daher der Sprung zum Symbol __vectors.

Also das mit den void (*funcptr)( void ) = 0x0; tut nicht; bei mir wird
das so übersetzt:
   LDS r30,0x0060
   LDS r31,0x0061
   ICALL

Also springt der Atmel auf den Inhalt dieser beiden SRAM Zellen :-(

_asm_ __volatile
                    (
                       "ldi r30,0"  "\n\t"
                       "ldi r31,0"  "\n\t"
                       "icall" "\n\t"
                     );

macht "jump 0x0000"

> _asm_ __volatile
>                     (
>                        "ldi r30,0"  "\n\t"
>                        "ldi r31,0"  "\n\t"
>                        "icall" "\n\t"
>                      );
>
> macht "jump 0x0000"

Sofern in r00 gerade eine 0 steht.

Ok, das war natürlich Quatsch. Hab hier irgendwie ldi und lds
verwechselt.

Hallo Joerg,

die Perücke bist du los ... da sind laut .map zwei Variablen abgelegt.
Übrigens, übersetzt wurde mit avr-gcc 3.4.5 und -os.

Gruß Wolfgang

Anbei der DCC Decoder; einfacher Accessory Decoder, selbstlernend,
entweder 4 Pulsausgänge oder Signale bzw. Ampelsteuerung.

Entschuldigung,

anbei nochmals des Pudels Kern.

Gruß Wolfgang

Ich hoffe, du meinst -Os. Mit -os würde das Ergebnis einfach in eine
Datei namens s geschrieben.

Hmm, also mein avr-g++ macht aus dem Aufruf:

1

        lds r30,funcptr

2

        lds r31,(funcptr)+1

3

        icall

Das ist genau das, was ich erwartet hätte.
Daß er den Zugriff auf funcptr nicht wegoptimieren kann, ist logisch,
da es weder eine lokale Variable, noch konstant ist. Damit kann der
Compiler nicht darauf vertrauen, daß der Wert immer 0 ist und muß den
Lesezugriff auf die Variable tatsächlich durchführen.

> Allerdings löst der Assembler den rcall 0 irgendwie ,,schräg''
> auf, offenbar versucht er die 0 relativ auf irgendwas zu beziehen.

Das r im rcall steht doch für "relative". Sollte der übergebene Wert
nicht relativ zur aktuellen Adresse sein?