Was unterscheidet PIC-Controller von 8051 und anderen?

Mikrocontroller Vergleich

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.

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.

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.

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

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

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 
:-)

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...

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.

>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

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

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

MfG
Ak Tronik

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

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.

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?

Christian H. schrieb:

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

Ich: oft.

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

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.

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?

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.

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).

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.

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.

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.

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.

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.

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.

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

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.

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?

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&search_submit=Suche&rm=search

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?

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.

Christian Berger schrieb:

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

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.

> 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.

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.

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.

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,...

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