Programmiersprache - C oder Assembler?

Ist das hier mal wieder der übliche C/ASM Flamewar?
Natürlich nimmt man Spin! :-P

Im Ernst: Ein so kleines Projektchen läßt sich prima in ASM umsetzen. 
Denn auch wenn man C lernt, empfiehlt es sich mit ASM den Controller 
erst mal kennen zu lernen.

Preislich nehmen sich ARM, AVR, PIC, MSP430 und 8051 nicht viel. Da von 
Hubschraubern zu sprechen, finde ich unangemessen, auch wenn der ARM mit 
der Aufgabe hoffnungslos unterfordert ist - die anderen sind es auch!

Für das von Dir geschilderte Problem würde ich einen ATmega48 benutzen. 
Der hat einen ADC und eine Hardware UART. Und ich würde es in ASM lösen. 
Ich denke, auch in ASM ist das mit <40 Zeilen Code realisierbar.

Gründe für meine uC-Auswahl:
PIC scheidet für mich aus, da ich mich damit nicht auskenne. (Ich habe 
damals die Finger davon gelassen, als ich die 'krummen' Registergrößen 
gesehen habe.)
ARM scheidet aus, da für Anfänger zu umständlich - auch in C.
Die kleinen 8051 haben häufig keinen ADC.
Die ATtinys haben keine UART. Für einen Anfänger möchte ich die SW-UART 
vermeiden.
Die kleinen MSP430 haben keine UART und keinen ADC - zumindest die, die 
ich kenne.
Den ATmega48 ziehe ich dem ATmega8 vor, da er moderner ist.


Gruß

Jobst

Bevor man auf ein Mopped steigt, sollte man erst mal richtig gehen 
können. Auch die meisten Rennfahrer laufen vorher die Strecke zu Fuß ab, 
weil man die Unebenheiten besser erkennen kann.

Es schadet definitiv nicht, die Hardware zunächst auf unterster Ebene 
kennenzulernen, man versteht sie so einfach besser. Wenn dann die Wege 
zu weit werden, kann man das Mopped starten.

sorry, aber wem erscheint denn bitte assembler auf den ersten blick 
logischer & einfacher als eine hochsprache?!

soll ja jeder machen wie er möchte, aber wer ungezwungen projekte mit 
mehr als ner DIN A4 seite quelltext in assembler schreibt, neigt wohl zu 
masochismus. und das bedeutet nicht im umkehrschluss, das man keine 
ahnung von der hardware haben muss/soll/braucht.

im hobbybereich kann das ja jeder handhaben wie er möchte, aber irgendwo 
wird es schon seinen grund haben, das in firmen niemand mehr seine 
firmware in assembler programmiert, ausser er ist wirklich drauf 
angewiesen
und mal ehrlich...die fälle, in welchen man unbedingt auf assembler 
angewiesen ist lassen sich an einer hand abzählen...wobei mir gerade 
kein triftiger grund einfällt

sebastian schrieb:
> Gerade für den Anfänger ist der ARM (acuh aufgrund des interrup
> handlings) nicht wirklich zu empfehlen (IMHO)

absolute zustimmung. aber dem anfänger dann den einstieg mit assembler 
zu empfehlen für schnelle erfolgserlebnisse finde ich schon gewagt

Hi,

Es ist nun ja schon einiges geschrieben worden...

MEine MEinung geht auch mit vielen vorhergesagtem konform...

WENN es jetzt nur für dieses eine Projekt eine schnelle Lösung sein soll 
UND du gar kein C beherrscht, dann ist ASM für die zeitnahe Realisierung 
wohl das Mittel der Wahl.
Wenn du also nur dies vor hast und nicht weiteres mit µC planst nimm ASM 
und du kannst direkt zum Ende des Beitrages Springen.

Für Spätere Projekte müsste man schauen wie umfangreich es wird. Diese 
Anforderungen die du oben genannt hast sind auf jeden Fall noch halbwegs 
bequem in ASM Umzusetzen. Ich denke sogar auf dieser Ebene ist der 
Zeitunterschied zwischen ASM und C für einen erfahrenen Programmierer 
noch nicht wirklich vorhanden.

Mit zunehmender Größe und komplexität der Software aber geht die Schere 
immer weiter auseinander. Wenn aufwendige MAthefunktionen dazukommen 
etwas früher, geht es nur um einfache Logikentscheidungen etwas später. 
Aber es wird der Zeitpunkt kommen ab dem die komplette Umsetzung in ASM 
einfach unsinnig ist weil es ein vielfaches der Zeit erfordert und nur 
einen Bruchteil der Übersichtlichkeit bietet.

Wenn soetwas abzusehen ist bietet es sich auf jeden Fall an auch C zu 
lernen. (ggf. halt auch nach der Realisierung des konkreten Projektes)
Wobei ich wie von anderen auch geschrieben, es durchaus Sinnvoll finde 
wenn jemand der plant später in C zu schreiben zumindest die Grundlagen 
von ein oder zwei ASM Varianten kennt.
Gerade mit ASM hat man noch einen sehr engen Bezug zum tatsächlichen 
Ablauf im µC und lernt so die eigenheiten soch etwas besser. Zudem kann 
es später auch bei großen Projekten immer wieder vorkommen das sich 
bestimmte sehr zeitkritische Anforderungen nur in ASM Sinnvoll umsetzen 
lassen und man so dann doch einige Zeilen ASM in sein C Programm 
einbetten muss (Inline). Zudem hilft es etwas beim Debuggen und man 
versteht auch die ausgaben des Compilers.

Daher würde ich sagen: ASM Lernen macht auf jeden Fall SINN! Es ist nur 
die Frage wie Intensiv du dich damit beschäftigen solltest. Wenn du bei 
ASM bleien willst, was bei Projekten wie oben durchaus im Rahmen ist, 
dann halt etws intensiver, willst du früh auf C umsteigen halt etwas 
später.

Zur Architektur:
HAst du dir denn schon einen µC ausgesucht?
Einige sind ja schon genannt worden. Für den Einstieg würde ich auf 
jeden Fall mal "tief" stapeln, also mit 8Bit µC anfangen. (PIC18F, AVR, 
evtl. auch noch 8051). Die 32 Bit µC sind zwar deutlich 
leistungsfähiger, aber für einen Einsteiger daher auch deutlich schwerer 
zu verstehen. Ein LKW fährt sich halt schwerer als ein VW Polo. Wenn man 
dann die Grundzüge beherrscht spricht natürlich nichts dagegen sich auch 
in größeren Leistungsbereichen zu versuchen (ARM, PIC32 usw.)

Diese 8 bitter lassen sich gerade für Anfänger am einfachsten 
programmieren. Erst recht in ASM. Als zweites Kriterium als Anfänger 
würde ich mir noch etwas die Verbreitung in Hobbykreisen und in Foren 
ansehen. Was nützt dir die tollste Architektur wenn man bei Problemen 
dazu nichts im Netz findet und auch keinen Ansprechpartner hat. Zumal 
man ja auch als Einsteiger gar nicht weiß "wo" man nun GENAU suchen muss 
und auch noch nicht so zwischen den ZEilen liest, man evtl. doch 
vorhandene Info gar nicht ohne ZAunpfahl findet...

Ich selbst bin ja eher PIC Fan, obwohl ich auch schon mit einer 
beachtlichen Anzahl anderer Architekturen gearbeitet habe und immer 
wieder arbeitet. Wenn du des Englischen (lesen) einigermaßen mächtig 
bist, dann würde ich dir die PIC18 für den Einstieg empfehlen.
Dort bekommt man fast alles was man so benötigt direkt vom Hersteller 
(Tutorials, Librarys, Frameworks, Beispiele) hat eine große 
HArdwareauswahl und eine recht große Verbreitung.
Die Programmiertools sind günstig, ab ca. 25 Euro bekommt man eines das 
ALLE aktuellen PIC Familien beschreiben kann und das eine Debug Funktion 
bietet. Braucht man mal mehr Leistung kann man mit den selben Tools auch 
die 16Bit oder 32Bit PICs programmieren. Es gibt zudem unter den 16Bit 
Typen auch welche mit einem abgespeckten DSP Kern. Die Verfügbarkeit ist 
auch für Hobbyisten gut. Die Softwaretools sind alle kostenlos ohne 
Größenbeschränkung verfügbar.

Wenn es bei dir aber mit dem Verständniss von englischen Texten hapert 
würde ich doch eher zu AVR Raten. die haben hier im Deutschsprachigen 
Raum eine etwas größere Verbreitung, wobei das manchmal auch etwas 
täuscht, denn vieles was bei den AVR an SW Projekten oder Libs von 
dritten bereitgestellt wird und so als Fundstelle auf einer Homepage 
o.ä. bei google auftaucht bekommt man bei Microchip direkt vom 
HErsteller was dazu führt das niemand es selbst schreiben muss...

Hier im Forum hat AVR die größere Verbreitung, wobei man bei genauem 
LEsen der Threads dann sieht das es zwar für die Masse gilt, bei der 
"Klasse" sich die Auskünfte zu beiden Architekturen aber nicht 
unterscheiden.
Ganz ohne Englischfähigkeiten geht es bei der µC Programmierung aber 
auch mit AVR  nicht, zumindest nicht wenn man mal über die Blinkenden 
Lichter hinausgehen will.

GANZ WICHTIG ABER:
Bevor du dich dann endgültig entscheidest, mache dir die Mühe und schaue 
dir mal die Herstellerwebseiten was da an Informationen und Beispielen 
geboten wird. Lade dir ein paar Datenblätter und APP Notes herunter. 
Schaue ob du mit der Schreibweise zurecht kommst und dir der Stil 
zusagt. Auch wenn dir das als Anfäner nicht wichtig erscheint, später 
wird das immer wichtiger. Und prüfe auch die Verfügbarkeit für dich, 
sowohl in kleinen Stückzahlen wie auch auf kurze Leiferzeit. (Wobei das 
bei vorhandemen Gewerbeschein mittlerweile für fast keine Architektur 
mehr ein Problem darstellt -solange Atmel sich nicht wieder mal 
verkalkuliert und sechs Monate Lieferzeit ausruft)

Ach ja:
Jobst M. schrieb:
> Preislich nehmen sich ARM, AVR, PIC, MSP430 und 8051 nicht viel. Da von
> Hubschraubern zu sprechen, finde ich unangemessen, auch wenn der ARM mit
> der Aufgabe hoffnungslos unterfordert ist - die anderen sind es auch!
Ich denke hier ging es weniger um den Preis, zumindest für 
Kleinststückzahlen oder Hobby spielt es keine Rolle ob ich 1,50 für 
einen CortexM0 oder 80ct. für einen kleinen PIC bezahle um mal die 
untere Größe zu nennen...

ICh vermute eher das es hier um den Programmieraufwand ging. Und der 
"Overhead" an Einstellungen usw. ist bei den 32Bittern deutlich größer 
als bei den 8Bittern. Für einen Einsteiger halt nicht so leicht zu 
durchschauen.

> Für das von Dir geschilderte Problem würde ich einen ATmega48 benutzen.
> Der hat einen ADC und eine Hardware UART. Und ich würde es in ASM lösen.
> Ich denke, auch in ASM ist das mit <40 Zeilen Code realisierbar.
AVR kann man nehmen, ich würde halt aufgrund meiner Präferenz eher einen 
PIC vorschlagen. Typen ohne ADC oder UART muss man bei beiden Familien 
ja mittlerweile mit der Lupe suchen.

> PIC scheidet für mich aus, da ich mich damit nicht auskenne. (Ich habe
> damals die Finger davon gelassen, als ich die 'krummen' Registergrößen
> gesehen habe.)
Hier muss ich deinem Beitrag - dem ich ansonsten bis auf den Vorschlag 
ATMEGA voll zustimme- aber wiedersprechen. Krumme Registergrößen bei 
PIC?
Das stimmt nicht so ganz, Je nach Familie hat der ganz normal 8, 16 oder 
32Bit Register. Da hst du damals wohl einfach die Registergröße mit der 
Befehlswortbreite verwechselt. Die ist ja recht krumm!
Allerdings hat der Anwender DAMIT nun wirklich absolut nichts zu tun!
Das ist nur ein Architektonisches Detail...

Gruß
Carsten

Markus schrieb:
> A. B. schrieb:
>> soll ja jeder machen wie er möchte, aber wer ungezwungen projekte mit
>> mehr als ner DIN A4 seite quelltext in assembler schreibt, neigt wohl zu
>> masochismus. und das bedeutet nicht im umkehrschluss, das man keine
>> ahnung von der hardware haben muss/soll/braucht.
>
> Aber dazu meine Meinung. C Sprache ist sehr viel Computer und sehr wenig
> E-Technik.
>
> Wenn ich mir die Tutorials für C anschaue, sehe ich erstmal nur
> ausführbare Windows Programme.

ein uC spezifisches tutorial sollte man sich natürlich schon anschauen

Markus schrieb:
> Ist es tatsächlich ein Unterschied ob ich 8 bit oder 32
> bit programmiere für mein Projekt oben?

Der Unterschied liegt im Einarbeitungsaufwand.
Ein 8Bitter läuft einfach los. Beim 32Bitter mußt Du erstmal die PLL und 
die ganze Takterzeugung usw. programmieren.

Beim 8Bitter gibst Du einfach nen Interrupt frei und schreibst den 
Handler an die festgelegte Einsprungadresse. Beim Einsprung löscht sich 
das Interruptflag automatisch.

Beim 32Bitter ist die Interruptlogik fast ein eigenständiger Prozessor, 
bei dem es ne Menge zu programmieren gibt. Und auch die Handler müssen 
viele Sachen in einer ganz bestimmten Reihenfolge machen, damit Du 
wieder sauber den nächsten Interrupt kriegst.

Und bei der sonstigen Peripherie sind ähnliche Unterschiede im 
Programmieraufwand.

Beim 32Bitter hast Du also schon einige kB Initcode bevor das Programm 
richtig läuft.


Peter

Hi,

spess53 schrieb:
>>Ist es tatsächlich ein Unterschied ob ich 8 bit oder 32
>>bit programmiere für mein Projekt oben?
>
> Nein. Bei deinem Projekt langweilt sich der Controller zu Tode. Das
> könnte man sogar mit einem 4-Bit-Controller erschlagen.

Also ich würde eher ein ganz klares JAIN zum besten geben.

Oder Ausführlich:
NEIN:
Von Kapazität her spielt es an sich keine Rolle.
Jeder halbwegs aktuelle µC mit 8 Bit wird sich wie geschrieben mit 
großer Wahrscheinlichkeit einfach nur fürchterlich Langweilen.
Und der 32Bit µC langweilt sich dann noch ein ganzes Eckchen mehr.

(Den 4Bit Controller und alte 8Bit µC würde ich so nicht 1-1 stehen 
lassen wollen da sich das zwar grundsätzlich realisieren lässt, diese 
alten Controller in der Regel aber noch kein On-Board UART haben und das 
deshalb alles in SW gemacht werden müsste, mit größerem Aufwand. Bei den 
4Bittern würde dann noch dazu kommen das zum Übetragen eines UART Datums 
gleich zwei Registerinhalte abgefragt werden müsste. -> Ist aber 
Korintenkackerei)

JA: Von der Schwierigkeit für einen Anfänger ist es schon ein 
Unterschied.
Die 32Bit µC, egal ob MIPS(wie PIC32) oder ARM sind ein ganzes Stück 
mächtiger als die hier genannten 8Bit µC (Pic, AVR).

Unter anderem gibt es in fast jeder hinsicht deutlich mehr 
Konfigrationsmöglichkeiten - Die dann aber auch ersteinmal alle 
abgearbeitet sein wollen! Auch bei den Direktzugriffen auf die Ports 
gibt es Unterschiede.
Für einen Anfänger der es wirklich von der Pieke auf lernen will - was 
meiner Ansicht nach zwar die ersten Tage etwas steiniger ist als mit 
dingen wie BASIC anzufangen- ist der direkteinstieg mit 32Bit einfach 
ein wenig mächtig.
Wenn es einem ausreicht einfach nur Copy&Paste zu machen und nur 90% des 
Programmcodes aus den Beispielprogrammen herauskopieren will ohne zu 
verstehen was das überhaupt ist, dann geht natürlich auch 32Bit direkt.

Allerdings führt NUR der erste Weg dazu das man dann auch flexibel ist 
und Projekte verwirklichen kann für die es keine Lib gibt und das man 
dann auch mal bei Bedarf einen µC aus einer anderen Familie einsetzen 
kann und nicht auf ewig nur an eine Familie gebunden ist.

Diejenigen die dann lauthals verkünden das der "steinigere" Weg ja 
blödsinn ist und man doch direkt mit BASIC oder "Arduino-C" anfangen 
sollte weil das schnelle Resultate bringt, das sind dann auch die Leute 
die hier regelmäßig auftauschen und schon Probleme bekommen wenn der µC 
bei selben Quarz dann statt 80Mhz nur mit 20Mhz läuft, oder die 
wochenlang herumdoktern weil das Programm einfach so langsam läuft ohne 
zu merken das in den Fusebits die PLL deaktiviert ist. Und so groß sind 
die ZEitunterschiede wirklich nicht. Lass es vielleicht 5 oder sechs 
lange NAchmittage für ein Grundlegendes Verständniss der HArdware von 
gängigen µC PLUS beherrschen der ASM Grundlagen sein, - Der Basic bzw. 
Arduino Nutzer hat dann zwar schon vier Tage seine LCDs am Leuchten, 
aber bei jeder Anforderung die nur ein wenig über Schema F hinausgeht 
wird er wieder ewig ins schleudern kommen...

Für reines Hobby mag die zweite Alternative ausreichen, für jede etwas 
anspruchsvolle (berufliche) Tätigkeit aber sicher nicht.

Gruß
Carsten

P.S.: eine Ergänzung noch zum Unterschied, unter dem Aspekt des 
Anwendungszwecks "Steuerung" vielleicht nicht ganz unwichtig:
Bei den üblichen 8Bit µC kann man GENAU das Zeitverhalten anhand des ASM 
Quellcodes (Entweder direkt selbst geschrieben oder halt die Ausgabe des 
C Compilers) vorhersagen und auch "Einstellen".
Bei den hier genannten 32Bit µC (ARM & MIPS) ist das nur recht 
eingeschränkt möglich da für viele Befehle die Ausführungszeit nicht 
exakt vorhersehbar ist und von äusseren Einflüssen abhängen kann. 
NAtürlich gibt es dann eine Menge anderer Wege ein halbwegs exaktes 
Zeitverhalten herzustellen, aber dazu muss man dann wieder die 
Grundlagen kennen.

da sich dieses Forum/Tutorial eigentlich hauptsächlich mit AVRs 
beschäftigt wurde es sich anbieten einen AVR zu nehmen.

Ich würde auf jedenfall mit Assembler anfangen dadurch lernst du die 
Hardware viel besser lernen. Später kannst du immer noch C lernen 
umgekehrt würde ich sagen fehlt einem die Grundlage wenn man gleich mit 
C anfängt.

Ich finde es immer wieder lustig wenn jemand schreibst der 2 kb Flash 
und seine 512 Byte RAM sind zu gering, für ein Programm das in Assembler 
nur 1/8 so groß ausfällt. Man muss sich hier sehr genau drum Kümmern ob 
z.b. eine Variable mit dem Wert 64 = 1 Byte nicht als Double Word 4 
Bytes verarbeitet wird und auch entsprechend Platz reserviert wird.

Peter Dannegger schrieb:
> Markus schrieb:
>> Ist es tatsächlich ein Unterschied ob ich 8 bit oder 32
>> bit programmiere für mein Projekt oben?
>
> Der Unterschied liegt im Einarbeitungsaufwand.
> Ein 8Bitter läuft einfach los. Beim 32Bitter mußt Du erstmal die PLL und
> die ganze Takterzeugung usw. programmieren.

Das kommt sehr stark auf die IDE an. Bei Crossworks z.B. wählt man 
einfach nur den µC aus und das Projekt lässt sich direkt compilieren und 
läuft, ohne das man irgendwas spezifisches einstellen müsste.

Mit freeware wie Eclipse ist das ganze natürlich deutlich komplizierter.


Trotzdem würde ich auch jedem erstmal einen ATMega empfehlen. Einfach 
weil z.B. die Komplexität der Funktionen deutlich geringer ist. Es gibt 
deutlich weniger Konfigurationsmöglichkeiten was die Fehlermöglichkeit 
stark verringert.

Sebastian H. schrieb:
> Bei Crossworks z.B. wählt man
> einfach nur den µC aus und das Projekt lässt sich direkt compilieren und
> läuft, ohne das man irgendwas spezifisches einstellen müsste.

Klar kann man das auch alles vor dem Anwender verstecken.  Allerdings
ist das dann alles erstmal wieder eine "Blackbox", eigentlich nicht
viel mehr als Bascom für BASIC-Hasser. ;-)  Mit "wissen, was wirklich
passiert" hat es jedenfalls nicht mehr viel zu tun.

Gut gut, auch ein ARM läuft natürlich erstmal irgendwie und mit
irgendeinem Takt los, ohne dass man die PLL anfasst.  Trotzdem ist
die Komplexität größer.  Sowas wie der vorgeschlagene ATmega48 (oder
ein beliebigens Pendant eines anderen Herstellers) sind da doch
deutlich überschaubarer.

16 ist mehr schrieb:
> Schon dieser FUSE
> Kram zur Konfiguration ist nicht mehr zeitgemäß.

Muss man allerdings eben auch gar nicht anfassen, um damit einfach
nur arbeiten zu können.  Das Argument der Fuses hält sich einfach
nur hartnäckig, weil es sonst nicht viele Argumente gegen einen AVR
(für ein Projekt dieser Dimension) gibt. ;-)

Ich persönlich würde übrigens so ein Projekt allemal in C anfangen,
allerdings bin ich notgedrungen voreingenommen, da ich C seit mehr
als 20 Jahren benutze.  Den Assemblercode seines Controllers sollte
man sehr wohl verstehen (insofern gehe ich mit all denen, die den
Assembler wegen des exakten Verständnisses für die Hardware hier
empfehlen, mit), aber es ist dann doch noch ein großer Unterschied
dazu, auch selbst ein entsprechendes Assemblerprogramm schreiben
zu können.

Markus schrieb:
> Es gibt sicher einfache Möglichkeiten, sich abrufbare Funktionen zu
> programmieren?

Ja.

> Einen Baustein, welchen man mit einer einfachen
> Call-Anweisung ablaufen lassen kann?

Ja.

> Wie schaut eine einfache bedingte Verzweigung im Assembler aus?
> Beispiel. Ist PINB1 = 1 dann springe zu Funktion SendeBusStufe1. Ist
> PINB 0 0, überspringe die CALL Funktion und checke PINB2

1

;SBIC – Skip if Bit in I/O Register is Cleared

2

;Es wird der nächste Befehl übersprungen, wenn geprüftes Bit 0 ist.

3

4

SBIC PINB, 1

5

CALL SendeBusStufe1 ; es kann auch RCALL verwendet werden

6

SBIC PINB, 2

Gruß

Jobst

Benutze das nächste mal die [ avrasm ]Hier Code[ /avrasm ] - Tags (ohne 
Leerzeichen)

Wieso definierst Du für den Stack ein eigenes Register?
temp reicht dafür.

> LDI R18, PINC

wieso benutzt Du temp nicht?


> lds temp, UCSR0B;
> sbr temp, (1<<TXEN0);
> sts UCSR0B, temp;

Du brauchst kein Semikolon am Ende der Zeile.

Setze UCSR0B einfach so, wie Du es haben möchtest.

Allerdings würde ich die serielle Schnittstelle nur einmal am 
Programmanfang initialisieren.


Am Ende Deiner 'loop:' (welche keine ist - wird die Sprungmarke irgendwo 
benötigt?) Wartest Du nicht mehr darauf, daß das Byte abgeschickt wurde. 
Solltest Du aber, denn das Programm ist oben wieder dabei das nächste 
Byte zu verschicken, obwohl das untere noch gar nicht weg ist.


Viel wichtiger finde ich allerdings, daß Du hier mal genau beschreibst, 
was das Programm wirklich tun soll.


Gruß

Jobst

Markus schrieb:
> .def temp = R18
> :
> LDI R16, 0xFF;
> OUT DDRB, temp;

Ach ja: Das hier geht im übrigen in die Hose.


Gruß

Jobst

Ralph schrieb:
> Jobst M. schrieb:
>> Denn auch wenn man C lernt, empfiehlt es sich mit ASM den Controller
>> erst mal kennen zu lernen.
>
> 1.  geht das auch in C ganz gut.

Die zusätzliche Schicht, die C hier drüber legt, macht die Sache nicht 
leichter, sondern oft schwieriger. Und es geht gar nicht so sehr um die 
Sprache C an sich, sondern vor allem um Eigenheiten des Compilers oder 
der Standardlibrary.

Beispiel: Interrupthandler. Das Datenblatt beschreibt z.B. eine Tabelle 
mit Adreßzeigern oder JMP-Instruktionen und nennt die Adresse für jeden 
einzelnen Interrupt. In Assembler liegt genau eine ORG Anweisung 
zwischen dem Lesen des Datenblatts und der erfolgreichen Anwendung.

Wenn man das gleiche in C machen will, muß man sich im Extremfall damit 
herumschlagen, wie man Code auf feste Adressen bindet und dem Compiler 
bestimmte Funktions-Prologe und Epiloge vorschreibt. Wenn man Erfahrung 
mit "C für Controller" hat, sucht man vielleicht gleich zielgerichtet 
nach dem C-Makro, mit dem man eine Funktion als ISR deklariert.

Ganz davon zu schweigen, daß sich Makros und Namen für Interrupts über 
die Grenzen von Toolchains (und Targets) typischerweise auch noch 
unterscheiden. Vorteil durch Verwendung von C: Null.


> 2.  wie tief willst du da in den µC einsteigen ?

Normal will man nur so tief einsteigen, daß man die zu verwendende 
Peripherie gebacken kriegt. Das ist in C genau gar nicht besser als in 
Assembler.

> Mann muss in C gar nicht wissen wie eine Multiplikation einer 32 bit mit
> einer 64 bit Zahl auf einem 8 bit µC gemacht wird.

Das hat so gut wie gar nichts mit dem µC zu tun. ALUs haben sich seit 
dem 6502 nur sehr geringfügig weiterentwickelt. Praktisch gar nicht, 
wenn man von der Wortbreite absieht [1].

Die Implementierung von Arithmetik mit einer größeren Breite als der 
ALU-Breite ist Grundwissen. Und auch wenn nicht jeder Programmierer 
solchen Code selber schreibt, so sollten ihm zumindest die Implikationen 
bezüglich Speicherbedarf und Laufzeit vertraut sein.


XL

[1] Ja, OK. Es gibt heutzutage Barrel-Shifter und 
Hardware-Multiplikation. An der Außenansicht der ALU hat das wenig bis 
nichts geändert.

So.

Der kleine Quellcode hat 58 Zeilen bei 1209Byte und erzeugt 230Byte 
Code.

Der große Quellcode (mit Kommentaren etc.) hat doppelte Zeilenzahl und 
die dreifache Größe. Erzeugt den selben Code.

Ist ungetestet. Wenn Du etwas davon sehen möchtest, sag bescheid.


Gruß

Jobst

A. B. schrieb:
> sorry, aber wem erscheint denn bitte assembler auf den ersten blick
> logischer & einfacher als eine hochsprache?!

Jedem, der mal eine Hochsprachen-Spezifikation komplett durchgelesen hat 
;-)

ich sehe die Vorteile des Assemblers darin das ich genau weiß was 
passiert, wie lange das dauert, wieviel RAM dafür gebraucht wird... 
Außerdem kann ich einige Sachen ganz gezielt beeinflussen z.B. 
Programmcounter, Stackpointer, Stack.

Bei C ist man da seinem Compiler und dessen Optimierungen ausgeliefert 
und kann das nie 100%tig sagen. Es sei den man deassembliert das 
Compilerergebnis, aber dann kann ich gleich mit Assembler arbeiten.

Vorteile sehe ich bei einer Hochsprache bei größeren Berechnungen

Thomas O. schrieb:
> seinem Compiler und dessen Optimierungen ausgeliefert

Klingt ja gerade so als ob der Compiler an allen Ecken und Enden totalen 
Unfug erzeugen würde.
Bei sauberer Programmierung gehen die Fälle in denen es Zweifel gibt 
doch auf ein Minimum zurück (extrem zeitkritische Geschichten, bei denen 
es auf jeden CPU-Takt ankommt, jetzt mal außen vor - da mag man mit ASM 
und genauer Kenntnis der genutzten Befehle und somit CPU-Zyklen besser 
dran sein).

Vielleicht noch ein Hinweis. Bin mit Studio 6 nicht vertraut (Assembler 
mache ich in Studio 4 und die meisten C Sachen auch), aber der 
eingebaute Simulator ist gerade in Assembler sehr hilfreich. Er hat zwar 
seine Macken (vllt. in Studio 6 nicht mehr?), aber der direkte Blick auf 
Ports, MCU und all das andere Gedödel kann gerade am Anfang sehr 
hilfreich sein. Im Hintergrund das Datenblatt offenhalten, um da 
nachzulesen. Ausserdem solltest du dir unbedingt das grosse PDF mit dem 
AVR Befehlssatz runterladen und griffbereit haben, um das Verhalten von 
Flags, arithmetischen Operationen usw. zu beobachten.
C ist für komplexere Sachen einfach übersichtlicher. Ich habe zwar auch 
mal ein DMX Pult in Assembler gemacht, aber das würde ich heute nicht 
mehr tun. Da die heutigen Compiler recht gut optimieren und der 
Flashspeicher der Chips immer grösser wird, ist Platzbedarf auch nicht 
mehr so unbedingt das Argument.

ich würde mal behaupten, das jeder heutige compiler besser optimiert als 
95% der standard-user hier und im allgemeinen...aber vielleicht hab ich 
auch zu wenig ahnung oder bediene meinen compiler einfach nur richtig.

hier wird ja so getan, als ob man da ständig hinterher sein müsste und 
der compiler nach dem zufallsprinzip irgendwelche compilate ausspucken 
deren zeitverhalten, flashverbrauch & ramvebrrauch beliebig gewürfelt 
werden

> ich sehe die Vorteile des Assemblers darin das ich genau weiß was
> passiert, wie lange das dauert, wieviel RAM dafür gebraucht wird...
> Außerdem kann ich einige Sachen ganz gezielt beeinflussen z.B.
> Programmcounter, Stackpointer, Stack.

klaro...beim 08/15 programm muss ich auch dauernd am stack & 
programmcountern rumfummeln.

evtl. hilft es, sich mal den quelltext eines RTOS anzuschauen...da sind 
gewisse teile (eben stackfummelei etc.) in asm geschrieben aber der 
grosse rest doch in C. also irgendwo wird sich ne hochsprache schon 
bewährt haben...

auch in der automobil industrie z.b. wo die programmierung sicherlich 
wesentlich sicherheitskritischer als bei irgendwelchen led-blinkern, 
heizungs&temperaturreglern etc. wird C eingesetzt(wenn auch nach 
besonderen standards ala MISRA usw.)
aber klar...man programmiert grössere projekte lieber in ASM wie schon 
1960

egbert schrieb:

> "C" ist immer dann das Mittel der Wahl, wenn das Ergebnis der
> Programmausführung bzw. dessen Funktion vollkommen egal ist.

Oje, da hat jemand mal ne gründliche Bauchlandung gemach, weil er zu 
faul war, die Sprache zu lernen und einfach nur rumgeclickt und 
rumprobiert hat.

Ging mir neulich genauso mit nem Flugzeug:

Eingestiegen, paar Knöpfchen gedrückt und Hebelchen umgelegt. Hat schön 
geblinkt und gebrummt aber das Resultat war komplett zufällig.

Scheiss Flugzeug.

Wenn du dir mit dem Hammer ständig auf die Finger schlägst, dann ist 
nicht der Hammer schuld.

Also lern erst mal worum es geht oder, anstatt bei jeder sich bietenden 
Gelegenheit dein unqualifiziertes "C = Zufall" loszulassen.

A. B. schrieb:
> ich würde mal behaupten, das jeder heutige compiler besser optimiert als
> 95% der standard-user hier und im allgemeinen

Ich hab etwa 10 Jahre 8051 Assembler gemacht, bin da also ziemlich fit.
Und dann habe ich ein C-Projekt übernehmen müssen.
Ich erzähl jetzt nicht die ganze Story, aber Fazit:
- C braucht etwa 5..20% mehr Flash
- C ist oft sogar schneller in der Ausführung
- C ist erheblich schneller beim Programm schreiben
- C ist wartbar und erweiterbar (Assembler überhaupt nicht)
- C ist portabel (Routinen von 8051 nach AVR sind ruckzuck portiert).

Insbesondere die Zeiteinsparung ist enorm. Wärend Villarriba (Assembler) 
noch Geschirr spült, feiert Villabacho (C) schon lange.

Auch beeindruckend, man kann ein fremdes C-Projekt erweitern, ohne es 
neu schreiben zu müssen oder komplett verstanden zu haben.


Peter

Code als Anhang, sonst scrollt man sich die Finger wund.
Am besten aber nen neuen Thread, da das Thema ja nichts mehr mit "C oder 
Assembler" zu tun hat.

Niemand antwortet gerne nur für eine Person.
Daher muß das Topic zum Post passen.


Peter

egbert schrieb:
> Richtig heissen müsste es: "C" oder eine Programmiersprache?

Nein: C, Assembler, oder eine Programmiersprache?  ;-)

Markus schrieb:
> 58 Zeilen? So einfach ist das? Hm.

Wenn Du jetzt nur die 58 Zeilen sehen würdest, würdest Du vermutlich 
nichts verstehen. Dort sind selbst die Label anonymisiert ;-)


> Ne Frage nebenbei, hast du dir dein Wissen selbst beigebracht oder im
> Studium?

Autodidakt. Ist aber eigentlich doch auch Studium :-D
Ich programmiere seit 1982 - da war ich 12.


> Ich würde gern etwas sehen. Nur wo anfangen? Wie hast du deinen Code
> strukturiert? In der Main Loop nur die Wertvergleiche mit Bedingter
> Sprunganweisung auf das entsprechende Unterprogramm?

Ich verzweige nicht, ich rechne. Ich ziehe vom gewandelten Wert den Wert 
für 4mA ab. Sollte ein Überlauf dabei passieren, kann eine 
Fehlerbehandlung gemacht werden (<4mA).
Dann Teile ich den Wert so, daß 20mA genau 10 ergeben. Es sollen doch 10 
gleiche Abschnitte sein, wenn ich das richtig verstehe?
Dieses Ergebnis multipliziere ich mit 5 (5 Byte pro Datenpaket) und 
addiere das wiederum zu der Staradresse meiner Wertetabelle. In dieser 
stehen hintereinander weg die einzelnen Datenpakete. Für die möglichen 
Werte 11-15 habe ich einfach noch 5 weitere Werte in die Tabelle 
geschrieben. Die Senderoutine sendet dann ab dieser Adresse einfach fünf 
Byte.


> An der Codelänge schätze ich, du hast nur ein UART Senden unterprogramm?

Nö. Steht einmal im Mainloop.


> Wie füttest du die Variablen für die letzen Bytes ein?

Stehen alle in der Tabelle. Ich sehe hier gerade noch Sparpotential :-D


Peter Dannegger schrieb:
> Am besten aber nen neuen Thread

Dann aber hier verlinken! ;-)


Muss los!

Gruß

Jobst

Hier ist der Thread, wo die konkrete Softwareumsetzung diskutiert wird:

  Beitrag "Assemblercode Hilfestellung (Anfänger)"

Johann L. schrieb:
> egbert schrieb:
>
>> "C" ist immer dann das Mittel der Wahl, wenn das Ergebnis der
>> Programmausführung bzw. dessen Funktion vollkommen egal ist.
>
> Oje, da hat jemand mal ne gründliche Bauchlandung gemach, weil er zu
> faul war, die Sprache zu lernen und einfach nur rumgeclickt und
> rumprobiert hat.
> ...
> Wenn du dir mit dem Hammer ständig auf die Finger schlägst, dann ist
> nicht der Hammer schuld.
>
Nett und zutreffend gesagt, ABER

Johann L. schrieb:
> Also lern erst mal worum es geht oder, anstatt bei jeder sich bietenden
> Gelegenheit dein unqualifiziertes "C = Zufall" loszulassen.

Glaubst du wirklich bei jemanden der einen ARTIKEL der nun schon vor 
fast 20 Jahre in einer Computerzeitschrift als APRILSCHERZ 
veröffentlicht wurde und seit Jahren auf allen Witzseiten mit IT Bezug 
durchs Netz geistert scheinbar für bare Münze nimmt noch Lernfähigkeit 
erwarten zu können?

Der Originaltext ist im übrigen unter "C Hoax" an zahlreichen Stellen im 
Netz zu finden...

Gruß
Carsten

Na zum Glück muss man auch mit ASM nicht so besch... programmieren :) 
Aber trotzdem. Einfach mal auf Peter&Ralph hören.

Und wie gesagt...wenn man im Hobbybereich Spass an ASM hat, gerne so 
kompliziert&minimalistisch programmiert wie möglich dann spricht da ja 
nix gegen.
Aber sobald andere Menschen den Quellcode auch verstehen sollen, und 
evtl. mal ne Änderung durchführen müssen, dann ist ASM sicherlich nicht 
die zu bevorzugende Sprache

ich denke mal das es unbestritten ist das sich C leichter lesen läßt als 
ASM. Allerdings hat man bei beiden noch die Möglichkeit Bausteine zu 
kommentieren.

Der Vorteil von C ist ja wohl die Portierbarkeit also kann man leicht 
auf einen neuen µC oder Mitarbeitet umswitchen. Weitere Vorteile sehe 
ich in komplexen Berechnungen das ist in ASM dann doch etwas aufwändiger 
wenn man sehr viele Formeln zu rechnen hat.

Einen größeren µC zu nehmen halte ich für die letzte Lösung, lieber 
sollte man sich Gedanken machen, möglichst sparsam mit Ressourcen 
umzugehen, dann bräuchten wir heute auch keinen Quadcores um zu 
vertuschen das das Betriebssystem elend langsam geworden ist. Da heute 
aber fast jeder C benutzt kommen dann so Kommentar wie, da muss man halt 
den µC 2-3 Nummern größer wählen.

Du begehst 100% keinen Fehler mit ASM anzufangen und später auf C zu 
wechseln.

Thomas O. schrieb:
> Der Vorteil von C ist ja wohl die Portierbarkeit also kann man leicht
> auf einen neuen µC oder Mitarbeitet umswitchen.

Ein Vorteil von C ist auch, dass bestimmte Routineoperationen
durch den Compiler abgenommen werden, und dieser aufgrund seiner
hinterlegten Vorschriften eben in diesen keine eigenen Fehler
mehr macht.  Die logische Umsetzung eines simplen "if (x > y)"
kann im Assembler halt in sowas ausarten wie "überspringe den
nächsten Befehl nicht, wenn die Bedingung wahr ist, und benutze
als nächsten Befehl einen Sprung, weil dieser ein weiter entferntes
Ziel erreichen kann als ein Branch".  Bei einer Assemblerprogram-
mierung hat man gute Chancen, in so eine doppelte oder dreifache
Negation schnell einen Denkfehler einzubauen.

> Einen größeren µC zu nehmen halte ich für die letzte Lösung

Jein.  Du erkaufst damit u. U. einfach Wartungsfreundlichkeit und
eine effizientere (im Sinne von: schneller fertig werden) Program-
mierung.  Wenn der nächstgrößere Controller nur zwei oder drei
Euro mehr kostet, du aber stattdessen für das minimalistische
Programm statt zehn Stunden Arbeit dann fünfzig Stunden in Assembler
programmierst und debuggst, dann würde ich für ein Einzelstück
allemal dem nächstgrößeren Controller den Vorzug geben.

Wenn man für Serien von 10000+ Stück bauen muss, sieht die Sache
natürlich völlig anders aus.

A.T. schrieb:
> und damit C überhaupt erst mit MISRA zu einer sauber
> spezifizierten Programmiersprache wird.

Nein, sauber spezifiziert ist sie so auch.  MISRA verbietet nur
die Nutzung bestimmter Konstrukte, die in der Vergangenheit als
Fehlerquellen (der Programmier wohlgemerkt) bekannt geworden sind.
(Inwiefern davon vieles noch zeitgemäß ist oder nicht durch
verbesserte Warnmöglichkeiten aktueller Compiler ohnehin überflüssig,
steht auf einem anderen Blatt geschrieben.  MISRA lebt noch auf einem
mittlerweile mehr als 20 Jahre alten Standard.)

Die Alternative in Richtung Hochsprache wäre wohl stattdessen Ada,
um vergleichbare Probleme möglichst von vornherein zu vermeiden.

Thomas O. schrieb:

> Einen größeren µC zu nehmen halte ich für die letzte Lösung, lieber
> sollte man sich Gedanken machen, möglichst sparsam mit Ressourcen
> umzugehen, dann bräuchten wir heute auch keinen Quadcores um zu
> vertuschen das das Betriebssystem elend langsam geworden ist. Da heute
> aber fast jeder C benutzt kommen dann so Kommentar wie, da muss man halt
> den µC 2-3 Nummern größer wählen.

nur leider wird dabei oft unter den teppich gekehrt, das heutige 
betriebssysteme um einiges mehr bieten (komfortfunktionen)
das sowas leistung schluckt ist ja normal. selbst das achso effiziente 
linux macht heute auf nem x486 auch keinen spass mehr(bzw es läuft da 
nicht mal mehr unbedingt).