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
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 :)
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
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.
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
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.
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. ...
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
@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
- 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. ...
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
@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
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
Ich würde in diesem speziellen Fall 2 Datensätze in eine Zeile schreiben. ...
@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
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)
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... ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.