Suche in großer Tabelle.... [Archiv] - ProgForum.com

Archiv verlassen und diese Seite im Standarddesign anzeigen : Suche in großer Tabelle....

Import-Script

17.10.2003, 20:47

Tag zusammen, als ziehmlicher Programmier-Stümper komme ich gerade in meinem Projekt an meine Grenzen. Ich versuche mich an einer digitalen Zündung fürs Motorrad. Grobe Funktion: Ein Timer zählt „Counts“ während einer Motorumdrehung. Die Werte der Timer-Register (also 2 Byte) werden in R0 und R1 umgeladen. Damit soll dann aus einer 1KB grossen Tabelle der Wert ermittelt werden, der dem Timer-Stand am nächsten kommt. Mein Problem: Die Such-Funktion bekomme ich nicht so hin, da ich das Datenpointer register über den Accu nur maximal um 255 manipulieren kann und damit nicht meine 1024 Adressen umfassende Tabelle abdecken kann. Fang ich an über DPH und DPL zu gehen, verliere ich schnell den überblick...(so ist das als Stümper...). Hat jemand eine Gute Idee oder kann mir sagen, wie so etwas üblicherweise gelöst wird? Ich freue mich über jeden Tipp! Danke, Stefan

Import-Script

17.10.2003, 21:10

Was für einen Controller verwendest du? Beim AVR kannst du zB. die X Y und Z Registerpaare für 16bittiges verwenden. LDI ZL, LOW(Startadresse) LDI ZH, HIGH(Startsdresse) Wenn du einfach nur inkrementieren/dekrementieren willst, dann geht das mit ADIW ZL, <zahl> SBIW ZL, <zahl> Gruss, Malte

Import-Script

17.10.2003, 21:57

hi Malte,hi Stefan, es geht natuerlich um den '51er. wenn der pointer nur 255 kann was eigentlich normal ist, dann bleibt eigentlich nur die loesung mit mehreren tabellen à 255. mir faellt nichts besseres ein. gute tabellenselektion ed

Import-Script

17.10.2003, 22:15

hi Malte, hi ed, aaalso es ist ein 51er, um genau zu sein ein Atmel AT89C4051 (dachte, der wäre gut, weil klein & billig). Inzwischen träume ich von einem 16bitter.... Das mit den mehreren Tabellen ging mir gestern auch schon mal durch den Kopf, hatte ich aber gleich wieder verworfen. Die Tabelle wird von einem VisualBasic Prog. erzeugt und in den ´51 Quelltext eingefügt, dass ich letztes jahr zwischen Weihnachten und Neujahr zusammengenagelt habe. VB kann ich noch schlechter als 8051 Assembler :o) Oder ich lass den Luxus sausen und zersäge die Tabelle mit Excel in 4 Stücke. Vielen Dank auf alle Fälle (wenn Euch noch was einfällt- immer her damit) Gruss, stefan

Import-Script

18.10.2003, 02:22

habs zwar nicht getestet, aber so müsste es doch gehen ! Grüessli Thedy . . . MOV DPTR, #Tabelle MOV A, DPH ADD A, R0 ; Higher Byte MOV DPH, A MOV A, R1 ; Lower Byte MOVC A, @A+DPTR . . . . . Tabelle: DB 01H, 03H, 09H, A0H ; ...... DB 00H, 05H, 00H DB 00H, 00H, 00H DB 00H, 00H, 00H DB 00H, 00H, 00H DB 00H, 00H, 00H

Import-Script

18.10.2003, 12:51

Ne, ein 16-Bitter muß da noch lange nicht her. Thedys Lösung ist genau richtig. Peter

Import-Script

20.10.2003, 12:41

Hi Thedyg, Peter kann man das für Anfänger noch einmal näher erklären? Mit den DB Datenfäldern und daraus Daten auslesen hatte ich das noch nicht so. Bitte weit ausholen (wenn's nichts ausmacht). MfG Carlos

Import-Script

20.10.2003, 22:11

mit DB kannst du direkt Daten an der ensprechenden Position ins Programm einlinken. Dies brauchst du z.B. für Texte (bei AUsgabe auf LCD-Displays), Codetabellen oder wie hier eine Wertedatenbank. Tabelle: enspricht der Adresse, wo in diesem Beispiel diese Daten beginnen. Das heisst, in dieser speziellen Anwendung kann Stefan seine 1024 Zahlen als 1-Byte Werte aus seiner Tabelle ablegen so dass sie dann für den MOVC Befehl zur Verfügung stehen. Einigermassen klar ? Grüessli Thedy

Import-Script

20.10.2003, 23:09

ich probiers mal, soweit meine Assemblerkenntnisse reichen... Das Programm beginnt irgendwo mit ORG XYZ, sagen wir auf Adresse 500 nur mal so. Tabelle: ist ein Label. Der Assembler berechnet nun die folgenden Mov.. und Add Befehle, also der erste MOV z.B. 3 Byte lang (MOV-Opcode + 2 Byte Operand), der 2. z.B. 2 Byte(Mov-Opcode + 1 Byte Registerangabe) usw. Also irgendwie kommt der Assembler an die Stelle wo Tabelle: steht und hat errechnet, das sei Adresse 527, also 27 Byte vom ORG entfernt bedingt durch die vorangegangenen Befehle. MOV DPTR, #Tabelle für Tabelle würde also jetzt 527 als Wert stehen. Wäre der ORG des Programms 200 würde hier 227 eingesetzt werden. Wie gesagt, der Assembler errechnet das während des Assemblierens. MOV A, DPH ADD A, R0 ; Higher Byte DPH ist jetzt DPH + R0; dürfte klar sein, einfache Addition. Jetzt mal angenommen, der 700ste Wert der Tabelle wäre gefragt; 700 sind 02BC (hex) also 02 im HighByte=R0, BC im LowByte=R1 Akku ist jetzt also DPH + 02 MOV DPH, A den Wert wieder in DPH zurücklegen. MOV A, R1 ; Lower Byte jetzt die BC in den Akku, also das LowByte MOVC A, @A+DPTR und jetzt den Inhalt der Speicherzelle, DPTR+DPH*256+Akku in den Akku laden. DPTR war 527, DPH*16+Akku gibt 700, haben wir ja vorher dto. zerpflückt, also den Inhalt der Speicherzelle 1227 in den Akku laden, den 700sten Tabelleneintrag also. . . . . Tabelle: DB 01H, 03H, 09H, A0H ; ...... DB 00H, 05H, 00H DB 00H, 00H, 00H DB 00H, 00H, 00H DB 00H, 00H, 00H DB 00H, 00H, 00H und hier steht irgendwo an 700ster Stelle, also nach dem 700sten DB xy ein Wert und dieser wird in den Akku geladen und dann wird mit dem weitergerechnet; irgendwie. Der @(at) Operator lädt also den Wert der in der Speicherzelle "(at)XYZ" drinsteht, wie das Wort "at" recht treffend aussagt... Jetzt kommt Mord und Zedere seitens der 80xxer Gemeinde, weil ein 68000 Fritz sowas versucht hat zu erklären; aber es kehrt auch wieder Ruhe ein, dessen bin ich mir sicher. Prinzipiell bieten alle CPUs derartiges, also einen 16Bit Zeiger Hi und Lo, der auf eine Speicherzelle im gesamten Adressraum zeigt, deren Inhalt man lesen will. Beim 68000 heisst der Befehl LEA (load effektive Adresse). also LEA Tabelle,A4 würde A4 mit 527 besetzen, eben dem Tabellenanfang MOVE 700(A4),D0 würde dann den Wert der Speicherzelle 700+527 nach D0 moven. Achtung beim 68xxx oder generell bei den Motorolas ist die Schreibweise Move Wert von nach, im gegensatz zu den 80ern, da heisst es load irgendwas mit Wert, also genau andersrum. Reine Gewöhnungssache, und das splitten in Hi und Lo wie im obigen Beispiel entfällt weil es ein 32 Bit Rechner ist, also LEA #20000h, A0 MOVE #10000(A0),D0 ist kein Problem, aber da hat Peter und Thedy schon Recht, dazu BRAUCHT´s keinen 32Bitter, das geht auch mit 8 Bittern, dann muss man eben in Hi Lo splitten, dafür gibt´s da auch extra einen DPH DatenPointerHi.<img src="http://progshop.com/elektronik/diskussion/clipart/smile.gif" border=0>

Import-Script

21.10.2003, 18:17

Hiho, suuper, hier kommt ja doch ´ne Lösung zustande! Eine Frage jedoch: wenn beim Addieren des DPL mit Accu es zu einem überlauf kommt, ja was dann? (Wie gesagt, Stümper!) Brauche ich dann nur das Carry-Bit zum DPH hinzurechen? Vielleicht so?: (Thedys Quelltext, nur DPL zuerst?) MOV DPTR, #Tabelle MOV A, DPL ADD A, R0 ; lower Byte MOV DPL, A jnc MARKE inc dph MARKE: MOV A, R1 ; higher Byte MOVC A, @A+DPTR kann das was werden oder habe ich was übersehen? Gruss, Stefan

Import-Script

21.10.2003, 18:17

Import-Script

21.10.2003, 19:15

jetzt muss ich mich leider ausklinken, weil ich nicht weiss, ob dieses Register überhaupt überlaufen kann oder einen Carry akzeptiert. Das ist kein "normales" Register, ich war schon drauf und dran zu fragen, was das soll von wegen "add" zu was unbekanntem dazu; weil initialisiert wurde es ja nirgends. Das hat aber wohl mit der kruschigen Speicheraufteilung zu tun, so von wegen Programm / Daten / intern / extern usw. und das ist wohl irgendwie vorbesetzt oder muss es sein. Die 68000er hanben nur "Speicher" - in der Regel intern, d.h. mit auf der Platine verbaut oder halt im Chip drin, also letztenendes im Computer drin, und der nimmt sowohl Daten als auch Code gleichermassen auf, weil aus FlipFlops bestehend, die nur High und Low werden, also auf Bitmuster gucken, und nicht noch nachsehen woher diese stammen??? - komische Teile, genau wie die PCs mit IN und Out, letztenendes ist das ein Move to oder from MEMORY; wüsste nicht, dass ein Latch auf einer I/O Karte was anderes wäre als ein 8Bit*1 Memory... Na ja, Hauptsache es hat wem gefallen und ich hab nicht gleich eins auf den Deckel bekommen für meine Ausführungen. <img src="http://progshop.com/elektronik/diskussion/clipart/smile.gif" border=0>; ist halt doch irgendwie bei allen Computern ähnlich.

Import-Script

21.10.2003, 23:13

Stefan, Du addierst nur das High-Byte und da sollte es keinen Überlauf geben, da nur 64kB Adreßraum. Das Low-Byte addiert dann der "MOVC A,@A+DPTR" richtig 16 Bittig. Peter

Import-Script

23.10.2003, 16:08

HI, und den Tabellenanfang setzt du in sicherer Entfernung hinter dein eigentliches Programm im Speicherbereich! Z.B. geht dein Prog bis 018Fh, dann machst du die Tabelle auf 0200h

Import-Script

23.10.2003, 16:33

und das mit "dahinter" nimmt Dir halt der Assembler ab indem du es einfach "physisch" dahinter schreibst, dann kennt er ja alle Befehle vorher. also: mov... mov... add... bis alles fertig ist... und dazu braucht´s keinen sicheren Abstand, der Assembler weiss das aufs Byte genau!!!<img src="http://progshop.com/elektronik/diskussion/clipart/smile.gif" border=0> TABELLE: db... db... END.

Import-Script

23.10.2003, 17:18

"...sicherer Entfernung..." Erinnert mich an meine frühere Z80-Zeit. Flash war noch nicht erfunden und ich hatte kein EPROM-Löschgerät zu Hause. Da hab ich hinter jeder Funktion ein paar Bytes freigelassen. War sie fehlerhaft, habe ich sie übergeNOPt und in den freien Bereich einen Jump zum richtigen Code gebrannt. Aber heutzutage ist jeder Abstand >=0 vollkommen ausreichend. Peter