MPASM dynamische symbolische Adressen?

[Info (Gast)]

Kann der (PIC-)Assembler die Startadresse z.B. einer Sprungtabelle 
dynamisch vergeben und vorher im Code als low- und high-byte des program 
counters "einsetzen"? Etwa

    PCLATH = highbyte(SPRUNGTABELLE)
    PC     = lowbyte( SPRUNGTABELLE) + index

....

SPRUNGTABELLE
    GOTO XYZ ; +0
    GOTO ABC ; +1

Wenn ja, wie? Es müsste wohl auch sichergestellt werden, dass index 
nicht zum Überlauf führt, d.h. die Tabelle kann nicht an beliebigen 
Adressen im Code platziert werden.

[./. (Gast)]

Sag dem Linker halt wo er es hinlegen soll:

-L-Pseg=080h

Weiter dann mit:

void __section ("seg") seg(unsigned char index){
; in W steht index
#asm
  call  entry
#endasm

...
  return;

#asm
entry:
  bcf  PCLATH,1
  bcf  PCLATH,0
  addwf  PCL,f
  retlw
  retlw
  retlw
  retlw
  retlw

#endasm
  return;
}


Viel Spass!

[./. (Gast)]

P.S.:

In Assembler fast genauso wie in C.
Einfach den fraglichen Assemblercode in das Segment "seg" packen.
Die passende Direktive musst Du Dir mal selber suchen.
Obiges war fuer den XC8.

[Jannyboy (Gast)]

Kann man fast so machen.
Man muss erst prüfen ob das lowbyte (Tabelle+Index) überrollt und 
entsprechend das highbyte setzen.

Die Makros lauten high und low ohne -byte am Ende.

[Jannyboy (Gast)]

movlw low TABELLE
addwf INDEX,w
movwf Temp

movlw high TABELLE
btfsc STATUS,C
addlw 0x01
movwf PCLATH

movf Temp,w
movwf PC

TABELLE
goto Marke1
...
goto MarkeX

So musste es funktionieren.
Temp und Index müssen in Comman-Ram liegen oder jeweils ein banksel ist 
notwendig.

[Thomas E. (picalic)]

Warum denn nicht einfach mit "BRW"?

z.B.:

  movf index,W
  goto TABELLE

...

TABELLE
  brw
  goto Marke1
  ...
  goto MarkeX

[Jannyboy (Gast)]

Kleiner Fehler, die Adresse in PCLATH muss schon bei FF erhöht werden. 
So sollte es richtig sein... ist frei geschrieben nicht getestet.

movlw low TABELLE ;Temp=TABELLE(low)+index
addwf INDEX,w
movwf Temp

movlw high TABELLE ;Lade TABELLE(high) in Wreg
btfsc STATUS,C ;Prüfe ob die Addition(oben) einen Überlauf hatte
addlw 0x01;Wenn Ja dann erhöhe Wreg um 1
movwf PCLATH ;Schreibe Wreg in PCLATH

incf Temp,w ; Teste Temp auf 0xFF
btfsc STATUS,Z ; Wenn Temp ==0xFF
incf PCLATH ;Dann erhöhe PCLATH um 1



movf Temp,w ;Schreibe Temp in PC
movwf PC

TABELLE
goto Marke1
...
goto MarkeX

[Jannyboy (Gast)]

Thomas E. schrieb:
> Warum denn nicht einfach mit "BRW"?

Die alten PICs haben kein BRW Befehl.

[Thomas E. (picalic)]

Jannyboy schrieb:
> Kleiner Fehler, die Adresse in PCLATH muss schon bei FF erhöht werden.

Warum das? Scheint mir nicht richtig zu sein!

Zu diesem Thema würde ich das Lesen der entsprechenden Application Note 
von Microchip empfehlen:
ww1.microchip.com/downloads/en/AppNotes/00556e.pdf

[Thomas E. (picalic)]

Jannyboy schrieb:
> Die alten PICs haben kein BRW Befehl.

Der TO hat ja nicht geschrieben, daß er sich noch mit einem alten PIC 
quält. Ich würde auf jeden Fall neue nehmen - sind besser, billiger und 
Pin-kompatibel.

[Jannyboy (Gast)]

Thomas E. schrieb:
> Warum das? Scheint mir nicht richtig zu sein!

Hier ist das gut erklärt.
http://sprut.de/electronic/pic/fallen/fallen.html#tabellenhtml#tabellen

Ich hatte den Code eben frei geschrieben wie ich mir dachte es 
funktioneren können.
Weil keine Adresse auf FF enden darf.
Die meisten Tabellen mache ich mit den FSR.
Nur Mini-Tabellen mit addwf PC. Aus der oben genannten Problematik.

[Jannyboy (Gast)]

Thomas E. schrieb:
> Ich würde auf jeden Fall neue nehmen - sind besser, billiger und
> Pin-kompatibel.

Neue Pic sind nicht immer gleich besser.
Vergleiche z.B. mal die Comparatoren von einem PIC12F629 und und 
PIC12F1571... Vielleicht findes du den unter schied.

[Thomas E. (picalic)]

Jannyboy schrieb:
> Weil keine Adresse auf FF enden darf.

Sorry, das ist wohl nicht richtig. Probiere es aus: Du kannst sehr wohl 
auf eine berechnete Adresse mit PCL = 0xFF springen und es wird auch 
normal funktionieren.
Lade z.B. PCLATH mit 0x02 und dann lade PCL mit 0xFF - dann wird der 
Befehl auf 0x2FF angesprungen, nicht etwa der auf 0x1FF!

Was Sprut meint, ist das, was auch in der APPNOTE steht, daß nämlich bei 
Addition von W auf PCL kein Übertrag auf PCH berücksichtigt wird.

Jannyboy schrieb:
> Vergleiche z.B. mal die Comparatoren von einem PIC12F629 und und
> PIC12F1571... Vielleicht findes du den unter schied.

Was soll das jetzt? Sind wir hier beim lustigen Ratespiel oder was? Es 
wäre für alle Mitleser deutlich nützlicher, wenn Du dann den "unter 
schied" hier einfach kurz erläutern würdest - da hätten dann alle was 
davon.
Nein, ich weiß den Unterschied nicht, und werde jetzt auch nicht 
sämtliche Parameter der Komparatoren dieser beiden PICs vergleichen.

[Jannyboy (Gast)]

Thomas E. schrieb:
> Sorry, das ist wohl nicht richtig. Probiere es aus: Du kannst sehr wohl
> auf eine berechnete Adresse mit PCL = 0xFF springen und es wird auch
> normal funktionieren.
> Lade z.B. PCLATH mit 0x02 und dann lade PCL mit 0xFF - dann wird der
> Befehl auf 0x2FF angesprungen, nicht etwa der auf 0x1FF!

Ja da hast du Recht.
ich habe jetzt mal ausprobiert. Mein erster Code ist der Richtige.

  list p=16f628a
  #include <p16f628a.inc>
  
  udata_shr
Index    res .1
Temp    res .1
  
  org 0x0000

Main
  movlw 0xff
  movwf Index

  movlw low TABELLE
  addwf Index,w
  movwf Temp
    
  movlw high TABELLE
  btfsc STATUS,0
  addlw 0x01
  movwf PCLATH
    
  movf Temp,w
  movwf PCL
  goto Main

  org 0x0101    
TABELLE
  goto Marke1
  goto Marke2
  goto Marke3

  org 0x0200
  goto MarkeFF

Marke1
Marke2
Marke3
MarkeFF
  goto Main
  end

> Es wäre für alle Mitleser deutlich nützlicher, wenn Du dann den "unter
> schied" hier einfach kurz erläutern würdest - da hätten dann alle was
> davon.

Unterschied Comparatoren

PIC12F629 bei 3V
Strombedarf: 6-8 µA
Offset: +/- 5-10 mV (Eher 2-5mV*)
Response Time: 150nS


PIC12LF1571 bei 3V im Highspeed Modus
Strombedarf: 21 µA (Eher 18-30µA*)
Offset: +/- 7,5-60 mV (Eher +15-20mV*)
Response Time: 400nS

* Erfahrungswerte aus Serienfertigung

Gerade bei RFID oder Batterie-Anwendungen tun die schlechteren Werte und 
der erhöhte Stromverbrauch weh.

[Info (Gast)]

Dankeschön, ich werde es ausprobieren. Es handelt sich um ausgelesenen 
Code. Derzeit habe ich die Adresse selbst vergeben, um das Programm 
verändern zu können, aber wenn es der Assembler automatisch macht, ist 
das die bessere Lösung.

[Thomas E. (picalic)]

Jannyboy schrieb:
> Unterschied Comparatoren

Danke - offenbar haben sie bei den Enhanced Midrange Typen tatsächlich 
die Comparatoren "verschlimmbessert".