3-Byte-PC woran erkennen?

[Gerald (Gast)]

Hallo Zusammen,

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?
Wie macht ihr das? Wird dies nur an der Flashgröße festgemacht oder gibt 
es eine andere Möglichkeit?

Gruß, Gerald

[Falk B. (falk)]

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

[Gerald (Gast)]

hmm, ja, ich kann nach V3 Core prüfen. 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?

Gruß, Gerald

[Thomas E. (thomase)]

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 (Gast)]

Thomas Eckmann schrieb:
> 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.

doch, natürlich. Also ist die Flashgröße schlussendlich das 
entscheidende Kriterium?

Gruß, Gerald

[Thomas E. (thomase)]

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.

[Peter D. (peda)]

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.

[Thomas E. (thomase)]

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.

[Peter D. (peda)]

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.

[Thomas E. (thomase)]

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.

[Johann L. (gjlayde)]

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

#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:

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

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

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

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

#include <avr/io.h>
#undef  __SFR_OFFSET
#define __SFR_OFFSET 0

;; R24 = sizeof (PC)
sizeof_PC:
    in      r24, SP
    set
    rcall 0f
0:  brtc 1f
    clt
    in      r0,  SP
    sub     r24, r0
1:  ret

[Gerald (Gast)]

Peter Dannegger schrieb:
> 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.

dann peitsch mich bitte aus rrr

parameter auf den stack

->in subroutine parameter holen

PC-breite muss bekannt sein, sonst geht der Zugriff in die Hose.

Gruß, Gerald

[Reinhard Kern (Gast)]

Gerald schrieb:
> PC-breite muss bekannt sein, sonst geht der Zugriff in die Hose.

Das kann man natürlich mit einem zusätzlichen pointer-Register für die 
Parameter umgehen. Aber musst du das denn umbedingt zur Laufzeit 
entscheiden? Kopierst du Binär-Programme ungeändert auf ganz 
verschiedene Prozessoren, und wenn ja, muss das denn sein?

Sonst steht das ja in einer h-Datei und wird beim Compilieren 
berücksichtigt, da muss man keine Register abfragen.

Gruss Reinhard