Was bedeutet extern, global beim PIC

[AEWE47]

Hi Leutz brauche dringend eine schnelle info

was machen und was bedeuten die Befehle extern, global, res usw also die Pseudobefehle die es sonst och gibt, bei Sprut habe ich nur wenige gefunden, hoffe ihr habt ne andere Seite für mich oder ne gute Beschreibung.

Bitte in Zukunft kein Datum angeben. MfG stegr

[PicNick]

Hi, für den Prozessor bedeuten diese Befehle gar nix, das sind Kompiler-definitionen, daher steht beim Sprut nix darüber.

[AEWE47]

OK schon klar, dass es fürn PIC kein Befehl ist, sorry falsch ausgedrückt.

Benötige aber trotzdem den Befehlssatz halt fürn Assembler LOL

[AEWE]

Bin nu unter meinem richtigen Namen On, sorry

[PicNick]

Jetzt steh' ich auf dem Schlauch: wenn's nur für den Kompiler und ggf. den Linker ist, gibt's natürlich keine Maschinenbefehle dafür.
Was brauchst du genau ?
mfg

[AEWE]

Sorry ich versuchs ma so ok, ich Teile meine Assemblerseiten verschiedenen Unterteilung ein.
Das alles kommt dann in Source File hinein schön geordnet so und nun kommt in einem Prog so etwas vor:

;Externe Variablen

extern DATA_EE_ADDR
extern EEPROM_Daten
extern I2C_EE_pos
extern I2C_EE_bank
extern pin1
extern month
extern day
extern min
extern min10
extern hour
extern hour10
extern output
extern pointstat

;Globale Routinen
global I2C_liste_lesen_datensatz, I2C_liste_schreiben
global data_read_1, data_read_2, data_read_3
global data_read_4, data_read_5
;externe Routinen
extern RS232out

;Variablen

GPR1 UDATA_shr
data_read_1 res 1
data_read_2 res 1
data_read_3 res 1
data_read_4 res 1
data_read_5 res 1


I2C_Listen_routinen code

I2C_liste_lesen_datensatz
btfsc PCdata
goto PCdatenlesen

movlw EE_pos
movwf DATA_EE_ADDR
call EERead
movfw EEPROM_Daten
movwf I2C_EE_pos


movlw EE_bank
movwf DATA_EE_ADDR
call EERead
movfw EEPROM_Daten
movwf I2C_EE_bank

Nun frag ich wie und was hat es mit dem extern, global auf sich ?

[PicNick]

Schau, der Compiler (Assembler) fährt ja durch den Source-Code (Text) durch und kommt zu sowas wie "CALL WTLBRNFT". Er braucht an dieser Stelle aber offensichtlich eine Addresse, um den Maschinen Code herzurichten. Wo nimmt er die jetzt her ? Er merkt sich die Stelle und fährt auch durch den restlichen Code durch (Pass 1, vielleicht schon gehört). Findet er nun unterwegs einen Label "WTLBRNFT" , schreibt er sich diese Adresse auf.
Dann fährt er nochmal durch den ganzen Code (Pass 2). Wenn er nun zu dem CALL kommt, geht's ihm gut, denn jetzt hat er ja die Adresse und kann das Statement fix und foxi in Maschinencode übersetzen.
Jetzt hat er EIN Object-Modul fertig. voila.
Ist aber nun "WTLBRNFT" eine Label, der in einer ANDEREN Source des Projektes definiert wird (und daher auch in einem anderen Object-Modul),
geht das obige nicht. Damit der Compiler aber weiß, daß "WTLBRNFT" kein Schreibfehler ist, sondern nur woanders definiert ist, schreibt man "EXTERN WTLBRNFT" rein. Deswegen kann er das statement zwar auch nicht übersetzen (er hat ja die Adresse immer noch nicht), aber er schreibt in das Object Modul eine Nachricht für den Linker, daß "WTLBRNFT" noch eine Adresse braucht und WO im dem Object diese Adresse überall fehlt (kann ja öfters drinstehen)
So.
Jetzt kommt der Linker daher und ist verzweifelt. Er sieht, daß er die Adresse von WTLBRNFT braucht und hat keine Ahnung, in welchen Objectmodule die sein könnte.
Wenn aber der Programmierer, der diese Funktion tatsächlich geschrieben hat, zusätzlich "GLOBAL WTLBRNFT" in die Source geschrieben hat, steht vorne im Objectmodul eine Zeile mit Namen und Adresse von dem Label.
JETZT ist der Linker glücklich, denn überall, wo der Wert fehlt, kann er jetzt was reinschreiben und alle freuen sich.

ALSO: der, der eine Funktion SCHREIBT, kann zusätzlich "GLOBAL" dazu sagen, dann ist die sie für alle anderen Module verwendbar.
Und der, der diese Funktion BRAUCHT, schreibt "EXTERN" dazu.
*schauf* klaro ?

[AEWE]

Sauber gemacht Robert, so hat ich mir das ungefair vorgestellt
Sau gut erklärt, selbst für die nicht sportlichen Hirne.

Habe im MPLAB IDE unter Hilfe --- Topic... --- Assembler nach einiger Zeit genau dies gefunden aber trotz alledem sau gut erklärt, werde mir deine Passage heraus kopieren, für Azubierklärungszwecke. Für meine Azubi nachfolger thx.

[AEWE]

KÖnntest du mir vielleicht noch eine kleine Erklärung zu diesem Punkt abgeben ???


GPR1 UDATA_shr
data_read_1 res 1
data_read_2 res 1
data_read_3 res 1
data_read_4 res 1
data_read_5 res 1

Zum udata_shr, _ovr, acs

ich danke dir noch ma

[PicNick]

Au weia.
"res 1" heißt mal nur, daß data_read_1 1 Byte lang sein soll.
(REServe 1 Byte)

"udataXXX" sind grundsätzlich daten-Sections mit ein paar Variationen.
Im Gegensatz zu "idata" pfeift sich kein Schwein drum, was da am Anfang drinsteht, das muß du selbst machen (auf NUL setzen z.b). Deswegen haut er dir Dinge wie "DB" etc. auch um die Ohren.

"udata" ist sozusagen das Normale, der Compiler weiß, daß er auf die bankselection aufpassen muß
"udata_acs" sind daten in dem speziellen "Access"-Bereich(nur f. PIC18...)
"udata_shr" sind daten im dem RAM, wo die Bankselection keine Rolle spielt, weil eh alle Banken auf den selben bereich hingreifen.
"udata_ovr" nimmt man, wenn man das GLEICHE Speicherbereich VERSCHIEDEN definieren will.

WO die Schweinebacke des "access" Bereich hat, kann ich nicht sagen, da müßt ich Datashit lesen.