Frage zu DB, DW und Label

[tomes]

Ich suche ein Lösung zu folgendem Problem:

In einem Programm werden viele unterschiedlich große Tabellen verwendet:



txy1: DB 014H, ...
txy2: DB 013H, ...
txy3: DB 004H, ...
....


Auf die Tabellen wird über eine Adresstabelle zugegriffen:



TabAdr:
ta00: DW 012A0H
ta02: DW 012A6H
ta04: DW 012C0H
....

Da die Adressen sich erst beim Assemblieren ergeben, würde ich die Adresstabelle gerne so aufbauen:



TabAdr:
ta00: DW txy1
ta02: DW txy2
ta04: DW txy3....

Wird aber offenbar vom ProgStudio einfach ignoriert. Der Abschnitt zu DB und DW im Manual hatte mir Hoffnung gegeben, in diesem Fall mit Label arbeiten zu können. Aber auch das Beispiel aus dem Manual funktioniert nicht.



LcdText: DB "Hello World!"
LcdTextLen: DB LcdTextLen – LcdText
DataTable: DB 5, 10, 15, 80h, 11111110b, "A", "Abc"


Was mache ich falsch und wie geht es doch? :o

[Jan Ruhländer]

Moin,

ich habe es mit folgenden Code getestet:


txy1: DB 014H
txy2: DB 013H
txy3: DB 004H

TabAdr:
ta00: DW txy1
ta02: DW txy2
ta04: DW txy3


Der Assembler erstellt daraus diese Hexdatei:


00000000 | 14 13 04 00 00 00 01 00 02 | .........


Das wäre OK. Welche Version verwendest du? Ansonsten kannst du mir auch gerne ein Beispielprogramm schicken, in dem der Fehler auftritt.

Falls hier ein Fehler enthalten ist, wird dieser natürlich sofort behoben. Keine Frage.

[tomes]

Danke für die schnelle Antwort. Hab es nochmal durchgespielt. Es scheint nur zu funktionieren, wenn die Labels im Quellcode vor der Referenzierung definiert wurden. So geht es nicht - gibt aber auch keinen Fehler aus:



ORG 11E0H
TabAdr:
ta00: DW txy1
ta02: DW txy2
ta04: DW txy3
　
txy1:
DB 014H
DB 004H
DB 02EH, 052H, 048H, 038H
DB 001H, 003H, 002H, 000H
txy2:
DB 013H
DB 002H
DB 041H, 080H
DB 080H, 080H
txy3:
DB 004H
DB 00CH
DB 004H, 007H, 008H, 00FH, 01AH, 035H, 01CH, 01CH, 010H, 007H, 003H, 016H
DB 002H, 013H, 025H, 034H, 048H, 05FH, 089H, 0A2H, 0C3H, 0E0H, 0F3H, 0FBH


Stellt man die Adresstabelle hinter die Tabellen, funktioniert es. Ist die Reihenfolge zwingend? Bei Sprungzielen ist es doch auch egal...

[Jan Ruhländer]

:eek:

Danke für das neue Beispiel. Das sollte natürlich auch genau so funktionieren.

Ich hab den Fall jetzt auf meiner "Werkbank".

Updates folgen.

[Jan Ruhländer]

Der Bug ist behoben.

Die aktuelle Assembler Ausgabe des Beispiels ist folgende:



...
000011E0 | 11 E6 11 F0 11 F6 14 04 2E 52 48 38 01 03 02 00 | .æ.ð.ö...RH8....
000011F0 | 13 02 41 80 80 80 04 0C 04 07 08 0F 1A 35 1C 1C | ..A..........5..
00001200 | 10 07 03 16 02 13 25 34 48 5F 89 A2 C3 E0 F3 FB | ......%4H_.¢Ãàóû
...


Eine neue Version mit diesem Bugfix wird mit einigen anderen Verbesserungen und Fixes wird im Laufe des Tages veröffentlicht.

[tomes]

Wow! Das ging wirklich schnell und hilft mir sehr.

Vielen Dank !!!!

[Jan Ruhländer]

Vielen Dank. Das Update steht nun bereit.

[Klaus]

Hallo!
ich habe das neue Update heruntergeladen und beim Erstellen bekomme ich Fehlermeldungen wie sie in den hochgeladenen Bildern zusehen ist.

Ich hoffe sie können damit was Anfangen H. Ruhlaender.

[tomes]

Bei mir funktioniert es jetzt so wie oben beschrieben. Vielen Dank!

Allerdings findet ProgStudio die CPU Includes nicht mehr selber sondern nur über den absoluten Pfad....

[Klaus]

In den Überwachungslisten verschwinden die zu überwachenden Variablen wenn man sie verschiebt. Also wenn man sie Packt und nach oben verschieben möchte verschwinden sie.

Noch eine Sache würde ich gerne Ansprechen und zwar das beim Laden einer Projekt-Datei das Layout nicht so wieder erscheint wie man es gespeichert hat.
Soll heissen dass z.b. Main.asm entweder am ende oder in der mitte auftaucht wenn mehrere *.asm geöffnet sind.

Wäre schön wenn man es nicht immer von Hand durchsortieren müsste.

[tomes]

Version .13 läuft jetzt gar nicht mehr... :(

Nach ein paar Arbeiten im Editor kommt jetzt ständig eine Fehlerweldung "Invalid cast in expression". Neu booten, installieren etc. hilft nicht...

Nachtrag:

Das Problem mit der Fehlermeldung muss am Projekt liegen. Auch mit der .11 tritt es auf. Andere Projekte funktionieren (noch).

Zudem verhält sich die .13 anders als die .11. Folgende Sequenz wurde früher problemlos übersetzt:



ORG 100h
CalcDwell:
NOP
RET
_CalcDwell EQU CalcDwell ; we use the old routine
Main:
LCALL _CalcDwell


Die .11 erstetzt _CalcDwell mit CalcDwell und löst sauber auf. Mit der .13 gibt es jetzt eine Fehlermeldung.

[Jan Ruhländer]

Die vermeintliche schnelle Hilfe bereitet leider mehr Probleme als erwartet. :mad:

Da die 9.0.13 offensichtlich noch schwere Fehler enthält, haben wir uns entschlossen diese Version nur noch als Preview/Beta Version auf eigene Gefahr anzubieten.

Aktuelle Version ist also bis auf weiteres (wieder) die 9.0.12.

Die x.13 werden wir nun in Ruhe auf "Herz und Nieren" prüfen und erst nach dem bestehen all unserer Tests als 9.0.14 freigeben.

[tomes]

Gibt es schon einen Zeitplan?

Das Problem mit den Labels bremst mich aus... :(

[Jan Ruhländer]

Die nächste Version kommt definitiv diese Woche.

Update: Die neue BETA Version ist nun fertig.

[Klaus]

Hallo!
Also die Beta Version hat auch ne Macke. siehe Anhang!

Also wenn ich vorhandene und schon geschriebene Projekte Compiliere
bekomme ich einen ganzen Rattenschwanz voller Fehlermeldungen.

Bei neu anlegen kommt das nicht vor. Allerdings habe ich wegen Zeitmangels noch nicht weiter ausprobiert.

Dabei Frage ich mich wie die Test den durchgeführt werden bevor Software veröffentlicht wird.

Außerdem sollten Fehlermeldungen besser beschreiben wo es klemmt.

Irgendwie gewinn ich den Eindruck das an der weiter Entwicklung der Software nur halbherzig gearbeitet wird. Vllt. täusch ich mich auch. http://www.progforum.com/images/icons/icon9.gif

[Jan Ruhländer]

In einer Beta Version können natürlich noch Fehler enthalten sein. Können Sie ein Projekt, dass die Fehler auslöst bitte an unseren Support schicken?

Wir schauen uns das Projekt an und beheben die Ursache natürlich.

[tomes]

Ich liebe das Prog-Studio wirklich und bin auch wirklich dankbar, dass ihr es weiter entwickelt. Aber manchmal nerven die Probleme doch... :(

Eine Kleinigkeit ist die Exception, die das Programm wirft, wenn die out.bin Datei nicht schreibbar ist. Z.B. wenn man das Ergebnis binär mit einer Solldatei vergleicht und so out.bin geöffnet hat. Eine entsprechende Meldung wäre mir lieber.

Einen dicken Hals habe ich durch dieses "Feature" bekommen:



;
$INCLUDE "8051.mc"
SerVar1 EQU vActRpm
vActRpm EQU 37H
; -------------------------------------------------------------
Main:
MOV A,SerVar1
; -------------------------------------------------------------


Das Projekt lässt sich nicht ohne Exception laden und nach eine Aufruf des Assemblers ist das Prog-Studio tot. Klar ist die Reihenfolge der Definitionen falsch - aber eine Fehlermeldung wäre hilfreicher als ein Totalabsturz. Es hat ein paar Stunden gedauert, bis ich diese Ursache fand und mein Projekt wieder laden und übersetzen konnte.

[Jan Ruhländer]

Eine entsprechende Meldung wäre mir lieber.

Uns auch. Deshalb haben wir diesen Fehler auch direkt nach dem Lesen des Beitrags behoben. Vielen Dank für die Meldung.


Einen dicken Hals habe ich durch dieses "Feature" bekommen:

Das kann ich gut nachvollziehen. Vielen Dank für das angehängte Beispiel. Wir konnten damit auch diesen Punkt leicht korrigieren.

Die automatischen Tests wurden inzwischen erweitert, damit diese Fehler in Zukunft vor jedem Release überprüft werden.

Die korrigierte Revision 22 kann ab jetzt über die eingebaute Update Funktion vom Prog-Studio installiert werden.