Hallo Zusammen, Bei verschiedenen 8051-Derivaten (z.B. 8052, 80C320, usw.) wir haben zwei DPTRs. Man muss aber ständig aufpassen, welchen DPTR verwendet wird. Momentan habe ich so gemacht (Keil A51, aber es ist egal): DPTR0 macro mov dps,#0 endm DPTR1 macro mov dps,#1 endm ................................ und: DPTR0 mov dptr,<irgendwas> dann: DPTR1 mov dptr,<irgendwas> Habt Ihr eine elegante Lösung dafür? z.B. etwas ähnliches: :))) mov dptr0,<irgendwas> und mov dptr1,<irgendwas> Danke, Karoly
Du kannst doch am Beginn Deines Programms die Namen der SFR's umdefinieren: also dptr --> zeiger o.ä.
Entschuldige bitte, ich verstehe nicht, wie Du meinst? Danke, Karoly
Was willst Du denn mit den 2 DPTRs machen ? Es kann immer nur ein DPTR ausgewählt sein. Peter
Mit 2 DPTRs kann man zum Beispiel Blockumladungen (kopieren) ausführen. Quelladresse in den 1. Zieladresse in den 2. und dann immer nur DPS umschalten, wobei DPTR jedesmal inkrementiert wird. Nachteil beim 8051 ist wirklich, daß es nur einen inc DPTR gibt, und das zum umschalten des DPTRs kein direkter Bitbefehl verwendet werden kann. Vorsicht ist vorallem geboten, wenn man DPTR in einer Interruptroutine verwendet. DPTR auf Stack und DPS (falls man Ihn verändert). Dirk
@Peter: Ich habe wahrscheinlich nicht richtig formuliert. Es gibt viele Programmteile, wo man alle beide DPTRs verwenden kann/muss/usw. Hier ist ein Beispiel: (kopieren aus Tabelle2 in Tabelle1) mov dps,#0 ; selekt dptr0 mov dptr,#tabelle1 mov dps,#1 ; selekt dptr1 mov dptr,#tabelle2 mov r4,#tablen zykl: movx a,@dptr inc dptr mov dps,#0 ; selekt dptr0 movx @dptr,a inc dptr mov dps,#1 ; selekt dptr1 djnz r4,zykl Es wäre viel eleganter (und SICHERER!) irgendwie so schreiben: mov dptr0,#tabelle1 mov dptr1,#tabelle2 mov r4,#tablen zykl: movx a,@dptr1 inc dptr1 movx @dptr0,a inc dptr0 djnz r4,zykl Karoly
@Dirk: Danke für die Unterstützung! :))) Bemerkung: Ich habe bereits ein AWK Script geschrieben (ich muss noch austesten). Karoly
Karoly Kovacs wrote: > @Peter: > Ich habe wahrscheinlich nicht richtig formuliert. > Es gibt viele Programmteile, wo man alle beide DPTRs verwenden > kann/muss/usw. > > Hier ist ein Beispiel: (kopieren aus Tabelle2 in Tabelle1) > > mov dps,#0 ; selekt dptr0 > mov dptr,#tabelle1 > mov dps,#1 ; selekt dptr1 > mov dptr,#tabelle2 > mov r4,#tablen > zykl: movx a,@dptr > inc dptr > mov dps,#0 ; selekt dptr0 > movx @dptr,a > inc dptr > mov dps,#1 ; selekt dptr1 > djnz r4,zykl > > Es wäre viel eleganter (und SICHERER!) irgendwie so schreiben: > > mov dptr0,#tabelle1 > mov dptr1,#tabelle2 > mov r4,#tablen > zykl: movx a,@dptr1 > inc dptr1 > movx @dptr0,a > inc dptr0 > djnz r4,zykl > > Karoly Hallo Karoly, ja, das wäre es. Aber der 8051core wird deswegen warscheinlich nicht mehr geändert ;-) Es gibt aber viele andere µCs, die das perfekt beherschen. Sogar der 8086 hatte schon sehr elegante Befehle, mit automatischer Umladung. Dirk
Die Frage ist doch, wann braucht man mal exzessive Kopierorgien im XRAM ? Eigentlich recht selten bis garnicht und da kann man durchaus die etwas umständliche Art des 8051 tolerieren. Falls man aber wirklich im extern angeschlossenen XRAM Kopierorgien veranstalten muß, nimmt man einfach als 2. Pointer P2+R0. Das geht dann noch schneller als mit nem 2. DPTR: http://home.tiscali.de/peterd/appl/soft/xcopy/index.htm Ich habe den 2.DPTR höchstens in Interrupts benutzt, damit man das Pushen und Poppen spart. Peter
@Peter:
Es geht nicht darum, dass der Programmierer zu blöd ist, und nicht
kennt, wie es NOCH machen kann! :)))
Also, ich muss sagen, es gibt solche Situationen, wo man diese
"Kopierorgien im XRAM" machen muss.
Ich habe auch ein Projekt, wo ich ziemlich komplizierte
Datentransformationen machen musste. (Orgelsteuerung) Die "Kopierorgie",
was ich oben geschrieben habe, war BLOß EIN BEISPIEL (das einfachste
Beispiel).
Danke aber für die nette Ideen!
(Wenn jemand noch Interesse hat, hier ist sich mein erster Versuch mit
AWK es zu "lösen" - es gehört aber noch zum Testen, u. erweitern.)
Karoly
========================================================================
===
function convert() {
if (tolower($0) ~ "dptr0") {
printf "\tmov dps,#0\n"
for (i=1;i<=NF;i++) {
printf "%s%s
",substr($i,1,index(tolower($i),"dptr0")+3),substr($i,index(tolower($i),
"dptr0")+5)
}
printf "\n"
}
else if (tolower($0) ~ "dptr1") {
printf "\tmov dps,#1\n"
for (i=1;i<=NF;i++) {
printf "%s%s
",substr($i,1,index(tolower($i),"dptr1")+3),substr($i,index(tolower($i),
"dptr1")+5)
}
printf "\n"
}
else {
print "Warning! Bad dptr usage:"
print tolower($0)
}
}
{
if (tolower($0) ~ "dptr") {
if (tolower($0) ~ "@a *\\+ *dptr") {
convert()
}
else if (tolower($0) ~ "dptr,") {
convert()
}
else if (tolower($0) ~ "@dptr") {
convert()
}
else {
convert()
}
}
else print tolower($0)
}
Peter Dannegger wrote: > Die Frage ist doch, wann braucht man mal exzessive Kopierorgien im XRAM > ? > > Eigentlich recht selten bis garnicht und da kann man durchaus die etwas > umständliche Art des 8051 tolerieren. > Das kommt auf die Anwendung an. Außerdem geht es nicht nur ums XRAM sonder auch vom Programmspeicher ins XRAM. Hatte durchaus schon Anwendungen, wo dies zum tragen kam. > Falls man aber wirklich im extern angeschlossenen XRAM Kopierorgien > veranstalten muß, nimmt man einfach als 2. Pointer P2+R0. Das geht dann > noch schneller als mit nem 2. DPTR: > > http://home.tiscali.de/peterd/appl/soft/xcopy/index.htm > Dann kann man aber auch gleich DPH,DPL auswechseln. Die 4 Befehle pro Wechsel machen es dann auch nicht mehr aus. > > Ich habe den 2.DPTR höchstens in Interrupts benutzt, damit man das > Pushen und Poppen spart. > Das ist bei mir ebenso der häufiste Anwendungsfall. Das ganze kann man auch mit den Registerbänken machen. > > Peter Dirk
@Peter: Übrigens, deine schnelle Routine ist NUR IN BESTIMMTEN FÄLLEN schneller, als "mein" Beispiel! (Ich habe Dallas 80C320 genommen) 1. Deine Routine: mov dph, r6 ; 2 mov dpl, r7 ; 2 mov p2, r4 ; 2 mov a, r5 ; 1 mov r0, a ; 1 add a, r3 ; 1 jz ?xcp3 ; 2 jc ?xcp1 ; 2 cjne r3, #0, ?xcp3 ; 3 ?xcp1: mov r3, a ; 1 -> 17 ?xcp2: movx a, @dptr ; 1 movx @r0, a ; 1 inc dptr ; 1 inc r0 ; 1 cjne r0, #0, ?xcp2 ; 3 -> 7*n inc p2 ; 2 ?xcp3: movx a, @dptr ; 1 movx @r0, a ; 1 inc dptr ; 1 inc r0 ; 1 djnz r3, ?xcp3 ; 1 - > 5*n Also 11 + 5*m, oder 14 + 7*n + 5*n, oder 17 + 7*n + 5*n Zyklen. "Mein" Beispiel: mov dps,#0 ; 2 mov dptr,#tabelle1 ; 3 mov dps,#1 ; 2 mov dptr,#tabelle2 ; 3 mov r4,#tablen ; 2 -> 12 zykl: movx a,@dptr ; 1 inc dptr ; 1 mov dps,#0 ; 2 movx @dptr,a ; 1 inc dptr ; 1 mov dps,#1 ; 2 djnz r4,zykl ; 1 -> 9*n Also immer 12 + 9*n Zyklen. Du hast aber Recht, in "Standardarchitektur" (8051, mit einem PDTR Register), deine Routine ist wirklich sehr gut. Karoly
Dirk Hofmann wrote: > Dann kann man aber auch gleich DPH,DPL auswechseln. Die 4 Befehle pro > Wechsel machen es dann auch nicht mehr aus. Na das meine ich nicht, sind immerhin 17/11 Zyklen. Ob das Kopieren also 55% länger dauert, kann schon ein erheblicher Unterschied sein. Das der 2. DPTR weitgehend nutzlos ist, hat damit zu tun, daß es einfach keine freien Befehle mehr gibt (außer 0xA5) für INC DPTR0/1, MOVX DPTR0/1. Aber wie schon gesagt, in Assemblerprogrammen habe ich nie größere XRAM Kopierorgien. Sowas braucht man nur in größeren Programmen und da lasse ich einfach den C-Compiler sich drum kümmern. Über 4kB Flash nehme ich keinen Assembler mehr, sonst verliere ich den Überblick. Da muß es C sein. @Karoly, was machst Du mit AWK aufm 8051 ? Ich denke, Du programmierst in Assembler. Peter
Es gibt viele Tricks. Man kann auch eine Adresse auf den Stack pushen und mit RET dahinspringen.
@Peter:
Ok, wir haben es schon einmal von Dir gelesen, wir haben es endgültig
gelernt! :))) (Nur unter vier Augen frage ich: was machst Du mit
"deiner" C-Code, wenn das Programm sehr Zeitempfindlich ist?) Übrigens:
ich mag auch in C programmieren, es gibt aber solche Aufgaben, wo man
mit C "nicht zu viel" machen kann.
> Das der 2. DPTR weitgehend nutzlos ist [...]
Habe bloß eine winzige Frage: WARUM haben dann die Hersteller den
zweiten DPTR-Register "entdeckt", wenn es soooo überflässig/unbrauchbar
wäre? :)))
Oh, meine Güte!
Zum AWK: Du bist gar nicht einfacher Mensch! :)))
Also zurück zu der Grundfrage!
Ich wollte die ganze DPTR-Geschichte ein bisschen einfacher (und
sicherer!) machen. Ich habe überlegt, ob man es mit einem
Makro-Preprozessor machen könnte. Wollte aber keine "komplizierte"
Makroprozessoren, wie M4 oder anderen einsetzen (weil es hier um nur ein
Paar spezielle DPTR-Befehle geht), habe deswegen das obige Progrämmchen
als "Preprozessor" verwendet.
Aber egal, ich sehe schon, dass meine Frage völlig überflüssig, und
störend war. Ich bitte um Entschuldigung, wenn ich Dich mit meinen
blöden Fragen sooo störe.
Karoly
Karoly Kovacs wrote: > Ok, wir haben es schon einmal von Dir gelesen, wir haben es endgültig > gelernt! :))) Oh Gott, da ist aber einer eingeschnappt. Wenn Du nur Deine Meinung bestätigt haben willst und keine andere hören, dann setz Dir doch nen Heiligenschein aus blinkenden LEDs auf. >> Das der 2. DPTR weitgehend nutzlos ist [...] Ist meine persönliche Meinung, darf ich doch mal äußern, ist ja ein freies Land. Ich hab ihn einmal für nen schnellen Interrupthandler eingesetzt, sonst nie. > Zum AWK: Du bist gar nicht einfacher Mensch! :))) Ich weiß nicht, was AWK ist, brauchst es mir jetzt aber auch nicht mehr erläutern. Würde Dich damit ja nur belästigen. > Ich wollte die ganze DPTR-Geschichte ein bisschen einfacher (und > sicherer!) machen. Ich habe überlegt, ob man es mit einem > Makro-Preprozessor machen könnte. Wollte aber keine "komplizierte" > Makroprozessoren, wie M4 oder anderen einsetzen (weil es hier um nur ein > Paar spezielle DPTR-Befehle geht), habe deswegen das obige Progrämmchen > als "Preprozessor" verwendet. Ich weiß ja nicht, was für einen Assembler Du einsetzt. Ich setze den Keil A51 ein und der hat ja auch schon nen Macroprozessor. Damit könnte man bestimmt das machen, was Du willst, wenn ich bloß wüßte, worauf Du hinaus willst. Auch wenn ich viel poste, muß ich noch lange nicht alles wissen und verstehen. Aber Du willst ja nicht erläutern, worum es Dir geht, sondern nur rummotzen. Peter
Karoly Kovacs wrote: > zykl: movx a,@dptr ; 1 > inc dptr ; 1 > mov dps,#0 ; 2 > movx @dptr,a ; 1 > inc dptr ; 1 > mov dps,#1 ; 2 > djnz r4,zykl ; 1 -> 9*n > > Also immer 12 + 9*n Zyklen. Meine Berechnungen bezogen sich aber auf den DS80C320 und da sind die Zyklenunterschiede so, wie ich es geschrieben habe. DS89C320: [avrasm] zykl: movx a,@dptr ; 2 inc dptr ; 3 inc dps ; 2 (mov dps, #0 = 3 zyklen) movx @dptr,a ; 2 inc dptr ; 3 inc dps ; 2 djnz r4,zykl ; 3 -> 17*n [avrasm] Peter P.S.: Jetzt sehe ich, Du hast die Bytezahl mit der Zyklenzahl verwechselt. Rechne mal mit den richtigen Werten nach.
Karoly Kovacs wrote: > Es wäre viel eleganter (und SICHERER!) irgendwie so schreiben: > > mov dptr0,#tabelle1 > mov dptr1,#tabelle2 > mov r4,#tablen > zykl: movx a,@dptr1 > inc dptr1 > movx @dptr0,a > inc dptr0 > djnz r4,zykl Das sieht zwar auf den ersten Blick schön aus, aber Du definierst den Standardbefehlssatz um und hast damit völlig inkompatiblen Code. Sowas erlauben die Macros im A51 nicht, Macros dürfen nicht nach Befehlen beginnen. Man könnte aber MOV_DPTR0 und MOV_DPTR1 usw. als Macronamen verwenden. Auch mußt Du dann jedesmal "mov DPS,#0" und "mov dps,#1" einfügen, d.h. der Code wird größer und langsamer. Der Preprozessor arbeitet ja zeilenweise, aber das Programm kann springen, wie es lustig ist. Warum das sicherer sein soll, erklärt sich mir nicht. In den Beispielen im Dallas-Datenblatt wird ja auch nicht darauf Wert gelegt, welcher DPTR nun der aktive ist, sondern es reicht völlig zu wissen, wann der andere aktiv sein muß. Deshalb wird dort auch "inc dps" statt "mov dps,#0/1" verwendet (spart einen Zyklus). Peter
Peter Dannegger wrote: > Karoly Kovacs wrote: > >> Es wäre viel eleganter (und SICHERER!) irgendwie so schreiben: >> >> mov dptr0,#tabelle1 >> mov dptr1,#tabelle2 >> mov r4,#tablen >> zykl: movx a,@dptr1 >> inc dptr1 >> movx @dptr0,a >> inc dptr0 >> djnz r4,zykl > > > Das sieht zwar auf den ersten Blick schön aus, aber Du definierst den > Standardbefehlssatz um und hast damit völlig inkompatiblen Code. > > Sowas erlauben die Macros im A51 nicht, Macros dürfen nicht nach > Befehlen beginnen. Man könnte aber MOV_DPTR0 und MOV_DPTR1 usw. als > Macronamen verwenden. > > Auch mußt Du dann jedesmal "mov DPS,#0" und "mov dps,#1" einfügen, d.h. > der Code wird größer und langsamer. > Der Preprozessor arbeitet ja zeilenweise, aber das Programm kann > springen, wie es lustig ist. > > Warum das sicherer sein soll, erklärt sich mir nicht. > > In den Beispielen im Dallas-Datenblatt wird ja auch nicht darauf Wert > gelegt, welcher DPTR nun der aktive ist, sondern es reicht völlig zu > wissen, wann der andere aktiv sein muß. > Deshalb wird dort auch "inc dps" statt "mov dps,#0/1" verwendet (spart > einen Zyklus). > > > Peter @Peter +++ @Karoly bin grad heimgekommen. Jetzt beruhigt Euch mal wieder. So bringt das ja wohl garnix. @Peter Wir hatten ja schon mal die Diskussion auch wegen Assembler versus C. Mein Standpunkt ist und bleibt: Sei gut in dem was Du tust, dann stehen viele Wege offen und einer kann vom anderen lernen. Niemand ist over the TOP. Ich programmiere jetzt schon über 20 Jahre. Und meine Passion ist es weiter zu tun. Ich denke, Du tust das auch schon eine Weile. Glaube, wir sollten uns wirklich mal zurückversetzen und nicht den Boden der Realität unter den Füssen verlieren. Im Prinzip ist die Diskussion um die DPTR switcherei nur Zeitverschwendung. Wenn es beim 8051 befehlsmäßig so ist, dann ist es so. Es gibt genügend andere µCs die dieses Manko nicht haben, dafür andere. Zufrieden werden wir nie richtig sein. Ich beschäftige mich grad nebenbei mit den TMS320C64xxx DSPs von TI. Die machen über 28 GFLOPS. Auch hier wird es Leute geben, die damit wieder unzufrieden sind. Wenn wir uns mit dem beschäftigen, was maßgeblich ist und Erfolge erzielen die nicht auf dem Rücken der Anwender oder Kunden ausgetragen werden auch "Bananensoftware" genannt, ist das wohl OK. Wünsche eine geruhsame Nacht.
@Dirk: Danke für die netten Worte! (Übrigens: ich programmiere seit ca. 31.J.) @Peter: Entschuldige, bitte, Du hast Recht, ich habe es versehen! (Bytezahl) > Ich setze den Keil A51 ein und der hat ja auch schon nen Macroprozessor. > Damit könnte man bestimmt das machen Nein, leider nicht. Es kann das nicht machen. > Sowas erlauben die Macros im A51 nicht, Soweit hast Du Recht, das kann A51 nicht. > Macros dürfen nicht nach Befehlen beginnen. Hier hast Du aber nicht Recht. Wer hat es gesagt? (Ich musste meinen "ersten" Makroprozessor in 1976 an der Uni schreiben...) Also Makroprozessor != Makroassembler (oder Makro Preprozessor) Siehe: http://de.wikipedia.org/wiki/Makroprozessor (Mit einem "guten" Makroprozessor kann man "fast beliebige" Textkonversionen machen. z.B. M4, o.ä.) Zur AWK: http://de.wikipedia.org/wiki/Awk AWK (und SED) sind sehr mächtige Textprozessoren. > In den Beispielen im Dallas-Datenblatt wird ja auch nicht darauf Wert > gelegt, welcher DPTR nun der aktive ist, sondern es reicht völlig zu > wissen, wann der andere aktiv sein muß. > Deshalb wird dort auch "inc dps" statt "mov dps,#0/1" verwendet (spart > einen Zyklus). Ja, ich weiss. (Seit 1997 programmiere ich den Dallas. Damals konnte man "nur" den Datenblatt in Internet finden, ich habe deswegen das komplette Buch von Dallas bestellt.) Aber ganz exakt macht man es mit ORL und ANL maskiert, weil in anderen Derivaten einige andere Bits auch belegt sind. Also jetzt höre ich auf mit unserer endlose Diskussion, danke für die nette Antworten! Karoly
Karoly Kovacs wrote: > Aber ganz exakt macht man es mit ORL und ANL maskiert, weil in anderen > Derivaten einige andere Bits auch belegt sind. Dazu steht bei Dallas, daß DPS.1 immer 0 bleibt, d.h. ein "inc dps" wechselt immer nur DPS.0 und läßt alle anderen unverändert. Peter
Ajajajaj! Peter! Was habe ich geschrieben? "in anderen Derivaten" Also nicht unbedingt bei Dallas. Ich gebe auf... Karoly
Karoly Kovacs wrote: > Ajajajaj! > > Peter! Was habe ich geschrieben? > "in anderen Derivaten" Atmel schreibt auch "inc AUXR1" Peter
Und was ist mit dem AT89S8252? (zum Bleistift) Siehe: http://www.atmel.com/dyn/resources/prod_documents/doc0401.pdf oder in http://www.atmel.com/dyn/resources/prod_documents/doc1018.pdf Dort steht: WMCON DATA 96h ; watchdog and memory control register DPS EQU 00000100b ; data pointer select bit ... xrl WMCON,#DPS ; switch data pointers :))) Karoly
Karoly Kovacs wrote:
> Und was ist mit dem AT89S8252? (zum Bleistift)
Ja, bei dem wirds höllisch kompliziert, daher habe ich solche Spielchen
sein gelassen.
Der hat ja unterschiedliche Adressen für DPH/L0 und DPH/L1 !!!
Wenn man da DPH/L berechnet (Sprungtabelle) und DPS aber falsch gesetzt
ist, stürzt dein Programm super ab.
Das nenne ich wirklich einen völlig unbrauchbaren 2.DPTR.
Peter
Peter Dannegger wrote: > Karoly Kovacs wrote: >> Und was ist mit dem AT89S8252? (zum Bleistift) > > Ja, bei dem wirds höllisch kompliziert, daher habe ich solche Spielchen > sein gelassen. > > Der hat ja unterschiedliche Adressen für DPH/L0 und DPH/L1 !!! > > Wenn man da DPH/L berechnet (Sprungtabelle) und DPS aber falsch gesetzt > ist, stürzt dein Programm super ab. > > Das nenne ich wirklich einen völlig unbrauchbaren 2.DPTR. > > > Peter Genau das ist das generelle Problem. Wenn Du in einer Interrupt Service Routine den DPTR ebenfalls verwendest, solltest Du ihn auf dem Stack retten. Die Frage ist, was jetzt schneller geht. Alle 4 Dxx Register auf den Stack (wenn man dort auch beide verwendet) oder nachschauen, welcher aktiv ist und nur diesen zu pushen. Version 1 geht warscheinlich schneller. Dirk
OK, die Frage war aber nicht das!
Peter hat geschrieben:
> Atmel schreibt auch "inc AUXR1"
Ich habe dann ein Beispiel (einen Derivat) genommen, wo ich Recht habe.
:)))
(Also, beim AT89S8252 darf man weder mit "mov", noch mit "inc" den DPS
setzen.)
Karoly
Dirk Hofmann wrote: > Die Frage ist, was jetzt schneller geht. Alle 4 Dxx Register auf den > Stack Das nenn ich ja mal wirklich ne super ""Einsparung"" ! Statt durch den 2.DPTR 2*Push+Pop zu sparen muß ich nun 4*Push+Pop machen. Nene, ich weiß schon, warum ich im 8252 nie den 2.DPTR benutzte (in meinen Assembler-Tagen und abgekündigt ist der 8252 ja auch). Peter
Peter Dannegger wrote: > Dirk Hofmann wrote: > >> Die Frage ist, was jetzt schneller geht. Alle 4 Dxx Register auf den >> Stack > > > Das nenn ich ja mal wirklich ne super ""Einsparung"" ! > > Statt durch den 2.DPTR 2*Push+Pop zu sparen muß ich nun 4*Push+Pop > machen. > > Nene, ich weiß schon, warum ich im 8252 nie den 2.DPTR benutzte (in > meinen Assembler-Tagen und abgekündigt ist der 8252 ja auch). > > > Peter @Peter gemeint war, wenn Du im Hauptprogramm beide verwendest. Kannst dann ja kaum den 2.DPTR in der ISR verwenden ohne ihn zu retten. Außerdem! C ist ja nun eine absolut stackorientierte Sprache und ballert vieles drauf. Absolute Optimierung des Programmcodes nützt also nur dort, wo dieser auch prozentual sehr häufig ausgeführt wird. Bei anderen Anwendungen ist die Flexibilität dann eher vordergründig. Dirk
Karoly Kovacs wrote: > Es wäre viel eleganter (und SICHERER!) irgendwie so schreiben: > > mov dptr0,#tabelle1 > mov dptr1,#tabelle2 > mov r4,#tablen > zykl: movx a,@dptr1 > inc dptr1 > movx @dptr0,a > inc dptr0 > djnz r4,zykl Hast Du eigentlich Deinen AWK überhaupt schonmal ausprobiert ? Es würde mich mal interessieren, welchen Assembler er aus Deinen obigen Zeilen erzeugt. Da muß ja vor jedem DPTR0/1-Befehl noch ein "mov dps,#0/1" stehen und der Code wesentlich größer sein, als wenn man ihn direkt in Assembler schreibt. Und dann müßte das AWK auch noch völlig anderen Code für den 8252 erzeugen, abhängig davon, welches Include Du lädst. Daher denke ich, der Code wird nicht SICHERER!, sondern UNSICHERER. Peter
> Und dann müßte das AWK auch noch völlig anderen Code für den 8252 > erzeugen, abhängig davon, welches Include Du lädst. Genau! Hier ist die erzeugte Liste: mov dps,#0 mov dptr,#tabelle1 mov dps,#1 mov dptr,#tabelle2 mov r4,#tablen mov dps,#1 ; Fehler! zyk: mov a,@dptr mov dps,#1 inc dptr mov dps,#0 mov @dptr,a mov dps,#0 inc dptr djnz r4,zykl Ich habe aber NIE gesagt, dass das Programm fertig ist. (Habe oben als "erster Versuch" gekennzeichnet. Es gibt noch Fehler, und müsste man weiter Optimieren, die unnötige DPS-Setzen zu vermeiden - tja, das AWK Script habe ich in ca. 15 Min. geschrieben). Habe aber nach Deine Einträge kein Lust es weiter entwickeln. :))) Ich bleibe bei meiner "alter" Lösung. Karoly
Thread beobachten
Seitenaufteilung abschaltenBitte 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.