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.
Danke, das zeigt schon mal ein paar unterschiedliche "Verhaltensweisen" der einzelnen Modelle. Allerdings ist hier von empfohlenen Einsatzbereichen nicht die Rede.
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.
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
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
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
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
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?
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.
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
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.
>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
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
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.
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
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.
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
spess53 schrieb:
> Mag für PCs sogar zutreffen.
Naja, das ist aber dann wieder die selbe Plattform (von der vorhandenen
Perepherie mal abgesehen).
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ß.
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?
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
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).
@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
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
> 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.
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.
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".
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,...
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
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.