mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Was unterscheidet PIC-Controller von 8051 und anderen?


Autor: Der alles gut macht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

in absehbarer Zeit werde ich wohl beginnen, mich mit der Programmierung 
von µC's zu beschäftigen. Ich habe schon viel über die verschiedenen 
Typen gelesen und es ist demnach nicht einfach, eine Entscheidung zu 
treffen, mit welcher Sorte µC man am besten beginnt. Meine 
grundsätzliche Frage ist, wo der wesentliche Unterschied zwischen µC's 
der PIC-Familie und µC's z.B. der 8051er-Reihe besteht, bzw. was ist das 
besondere am PIC was andere nicht können? Wann sollte man lieber einen 
PIC benutzen oder wann ist ein PIC fehl am Platz? Vielen Dank!

PS: Mit Antworten wie "Der PIC hat eine andere Architektur" ist mir 
nicht geholfen, bitte dann schon etwas genauer.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Der alles gut macht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke, das zeigt schon mal ein paar unterschiedliche "Verhaltensweisen" 
der einzelnen Modelle. Allerdings ist hier von empfohlenen 
Einsatzbereichen nicht die Rede.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist an sich ziemlich egal, mit was du anfängst. Im Grunde und von der 
Idee her sind sich die Dinger alle ähnlich.
Nur solltest du dich nicht auf diese Anfängerhardware (oder 
Anfangshardware) fixieren. Besser ist es, immer über den Tellerrand zu 
sehen, und den für die Aufgabe passenden uC zu verwenden. Ich habe 
z.B. zwischenzeitlich angefangen vom 8048 übder die 8051++, 68332&Co, 
AVR, ST10, MSP430, RC08 und C167 auch eine (allerdings recht kurze) 
PIC-Episode. Das schlechteste was dir passieren kann, ist, dass du 
sagst: Ausser PIC (oder AVR...) ist alles Schrott.

Ungeachtet dieser Argumente empfehle ich dir zum Einstieg die 
AVR-Architektur. Das (abgesehen davon, dass die Architektur recht gut 
gelungen ist) aus dem einfachen Grund, weil du hier am ehesten Hilfe 
finden wirst.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der alles gut macht schrieb:

> treffen, mit welcher Sorte µC man am besten beginnt.

Steig nicht zu hoch ein. Die Komplexität eines gern für Anfänger 
empfohlenen ATmega8 ist überschaubar und das Manual auch 
einsteigertauglich. Aktuelle 32-Bitter sind zwar viel leistungsfähiger 
und nicht mehr so viel teurer, aber sehr viel komplexer und die Manuals 
setzen viel vorhandenes Grundverständnis voraus.

Autor: Carlos (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von der Flexibilität und von Funktionsumfang her ist die 8051er-Famile 
sicherlich den anderen Familien weit voraus (das gibt wieder 
Diskussionen im Forum), denn weltweit gibt es bei keiner Familie so 
viele internationale Hersteller, die die unterschiedlichsten 
8051er-Derivate im Programm haben.
AVR und PIC werden nun mal immer nur von einem einzigen Hersteller 
hergestellt, wobei z.B. Atmel neben den AVRs auch noch jede Menge 8051er 
herstellen.
Aber die Diskussion, welche µC-Familie die beste ist, ist sowieso sehr 
müßig, denn fast alle Probleme kann man mit jeder Familie lösen.

Zum Thema 8051er gibt es ebenfalls reichlich Infos in Netz, nur ist 
diese leistungsfähige Familie mittlerweile weltweiter Industrie-Standard 
geworden und wird daher im "Hobby-Bereich" von der Herstellern gar nicht 
mehr beworben (die sind mit ihren Industrie-Anwendungen bestens 
ausgelastet), wohl aber weiter entwickelt, s. z.B. Texas Instrumnent, 
Atmel, infineon , Maxim-Dallas, Cypress, Philips (NXP), etc.

Schade eigentlich, daß die 8051er in diesem Forum so wenig "Freunde" 
haben, denn eine Beschäftigung damit lohnt sich auf jeden Fall.

Carlos

Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch ich habe reichlich (>25 Jahre) Erfahrung mit diversen
µCs. Angefangen vom 1802, Z80, 8051-Family, einige 4-Bitter
(Mircro-Electronic-Marin), eine kurze PIC-Periode (glücklicherweise zu 
Ende) und die AVRs.

Derzeit setze ich 8051-Familiy sowie AVRs ein, jedoch Projektbezogen.
Mal ist die eine, dann wieder die andere Reihe günstiger.

Wie schon gesagt die 8051 gibt es von vielen Herstellern, da kann
man einfacher ausweichen.

Wenn Du einsteigen willst halte ich die AVRs oder die 8051-
Family für einfacher weil beide logischer aufgebaut sind.

Bei den Pics (vor ein paar Jahren) hatte ich den Eindruck, daß
man einfach per "Bankswitching" z.B. Programmspeicher hinzufügt hat,
das macht dann (bei ASM-Prog) wenig Freude und ist Fehlerträchtig.

Die Speicher bei den 8051 und den AVRs sind einfach linear fortlaufend.

Für die 8051-Family empfehle ich z.B: einen Starterkit für den ADUC832
von Analog-Devices, da ist auch recht gute Software dabei.

Für die AVRs kann ich nur den STK500 wärmstens empfehlen.

Ein schönes Wochenende

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anton schrieb:
> Wenn Du einsteigen willst halte ich die AVRs oder die 8051-
> Family für einfacher weil beide logischer aufgebaut sind.
Die 8051 Architektur ist zwar einfach zu verstehen, aber aus heutiger 
Sicht absolut veraltet. Nur 1 Register (Accumulator) um wichtige 
Berechnungen durchzuführen? Das muß nicht sein...

> Bei den Pics (vor ein paar Jahren) hatte ich den Eindruck
Bei den ersten PICs hatte ich den Eindruck, dass da mal schnell noch vor 
der Konkurrenz was auf den Markt musste...
Und über solche heiß gestrickten Sachen stolpert man dann andauernd.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der alles gut macht schrieb:
> was ist das
> besondere am PIC was andere nicht können?

Da gibt es nichts.
Man kann alles auch mit anderen MCs machen.
Ich benutze keine PICs, sie sind mir zu kompliziert.


> wann ist ein PIC fehl am Platz?

Immer.
Das ist aber nur meine persönlichen Meinung, die will ich niemanden 
aufdrängen.
Anders gesagt, es ist Geschmackssache, kann jeder halten, wie er will.


Peter

Autor: Michelle Konzack (Firma: electronica@tdnet) (michellekonzack) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe 1982 mit dem 8038/39/49 angefangen und nin dann zu 8051/52 
gekommen.  Eine Weile Z8000 (Z80, 8bit) und Z8400 (16bit) verwendet owie 
eineige DSP's von Motorola.

Mittlerweile setze ich nur noch 8051 (SiLAbs, Maxim, TI, Cypress, Atmel 
und NXP) sowie ARM7 (Atmel) und ARM9 (Armel, NXP, Freescale) ein.

Wenn ich richtige Killer benötige sind es ARM1176JZF-S von Marvel.

Denke, es bringt einfach nichts, noch mehr verschieden Architekturen zu 
verwenden, denn dann kommen noch die probleme mit den verschiedenen 
Developer-Tools, den Flashern und weis der Geier was...

Vor allem achte ich 100% darauf, das ich ALLES unter GNU/Linux oder 
Free/Net/Open-BSD programmieren und verwenden kann um zukunftssicher zu 
sein.

Grüße
Michelle

Autor: avr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man privat einsteigen will ist es wichtig sich über
Bezugsquellen gedanken zu machen.

Einige µC haben zwar tolle Features sind aber nicht oder
schwer erhältlich.

Die Entwicklungsumgebung sollte bezahlbar sein.

Ein Suport (evtl. auch ein Forum wie dieses) sollte gegeben
sein.

Zum µC selber sollte er am Anfang nicht zu viel können, aber
aus einer Familie kommen die breit gefächert ist und mit
den selben Tools arbeitet.

Wenn man mal in der Materie drin ist bzw. einige µC kennt
sucht man sich diese dann nach Anwendung aus.

Eigene Erfahrungen mit 65xx, 68xxx, ST6, PIC16, 8051 und Co,
und (heute meist verwendet) Atmel.
Hautgrund für Atmel war ursprünglich Flash und C-Compieler
(damals bei PIC noch OTP und das Paging).

Aber heute geht PIC, Atmel, 8051, und die Motorola.

avr

Autor: Der alles gut macht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das sind doch mal klare Worte! Hätte gar nicht gedacht, doch so viele 
brauchbare Antworten zu bekommen. Jetzt bin ich noch auf der Suche nach 
einer (evtl. zukunftstauglichen) bezahlbaren Entwicklungsumgebung. Bin 
bei Conrad auf folgende gestoßen: MYAVR BOARD MK3/64MB AVR 
ENTWICKL.BOARD (ATMega 2560) mit der Art.-Nr. 191242 - 62. Das board hat 
ja schon so ziemlich alles, womit man in Kontakt kommen könnte. Für mich 
sind jedenfalls das Display (zumindest in ferner Zukunft) und die 
A/D-Wandler interessant. Außerdem ist es über USB programmierbar, mein 
Laptop hat leider keine serielle Schnittstelle mehr. Frage an die 
Experten hier: Was ist von diesem Board zu halten? Hat damit schon 
jemand (positive/negative) Erfahrungen gemacht oder sollte man besser 
etwas anderes nehmen?

Autor: Master Snowman (snowman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ob PIC oder AVR ist glaubenssache. vieles hat sich bei beiden familien 
geändert - nur die wahrnehmung gewisser leute nicht ;-)
da sich einige erlauben zu sagen, dass PICs ungeeignet sind und AVR 
alles, so erlaube ich hier auch meine meinung kund zu tun: die PIC16Fxx 
sind echt kacke, aber von denen sprechen nur die, die PICs hassen. ich 
habe mit PICs angefangen und habe anschliessend AVRs probiert, bin aber 
wieder zurück zu den PICs. der grund: MPLAB und C18 (beides gratis) sind 
einfach einfacher zu bedienen! :-) und code-beispiele muss man nicht im 
internet suchen sondern einfach im installationsverzeichnis nachschlagen 
:-)

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei mir hing das von der programmiersprache ab. ich programmiere sowas 
sehr gerne in assembler - in der schule hat man uns leider turbo-pascal 
beizubringen versucht anstelle von C++ - was dazu führt, daß ich C/C++ 
heute noch nicht kann.

die ersten µCs die ich gesehen habe waren PICs. ein sehr interessantes 
teil auf irgendeinem teilespender, und was das alles kann... klasse! 
also her mit zwei PIC16F877. dann assembler und - ach du k**k - nur ein 
register R0! in der folge kam der erste der 16F877 nicht über ein paar 
flashes und blinkende LEDs hinaus und der zweite liegt heute noch 
werksneu in der bastelkiste.

besser finde ich die AVRs, die haben einen kompletten registersatz und 
lassen sich in assembler wesentlich besser programmieren. bei denen bin 
ich also hängengeblieben. im grunde können beide familien das gleiche, 
die AVRs empfand ich aber als einfacher zu handhaben. ist dieselbe frage 
die sich ein pc-distributor stellen muß - schwIntel oder Advanced 
MegaDreck...

Autor: Wolfgang Bengfort (et-tutorials) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Für Einsteiger biete ich zur Zeit auf 
http://et-tutorials.de/mikrocontroller/ einen Anfängerkurs an.

Dieser Kurs ist wirklich für Anfänger gedacht. Für die meisten Leser in 
diesem Forum sicher eine Nummer zu niedrig angesetzt. Für Einsteiger 
aber sicher interessant.

Autor: skorpionx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kein Assembler. Nur C-Sprache. Über die Notwendigkeit in Assembler zu 
programmieren schreiben hier meistens nur die, die sich mit AVR 
beschäftigen. Die Ursache ist die Knappheit an Programmspeicher. Mein 
PIC18F258 kann viel und mit 32 K Programmspeicher wird ohne Probleme mit 
„C“ programmiert

Autor: gtf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
skorpionx schrieb:
> Kein Assembler. Nur C-Sprache. Über die Notwendigkeit in Assembler zu
> programmieren schreiben hier meistens nur die, die sich mit AVR
> beschäftigen. Die Ursache ist die Knappheit an Programmspeicher. Mein
> PIC18F258 kann viel und mit 32 K Programmspeicher wird ohne Probleme mit
> „C“ programmiert

Nöö nicht unbedingt. Ein Atmega32 hat genau soviel wie dein PIC.
ASM ist vor allem dann gut, wenn man den µController möglichst 
Hardwarenahe kennen lernen möchte. Außerdem programmiere ich in ASM weil 
man damit wesentlich schnellere Codes basteln kann, dabei kommen nicht 
selten Tabellen ins spiel, und diese sind alles andere als Platz 
sparend.

@ Der alles gut macht

Ich würde dir auch C++ empfehlen, weil’s recht gute und kostenlose 
Compiler gibt.
Und Finger weg vom Conrad Spielzeug( MYAVR BOARD MK3/64MB), da bist du 
stark beschränkt was die AVR- Auswahl angeht. Dann lieber zwei STK 500 
und gut ist.

Autor: Ak Tronik (aktronik)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Mein PIC18F258 kann viel und mit 32 K Programmspeicher wird ohne Probleme
> mit „C“ programmiert

Hmm, was ist den an dem Ding so toll?
10MIPS sind für meine Applis mittlerweile zu langsam.

Haben die PIC18 immer noch nur ein Workregister oder Akkumulator?

Wenn ja, dann sind es eher 10MUPS (Millionen Umwege pro Sekunde ;-)

32k Programmspeicher ist zwar nicht wenig aber verglichen mit einem 
ATmega 644P mit 20MIPS kann der EEProm-Zwerg PICF258 nicht mithalten.

MfG
Ak Tronik

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der 258 (besser: 2680) hat etwas, was Atmel bei gleicher Bauform nicht 
bieten kann: CAN.

Autor: Ak Tronik (aktronik)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, da muss man bei Atmel auf den größeren AT90CAN32/64/128 
zurückgreifen.

MfG
Ak Tronik

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

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Kein Assembler. Nur C-Sprache. Über die Notwendigkeit in Assembler zu
>programmieren schreiben hier meistens nur die, die sich mit AVR
>beschäftigen. Die Ursache ist die Knappheit an Programmspeicher.

Ich weiss ja nicht, wie du dir Assemblerprogammierung vorstellst. Bei 
mir sieht das nach über 12 Jahren AVR so aus: Das angehängte File mit 
einem Programmrumpf hat z.B. ca. 10s gedauert. Kann ich für jeden AVR 
machen, für den es ein Partdescriptionfile im AVR-Studio gibt. Meine 
Mathe-Lib geht z.B.bis 64Bit incl. Fliesskomma, Wurzel, CRC, Random , 
Konvertierungen Hex, Dezimal, Binär, ASCII hin und zurück und noch 
einige andere Sachen. Desweiteren habe ich noch eigene Libs für gängige 
Text- und Grafikdisplays, Sensoren und was mir sonst noch so 
untergekommen ist. Sollte ich jetzt gegenüber C etwas vermissen?
Und das Schöne an Assembler ist, das mir kein Compiler irgendwelchen 
Code wegoptimiert, weil er meint klüger als ich zu sein.

> Mein PIC18F258 kann viel und mit 32 K Programmspeicher wird ohne Probleme
>mit „C“ programmiert

Also ich habe mal spassenhalber ein GPS mit Grafikdisplay und 
Kartenanzeige programmiert. Das Programm hatte zwar nur etwas über 4K, 
aber die Karte brauchte 64k.

MfG Spess

Autor: skorpionx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe über sehr vielen Jahren Assembler beruflich programmiert. In 
der ganzen Welt befinden sind  tausende Anlagen  in denen meine Ideen 
stecken.  Auch mit dem Assembler kann man strukturierte Programme 
schreiben.  Aber sind das immer Programme nur für DEN Prozessor. Mit 
meinen C-Routinen  kann ich bei vielen verschiedenen Prozessoren zu 
Hause sein, egal ob das PIC oder AVR ist. Darum bitte den potenzialen 
Anfänger mit dem Satz: „nur mit dem Assembler…“ nicht zu irritieren. 
Dann noch orthodoxer wäre vielleicht „mit einer Lochstanze Bietsstreifen 
zu lochen“.
„C“  ist heute für Programmierung eines Mikrocontrollers eine richtige 
Wahl.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

> Aber sind das immer Programme nur für DEN Prozessor.

Hat keiner das Gegenteil behauptet.

>Mit meinen C-Routinen  kann ich bei vielen verschiedenen Prozessoren zu
>Hause sein, egal ob das PIC oder AVR ist.

Ein:

 TIMSK |= (1 << OCIE1A);

versteht auch ein PIC?

MfG Spess

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Ein:
>
>  TIMSK |= (1 << OCIE1A);
>
> versteht auch ein PIC?
Mit entsprechend optimierenden Compiler sicherlich (ich kenne aber 
keinen solchen).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:

>  TIMSK |= (1 << OCIE1A);
>
> versteht auch ein PIC?

Die unterste Ebene ist immer gerätespezifisch. Also beispielsweise jener 
Code, der den Pin eines 1-Wire Busses anspricht.

Aber bereits der darauf aufbauende Code des 1-Wire Protokolls ist auf 
verschiedenste Architekturen portabel realisierbar und erst recht der 
wiederum auf dem allgemeinen 1-Wire-Code aufbauende Code für einen 
DS18B20.

Darum geht es.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ergänzung:
Wenn ich ein Programm für mehrere Architekturen schreiben will, bereite 
ich das entsprechend vor (prozessorspezifische Bibliotheken). Aber wie 
oft macht man sowas?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian H. schrieb:

> ich das entsprechend vor (prozessorspezifische Bibliotheken). Aber wie
> oft macht man sowas?

Ich: oft.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Die unterste Ebene ist immer gerätespezifisch.

Also nicht kompatibel.

Ich habe doch nichts gegen C. Ich wehre mich nur gegen die Mär, das 
C-Programme auf beliebigen Plattformen laufen . Mag für PCs sogar 
zutreffen.

MfG Spess

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Mag für PCs sogar zutreffen.
Naja, das ist aber dann wieder die selbe Plattform (von der vorhandenen 
Perepherie mal abgesehen).

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Spess,

kann deine Freude über Assembler durchaus teilen aber auch ich bin vor 
Jahren auf C umgestiegen. Es ist vieles portierbar wenn auch 
Prozessorspezifische Dinge wie Timer etc. sicherlich immer wieder anders 
sind.

C ist auch nicht C... das merkt man sehr schnell wenn man zwischen 
diversen Compilern wechseln muß ABER, in Assembler ist nix kompatibel, 
in C sind es immer nur Anpassungen.

Nach über 15 Jahren ASM bin ich eigentlich nach dem mühsamen Umstieg auf 
C nie wieder nach ASM zurückgekehrt... und das heißt was, war echter ASM 
Fan.

C braucht Jahre bis man es wirklich besser beherrscht, ich hab das 
Gefühl das ich es nie ganz lerne :-) aber es geht sehr gut, zwingt dich 
in saubere Strukturen und ist heute ein Muß.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ben _ schrieb:
> in der schule hat man uns leider turbo-pascal
> beizubringen versucht anstelle von C++ - was dazu führt, daß ich C/C++
> heute noch nicht kann.

C++ ist keine erste Sprache. C++ kann man mal lernen, wenn man mal seine 
masochistischen Neigungen ausleben möchte. Aber ernsthaft, es ist nicht 
wirklich für größere Projekte geeignet. (ungefähr 2/3tel der C++ 
Projekte scheitern total)
C hab ich auch mal probiert, das vereint aber leider die Nachteile von 
Assembler und Pascal.

Was aber C und C++ brauchen sind Funktionszeiger. Die kann nicht jeder 
Mikrocontroller. Wenn Du diese Sprachen also laufen lassen, so wirst 
keine 100%ige Kompatibilität zu normalen Systemen haben.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:

> Was aber C und C++ brauchen sind Funktionszeiger.

Weshalb benötigt C-Programmierung unbedingt Funktionszeiger? Bei C++ ist 
das keine Frage, aber warum C, abgesehen von der Erfüllung des Standard. 
Es gibt jede Menge C Programme ohne Funktionszeiger.

> Die kann nicht jeder Mikrocontroller.

Welcher nicht?

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>ich das entsprechend vor (prozessorspezifische Bibliotheken).

Heisst das , wenn ein µC kein I²C hat, kommt dort eine Software I²C 
rein?

MfG Spess

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:

> Heisst das , wenn ein µC kein I²C hat, kommt dort eine Software I²C
> rein?

Klar, wenn man I2C benötigt aber nicht hat. Nur ist so eine Lib kein 
Selbstzweck, man baut das was man benötigt. Man baut ja auch kein 
Soft-CAN bloss um die Lib zu komplettieren.

Übrigens gilt für Soft-I2C das was ich schon für 1-Wire beschrieb: Die 
Pinfunktionen sind gerätespezifisch, das darauf aufbauende I2C-Protokoll 
ist es nicht mehr und lässt sich daher portabel realisieren.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte man so machen, falls es so zusammen passt.
Ansonsten muss man sich hat auf ausgewählte Prozessoren beschränken, die 
I2C in Hardware machen.

Ich will damit aber nicht sagen, dass man somit alle verfügbaren 
Prozessoren abdecken kann. Es ist nur ein Beispiel, wie verschiedene 
Architekturen unterstützt werden können (Beispiel Linux-Kernel).

Autor: avr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Die alles schlecht machen

"Der alles gut macht" wollte nur ein paar Tipps haben.
Einige hat er gekriegt.
Was er nicht braucht ist der alte Streit
  AVR <-> PIC
    C <-> Assembler

Welchen µC er jetzt wählt ist seine Sache. Welche Sprache
er bevorzugt (evtl. BASCOM) auch.
Wenn er seinen µC besser kennenlernen will (oder beim
Fehlersuchen muß) kommen automatisch auch die
Prozessorbefehle ins Spiel.

Jetzt soll "Der alles gut macht" es erst einmal gut machen,
eine Wahl treffen und sich bei neuen Fragen wieder melden.

Gute Nacht

avr

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>kann deine Freude über Assembler durchaus teilen aber...

Bisher hatte noch kein Problem, das ich nicht mit AVRs und Assembler 
lösen konnte. Von den Geräten, für die ich Programme geschrieben habe 
sind Anlagen im Wert von Ein- bis Mehrfamilienhäusern abhängig. Bei 
Assembler weiss ich, was wirklich passiert. Bei C müsste ich erstmal im 
Disassembler nachsehen.

MfG Spess

Autor: horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> TIMSK |= (1 << OCIE1A);
> versteht auch ein PIC?

Ja, das versteht jeder Controller / Prozessor der einen C-Compiler hat. 
;-P
Was der PIC damit allerdings macht kommt darauf an, wie die Makros TIMSK 
und OCIE1A definiert sind.
Für verschiedene Hardware braucht man nunmal verschiedene Treiber um 
sinnvoll damit arbeiten zu können.

> Ich wehre mich nur gegen die Mär, das
> C-Programme auf beliebigen Plattformen laufen . Mag für PCs sogar
> zutreffen.

Auch auf dem PC braucht man bei unterschiedlicher Ausstattung auch 
unterschiedliche Treiber. Und wenn das Programm dann auf Hardware 
zugreift, die auf einem Rechner nicht vorhanden ist, hat man auch hier 
Probleme.
Der Unterschied beim PC ist: Die Treiber programmiert man hier selten 
selber.


Meine Erfahrung mit Java ist, es läuft zwar praktisch auf jedem PC, aber 
das heißt noch lange nicht, dass ein Javaprogramm auf jedem PC das 
Gleiche macht.
Ok, das sind seltene Ausnahmen, die können aber die Brauchbarkeit eines 
Programms auch zu Nichte machen.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Christian Berger schrieb:
>
>> Was aber C und C++ brauchen sind Funktionszeiger.
>
> Weshalb benötigt C-Programmierung unbedingt Funktionszeiger? Bei C++ ist
> das keine Frage, aber warum C, abgesehen von der Erfüllung des Standard.
> Es gibt jede Menge C Programme ohne Funktionszeiger.

Ja, es gibt viele Programme, die das nicht brauchen. Aber schon wenn Du 
ein fein einstellbares Delay brauchst brauchst Du das schon, weil Du ja 
so was dadurch machst, in dem Du NOPs überspringst.

Viele Programme nutzen sogar die Eigenschaft, dass der Rücksprungszeiger 
auf dem Stack gespeichert wird, und der Stack nach unten wächst. 
Berühmte Beispiele sind der Microsoft SQL-Server, Word, sowie Samba, 
oder im eingebetteten Bereich die Software einiger Wahlmaschinen.

Dann ist unter C auch noch selbstmodifizierender Code übrig, da es eine 
einfache Möglichkeit ist, Funktionswerte zurückzugeben.

>> Die kann nicht jeder Mikrocontroller.
>
> Welcher nicht?

Zum Beispiel können das die AtTiny so weit wie ich weiß nicht.

Autor: horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch mal kurz zusammengefasst:
Wenn du direkt auf die Hardware zugreifst, z.B. auf die 
Konfigurationsregister, dann ist die Software auch an die entsprechende 
Hardware gebunden.

z.B.: printf funktioniert überall, wo diese Funktion implementiert ist. 
Da ist es egal, ob dahinter die serielle Schnittstelle in HW oder in SW 
vorliegt oder ob in eine Datei oder auf einen Bildschirm gedruckt wird.
Wenn du aber jedesmal auf die Register der HW Schnittstelle zugreifst, 
dann funktioniert das nicht mehr "überall".

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
horst schrieb:

> Wenn du aber jedesmal auf die Register der HW Schnittstelle zugreifst,
> dann funktioniert das nicht mehr "überall".

Das Problem damit ist ganz einfach, dass unter C so ziemlich alles ein 
Zugriff auf Register ist. Zum Beispiel ein Funktionsaufruf in einer 
normalen Sprache bildet Argumente auf Funktionsergebnisse ab.
Unter C ist ein Funktionsaufruf folgendes:
Die Parameter werden auf den Stack gelegt. Die Rücksprungadresse wird 
auf den Stack gelegt und die "lokalen Variablen" liegen ebenfalls auf 
dem Stack. Wenn Du irgendwas daran änderst, und sei es nur die Parameter 
über Register zu übergeben, fällt das ganze zusammen, und viele 
Programme laufen nicht mehr.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:

> Ja, es gibt viele Programme, die das nicht brauchen. Aber schon wenn Du
> ein fein einstellbares Delay brauchst brauchst Du das schon, weil Du ja
> so was dadurch machst, in dem Du NOPs überspringst.

Und solche Delays mit Auflösung auf den einzelnen Takt runter 
realisierst du über Funktionszeiger in C???

> Berühmte Beispiele sind der Microsoft SQL-Server, Word, sowie Samba,

Typische Anwendungen für vollintegrierte Mikrocontroller.

> Dann ist unter C auch noch selbstmodifizierender Code übrig, da es eine
> einfache Möglichkeit ist, Funktionswerte zurückzugeben.

Ist mir in diesem Zusammenhang noch nie untergekommen. 
Selbstmodifizierender Code ist heutzutage auch ausgesprochen selten, 
einerseits weil das bei Code im Flash-ROM etwas schwierig ist, 
andererseits weil hochentwickelte Prozessoren mit getrennten I/D-Caches 
dabei tief ins Performance-Loch purzeln, vom dadurch komplett 
leergefegten Trace Cache des Pentium 4 ganz abgesehen..

> Zum Beispiel können das die AtTiny so weit wie ich weiß nicht.

Abgesehen vom allerersten AVR, dem längst eingestellten AT90S1200 können 
es alle, sogar der stark auf Diät gesetzte Zwerg Tiny10.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
>> Berühmte Beispiele sind der Microsoft SQL-Server, Word, sowie Samba,
>
> Typische Anwendungen für vollintegrierte Mikrocontroller.

Was Du als typische Anwendungen für vollintegrierte Mikrocontroller 
bezeichnest sind wohl einfacher in Assembler zu realisieren.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:

> Was Du als typische Anwendungen für vollintegrierte Mikrocontroller
> bezeichnest sind wohl einfacher in Assembler zu realisieren.

Sorry, du hattest den SQL-Server hier im Kontext von 
Mikrocontrollerprogrammierung eingeführt, nicht ich.

Zwischen dem und einem 20-Zeiler als Ersatz eines Treppenhaustimers ist 
durchaus noch etwas Luft. Herrje, die Klasse der vollintegrierten 
Mikrocontroller geht mittlerweile bis mindestens 2MB Flash. Willst du 
die alle in Assembler programmieren?

Ich hatte versucht, ersthaft rauszukriegen, worin für dich die Probleme 
von C auf Mikrocontroller lagen, denn du hattest ja angedeutet, dass es 
welche gibt.

Und würde wirklich gerne ein ernsthaftes Beispiel für derart 
selbstmodifizierenden Code sehen. Etwas Erfahrung mit C-Compilern und 
verschiedensten Rechnerarchitekturen habe ich. Der einzige moderne 
Prozessor wo ich sowas routinemässig erwarte ist der Parallax Propeller.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:

> Unter C ist ein Funktionsaufruf folgendes:
> Die Parameter werden auf den Stack gelegt. Die Rücksprungadresse wird
> auf den Stack gelegt und die "lokalen Variablen" liegen ebenfalls auf
> dem Stack.

So kann das zwar implementiert werden, muss es aber nicht. Insbesondere 
nicht bei AVRs, ARMs, MSP430, PIC30, ... Auch allerlei Compiler für 
PIC16 und 8051 ziehen es soweit möglich vor, auf klassische activation 
records im Stack zu verzichten. Architekturen mit Registern statt Akku 
(RISC, MSP430, PIC30, sogar x86) machen es eben aufgrund der vorhandenen 
Register anders. Ebenfalls anders machen es 8051 und 12/14-Bit PICs, 
weil Register-relative Adressierung und grössere Stacks nicht zu deren 
Stärken zählt.

Nur: Was hat das mit Portabilität auf Quellcodeebene zu tun? Das heisst 
ja nicht, dass man einen Compiler für AVRs mit einem PIC verwenden will, 
oder ein von einem IAR-Compiler übersetztes Programm mit einer fertig 
für avr-gcc übersetzten Library linken will. Richtiger Umgang mit dem 
ABI ist Aufgabe des Compilers. Für den Programmierer ist das nur 
relevant, wenn er C mit eigenem Assembler-Code mischt.

Horsts Beispiel des printf Codes ist doch ein schönes Beispiel für jene 
Sorte Code, die abgesehen von der seriellen Einzelzeichenausgabe 
(typisches Szenario bei Mikrocontroller-Debugging) problemlos portabel 
realisierbar ist.

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Meine
> Mathe-Lib geht z.B.bis 64Bit incl. Fliesskomma, Wurzel, CRC, Random ,
> Konvertierungen Hex, Dezimal, Binär, ASCII hin und zurück und noch
> einige andere Sachen. Desweiteren habe ich noch eigene Libs für gängige
> Text- und Grafikdisplays, Sensoren und was mir sonst noch so
> untergekommen ist. Sollte ich jetzt gegenüber C etwas vermissen?
Ja - und zwar:

- Portabilität/Wiederverwendung/Kontinuität/Flexibilität:
Du hast viel Zeit in Deine Infrastruktur investiert und ich glaube Dir 
unbesehen, dass du für diese *eine* Architektur sehr schnell, 
flexibel und ressourcenschonend in Assembler entwickeln kannst. Wenn Du 
das Glück hast, sicherstellen zu können, dass Du lange Zeit auf dieser 
einen Architektur entwickeln kannst ist alles O.K. - die meisten 
Entwickler können aber genau das nicht.
Wenn aber dein Auftraggeber/Arbeitgeber oder das Problem eine andere 
Architektur verlangen (Controller mit DSP-Kern für Teilaufgabe nötig, 
kein IP um den Lieblingscore im verwendeten FPGA zu synthetisieren, zu 
wenige Speicher, ...), dann hast Du ein Problem.

Mit C kannst Du auf so gut wie jedem Prozessor, der jemals entwickelt 
wurde (wenn er nicht gerade mit Röhren oder Relais läuft) entwickeln und 
bist sehr flexibel - jedenfalls um Dimensionen flexibler als mit 
AVR-Assembler.

- Testbarkeit:
Wenn Du in C modular programmierst, dann kannst Du ein Modul (oder fast 
das komplette Programm) sehr einfach auf dem PC übersetzen und (mit 
einem kleinen Stub) gegen beliebige Eingabedaten laufen lassen. Dadurch 
erreicht man eine gute Testtiefe und kann einigermaßen sicher sein, 
einmal gemachte Fehler nicht wieder zu machen - insbesondere wenn mehr 
als eine Person an einem Programm arbeitet und die Entwicklung nicht 
nach der ersten abgelieferten Version abgeschlossen ist, sondern über 
Jahre weitergeht. Viele Kunden reagieren äußerst sensibel und 
verständnislos darauf, wenn ein einmal gefixter Fehler in einer späteren 
Version wieder auftaucht.

> Und das Schöne an Assembler ist, das mir kein Compiler irgendwelchen
> Code wegoptimiert, weil er meint klüger als ich zu sein.
Wenn ein Compiler Code wegoptimiert, von dem der Programmierer glaubt, 
dass er ihn braucht, dann war nicht der Compiler klüger, sondern der 
Programmierer dümmer. Was ein Compiler machen darf und was nicht ist 
definiert - und das Schlüsswlwort "volatile" ist kein Geheimtipp.

Man muß eben wissen, was man tut - aber das muß man mit Assembler auch.

Ich habe 2 Jahre komplett für PICs in Assembler entwickelt (mit einem 
vorgeschalteten Makroprozessor) - das ist schon nicht so "unelegant" wie 
viele vermuten. Mein damaliger Chef hätte das Projekt gerne auf 8051 
umgestellt (weil damit die restlichen Entwicklungen dieser Firma 
liefen), hat aber den Kostenaufwand gescheut, weil außer der 
Programmstruktur quasi nichts hätte übernommen werden können. Das 
gleiche Problem hatte er übrigens auch mit einem 8085-basierten Projekt, 
ebenfalls in Assembler. Der Grund, warum die Controller in Assembler 
programmier wurden war übrigens, dass es in dieser Firma eine tiefe 
(aber unbegründete) Abneigung gegenüber C gab, weil die PC-Programme in 
Pascal und Delphi entwickelt wurden - und ein Pascal-Programmierer 
scheinbar der natürliche Feind eines C-Programmierers ist (und 
vice-versa).
Letztendlich haben technische Fehlentscheidungen aufgrund solcher Dogmen 
"C ist schlecht, Pascal gut", "nur in Assembler kann ich alles 
kontrollieren" und noch diverse weitere zum Untergang dieser Firma 
geführt.

Für meine nächsten Projekte habe ich dann auf C gesetzt und es bisher 
nicht bereut. Wenn der Embedded-Markt sich weiterentwickelt, dann 
programmiere ich übermorgen eben in ZIT (fiktiv). Fundamentalismus 
bezüglich der Programmiersprache ist ebenso fehl am Platze wie jeder Sau 
hinterherzujagen, die gerade durch's Dorf getrieben wird.

Wenn es auf jedes Bit und auf präzises Timing auf Befehlsebene ankommt 
braucht man sicherlich Assembler und nichts anderes, aber das trifft nur 
auf einen Bruchteil der Projekte zu - die große Mehrheit der Projekte 
ist in C einfach schneller und flexibler entwickelt - und damit 
erfolgreicher.
Ich glaube Dir, dass Du in Deiner selbst geschaffenen Umgebung mit 
Assembler ähnlich schnell und flexibel bist als ein durchschnittlicher 
Entwickler in C, aber ein durchschnittlicher Entwickler ist in C 
schneller und flexibler als in Assembler - und darauf kommt es an. 
Natürlich stört es einen als Entwickler in seinem Streben nach 
Perfektion, wenn er weiß, dass das selbst erstellte Programm weil es in 
C erstellt wurde sagen wir mal 5 % mehr Ressourcen benötigt als ein 
Assemblerprogramm. Aus wirtschaftlicher Sicht mag es aber wesentlich 
interessanter sein, selbst 50 % der Controller-Ressourcen zu 
verschwenden, damit aber im Plan zu bleiben und den Markt zu besetzen. 
Auch hier gilt das Paretoprinzip. Lieber in akzeptabler Zeit auf dem 
Markt zu sein als in Schönheit nie.

Die gleiche Diskussion findet heute übrigens auf einer anderen Ebene 
statt - hier geht es darum, ob man einen Codegenerator einsetzen soll 
(der dann C-Code erzeugt) oder ob man auf dieses "Teufelszeug" lieber 
verzichten soll und bei "solidem handgeschriebenem" C bleiben soll. Mit 
übrigens genau den gleichen Argumenten wie damals bei ASM vs. C. "da 
weiß ich genau was passiert ..."
=> Geschichte wiederholt sich doch!

Nun noch meine Empfehlung an den Threadstarter:
Mach' Dir nicht allzuviele Gedanken um das "richtige Einstiegssystem 
(tm)". Kauf' Dir einfach ein STK500 und leg' mit einem ATmega32 los. 
Damit machst Du nichts falsch und hast viel Support im Forum. Du kannst 
in Assembler und in C programmieren und dabei viel lernen. Wenn Projekte 
später ARM, PIC, x86 oder was auch immer erfordern, profitierst Du 
allemal von den Erfahrungen, die Du mit dem AVRs gesammelt hast - die 
Prinzipien sind immer die gleichen. Das optimale Einstiegssystem gibt es 
schlichtweg nicht, da niemand weiß, mit welchem System er später 
produktiv arbeiten wird. Wichtig ist, schnell "reinzukommen".

Gruß,
Bernd

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem ist, dass ein durchschnittlicher Programmierer C nicht 
versteht und damit nichts vernünftiges hinkriegt, weil er glaubt, es sei 
eine Hochsprache, die beispielsweise Arraygrenzen überprüft.

Es ist auch das Problem, dass ein Programm, welches für einen 
Microcontroller in C entwickelt wurde auf einem anderen nicht ohne 
Weiters zum Laufen zu kriegen ist. Und das selbst, wenn keine 
IO-Routinen vorhanden sind. Sprich eine FFT für Prozessor X läuft nicht 
unbedingt auf Prozessor Y. Nur wenn man ein sehr kleines eingeschränktes 
Subset von C benutzt, dann ist das möglich.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:

> Das Problem ist, dass ein durchschnittlicher Programmierer C nicht
> versteht und damit nichts vernünftiges hinkriegt, weil er glaubt, es sei
> eine Hochsprache, die beispielsweise Arraygrenzen überprüft.

Ich bin bei C schon allerlei Missverständnissen begegnet, aber dieser 
Aspekt ist selten dabei.

Richtig ist aber schon, dass C eine hundsmiserable Sprache für viele 
Anwendungsfälle ist. Ada beispielsweise wäre bei Mikrocontrollern wohl 
eher geeignet. Aber dieser Zug ist raus und durch 
Assemblerprogrammierung rettet man nichts.

> Es ist auch das Problem, dass ein Programm, welches für einen
> Microcontroller in C entwickelt wurde auf einem anderen nicht ohne
> Weiters zum Laufen zu kriegen ist. Und das selbst, wenn keine
> IO-Routinen vorhanden sind.

Zu portabler Programmierung gehört etwas Disziplin und Übung.

> Sprich eine FFT für Prozessor X läuft nicht unbedingt auf Prozessor Y.

Korrekt. Ganz von allein geht das nicht.

> Nur wenn man ein sehr kleines eingeschränktes
> Subset von C benutzt, dann ist das möglich.

Kannst du konkretisieren an was für Einschränkungen du dabei denkst?

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das Missverständnis, dass Arraygrenzen und Integer-Überläufe 
geprüft werden ist häufig.

Nur mal so grob kann man das über diese Suche abschätzen:
http://www.heise.de/suche/?q=Buffer+%C3%9Cberlauf&...

Das größte Problem mit C-Code auf Mikrocontrollern ist natürlich dass C 
für von Neumann-Architekturen ausgelegt ist. Auf Rechnern mit mehreren 
unabhängien Speichern hat C massive Probleme.

Beispielsweise gibt es dann unterschiedliche Pointer für ROM und RAM. 
Oder es wird irgendwie probiert beides zu kombinieren, was eigene 
Probleme bringen kann.

Wo ist eigentlich das Problem mit ADA?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:

> Das größte Problem mit C-Code auf Mikrocontrollern ist natürlich dass C
> für von Neumann-Architekturen ausgelegt ist. Auf Rechnern mit mehreren
> unabhängien Speichern hat C massive Probleme.

Korrekt, aber auf beispielsweise 68xx, MSP430, PIC30 und allen 
32-Bittern ist das kein Thema.

> Das größte Problem mit C-Code auf Mikrocontrollern ist natürlich dass C
> für von Neumann-Architekturen ausgelegt ist. Auf Rechnern mit mehreren
> unabhängien Speichern hat C massive Probleme.

Und das stört bei einer FFT?

> Wo ist eigentlich das Problem mit ADA?

Wieviele Entwicklungsumgebungen (Compiler+Debugger) für Ada auf 
Mikrocontrollern kennst du? Vorzugsweise solche, die auch Einsteiger 
interessieren könnten.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:

> Nur mal so grob kann man das über diese Suche abschätzen:
> http://www.heise.de/suche/?q=Buffer+%C3%9Cberlauf&...

Das sind zu 99,9% keine Missverständnisse hinsichtlich der 
Programmiersprache, sondern Unterlassungssünden, Programmierfehler oder 
Schwächen der C-Library.

Sprachen mit Runtime-Checks sind dagegen auch nicht immer gefeit, wenn 
die in der Produktionsversion der Effizienz halber abgeschaltet werden.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Sprachen mit Runtime-Checks sind dagegen auch nicht gefeit, weil die in
> der Produktionsversion der Effizienz halber meistens abgeschaltet
> werden.

Ähm, ich hab es mal ganz konkret ausprobiert in einem Pascal Projekt mit 
sehr vielen Array-Zugriffen. Da hatte man keine nennenswerten 
Unterschiede zwischen mit und ohne Überprüfungen.

Früher war das mal ein Problem. Heute dank Pipelining und paralleler 
Ausführung mehrer Befehle ist das kein Problem mehr.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber ich denke, wir schweifen ab. Mit Portabilität von Code hat das 
nichts zu tun, und dass C eine inhärent unsichere Sprache ist, das ist 
unstrittig.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger schrieb:

> Früher war das mal ein Problem. Heute dank Pipelining und paralleler
> Ausführung mehrer Befehle ist das kein Problem mehr.

Bist du wieder beim SQL-Server angekommen? Darf ich dich daran erinnern 
wo du dich grad befindest? So arg viele AVRs oder ARM7 mit paralleler 
Ausführung sind noch nicht auf dem Markt.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Aber ich denke, wir schweifen ab. Mit Portabilität von Code hat das
> nichts zu tun, und dass C eine inhärent unsichere Sprache ist, das ist
> unstrittig.

Wenn C unsicher ist, ist es Assembler noch viel mehr ;-) Mit beidem 
kannst Du viel Mist bauen. Mit Assembler hast Du nur noch viel mehr 
Möglichkeiten dazu.

Hier geht es aber nicht um C, Assembler, ZIT oder 
Was-Weiss-Ich-Nicht-Was.
Der Threadstarter wollte Doch wissen, was für Unterschiede zwischen den 
Prozessorfamilien existieren und ob die einen für bestimmte 
Einsatzgebiete besser sind als andere.

Naja,...

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HI

>Wenn C unsicher ist, ist es Assembler noch viel mehr ;-) Mit beidem
>kannst Du viel Mist bauen. Mit Assembler hast Du nur noch viel mehr
>Möglichkeiten dazu.

Und hier wird immer behauptet C sei mächtiger als Assembler.

MfG Spess

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> HI
>
>>Wenn C unsicher ist, ist es Assembler noch viel mehr ;-) Mit beidem
>>kannst Du viel Mist bauen. Mit Assembler hast Du nur noch viel mehr
>>Möglichkeiten dazu.
>
> Und hier wird immer behauptet C sei mächtiger als Assembler.
Das Wort "mächtig" taucht im ganzen Thread in Deinem Beitrag zum ersten 
Mal auf. Darüber hinaus ist "mächtig" ein sehr schwammiger Begriff. Der 
C-Compiler produziert ja auch nur Assembler-Quelltext aus dem 
C-Quelltext.

Mit C bist Du jedenfalls deutlich flexibler was Programmerstellung, 
Zielsysteme und Testbarkeit angeht und C nimmt Dir viel Kleinarbeit ab, 
um die Du dich bei Assembler kümmern musst. Letztlich kannst Du in C 
dein Problem eher so lösen, wie man üblicherweise Probleme löst.

Wenn Du beispielsweise zwei Variablen addieren willst, dann schreibst Du 
einfach:

a = b + c;

Das funktioniert für 8-Bit-Werte genauso wie für 64-Bit-Werte. In 
AVR-Assembler sehen die Sequenzen für 8-Bit, 16-Bit, 32-Bit und 64-Bit 
Additionen jeweils unterschiedlich aus bzw. sind länger oder kürzer.

Wenn Du beim Programmieren also merkst, dass ein anfangs gewählter 
Datentyp mit 8-Bit zu klein war, dann ist das in C relativ schnell 
geändert. Der Änderungsumfang ist jedenfalls um Dimensionen kleiner als 
für die Assembler-Implementierung.

Jetzt kann man natürlich in Assembler hergehen und sich unterschiedliche 
Funktionen für 8-Bit, 16-Bit, 32-Bit und 64-Bit Additionen erstellen. 
Das ganze noch unterschiedlich für die Kombinationen signed/signed, 
signed/unsigned und unsigned/unsigned, für float/int, float/float. Dann 
noch für Subtraktionen, Multiplikationen, Divisionen, trigonometrische 
Funktionen, ...
Wenn man das nur fleißig genug macht, dann hat man irgendwann einen 
ähnlichen Funktionsumfang, wie ihn ein C-Compiler mit zugehöriger 
C-Library "out of the box" liefert.

Für den technikbegeisterten Entwickler mag das ja ganz nett sein, 
wirtschaftlich ist es jedenfalls kompletter Blödsinn, das Rad immer 
wieder neu zu erfinden. Die Arbeitszeit die dabei draufgeht, große Teile 
der C-Library neu zu implementieren fehlt letztlich bei der 
Produktentwicklung. Von den vielen zu erwartenden Fehlern aufgrund 
fehlender Testtiefe mal ganz abgesehen. Es macht eben einen größen 
Unterschied, ob eine Funktion für einen Zweck entwickelt und 1-10 mal 
eingesetzt wird oder von Millionen Entwicklern zu unterschiedlichen 
Zwecken eingesetzt wird und schon alleine dadurch auf Fehler abgeklopft 
wird.

Vom wirtschaftlichen Totalschaden wenn der Controller bei wachsendem 
Programmumfang nicht mehr ausreicht oder der Hersteller des Controllers 
die Architektur abkündigt mal ganz abgesehen.

Wie viel Zeit brauchst Du um Deine ASM-Programme von AVR auf ARM oder 
PIC zu portieren? Ich vermute mal ähnlich viel Zeit wie die 
ursprüngliche Erstellung gedauert hat => Portierung wird zum 
wirtschaftlichen Totalschaden!

Gruß,
Bernd

Autor: skorpionx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum hat C-Sprache so mächtige Position...? Zu dieser Position haben
ihr die Assembler Programmierer wie Bernard (ich  auch…) verholfen. Am 
Anfang war nur Assembler und es war gut so. Programmierer haben sehr 
wenig Speicher aber sehr viel Zeit zu Verfügung gehabt. Alle waren 
damals überzeugte „Assemblisten“. Im laufe der Zeit  Software spielte 
immer größere Rolle. Und auch Entwicklungszeit bei immer größeren 
Programmen  war immer wichtiger. Auch die Portabilität war bei  immer 
neueren  leistungsfähigeren auf dem Markt  Prozessoren  gefragt. Man 
brauchte eine neue Programmierungssprache, einen „universellen 
Assembler“. Zur Verfügung standen zwei Hauptkonkurrenten: C   und 
Pascal. Warum haben sich Assemblisten  zur „C“ entschieden? Die Uhrsache 
war damals bei Pascal  der fehlende und verpönte Pointer, aber ein 
richtiger Programmier braucht ihn mit der ganzen dazu gehörenden 
Pointerarithmetik (Akrobatik…). So haben sich die Assemblisten zur C 
entschieden. Über vielen Jahren haben Studenten der Hochschulen Pascal 
gelernt, aber als Absolventen Beruflich in C-Programmiert.

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.