mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Tabellen mit .db - misalignment


Autor: Pavian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

wie kann ich im AVR-Studio (Assembler) Tabellen mit
.db definieren, ohne daß immer bei ungeraden Einträgen
ein 0-Byte angehängt wird?

Beispiel:
.db BLA1, 0x00,0x01
.db BLA2, 0x00,0x00
.db BLA3, 0x04,0x00

Möglich wäre zwar alles in eine Zeile zu schreiben,
oder:

.db BLA1, 0x00,0x01,\
    BLA2, 0x00,0x00,\
    BLA3, 0x04,0x00

Aber ersteres sieht nicht schön aus und letzteres erlaubt keine
Kommentare hinter dem '\'

Tips?

Grüße,
Pavian

Autor: Läubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das geht nicht, da der Speicher in 16bit worten organisert ist,
deswegen, entweder ein ,0 dranhängen oder es so aufteilen das immer
alles schon in 2er Blöcken ist :)

Autor: Pavian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

das weiß ich. Er soll die Tabelle ja auch als Ganzes betrachten
und von mir aus am Ende ein \0 anhängen.

Er macht das aber an jeder Zeile !!

Gewünscht ist ein Ergebnis im Speicher wie:
BLA1, 0x00, 0x01, BLA2, 0x00, 0x00, BLA3, 0x04, 0x00, 0x00 (Extra-\0)

Grüße,
Pavian

Autor: mmerten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist durch die 16 Bit Organistion des Flash so bedingt. Dieses kann immer
nur word-weise (2 Byte) beschrieben werden. wie Läubi schon richtig
bemerkte .db .dw .dd Direktiven bei längeren tabellen immer so
aufteilen, daß sich immer eine gerade Anzahl von Bytes (2, 4, 8, 16
...) pro Zeile Sourcecode ergibt.

Autor: Pavian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

was die Organisation des Speichers mit den Fähigkeiten des Assemblers
zu tun?
Stell ich meine Frage so ungenau?
Ich WEIß, daß der Flash 16Bit breit organisiert wird. Das ist mir aber
auch egal.
Ich will nur, daß der Assembler meine Tabelle nicht versaut.
Es muß doch möglich sein eine Tabelle anzulegen, die lesbar ist
und die der Assembler richtig übersetzt.
Sowas wie "#pragma align 1" oder so.

Grüße,
Pavian

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Atmel Assembler arbeitet nun einmal so, dass am Ende jedes
Statements eine gerade Anzahl Bytes rauskommt. Das ist auch nicht
vermeidbar, weil er im ROM-Space in Wortadressen statt in Byteadressen
rechnet.

Der GNU-Assembler arbeitet mit Byte-Adressen, kann gut sein, dass es
dort geht.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe damit keine Probleme.

Bei .db halte ich die Anzahl der Bytes geradzahlig.
Kommentare sind nach einem ";" auch möglich.
Der Assembler frisst auch die Tabellen, die ich mir von
Eigenbau-VB-Programmen als Include-Dateien generieren lasse.

Mit etwas Disziplin ist das alles auch gut lesbar.

...

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du verstehst den grundsätzlichen Unterschied zwischen Compiler und
Assembler nicht:

Ein Assembler arbeitet immer Befehl für Befehl ab.

Ein Assembler darf nichts rausoptimieren und macht es auch nicht.

Ihm ist völlig egal, welche Anweisung davor oder dahinter steht.

Somit muß auch jedes ".db" für sich abgearbeitet und in Codewords
umgesetzt werden. Und Codewords bedingen numal eine geradzahlige
Byteanzahl.


Peter

Autor: Pavian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter

> Du verstehst den grundsätzlichen Unterschied zwischen Compiler und
> Assembler nicht:
Doch. Ich verlange aber auch keine compilerfähigkeit von einem
Assembler. Aber er könnte sich ein wenig was sagen lassen. Z.B.
mit '#pragma' oder 'align'

> Ein Assembler arbeitet immer Befehl für Befehl ab.
Nicht wirklich. Es gibt Mehr-Pass-Assembler.
Außerdem muß er ja wohl Sprungadressen berechnen
können. Dafür benötigt er normalerweise mindestens 1-2 Durchgänge.
Es ist also durchaus möglich sowas zu implementieren. Damit errecht man
bei Weitem noch nicht die Möglichkeiten eines Compilers.

> Ein Assembler darf nichts rausoptimieren und macht es auch nicht.
Soll er auch nicht. Er soll die Tabelle als Ganzes sehen und
nicht nur einzelne Statements.

> Ihm ist völlig egal, welche Anweisung davor oder dahinter steht.
Den Eindruck hab ich auch. Aber verwechselt bitte nicht die Fähigkeit
eines Compilers inklusive der Optimierungsmöglichkeiten mit
der einfachen Tatsache, daß der AVR-Assembler zu blöd ist für sowas.

> Somit muß auch jedes ".db" für sich abgearbeitet und in Codewords
> umgesetzt werden. Und Codewords bedingen numal eine geradzahlige
> Byteanzahl.
Das Argument im zweiten Satz kenn ich, daß hat A.K. auch schon gesagt
und das akzeptiere ich auch.

Ich finde es nur schade, daß sowas wie

> Bei .db halte ich die Anzahl der Bytes geradzahlig.

nötig ist und ...

> Mit etwas Disziplin ist das alles auch gut lesbar.

... ist auch nicht gerade ein Ruhm für den Assembler.

Fazit:
- Der AVR-Assembler kann es nicht.
- Ich bin gezwungen bei z.B. 100 Tabelleneinträgen 100 Bytes zu
  verschenken plus dem unnötigen Code um das Byte bei sequenziellen
  Zugriff zu überspringen.
- Ich muß 2 Einträge je Reihe benutzen (=> schwieriger lesbar)
- ein \ am Ende der Zeile verhindert Kommentare

Grüße,
Pavian

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- Ich bin gezwungen bei z.B. 100 Tabelleneinträgen 100 Bytes zu
  verschenken plus dem unnötigen Code um das Byte bei sequenziellen
  Zugriff zu überspringen.

Nööö... Du musst nur die Daten ordentlich und diszipliniert anordnen,
dann verschenkst du nicht ein Byte. Und die Tabelle bleibt auch
unfragmentiert, es ist also kein zusätzlicher Code nötig.

Alles was du brauchst, ist etwas Disziplin.

...

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
irgend eine alte Version vom AVR-Studio, ich glaube unter Version 3, hat
mal die Korrektur nicht gemacht. Da musste man selbst auf die
Geradzahligkeit achten, was dann wieder Fehler hervorgerufen hat. Aber
ich verstehe den Einwand von Pavian, man müsste das sequenziell
abschalten können um Tabellen besser lesbar zu machen.

Mike

Autor: Pavian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Mike
Danke.

> Nööö... Du musst nur die Daten ordentlich und diszipliniert
anordnen,
> dann verschenkst du nicht ein Byte. Und die Tabelle bleibt auch
> unfragmentiert, es ist also kein zusätzlicher Code nötig.
> Alles was du brauchst, ist etwas Disziplin.
Da muß ich Dir Recht geben. Damit hapert es ;-)

Okay. Here we go. Ziel ist es eine Sequenz von Befehlen über SPI zu
senden. Immer ein Kommando (1Byte) und zwei Parameter (jeweils 1Byte).
Aus Performancegründen wird das so gemacht:

  ldi    R20, (Ende-Start)*2/3
  ldi    ZH, HIGH(Start<<1)
  ldi    ZL, LOW(Start<<1)
  L0:
  lpm    R17, Z+
  lpm    R18, Z+
  lpm    R19, Z+
  R17-R19 Übertragen
  dec    R20
  brne    L0
  ret

Die Tabelle ist deswegen so aufgebaut:
Start:
  .db Kommando, Para1, Para2
  .db Kommando, Para1, Para2
Ende:

@...HanneS...
Wie würdest Du die Tabelle umsortieren?
Selbst mit Disziplin würde ich ungern Bytes verschenken (Code oder
Daten), bzw Performance einbüßen. Wäre auch nett, wenn das noch lesbar
wäre.

Danke,
Pavian

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau das ist das Problem, an jede .db Zeile hängt der ASM eine 0 an die
keiner braucht. Willst du die Null nicht, musst du 2 Sequenzen als eine
Zeile schreiben, das währe der Kompromiss. Ich finde es auch
sch----se.

Mike

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde in diesem speziellen Fall 2 Datensätze in eine Zeile
schreiben.

...

Autor: Pavian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hannes
Da gehört dann die Disziplin eher in Richtung 'Lesebeherrschung'.
Die Möglichkeit hatte ich auch. Ist aber etwas unschön, da Kommentare
immer 2 Sequenzen betreffen. Naja. Mal sehen. Vielleicht überrede ich
meinen Assembler noch (eventuell mit Macros).

Danke für Eure Hilfe,
Pavian

Autor: Läubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
test:
.org 0x26
.db 1,2,3
.org 0x29
.db 4,5,6

Vileicht geht sowas?
Hab allerdings keien Plan wo so im Flash der kram liegt (bei welchen
Adressen)

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die .org-Angaben beziffern Worte, .db belegt Bytes.
Du nutzt damit also 3 Bytes von 3 Worten. Das vierte Byte belegt der
Assembler mit 0, das 5. und 6. Byte ist undefiniert, wird dann
vermutlich vom Programmer ignoriert und leer ($ff) gelassen.

Fazit: Das ist auch keine Lösung...

...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.