mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Organisation von AVR-Projekten


Autor: Jan Schirrmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Mitstreiter,

habe vor ein paar Wochen mit diesem kommodigem AVR-Assembler begonnen 
und erwecke nun einige Hardwarekomponenten (die üblichen Verdächtigen) 
zum Leben.

Aus der Hochsprachenprogrammierung habe ich noch die dumme Angewohnheit 
meinen Code auf Wiederverwendbarkeit und schlanke Schnittstellen zu 
trimmen, sodass ich keine Monolithen bekomme und nie mit Codekopieren 
arbeiten muss.
Das ist in Assembler gar nicht so leicht, insbesondere wenn kein 
Betriebsystem und damit keine Speicherverwaltung vorhanden ist wie auf 
meinen ATmega-Systemen.

Wenn ich nun Assembler-Dateien, z.B. für UART-Zugriff und 
Display-Ansteuerung für Wiederverwendbarkeit gestalte, habe ich 
Schwierigkeiten und erhoffe hier ein paar Hinweise von Euch zur 
Gestaltung von Projekten mit mehreren Dateien.

Beispiel: ich habe Basisroutinen zur Ringpufferverwaltung auf die die 
UART-Routinen aufbauen (ich arbeite mit blockierendem Senden und 
gepuffertem Empfang). Die UART-Routinen sollen wiederum im Hauptprogramm 
verwendet werden, welches aber möglicherweise selber auch 
Ringpufferroutinen verwendet. In C und C++ und ähnlichen bindet jedes 
"Modul" das ein, was es benötigt und Präprozessor oder ein anderer 
Mechanismus verhindert doppeltes Kompilieren.

Im Moment muss ich immer auf die Reihenfolge der includes von 
asm-Dateien achten und teilweise deren defs in eigene .inc-Dateien 
auslagern, damit ich diese .inc-Dateien oben im Hauptprogramm und die 
asm-Dateien weiter unten einbinden kann.

Gibt es dazu Hinweise und Verfahren, die sich bewährt haben, vielleicht 
ähnliche Krücken wie in C mit #ifndef MEINEDATEI_H usw.?

Grüße, Dank und viel Spaß

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nunja, wenn ich bisher ein Projekt in Assembler aufgesetzt habe, dann 
meistens immer aus dem Grund, das letzte Bisschen Geschwindigkeit und 
Rechenzeit herauszunehmen.
Allein daher wars dann eben schon unpraktisch, 'generische' Module zu 
schreiben und wieder Tempo zu verschenken.

Kurzun: Meistens immer ein langes ASM-Listing :->

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann mit include dateien arbeiten... {$include mymath.asm} oder so.

Autor: Assemblerfreak (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan Schirrmacher schrieb:
> Wenn ich nun Assembler-Dateien, z.B. für UART-Zugriff und
> Display-Ansteuerung für Wiederverwendbarkeit gestalte, habe ich
> Schwierigkeiten und erhoffe hier ein paar Hinweise von Euch zur
> Gestaltung von Projekten mit mehreren Dateien.

Schau Dir mal amforth (amforth.sf.net) an, dort werden einige viele
Assemblersourcen nach Bedarf zusammengestellt. Die Schnittstelle 
zwischen
den Modulen ist relativ einfach als Stack ausgebildet. Wiederverwendung
und austauschbare Module sind ebenfalls an Bord.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du in C genau das kannst, was du willst, warum schreibst du deine 
Programme dann stattdessen in Assembler?

Autor: Oliver Döring (odbs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum wird immer wie selbstverständlich die Annahme gemacht, daß man 
seine Code-Module von vornherein möglichst generisch gestalten und auf 
Wiederverwendbarkeit trimmen sollte? Steht das in irgendwelchen 
Lehrbüchern, die nicht hinterfragt werden?

Ich halte das für einen großen Irrtum und einen Hauptgrund für 
aufgeblasene, fehlerträchtige und ineffiziente Software.

Insofern schließe ich mich meinen Vorrednern an, gerade wenn es um 
Assembler-Programmierung geht. ASM-Codeschnipsel sind per definitionem 
weder portabel noch generisch. Was nicht heißt, daß man nicht aus einem 
alten Projekt bewährte Codesequenzen in ein neues kopieren und dort 
anpassen sollte.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist doch meine Rede.

Autor: spess53 (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Hier mal mein Ansatz am Beispiel Dog-Grafik-LCDs.

Für die ASM-LIB existiert eine Konfigurations-Datei in der alle 
notwendigen Konstanten festgelegt und die verwendeten Unterprogramme 
freigeschaltet werden. Diese wird in das Projektverzeichnis kopiert, 
konfiguriert und am Anfang des Hauptprogramms mit include eingebunden. 
Die ASM-Datei befindet sich in einen anderen Verzeichnis, das mit 
'Additonal include path' für den Assembler sichtbar ist.

MfG Spess

Autor: Jan Schirrmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
> Wenn du in C genau das kannst, was du willst, warum schreibst du deine
> Programme dann stattdessen in Assembler?

ooch, ich finde maschinennahe Sachen sehen in Assembler besser aus. 
Beispielsweise sind die verschiedenen Bitroll-Befehle kaum unterstützt. 
Außerddem kann man in Assembler sehr wohl strukturiert programmieren. 
Das hängt aber ein wenig an einer eventuell vorhandenen 
Betriebsystemstruktur ab. Habe solche Systeme in jungen Jahren 
entwickelt.

Aber hauptsächlich finde ich AVR so schön Back-To-The-Roots. Da passt 
eben Assembler. Aber dein Einwand ist natürlich prinzipiell berechtigt.

Autor: Jan Schirrmacher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver Döring schrieb:
> Warum wird immer wie selbstverständlich die Annahme gemacht, daß man
> seine Code-Module von vornherein möglichst generisch gestalten und auf
> Wiederverwendbarkeit trimmen sollte? Steht das in irgendwelchen
> Lehrbüchern, die nicht hinterfragt werden?
>
> Ich halte das für einen großen Irrtum und einen Hauptgrund für
> aufgeblasene, fehlerträchtige und ineffiziente Software.

Das steht sehr wohl in Lehrbüchern drin. Und Assembler ist nicht 
gleichbedeutend mit Unstrukturiert. Die Strukturen sind eben bloß nicht 
portierbar.

Autor: Ronny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein Problem rührt einfach daher, dass der AVR Assembler nur ein recht 
einfacher Assembler ist. Mit dem AVR-GCC kann man sehr wohl mehrere 
Module getrennt assemblieren und dann zu einem einzigem ELF oder HEX 
zusammen linken.

Symbole kann man dann in einem Modul (glaub per 'public') auch nach 
aussen sichtbar machen und von wo anders her aufrufen. Schau dir am 
besten mal die Man-Pages zum AVR-GCC an.

Einziger Stolperstein ist hier, dass der Linker immer noch den 
Einsprungpunkt in der C-Startup Funktion vermutet. Aber das liess sich 
auch deaktivieren, müsste nochmal nachschauen wo das war.

Wenn man meist auf dem selben AVR arbeitet, kann es schon Sinn machen 
die gut optimierten Assembler Routinen in ein Modul zu schieben und dann 
per #define abhängig vom konkret verwendeten AVR festzulegen welcher 
Code erzeugt wird. Mit jedem neuem AVR wächst dann das Modul-Listing 
eben etwas.

Gruß,

Ronny

Autor: horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Warum wird immer wie selbstverständlich die Annahme gemacht, daß man
> seine Code-Module von vornherein möglichst generisch gestalten und auf
> Wiederverwendbarkeit trimmen sollte? Steht das in irgendwelchen
> Lehrbüchern, die nicht hinterfragt werden?

Na endlich spricht das mal jemand an! Die meisten Projekte haben nämlich 
immer wieder etwas andere Anforderungen an das konkrete Modul. Da fährt 
man einfach dreimal besser, wenn man den Code kopiert und nicht bloss 
einbindet. Insbesondere treten so in alten Projekten nicht plötzlich 
Bugs aufgrund von Änderungen in den Bibliotheken auf.

Natürlich, wenn man am Anfang die Module perfekt durchplant und sehr 
flexibel gestaltet, dann sollten weder Änderungen an den Bibliotheken 
noch Kompatibilitätsprobleme mit älteren Projekten auftreten. Aber jeder 
hier kennt die Grenzen von Vorausplanung (und -sehung) sowie 
Bugfreiheit.

Und Assemblerprojekte zu modularisieren ist sowieso ein Widerspruch in 
sich - wer heute auf Mikrocontrollern in Assembler programmiert, der 
will ja gerade maximale Effizienz und/oder exakt vorhersehbares 
Zeitverhalten. Das beisst sich aber mit generischen Schnittstellen ganz 
gewaltig.

Autor: Markus M. (adrock)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

kann auch nur WinAVR empfehlen, arbeitet mit AVR Studio zusammen (wenn 
man das denn will) und man kann ASM und C kombinieren.

In meinem aktuellen Projekt (12x12 LED-Matrix mit Software PWM und 
diversen auf dem AVR selbst berechneten Effekten) habe ich im C-Programm 
mehr die Steuerfunktionen und Berechnungen.

Im ASM Teil habe ich die Sachen, die oft aufgerufen werden und Schleifen 
beinhalten (PWM, kopieren von Speicherbereichen, Linien zeichnen etc.).

Zwangsweise ergeben sich zum C-Programm entsprechende Schnittstellen die 
auch ein paar Zyklen kosten (Register auf Stack sichern etc.), auch habe 
ich einige Programmteile ziemlich allgemein gehalten bzw. paramtrierbar 
gemacht.

Aber ich schätze alles in allem dürfte der Vorteil durch direkten 
ASM-Code noch min. Faktor 2 sein was auf einem µC schon einiges 
ausmacht.

Ciao...
Markus

Autor: GefährlichesHalbwissen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus M. schrieb:
> kann auch nur WinAVR empfehlen, arbeitet mit AVR Studio zusammen (wenn
> man das denn will) und man kann ASM und C kombinieren.

Sehr gut, so langsam wird mir der Hintergrund klarer. Der AVR-Assembler 
des AVR-Studio arbeitet ohne Linker (da er eh keinen Code zu relozieren 
hat) und daher funktioniert Modularisierung auf Linker-Ebene sowieso 
nicht.

habe mich auch schon gefragt, wie man dann C und Assembler mischen kann 
(ausser inlne Assembler) ohne Linker. Aber der Hinweis mit WinAVR ist 
interessant in diesem Zusammenhang, da ich über kurz oder lang die 
Gurken auch mal in C programmieren werde.

Dann auch für die Hinweise der anderen Poster. Die Diskussion über den 
Sinn des Assemblerprogrammierens ist berechtigt und ich sehe auch das 
Problem der Codeanpassung, z.B. an andere Port-Konfigurationen, das 
strukturiert nur aufwändig zu realisieren ist.

Wahrscheinlich denke ich zu softwarelastig. Mir ist gerade eingefallen, 
dass die AVRs recht billig sind und daher eine Modularisierung auf 
Hardwareebene ebenfalls in Frage kommt. So könnte ich mein LCD-Modul 
einfach mit einem ATTiny ausstatten und ein simples SPI-Interface 
implementieren mit einem eigenen Softwareprotokoll und schon wäre die 
Sache einfacher in andere Projekte zu integrieren.

Haach. Das bringt schon Spaß mit diesen kleinen Chips.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde modulare Programmierung schon sehr sinnvoll.
Z.B. beim LCD möchte ich mir nicht vorschreiben lassen, welche Pins ich 
nehmen soll, da man dann oft die Spezialfunktionen (UART, PWM, ADC, ...) 
verliert.
Da nehme ich einfach nen Universalcode für beliebige Pins:
http://www.mikrocontroller.net/attachment/30300/lcd_drv.zip

Auch wird durch die Modularisierung die Programmierung deutlich leichter 
und fehlersicherer.
Ein einmal entwickelter Modul wird benutzt und gut is.


Programme über 2kB möchte ich aber nicht mehr in Assembler proggen 
müssen, das ist mir deutlich zu aufwendig.
C-Compiler sind garnicht so schlecht, etwa 5..20% Overhead bezüglich 
Größe und Geschwindigkeit ist doch kein großer Nachteil.
Die 5..20% gelten aber nur für erfahrene Assemblerprogramierer. 
Assembleranfänger erreichen oft das Gegenteil, d.h. größeren und 
langsameren Code als der C-Compiler.

Was nützt es, einige Befehle einzusparen um damit bezogen auf das 
Gesamtprogramm 0,1% CPU-Last weniger zu haben. Es ist einfach nur 
vergeudete Arbeitszeit.


Peter

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@oliver

>Ich halte das für einen großen Irrtum und einen Hauptgrund für
>aufgeblasene, fehlerträchtige und ineffiziente Software.

Das Stimmt so nicht ganz. Aufgeblasene Software hat man doch ohnehin 
meist "nur" auf dem PC, wo es eben nicht auf ein Megabyte genau ankommt. 
Beim AVR hat man eben aber kein Megabyte. Und ich behaupte mal das wenn 
man sich die Schnittstellen seiner Module vernünftig zurechtlegt dann 
spart man doppelt und dreifache Arbeit, selbst wenn es etwas mehr Code 
kostet.
Und wie Peter schon erwähnte, bei großen Projekten ist Assembler einfach 
zu aufwendig, selbst wenn man dann vllt ein paar Prozent eingespart hat.
Zumal hat man bei Assembler eben nicht die Möglichkeit den Code für 
einen anderen Prozessor (bzw andere Prozessorfamilie) einzusetzen und 
muß dann wirklich alles neu schreiben.
Assembler ist dann eine Alternative, wenns auf jeden Taktzyklus oder 
jedes Byte ankommt.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver Döring schrieb:
> Warum wird immer wie selbstverständlich die Annahme gemacht, daß man
> seine Code-Module von vornherein möglichst generisch gestalten und auf
> Wiederverwendbarkeit trimmen sollte? Steht das in irgendwelchen
> Lehrbüchern, die nicht hinterfragt werden?

Das zeichnet einfach die Entwickler aus, die etwas weiter als bis zum 
aktuellen Projekt denken. ;)
Wiederverwendbarer Code spart nicht nur Arbeitszeit, er sorgt auch für 
bessere getestete Software und - was immer wieder vergessen wird - er 
ist oft deutlich besser strukturiert und damit besser wartbarer. 
Außerdem macht sich der Entwickler vorher eher Gedanken über einen 
sinnvollen Aufbau.

> Ich halte das für einen großen Irrtum und einen Hauptgrund für
> aufgeblasene, fehlerträchtige und ineffiziente Software.

Nö. Aufgeblasen und fehlerträchig wird es erst, wenn der Entwickler 
nicht verstanden hat, wie weit die Wiederverwendbarkeit sinnvoll 
getrieben werden kann. Und auch dann, wenn sich der Entwickler keinerlei 
Gedanken um Wiederverwendbarkeit macht und einfach drauflos 
programmiert.

Ich versuche meinen Code auch immer so zu strukturieren und die 
Schnittstellen von Funktionen so zu gestalten, dass ich die auf 
möglichst vielseitige Art in verschiedenen Projekten nutzen kann.
Der Code ist deswegen kein bisschen aufgeblasen.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>C-Compiler sind garnicht so schlecht, etwa 5..20% Overhead bezüglich
>Größe und Geschwindigkeit ist doch kein großer Nachteil

Ich habe hier noch keinen disassemblierten C-Code gesehen der diese 
Bedingung erfüllt hätte.

>Programme über 2kB möchte ich aber nicht mehr in Assembler proggen
>müssen, das ist mir deutlich zu aufwendig.

Wenn du davon 1,5k aus der Schublade holen kannst, kein Problem.

>Zumal hat man bei Assembler eben nicht die Möglichkeit den Code für
>einen anderen Prozessor (bzw andere Prozessorfamilie) einzusetzen und
>muß dann wirklich alles neu schreiben.

Das hat sich auch erledigt, wenn du in C auf irgendwelche IO-Register 
zugreifst.

MfG Spess

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das hat sich auch erledigt, wenn du in C auf irgendwelche IO-Register
>zugreifst.

Wenn der Code wiederverwendbar werden soll benutzt man i.d.R. Makros die 
man bei Wiederverwendung innerhalb der selben Prozessorfamilie einfach 
nur anpasst.

Beispiel 7-Segmentanzeige :

#define LED7_DATA_PORT  PORTA
#define LED7_DATA_DDR   DDRA
#define LED7_STRB_PORT  PORTD
#define LED7_STRB_DDR   DDRD
#define LED7_STRB_PIN   4
#define LED7_SIZE       3
#define LED7_STRB_MASK  0x70


#define LED7_DATA_INIT  LED7_DATA_DDR  = 0xff;
#define LED7_STRB_INIT  LED7_STRB_DDR |= LED7_STRB_MASK;

#define LED7_STRB(x)    LED7_STRB_PORT = \
                          (LED7_STRB_PORT & ~LED7_STRB_MASK) | \
                          (1 << (LED7_STRB_PIN + (x)))
#define LED7_DATA(x)    LED7_DATA_PORT = (x)

void v7SegInit (void);
void v7SegDoTimer (void);
void v7SegSet (char cSeg, unsigend char cDigits);


So ähnlich könnte ein 7-Segment-Modul-Header aussehen.
Der eigentliche Quellcode lässt sich für alle Prozessoren der selben 
Familie verwenden. Außerdem kann man durch Anpassung der Makros 
LED7_DATA und LED7_STRB die Anzeige auch über einen I2C Bus, ein 
Schieberegister oder dergleichen für den Anschluß realisieren.

Wenn das ganze z.b. für einen ARM7 portiert werden soll, passt man 
einfach nur die Makros LED7_DATA, LED7_DATA_INIT, LED7_STRB und 
LED7_STRB_INIT an.

Bei komplexeren Sachen die die direkte Hardware des Prozessors betreffen 
wie z.b. UART, I2C, SPI muß das Modul neugeschrieben werden.
Aber bei Verwendung der gleichen Software-Schnittstellen kann darauf 
basierende Hardware (z.b. LCD via SPI oder I2C EEProm) bei 
entsprechender Kapselung (meist) ohne weiteres angesprochen werden.

Alle weiteren Software-Module die nichts mit der Hardware zu tun haben, 
Middleware, Tools und Ablaufsteuerungen lassen sich fast gänzlich ohne 
Anpassungen portieren, dadurch das da eben keine Registerzugriffe 
gemacht werden.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
>Wenn der Code wiederverwendbar werden soll benutzt man i.d.R. Makros die
>man bei Wiederverwendung innerhalb der selben Prozessorfamilie einfach
>nur anpasst.

Geht in Assembler ebenso. Sieh dir mal meinen ersten Anhang vom 17.1. 
an. Das Problem ist, das viele die Möglichkeiten des 
Assemblers/Preprozessors nicht nutzen oder gar nicht kennen.

MfG Spess

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Ich habe hier noch keinen disassemblierten C-Code gesehen der diese
> Bedingung erfüllt hätte.

Nimm einfach mal das oben erwähnte LCD-Beispiel und versuch es 
einzudampfen.
Ich kann Dir auch das Assemblerlisting erzeugen (mit eingeschalteter 
Optimierung).

Es gibt natürlich viele C-Programme, die aufgebläht sind.
Sehr oft sieht man z.B. daß gedankenlos int genommen wird, obwohl 
uint8_t ausreicht. Klar, daß sich dann der Code verdoppeln muß, wenn man 
16Bit auf nem 8Bitter macht.


Peter


P.S.:
Hast Du ein schönes Assemblermacro, was es auch gestattet, Portpins 
bequem als Bitvariablen zu definieren. D.h. Bitnummmer und Adresse in 
einem Namen abzulegen?
Das gefällt mir am GCC sehr, hat mir auch am Keil C51 schon gut 
gefallen.

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.