Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - FAQ - Zum CC1-Forum - Zum CC-Pro-Forum
Re: Portzugriff aus Segment 3 Kategorie: Progr. Assembler, TaskingTools, OS (von Hansi - 20.11.2004 10:53)
Als Antwort auf Re: Portzugriff aus Segment 3 von Hansi - 19.11.2004 22:35
Ich nutze:
C-Control II Unit, C-Control II Station, CC2-Application-Board, OSOPT_V2
> > Hallo Hansi,
> >
> >
> > > >
> > > > P1L_  EQU 0FF04h
> > > > P1H_ EQU 0FF06h
> > > >
> > > > .....
> > > >           move  r3,#Speicheradresse     ; Speicherplatz, der #P1L_ oder #P1H_ enthält
> > > >           EXTS #8,#1
> > > >           mov    r7,[r3]               ; r7 enthält jetzt P1L_
> > > >           EXTS #0,#1
> > > >           mov    r2,[r7]               ; r2 soll jetzt die Ports enthalten tut es aber nicht
> > > > ......
> > > >
> > > >
> > > > eine andere Variante funktioniert
> > > >
> > > > P1L_  EQU 0FF04h
> > > > P1H_ EQU 0FF06h
> > > >
> > > > .....
> > > >           EXTS #0,#1
> > > >           mov    r2,P1L_            ; so funktioniert es
> > > > ......
> > > >
> > > >
> > > > ist das ein generelles Problem, gib es eine andere Möglichkeit den Port in r2 zu laden?
> >
> > Bist Du sicher, daÃ? Der Speicherplatz (R3) korrekt ist ?
> >
> > Denn bei mir funzt es Problemlos:
> >
> > $segmented
> > $model(medium)
> > $extend
> > $nomod166
> > $stdnames(reg164ci.def)
> > $NOLOCALS
> >     regdef  R12,R4,R1 ,R2
> > ;****************************************************************************
> >
> > BusAddr         EQU 0FD10H
> > BusAddrA        EQU 0FD12H
> > AddrL               EQU     0FD14H
> > AddrH               EQU     0FD16H
> > DataW               EQU     0FD18H
> > Ports               EQU     0FD1AH ; I/O-Ports= Bit 6,7
> >
> > ; Definition des OS-Routinen
> > OSsegment   EQU     0
> > POP_R4              EQU     0765AH
> > PUSH_R12    EQU     075D6H
> >
> > userseg             SECTION CODE word at 32000h
> > assume      dpp3:userseg
> >
> >
> > ;****************************************************************************
> > ptest       proc far
> >     CALLS   OSsegment,POP_R4        ;hole Daten vom Stack
> >
> >     EXTS    #0, #1
> >     MOV     R12, [R4]
> >    
> >     CALLS   OSsegment,PUSH_R12      ;lade Daten auf den Stack
> >     POP     R1
> >     POP     R1
> >     RETS
> > ptest       endp
> > userseg     ENDS
> >     END
> >
> >
> > Das C2-Testproggie dazu:
> > //------------------------------------------------
> >   inline function test (int port) returns int
> > //------------------------------------------------
> > {
> >  inline vmcodes.VM_LOAD_IMMEDIATE_BYTE+0x300;
> >  inline vmcodes.VM_LOAD_IMMEDIATE_INT;
> >  inline 0x2000;
> >  inline vmcodes.VM_SYSCALL;
> > }
> >
> > thread main
> > {byte i;int wert;
> >  lcdext.init();
> >  loop
> >  {
> >   lcdext.line(1);
> >   for i= 8 ... 15 lcdext.ziff(ports.get(i)and 1);
> >   lcdext.line(2);
> >   wert=test(0xFF06);
> >   for i= 0 ... 7 lcdext.ziff((wert shr i)and 1);
> >  }
> > }
> >
> >      
> > > Hat da noch niemand eine Antwort drauf? André H. , Du auch nicht?
> > > Andre, ich habe Dir übrigens am 15. eine mail geschickt ( .....@imail.de ) , kam sie nicht an?
> >
> > Sorry, aber da ich z.Zt. fast keine Zeit habe, dauert bei mir alles ein wenig länger.
> > Das gilt für E-Mail, Postings und alles andere auch.
> >
> > Bei EMails kann es daher schon einmal über eine Woche dauern, bis ich zum Antworten komme.
> > Im Forum ist es ähnlich, nur da� dies meist sogar länger dauert.
> > Eigentlich müsste ich jetzt produzieren, jedoch hat sich im Forum wieder zuviel angesammelt,
> > und mein Platinenhersteller lässt mich gerade im Stich, soda� ich nur einen kleinen Teil
> > der Bestellungen heute fertigmachen kann. (Meine Platinenproduktion, die gestern fertig sein sollte,
> > bekomme ich wegen eines Herstellungsfehlers ich erst am Dienstag, da alle Platinen
> > scheinbar neu produziert werden müssen.)
> >
> > MfG André H.
>
> Guten Abend André,
>
> da bin ich mir sogar sehr sicher weil ich die gleiche Speicherstelle mit dem gleichen Inhalt
> jetzt in einer anderen Form Abfrage und beide Ports klappen einwandfrei.
>
>
>
> .....
>  P1L_  EQU 0FF04h
>  P1H_ EQU 0FF06h
>
> .......
>                  mov  r3,#Speicheradresse     ; Speicherplatz, der #P1L_ oder #P1H_ enthält
>                  EXTS #8,#1
>                  mov    r7,[r3]               ; r7 enthält jetzt #P1L_
>                  cmp   r7, #P1L_
>                  jmpr   cc_EQ, Sub_P1L
>
> Sub_P1H:  EXTS #0,#1
>                  mov    r2,#P1H_              
>  ......
> Sub_P1L:  EXTS #0,#1
>                  mov    r2,#P1L_              
> .......
>
>  
>
> GruÃ? Hansi          
>


Guten Morgen,

Da kommt mir gerade so ein Verdacht!

Vieleicht wurde ja tatsächlich der Port eingelesen, allerdings dürfte der Befehl mov r2,#P1L langsammer
abgearbeitet werden als der Befehle mov r2,[r7]. Dann kann es durchaus sein, dass das Timing in
meiner Routine nicht mehr pa�t ( 75 bis 175 Durchläufe ) und deshalb keine gültigen Bits erkannt
wurden.

Ich habe eine Testschleife geschrieben, wo 2  Befehle  ( "mov r2,#PiL_ ", "and r2,#0080h",
 "xor r2,#0080h" ) gegen  "and r2,r6 ", "xor r2,r6" ausgetauscht wurden. ( vorher r6 mit #0080h geladen ).
Die Schleife wurde sage und schreibe 20% schneller durchlaufen.

GruÃ? Hansi ...ich werde die Angelegenheit noch einmal austesten
 

    Antwort schreiben

Antworten: