3-Byte-PC woran erkennen?

Per Define bzw. #ifdef und Erkennung des AVR-Typs? Schau mal in die 
Includefiles von Atmel.

Gerald schrieb:
> Wäre das Vorhandensein von RAMPZ
> oder EIND praktikabel (so habe ich es aktuell gemacht), oder besteht
> auch die Möglichkeit, dass ein avr-Controller diese beiden register hat
> aber keinen 3-byte-PC?
Bislang nicht.

In C ist in der io.h u.a. FLASHEND definiert. Bietet der assembler nicht 
die Möglichkeit das darüber abzufragen?

mfg.

Gerald schrieb:
> Also ist die Flashgröße schlussendlich das entscheidende Kriterium?
Das ist bei fest eingebautem Programmspeicher, wie bei den Atmegas, das 
einzige Kriterium. Der PC muss genauso breit sein wie der interne 
Adressbus. Das sind beim 2560 mit seinen 128KWord 17 Leitungen bzw. 17 
Bit im PC. Was dann 3 Bytes erforderlich macht. Bei <64KWord braucht man 
das 3.Byte nicht und ist demzufolge auch nicht eingebaut.

mfg.

Gerald schrieb:
> ich habe hier die Prozessoren Atmega2560 und Atmega2561 die mit meinen
> Assemblerroutinen nicht laufen wollen, da sie einen
> 3-Byte-Programmcounter haben.

Wie kommst Du darauf, daß es daran liegt?
Daß pro Call ein Byte mehr auf dem Stack liegt, stört doch nicht.

Es stört nur, wenn Du irgendwelche Schweinereien mit dem Stack machst. 
Die gehören natürlich bestraft.

Peter Dannegger schrieb:
> Die gehören natürlich bestraft.
Das ist natürlich klar.
Aber der 2560 kann mit ICALL und IJMP nur in seiner 64K-"Page" springen. 
Will er darüber hinaus, braucht er das EIND-Register. Das haben die 
<64K-Typen aber nicht.

mfg.

Thomas Eckmann schrieb:
> Aber der 2560 kann mit ICALL und IJMP nur in seiner 64K-"Page" springen.

Schreib erstmal die 64kB Assembler, dann sehen wir weiter.
Meine absolute Schmerzgrenze für Assembler ist 2kB. Aber auch meine 
ATtiny13 kriegen schon lange nur noch C zu sehen.

Peter Dannegger schrieb:
> Schreib erstmal die 64kB Assembler, dann sehen wir weiter.
Ich bestimmt nicht. Die Zeiten sind lange vorbei. Aber auch der GCC 
hat(te)seine Probleme damit. Da muss(te) man das Bit im EIND von Hand 
setzen.

mfg.

Gerald schrieb:

> ich habe hier die Prozessoren Atmega2560 und Atmega2561 die mit meinen
> Assemblerroutinen nicht laufen wollen, da sie einen
> 3-Byte-Programmcounter haben.
>
> Wie kann ich für eine automatisierte Lösung in meinen Bibliotheken eine
> Abfrage einbauen, die erkennt ob ein 3-Byte-PC Verwendung findet?

Zunächst mal die Doku lesen, hier für die aktuelle Compilerversion:

3.17.3.3 AVR Built-in Macros

http://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/AVR-Options.html

Wird ein Assembler-Modul übersetzt, dann gibt man ihm die Endung .sx 
oder .S oder Assembliert per -x assembler-with-cpp so daß der 
C-Präprozessor über die Assembler-Quelle läuft.

Da du nach 3-Byte PC fragst ist naheliegend

1

#ifdef __AVR_3_BYTE_PC__

Falls es sich um eine echte Bibliothek handelt (libfoo.a) dann wirken 
Makros natürlich nur zur Buildzeit der Lib. In dem Falle wird die Lib 
abhängig von der Architektur erzeugt und gelinkt. Weil ATmega256[01] zu 
-mmcu=avr6 gehören, wäre dies der Schalter der Wahl.

Übrigens kann man avr-gcc nach dem Multilib-Pfad fragen, etwa im 
Makefile:

1

LPATH = $(shell avr-gcc -print-multi-directory -mmcu=atmega2560)

setzt LPATH auf "avr6" oder im sh-Skript:

1

LPATH=`avr-gcc -print-multi-directory -mmcu=atmega2560`

Falls es wirklich zur Laufzeit sein muss, dann tut Code wie

1

#include <avr/io.h>

2

#undef  __SFR_OFFSET

3

#define __SFR_OFFSET 0

4

5

;; R24 = sizeof (PC)

6

sizeof_PC:

7

    in      r24, SP

8

    set

9

    rcall 0f

10

0:  brtc 1f

11

    clt

12

    in      r0,  SP

13

    sub     r24, r0

14

1:  ret