Hallo, Gemeinde, bei Sprut findet sich zum Thema Speicher-Reservieung folgendes Beispiel: Beispiel: ORG 0x20 Wert RES 1 ; Wert bedeutet ab sofort 0x20, Wert ist eine 1 Byte große Variable Pointer RES 3 ; Wert bedeutet ab sofort 0x21, Pointer kann als 3 Byte große Variable dienen Temp RES 1 ; Wert bedeutet ab sofort 0x24 MOVLW Wert ; W wird mit dem Zahlenwert 0x20 beschrieben MOVWF Temp ; nun wird der Inhalt von W in die Zelle mit der Adresse 0x24 kopiert Wenn ich es anwende, werden die entsprechende Zellen im Programmspeicher und nicht im RAM reserviert. Wie stelle ich es an, eine bestimmte Zahl von Zellen im RAM zu reservieren? Danke im voraus. Dieter
Mit Speicher sind die File-Register gemeint! RAM reserviert man im allgemeinen mit einer Variable. Da du aber in Assembler programmierst, ist das alleinig deine Aufgabe, während des Programmierens dafür zu sorgen, das DU in nicht anderweitig verwendest. Beschreibe doch mal was du machen willst. Dann lassen sich Missverständnisse schneller ausräumen.
--- schrieb: > cblock 20 --- schrieb: > endc Hallo, Gast, 20h ist wohl die Anfangsadresse, aber wie definiere ich den zu reservierenden Bereich?
...\MPASM Suite\hlpMPASMAsm.chm -> Directives Zu ploet oder zu faul?
Hallo Dieter, im Prinzip hast Du zwei sinnvolle Möglichkeiten: - A: für Assemblierung im "absolute" Mode
1 | CBLOCK 0x20 |
2 | var1:1 ;Variable belegt ein Byte |
3 | var2 ;1 Byte ist Default, ":1" kann auch weggelassen werden |
4 | var3:3 ;reserviert drei Bytes |
5 | var4:0 ;reserviert kein Byte, |
6 | var5:2 ;var4 und var5 haben also die gleiche Adresse |
7 | ENDC |
- B: für Projekte mit relozierbaren Adressen (die entgültige Adresse legt dann der Linker fest, falls keine Adresse der Sektion angegeben ist)
1 | DATA0 udata 0x20 |
2 | var1 RES 1 ;Variable belegt ein Byte |
3 | var2 RES 1 |
4 | var3 RES 3 ;reserviert drei Bytes |
5 | var4 ;reserviert kein Byte, |
6 | var5 RES 2 ;var4 und var5 haben also die gleiche Adresse |
:
Bearbeitet durch User
Danke Euch Allen Alle Unklarheiten beseitigt. (Da muss Sprut wohl ein Fehler unterlaufen sein. In einem seiner Lernbeispiele ist die Methode mit cblock/endc erklärt.)
Dieter Kohtz (dikomoe) schrieb: > Da muss Sprut wohl ein Fehler unterlaufen sein. Nicht unbedingt. Immerhin hat das alles seine Geschichte von so rund 25 Jahren und mehr. Vermutlich bezieht sich bei Sprut da auf einen mittlerweile veralteten Stand der Technik - und das wär's dann. Ich hatte mich vor Urzeiten über die Erbärmlichkeit des damaligen PIC-Assemblers PICALC schwarz geärgert und mir deshalb meinen eigenen Assembler geschrieben. Und der beherrscht Segmente, wie es sich gehört:
1 | SEG RAM |
2 | ORG 20h |
3 | Karlheinz: DS 1 |
4 | aFloat: DS 4 |
5 | |
6 | ORG 70h |
7 | RetteW: DS 1 |
8 | RetteFSR: DS 1 |
9 | RetteFlags: DS 1 |
10 | |
11 | |
12 | SEG CODE |
13 | ORG 2007h |
14 | Config: DATA 11111100110010b |
15 | ORG 2100h |
16 | MyEEProm: ..... |
17 | |
18 | ORG 0 |
19 | CLRF Status |
20 | CLRF PCLATH |
21 | GOTO Start |
22 | |
23 | ORG 4 |
24 | Interrupt: |
25 | MOVWF RetteW ; W retten |
26 | SWAPF Status,W ; Flags in W holen |
27 | ...usw. |
Nun hab ich den MicroChip-Assembler seitdem nicht weiter verfolgt, aber inzwischen kennt der gewiß auch Segmente. Also guck mal in dessen Dokumentation nach Segmenten. W.S.
Dieter Kohtz (dikomoe) schrieb: > Alle Unklarheiten beseitigt. (Da muss Sprut wohl ein Fehler unterlaufen > sein. In einem seiner Lernbeispiele ist die Methode mit cblock/endc > erklärt.) Irgendwie geht hier was total durcheinander. "cblock" ist eine Anweisung in der Programmierung im (alten) "absolute mode". "ORG" ist aus dem moderneren "relocatable mode" und bezieht sich allerdings auf Programmspeicher (ROM). Das Beispiel von Thomas Elger (-B) und natürlich der User's Guide (z.B. 4.62 udata - BEGIN AN OBJECT FILE UNINITIALIZED DATA SECTION) zeigen wie es aktuell (relocatable) gemacht wird, falls wirklich die Notwendigkeit bestehen sollte, dass Variablen an bestimmten Adressen liegen müssen.
Teo D. schrieb: > Da du aber in Assembler programmierst, ist das alleinig deine Aufgabe, > während des Programmierens dafür zu sorgen, das DU in nicht anderweitig > verwendest. Das ist schon sehr lange nicht mehr so ;-)
Beitrag #5016985 wurde vom Autor gelöscht.
Volker S. schrieb: > Irgendwie geht hier was total durcheinander. Volker S. schrieb: > Programmierung im (alten) "absolute mode". Über diesen mode bin ich bisher nicht hinausgekommen und habe auch nicht die Absicht, es zu tun. Nochmals Danke für Eure Beiträge. Dieter
> Über diesen mode bin ich bisher nicht hinausgekommen und habe auch nicht > die Absicht, es zu tun. Solang es bei Assembler pur bleibt, sei es dir unbenommen. Aber lass mal, schon der Bequemlichkeit wegen, ein paar C-Objekte dazukommen. Da wird sich deine Meinung schon noch aendern.
Dieter Kohtz (dikomoe) schrieb: > Über diesen mode bin ich bisher nicht hinausgekommen und habe auch nicht > die Absicht, es zu tun. Geht bis jetzt ja auch immer noch "absolut". ((((( In MPLABX kann man anscheinend schon Projekte mit mehreren Assembler Dateien nur noch "relocatable" anlegen. Der Support für absolut wird wohl irgendwann gar nicht mehr da sein. Wozu auch beides unterstützen wenn der "alte" Stil nichts hat, was relocatable nicht genauso möglich is. Im Programmcode ändert sich wirklich sehr wenig. Die Schlüsselworte CODE -> ORG und CBLOCK -> (z.B.) udata. )))))
Sorry, weicht jetzt etwas vom Thema ab, aber es würde mich echt mal interessieren, wann der Linker MPLINK kam, der relocatable Code ermöglichte. Vor ~20 Jahren, oder gibt es den schon länger? Hier http://datasheetarchive.kr/files/microchip/10/tools/picmicro/code/mpasm/index.htm sind schon relocatable Beispiele von 1998.
vloki schrieb: > Wozu auch beides unterstützen wenn der "alte" Stil nichts hat, was > relocatable nicht genauso möglich is. Auch wenn ich den Vorteil von "relocable" durchaus sehe und inzwischen neue Projekte nicht mehr "absolute" mache, ist der alte absolute Mode manchmal doch weniger "zickig", was das Herumrechnen mit Adressen betrifft. Beispiel hier: Beitrag "MPLAB - Makro für PC-relative Addresse"
vloki schrieb: > Der Support für absolut wird wohl irgendwann gar nicht mehr da sein. Na, ich hoffe aber, daß CBLOCK erhalten bleibt - das benutze ich nämlich munter auch bei "relocatable" Code! Wie soll man denn sonst sinnvoll Offset-Adressen für eine Variablen-Struktur erzeugen? z.B. sowas:
1 | #define NSERVOS 5 ;Anzahl Servos |
2 | |
3 | ;Struktur für Servo-Daten: |
4 | CBLOCK 0 |
5 | flags ;Steuer- und Statusbits |
6 | currentpw: 2 ;aktuelle Stellung |
7 | middle: 2 ;Mitte |
8 | leftlimit:2 |
9 | rightlimit:2 |
10 | SIZESERVO:0 ;Länge der Struktur |
11 | ENDC |
12 | |
13 | LINEAR0 udata |
14 | servodata res NSERVOS*SIZESERVO ;Array mit Servodaten |
:
Bearbeitet durch User
Thomas E. schrieb: > im Prinzip hast Du zwei sinnvolle Möglichkeiten: > - A: für Assemblierung im "absolute" Mode CBLOCK 0x20 > var1:1 ;Variable belegt ein Byte > var2 ;1 Byte ist Default, ":1" kann auch weggelassen werden > var3:3 ;reserviert drei Bytes > var4:0 ;reserviert kein Byte, > var5:2 ;var4 und var5 haben also die gleiche Adresse > ENDC Liebe Leute, der obige Beitrag war der einzige, der mir wirklich geholfen hat. Mehr brauche ich nicht, selbst wenn es relocatable wäre. Ich denke es ist an der Zeit, den thread zu beenden, oder? Beste Grüße Dieter
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.