Hallo Community, ich möchte mir für eine Steuerung eines Bus Systems einen Mikro-Controller programmieren. Ich habe bisher alles mit SPS gemacht, hier stößt man aber schnell auf Grenzen der Wirtschaftlichkeit. Die Frage ist nun, in welcher Sprache ich mein Projekt am schnellsten erlernen und realisieren kann. Im Projekt schaut so aus: Eingang analog 4-20 mA, Digital wandeln. Mittelwert von 3 Sekunden, 3 Abtastungen digital wandeln in 10 verschiedenen Schaltstufen. Je nachdem welche Schaltstufe ermittelt wird, soll ein fester Befehl über den UART verschickt werden, 9200 Baud, 8N1. Der Befehl ist 8 Bit lang, und 4 Bytes. [Startbyte] [Adressbyte] [Parameterbyte] [Checksum] Mit welcher Sprache kann ich sowas am schnellsten erlernen? Assembler erscheint mir auf den ersten Blick logischer und einfacher. Und noch eine Frage vorweg. Kann der UART mit Nutzdaten gefüttert werden, die Start und Stoppbits eigenständig dazu setzen? Oder müssen diese Bits von Hand mitprogrammiert werden? Danke!
Markus schrieb: >Assembler erscheint mir auf den ersten Blick logischer und einfacher. Wenn du weder C noch ASM kannst nimm ASM. Das ist zwar aufwändiger aber lernt sich schneller als C. > Und noch eine Frage vorweg. Kann der UART mit Nutzdaten gefüttert > werden, die Start und Stoppbits eigenständig dazu setzen? Ja. > Oder müssen > diese Bits von Hand mitprogrammiert werden? Nein. Näheres im Datenblatt des verwendeten Controllers.
Markus schrieb: > Und noch eine Frage vorweg. Kann der UART mit Nutzdaten gefüttert > werden, die Start und Stoppbits eigenständig dazu setzen? Oder müssen > diese Bits von Hand mitprogrammiert werden? Bei einem Software-UART muß man sich natürlich darum kümmern, beim Hardware-UART werden Start- und Stopbit gewöhnlich durch die Hardware automatisch erzeugt. Darüber gibt i.A. das Datenblatt des betreffenden µCs Auskunft.
Hi >Und noch eine Frage vorweg. Kann der UART mit Nutzdaten gefüttert >werden, die Start und Stoppbits eigenständig dazu setzen? Ja. >Die Frage ist nun, in welcher Sprache ich mein Projekt am schnellsten >erlernen und realisieren kann. >Im Projekt schaut so aus: >Eingang analog 4-20 mA, Digital wandeln. Mittelwert von 3 Sekunden, 3 >Abtastungen digital wandeln in 10 verschiedenen Schaltstufen. Das Problem ist eher trivial. Such dir eine Programmiersprache die dir gefällt aus. In beiden Fällen wirst du die erst mal mehr mit dem Controller beschäftigen müsse. MfG spess
Hi, da du, deinem Post zu folgen, wohl noch nichts mit uPC gearbeitet hast, gibt es neben dem erlernen der Programmiersprache auch noch weiter herausforderungen für dich. Du mußt dich, anders als bei einer SPS, damit auseinandersetzten wie du z.B. den Oszillator ansteuerst, Interrups auswetest, timer setzten, I/Os ber Special function register configurierst usw.... Als Einstieg eignet sich IMHO das MSP430 Launchpad (~5€) ideal. Hier findest du einen sehr guten einführungsworkshop und viele Beispielprojekte. Auch die tools (bis 16k) bekommst du Kostenlos. siehe: http://e2e.ti.com/group/msp430launchpad/w/default.aspx Deiner Projektbeschreibung zu folge sollte das mit +/- 40 Zeilen C-Code auf einem MSP430 implementieren können. viel spaß
sebastian schrieb: > Deiner Projektbeschreibung zu folge sollte das mit +/- 40 Zeilen C-Code > auf einem MSP430 implementieren können. Wenn man die Sprache kann... (und da gibt es bekanntlich einige Fallstricke). 430 ist imho unnötig kompliziert, da reicht wohl auch ein kleiner AVR.
Markus schrieb: > Die Frage ist nun, in welcher Sprache ich mein Projekt am schnellsten > erlernen und realisieren kann. C Markus schrieb: > Mit welcher Sprache kann ich sowas am schnellsten erlernen? C Markus schrieb: > Assembler erscheint mir auf den ersten Blick logischer und einfacher. Auf den ersten Blick magst du da recht haben. Du wirst aber dabei über viele kleine Hinterhältigkeiten und Fallen stolpern. Ganz besonderst im Bereich Speicheradressierung. Ein C Compiler nimmt dir sehr viel dieser Fallstricke weg indem der Compiler Speicherzugriffe, Speicheradressen,.... selbstständig regelt. Du kannst dich also im großen und ganzen auf diene Programmlogik konzentrieren und musst dich nicht darum kümmern wie die Bits bei einer Addition,...... durch den µC geschoben werden. Abgesehen davon, wenn du C lernst ist es nahezu egal wo du lernst, µC , Pc , ..... C bleibt C . ( zumindest wenn du dich an die ANSI Normen hälst) Assembler ist auf jedem Prozessor unterschiedlich wobei innerhalb einer Familie doch meist sehr ähnlich. Allerdings kann es auch nichts schaden wenn zumindest Grundkenntnisse Assembler für den verwendeten µC vorhanden sind. Es erleichtert das Debuggen ungemein.
Hi >Auf den ersten Blick magst du da recht haben. >Du wirst aber dabei über viele kleine Hinterhältigkeiten und Fallen >stolpern. Und die hat C natürlich deiner Meinung nach nicht. MfG Spess
avr schrieb: > 430 ist imho unnötig kompliziert, da reicht wohl auch ein > kleiner AVR. Ja, AVR oder PIC gehen natürlich auch genauso einfach. Persönlich finde ich z.Zt. die MSP430 unschlagbar: - Preis/Leistung sehr gut - 16 bit - gute Doku - gute Bibliotheken (auch für SW UART) - Kostenlose Toolchain (zumindest für die 16k value line) - super preiswerter einstieg mit dem launchpad Persönlich ist es mir egal wer was für einen chip einsetzt. d.h ich hänge keiner uPC religion an ;-) Ich habe schon Projekte (privat/studium/job) mit AVR, PIC, 8051, arm7, cortex m3 ,c166, 68k, ppc e200z und alle haben Vor und Nachteile, so what..
spess53 schrieb: > Hi > >>Auf den ersten Blick magst du da recht haben. >>Du wirst aber dabei über viele kleine Hinterhältigkeiten und Fallen >>stolpern. > > Und die hat C natürlich deiner Meinung nach nicht. > > MfG Spess Die hat jeder Programmiersprache, aber bei weitem nicht in dem Umfang wie in Assembler. Die Compiler und Interpreter der höheren Sprachen nehmen doch einiges an Fallen raus die man als Programmierer in Assembler immer wieder mal trifft.
Hi >Die Compiler und Interpreter der höheren Sprachen nehmen doch einiges an >Fallen raus die man als Programmierer in Assembler immer wieder mal >trifft. Na welche denn, die nicht im Datenblatt stehen? MfG Spess
Hi Ergänzung: ...nicht im Datenblatt oder Instruction Set stehen? MfG Spess
avr schrieb: > 430 ist imho unnötig kompliziert, da reicht wohl auch ein > kleiner AVR. Jeder kleine AVR ist komplizierter als der MSP430. Schon dieser FUSE Kram zur Konfiguration ist nicht mehr zeitgemäß. Ja, ich habe schon mit beiden Achitekturen gearbeitet.
Na es ist schon einiges an Übung und Erfahrung nötig um eine Spec so eindeutig lesen und verstehen zu können, ganz besonders für die Zusammenhänge die zwischen den Zeilen stehen. Und außerdem sind solche Specs von Leuten geschrieben die Wissen von was sie schreiben, und für Leute die Wissen was sie da lesen. Das ist kein Stoff für Anfänger weil einfach zuviel vorausgesetzt wird. Für einen Anfänger ist das schon eine gewaltige Herausforderung sich um jeden kleine Furz zu Fuß kümmern zu müssen. Und bietet eine gewaltiges Frustpotential. Was hat ein Anfänger damit gewonnen wenn er nach ein paar Monaten seinem Ziel keinen Schritt nähergekommen ist, weil er immer noch drum kämpft warum zb das CaryBit im Fall A nach Register xx geschoben wird und im Fall B ignoriert wird. Und das nur weil er zwei Zahlen multiplizieren will..... Was hat das mit der eigentlichen Aufgabenstellung zu tun. Lass so einen kleinschiss den Compiler machen, der kann das besser, und vor allem vergisst er auch bei der 40 Wiederholung im sourcecode nicht irgendeinen Zwischenschritt. Erst mal sehen das die eigentliche Programm Logik zum laufen kommt. ==> erste Erfolgserlebnisse. Der tiefer Einstieg in die Details eines µC kommt dann im Lauf der Zeit von alleine. Meiner Meinung nach ist Assembler für einen Einstieg in µC einfach eine Nummer zu heftig. Und wird oft durch viel Frust das Thema µC für denjenigen beenden. und das wäre Schade.
>Jeder kleine AVR ist komplizierter als der MSP430. Schon dieser FUSE >Kram zur Konfiguration ist nicht mehr zeitgemäß. > >Ja, ich habe schon mit beiden Achitekturen gearbeitet. Heute nimmt man ARM. Ich kenne PIC, AVR, 8051 und noch ein paar mehr. Erst mit ARM wird man glücklich. Kein Code Banking, kein PROGMEM Geraffel und der sonstige Unsinn. Programmiert wird natürlich in C.
holger schrieb: > Heute nimmt man ARM. Ich kenne PIC, AVR, 8051 und noch > ein paar mehr. Erst mit ARM wird man glücklich. Ja und heute nimmt man auch keine Fliegenklatsche um eine Mücke zu erlegen sonder schickt eine cruise missile? Gerade für den Anfänger ist der ARM (acuh aufgrund des interrup handlings) nicht wirklich zu empfehlen (IMHO)
Ist das hier mal wieder der übliche C/ASM Flamewar? Natürlich nimmt man Spin! :-P Im Ernst: Ein so kleines Projektchen läßt sich prima in ASM umsetzen. Denn auch wenn man C lernt, empfiehlt es sich mit ASM den Controller erst mal kennen zu lernen. Preislich nehmen sich ARM, AVR, PIC, MSP430 und 8051 nicht viel. Da von Hubschraubern zu sprechen, finde ich unangemessen, auch wenn der ARM mit der Aufgabe hoffnungslos unterfordert ist - die anderen sind es auch! Für das von Dir geschilderte Problem würde ich einen ATmega48 benutzen. Der hat einen ADC und eine Hardware UART. Und ich würde es in ASM lösen. Ich denke, auch in ASM ist das mit <40 Zeilen Code realisierbar. Gründe für meine uC-Auswahl: PIC scheidet für mich aus, da ich mich damit nicht auskenne. (Ich habe damals die Finger davon gelassen, als ich die 'krummen' Registergrößen gesehen habe.) ARM scheidet aus, da für Anfänger zu umständlich - auch in C. Die kleinen 8051 haben häufig keinen ADC. Die ATtinys haben keine UART. Für einen Anfänger möchte ich die SW-UART vermeiden. Die kleinen MSP430 haben keine UART und keinen ADC - zumindest die, die ich kenne. Den ATmega48 ziehe ich dem ATmega8 vor, da er moderner ist. Gruß Jobst
Hi Nun noch meine Meinung.... Wenn du von der SPS Seite kommst, wirst du wohl eher mit Assembler zurecht kommen wie mit "C". Die AWL einer SPS ist dem Assembler sehr ähnlich. Allerdings, wenn du mathematische Funktionen brauchst, ist C die bessere Wahl. Aber um jetzt schnell einen Erfolg zu sehen, denk ich, solltest du erst mal mit Assembler ein wenig üben. Ubrigends.... ich will auch mal wieder klugsch.... >Ergänzung: >...nicht im Datenblatt oder Instruction Set stehen? Das Instuction Set steht im Datenblatt.... Gruß oldmax
Hi
>Das Instuction Set steht im Datenblatt....
Aber nur als Übersicht.
MfG Spess
Jobst M. schrieb: > Denn auch wenn man C lernt, empfiehlt es sich mit ASM den Controller > erst mal kennen zu lernen. 1. geht das auch in C ganz gut. 2. wie tief willst du da in den µC einsteigen ? Mann muss in C gar nicht wissen wie eine Multiplikation einer 32 bit mit einer 64 bit Zahl auf einem 8 bit µC gemacht wird. Es ist VÖLLIG egal. Der Compiler weiß es und macht das für dich. Wer natürlich meint das er eine solche Multiplikation besser als der Compiler hinbekommt, der soll sich daran gerne versuchen. Und wenn er dann fürs nächste Projekt eine andere µC Familie nutzen muss, fängt er wieder von vorne an. Damit hat er dann viel gewonnen....... Nur mal als Beispiel, wenn du Auto fährst willst du auch nur wissen das ein Tritt aufs Gaspedal das Auto beschleunigt. Es interessiert dich gar nicht welche Ventile, Hebel, Klappen, Zahnräder,...... sich da Bewegen müssen. Das gleiche bei µC, du willst eine Logik die irgendwo zu bestimmten Bedingungen zb eine Lampe anmacht. Es interessiert dich gar nicht welche Bits, Register, Speicherstellen, ...... sich da Bewegen müssen. Von der Seite aus, Assembler ist ganz nett, man sollte es zumindest in Grundzügen zum debuggen können. Aber dann hat es sich damit auch schon. Und zur Auswahl des µC. Man bekommt in jeder Familie ; PIC; AVR; 805x; ARM; irgendetwas passendes was von Größe, Leistung, Preis einen brauchbaren Kompromiss darstellt. Viel wichtiger ist die Entwicklungsumgebung. Man muss sich hier etwas suchen mit der man klarkommt, die alles bietet was benötigt wird, dazu bei einem akzeptablen Preis verfügbar ist.
Bevor man auf ein Mopped steigt, sollte man erst mal richtig gehen können. Auch die meisten Rennfahrer laufen vorher die Strecke zu Fuß ab, weil man die Unebenheiten besser erkennen kann. Es schadet definitiv nicht, die Hardware zunächst auf unterster Ebene kennenzulernen, man versteht sie so einfach besser. Wenn dann die Wege zu weit werden, kann man das Mopped starten.
Danke für die vielen Antworten. Ich werde mich mal in der Assembler Sprache probieren, mit dem ATMega 48, wie von Jobst empfohlen. Grund ist, weil mir die Assembler Schreibweise sehr viel Vertrauter vorkommt. Es gibt sicher einfache Möglichkeiten, sich abrufbare Funktionen zu programmieren? Einen Baustein, welchen man mit einer einfachen Call-Anweisung ablaufen lassen kann? Wie schaut eine einfache bedingte Verzweigung im Assembler aus? Beispiel. Ist PINB1 = 1 dann springe zu Funktion SendeBusStufe1. Ist PINB 0 0, überspringe die CALL Funktion und checke PINB2 Kann mir jemand jetzt noch dazu gute Literatur empfehlen?
Nimm BASCOM, dann bist du in 10 Minuten fertig mit deinem Projekt.
sorry, aber wem erscheint denn bitte assembler auf den ersten blick logischer & einfacher als eine hochsprache?! soll ja jeder machen wie er möchte, aber wer ungezwungen projekte mit mehr als ner DIN A4 seite quelltext in assembler schreibt, neigt wohl zu masochismus. und das bedeutet nicht im umkehrschluss, das man keine ahnung von der hardware haben muss/soll/braucht. im hobbybereich kann das ja jeder handhaben wie er möchte, aber irgendwo wird es schon seinen grund haben, das in firmen niemand mehr seine firmware in assembler programmiert, ausser er ist wirklich drauf angewiesen und mal ehrlich...die fälle, in welchen man unbedingt auf assembler angewiesen ist lassen sich an einer hand abzählen...wobei mir gerade kein triftiger grund einfällt
sebastian schrieb: > Gerade für den Anfänger ist der ARM (acuh aufgrund des interrup > handlings) nicht wirklich zu empfehlen (IMHO) absolute zustimmung. aber dem anfänger dann den einstieg mit assembler zu empfehlen für schnelle erfolgserlebnisse finde ich schon gewagt
A. B. schrieb: > soll ja jeder machen wie er möchte, aber wer ungezwungen projekte mit > mehr als ner DIN A4 seite quelltext in assembler schreibt, neigt wohl zu > masochismus. und das bedeutet nicht im umkehrschluss, das man keine > ahnung von der hardware haben muss/soll/braucht. Aber dazu meine Meinung. C Sprache ist sehr viel Computer und sehr wenig E-Technik. Wenn ich mir die Tutorials für C anschaue, sehe ich erstmal nur ausführbare Windows Programme.
Ich finde C auf'm Arduino ein sehr guter Einstieg. Da wird dieses ganze Bitgeraffel mit den Port-Bits in bereits vorhandenen Funktionen versteckt. Man kann in verständlichem C anfangen zu programmieren.
>Wenn ich mir die Tutorials für C anschaue, sehe ich erstmal nur >ausführbare Windows Programme. Das stimmt. Weil alle meinen, ein C-Tutorial muss man mit Pointer anfangen.
Hi, Es ist nun ja schon einiges geschrieben worden... MEine MEinung geht auch mit vielen vorhergesagtem konform... WENN es jetzt nur für dieses eine Projekt eine schnelle Lösung sein soll UND du gar kein C beherrscht, dann ist ASM für die zeitnahe Realisierung wohl das Mittel der Wahl. Wenn du also nur dies vor hast und nicht weiteres mit µC planst nimm ASM und du kannst direkt zum Ende des Beitrages Springen. Für Spätere Projekte müsste man schauen wie umfangreich es wird. Diese Anforderungen die du oben genannt hast sind auf jeden Fall noch halbwegs bequem in ASM Umzusetzen. Ich denke sogar auf dieser Ebene ist der Zeitunterschied zwischen ASM und C für einen erfahrenen Programmierer noch nicht wirklich vorhanden. Mit zunehmender Größe und komplexität der Software aber geht die Schere immer weiter auseinander. Wenn aufwendige MAthefunktionen dazukommen etwas früher, geht es nur um einfache Logikentscheidungen etwas später. Aber es wird der Zeitpunkt kommen ab dem die komplette Umsetzung in ASM einfach unsinnig ist weil es ein vielfaches der Zeit erfordert und nur einen Bruchteil der Übersichtlichkeit bietet. Wenn soetwas abzusehen ist bietet es sich auf jeden Fall an auch C zu lernen. (ggf. halt auch nach der Realisierung des konkreten Projektes) Wobei ich wie von anderen auch geschrieben, es durchaus Sinnvoll finde wenn jemand der plant später in C zu schreiben zumindest die Grundlagen von ein oder zwei ASM Varianten kennt. Gerade mit ASM hat man noch einen sehr engen Bezug zum tatsächlichen Ablauf im µC und lernt so die eigenheiten soch etwas besser. Zudem kann es später auch bei großen Projekten immer wieder vorkommen das sich bestimmte sehr zeitkritische Anforderungen nur in ASM Sinnvoll umsetzen lassen und man so dann doch einige Zeilen ASM in sein C Programm einbetten muss (Inline). Zudem hilft es etwas beim Debuggen und man versteht auch die ausgaben des Compilers. Daher würde ich sagen: ASM Lernen macht auf jeden Fall SINN! Es ist nur die Frage wie Intensiv du dich damit beschäftigen solltest. Wenn du bei ASM bleien willst, was bei Projekten wie oben durchaus im Rahmen ist, dann halt etws intensiver, willst du früh auf C umsteigen halt etwas später. Zur Architektur: HAst du dir denn schon einen µC ausgesucht? Einige sind ja schon genannt worden. Für den Einstieg würde ich auf jeden Fall mal "tief" stapeln, also mit 8Bit µC anfangen. (PIC18F, AVR, evtl. auch noch 8051). Die 32 Bit µC sind zwar deutlich leistungsfähiger, aber für einen Einsteiger daher auch deutlich schwerer zu verstehen. Ein LKW fährt sich halt schwerer als ein VW Polo. Wenn man dann die Grundzüge beherrscht spricht natürlich nichts dagegen sich auch in größeren Leistungsbereichen zu versuchen (ARM, PIC32 usw.) Diese 8 bitter lassen sich gerade für Anfänger am einfachsten programmieren. Erst recht in ASM. Als zweites Kriterium als Anfänger würde ich mir noch etwas die Verbreitung in Hobbykreisen und in Foren ansehen. Was nützt dir die tollste Architektur wenn man bei Problemen dazu nichts im Netz findet und auch keinen Ansprechpartner hat. Zumal man ja auch als Einsteiger gar nicht weiß "wo" man nun GENAU suchen muss und auch noch nicht so zwischen den ZEilen liest, man evtl. doch vorhandene Info gar nicht ohne ZAunpfahl findet... Ich selbst bin ja eher PIC Fan, obwohl ich auch schon mit einer beachtlichen Anzahl anderer Architekturen gearbeitet habe und immer wieder arbeitet. Wenn du des Englischen (lesen) einigermaßen mächtig bist, dann würde ich dir die PIC18 für den Einstieg empfehlen. Dort bekommt man fast alles was man so benötigt direkt vom Hersteller (Tutorials, Librarys, Frameworks, Beispiele) hat eine große HArdwareauswahl und eine recht große Verbreitung. Die Programmiertools sind günstig, ab ca. 25 Euro bekommt man eines das ALLE aktuellen PIC Familien beschreiben kann und das eine Debug Funktion bietet. Braucht man mal mehr Leistung kann man mit den selben Tools auch die 16Bit oder 32Bit PICs programmieren. Es gibt zudem unter den 16Bit Typen auch welche mit einem abgespeckten DSP Kern. Die Verfügbarkeit ist auch für Hobbyisten gut. Die Softwaretools sind alle kostenlos ohne Größenbeschränkung verfügbar. Wenn es bei dir aber mit dem Verständniss von englischen Texten hapert würde ich doch eher zu AVR Raten. die haben hier im Deutschsprachigen Raum eine etwas größere Verbreitung, wobei das manchmal auch etwas täuscht, denn vieles was bei den AVR an SW Projekten oder Libs von dritten bereitgestellt wird und so als Fundstelle auf einer Homepage o.ä. bei google auftaucht bekommt man bei Microchip direkt vom HErsteller was dazu führt das niemand es selbst schreiben muss... Hier im Forum hat AVR die größere Verbreitung, wobei man bei genauem LEsen der Threads dann sieht das es zwar für die Masse gilt, bei der "Klasse" sich die Auskünfte zu beiden Architekturen aber nicht unterscheiden. Ganz ohne Englischfähigkeiten geht es bei der µC Programmierung aber auch mit AVR nicht, zumindest nicht wenn man mal über die Blinkenden Lichter hinausgehen will. GANZ WICHTIG ABER: Bevor du dich dann endgültig entscheidest, mache dir die Mühe und schaue dir mal die Herstellerwebseiten was da an Informationen und Beispielen geboten wird. Lade dir ein paar Datenblätter und APP Notes herunter. Schaue ob du mit der Schreibweise zurecht kommst und dir der Stil zusagt. Auch wenn dir das als Anfäner nicht wichtig erscheint, später wird das immer wichtiger. Und prüfe auch die Verfügbarkeit für dich, sowohl in kleinen Stückzahlen wie auch auf kurze Leiferzeit. (Wobei das bei vorhandemen Gewerbeschein mittlerweile für fast keine Architektur mehr ein Problem darstellt -solange Atmel sich nicht wieder mal verkalkuliert und sechs Monate Lieferzeit ausruft) Ach ja: Jobst M. schrieb: > Preislich nehmen sich ARM, AVR, PIC, MSP430 und 8051 nicht viel. Da von > Hubschraubern zu sprechen, finde ich unangemessen, auch wenn der ARM mit > der Aufgabe hoffnungslos unterfordert ist - die anderen sind es auch! Ich denke hier ging es weniger um den Preis, zumindest für Kleinststückzahlen oder Hobby spielt es keine Rolle ob ich 1,50 für einen CortexM0 oder 80ct. für einen kleinen PIC bezahle um mal die untere Größe zu nennen... ICh vermute eher das es hier um den Programmieraufwand ging. Und der "Overhead" an Einstellungen usw. ist bei den 32Bittern deutlich größer als bei den 8Bittern. Für einen Einsteiger halt nicht so leicht zu durchschauen. > Für das von Dir geschilderte Problem würde ich einen ATmega48 benutzen. > Der hat einen ADC und eine Hardware UART. Und ich würde es in ASM lösen. > Ich denke, auch in ASM ist das mit <40 Zeilen Code realisierbar. AVR kann man nehmen, ich würde halt aufgrund meiner Präferenz eher einen PIC vorschlagen. Typen ohne ADC oder UART muss man bei beiden Familien ja mittlerweile mit der Lupe suchen. > PIC scheidet für mich aus, da ich mich damit nicht auskenne. (Ich habe > damals die Finger davon gelassen, als ich die 'krummen' Registergrößen > gesehen habe.) Hier muss ich deinem Beitrag - dem ich ansonsten bis auf den Vorschlag ATMEGA voll zustimme- aber wiedersprechen. Krumme Registergrößen bei PIC? Das stimmt nicht so ganz, Je nach Familie hat der ganz normal 8, 16 oder 32Bit Register. Da hst du damals wohl einfach die Registergröße mit der Befehlswortbreite verwechselt. Die ist ja recht krumm! Allerdings hat der Anwender DAMIT nun wirklich absolut nichts zu tun! Das ist nur ein Architektonisches Detail... Gruß Carsten
Markus schrieb: > Kann mir jemand jetzt noch dazu gute Literatur empfehlen? Damals (tm) habe ich mit dieser Seite angefangen: http://www.avr-asm-tutorial.net/ (->deutsch) Das AVR-Assembler-Tutorial auf dieser Seite (http://www.mikrocontroller.net/articles/AVR-Tutorial) ergänzt sich damit sehr gut. Als erster Fallstrick könnte evtl. die "falsche" Interrupttabelle auftauchen. Die richtige Reihenfolge (und Anzahl der Einspungadressen) steht im Datenblatt des Controllers. Einfach sich die Beispiele ansehen und die eigene passende Interrupttabelle eintippen. (Oder man findet noch eine der älteren µC und kann das per Copy&Paste aus dem Tutorial übernehmen). Wenn die erste LED blinkt kommt dann der Rest von alleine... ;) Mirko
Markus schrieb: > A. B. schrieb: >> soll ja jeder machen wie er möchte, aber wer ungezwungen projekte mit >> mehr als ner DIN A4 seite quelltext in assembler schreibt, neigt wohl zu >> masochismus. und das bedeutet nicht im umkehrschluss, das man keine >> ahnung von der hardware haben muss/soll/braucht. > > Aber dazu meine Meinung. C Sprache ist sehr viel Computer und sehr wenig > E-Technik. > > Wenn ich mir die Tutorials für C anschaue, sehe ich erstmal nur > ausführbare Windows Programme. ein uC spezifisches tutorial sollte man sich natürlich schon anschauen
Carsten Sch. schrieb: > HAst du dir denn schon einen µC ausgesucht? > Einige sind ja schon genannt worden. Für den Einstieg würde ich auf > jeden Fall mal "tief" stapeln, also mit 8Bit µC anfangen. Danke für deinen Post, Carsten Sch. Zum Verständnis. Ist es tatsächlich ein Unterschied ob ich 8 bit oder 32 bit programmiere für mein Projekt oben?
>Zum Verständnis. Ist es tatsächlich ein Unterschied ob ich 8 bit oder 32 >bit programmiere für mein Projekt oben? nein
Hi >Ist es tatsächlich ein Unterschied ob ich 8 bit oder 32 >bit programmiere für mein Projekt oben? Nein. Bei deinem Projekt langweilt sich der Controller zu Tode. Das könnte man sogar mit einem 4-Bit-Controller erschlagen. MfG Spess
Markus schrieb: > Ist es tatsächlich ein Unterschied ob ich 8 bit oder 32 > bit programmiere für mein Projekt oben? Der Unterschied liegt im Einarbeitungsaufwand. Ein 8Bitter läuft einfach los. Beim 32Bitter mußt Du erstmal die PLL und die ganze Takterzeugung usw. programmieren. Beim 8Bitter gibst Du einfach nen Interrupt frei und schreibst den Handler an die festgelegte Einsprungadresse. Beim Einsprung löscht sich das Interruptflag automatisch. Beim 32Bitter ist die Interruptlogik fast ein eigenständiger Prozessor, bei dem es ne Menge zu programmieren gibt. Und auch die Handler müssen viele Sachen in einer ganz bestimmten Reihenfolge machen, damit Du wieder sauber den nächsten Interrupt kriegst. Und bei der sonstigen Peripherie sind ähnliche Unterschiede im Programmieraufwand. Beim 32Bitter hast Du also schon einige kB Initcode bevor das Programm richtig läuft. Peter
Hi, spess53 schrieb: >>Ist es tatsächlich ein Unterschied ob ich 8 bit oder 32 >>bit programmiere für mein Projekt oben? > > Nein. Bei deinem Projekt langweilt sich der Controller zu Tode. Das > könnte man sogar mit einem 4-Bit-Controller erschlagen. Also ich würde eher ein ganz klares JAIN zum besten geben. Oder Ausführlich: NEIN: Von Kapazität her spielt es an sich keine Rolle. Jeder halbwegs aktuelle µC mit 8 Bit wird sich wie geschrieben mit großer Wahrscheinlichkeit einfach nur fürchterlich Langweilen. Und der 32Bit µC langweilt sich dann noch ein ganzes Eckchen mehr. (Den 4Bit Controller und alte 8Bit µC würde ich so nicht 1-1 stehen lassen wollen da sich das zwar grundsätzlich realisieren lässt, diese alten Controller in der Regel aber noch kein On-Board UART haben und das deshalb alles in SW gemacht werden müsste, mit größerem Aufwand. Bei den 4Bittern würde dann noch dazu kommen das zum Übetragen eines UART Datums gleich zwei Registerinhalte abgefragt werden müsste. -> Ist aber Korintenkackerei) JA: Von der Schwierigkeit für einen Anfänger ist es schon ein Unterschied. Die 32Bit µC, egal ob MIPS(wie PIC32) oder ARM sind ein ganzes Stück mächtiger als die hier genannten 8Bit µC (Pic, AVR). Unter anderem gibt es in fast jeder hinsicht deutlich mehr Konfigrationsmöglichkeiten - Die dann aber auch ersteinmal alle abgearbeitet sein wollen! Auch bei den Direktzugriffen auf die Ports gibt es Unterschiede. Für einen Anfänger der es wirklich von der Pieke auf lernen will - was meiner Ansicht nach zwar die ersten Tage etwas steiniger ist als mit dingen wie BASIC anzufangen- ist der direkteinstieg mit 32Bit einfach ein wenig mächtig. Wenn es einem ausreicht einfach nur Copy&Paste zu machen und nur 90% des Programmcodes aus den Beispielprogrammen herauskopieren will ohne zu verstehen was das überhaupt ist, dann geht natürlich auch 32Bit direkt. Allerdings führt NUR der erste Weg dazu das man dann auch flexibel ist und Projekte verwirklichen kann für die es keine Lib gibt und das man dann auch mal bei Bedarf einen µC aus einer anderen Familie einsetzen kann und nicht auf ewig nur an eine Familie gebunden ist. Diejenigen die dann lauthals verkünden das der "steinigere" Weg ja blödsinn ist und man doch direkt mit BASIC oder "Arduino-C" anfangen sollte weil das schnelle Resultate bringt, das sind dann auch die Leute die hier regelmäßig auftauschen und schon Probleme bekommen wenn der µC bei selben Quarz dann statt 80Mhz nur mit 20Mhz läuft, oder die wochenlang herumdoktern weil das Programm einfach so langsam läuft ohne zu merken das in den Fusebits die PLL deaktiviert ist. Und so groß sind die ZEitunterschiede wirklich nicht. Lass es vielleicht 5 oder sechs lange NAchmittage für ein Grundlegendes Verständniss der HArdware von gängigen µC PLUS beherrschen der ASM Grundlagen sein, - Der Basic bzw. Arduino Nutzer hat dann zwar schon vier Tage seine LCDs am Leuchten, aber bei jeder Anforderung die nur ein wenig über Schema F hinausgeht wird er wieder ewig ins schleudern kommen... Für reines Hobby mag die zweite Alternative ausreichen, für jede etwas anspruchsvolle (berufliche) Tätigkeit aber sicher nicht. Gruß Carsten P.S.: eine Ergänzung noch zum Unterschied, unter dem Aspekt des Anwendungszwecks "Steuerung" vielleicht nicht ganz unwichtig: Bei den üblichen 8Bit µC kann man GENAU das Zeitverhalten anhand des ASM Quellcodes (Entweder direkt selbst geschrieben oder halt die Ausgabe des C Compilers) vorhersagen und auch "Einstellen". Bei den hier genannten 32Bit µC (ARM & MIPS) ist das nur recht eingeschränkt möglich da für viele Befehle die Ausführungszeit nicht exakt vorhersehbar ist und von äusseren Einflüssen abhängen kann. NAtürlich gibt es dann eine Menge anderer Wege ein halbwegs exaktes Zeitverhalten herzustellen, aber dazu muss man dann wieder die Grundlagen kennen.
da sich dieses Forum/Tutorial eigentlich hauptsächlich mit AVRs beschäftigt wurde es sich anbieten einen AVR zu nehmen. Ich würde auf jedenfall mit Assembler anfangen dadurch lernst du die Hardware viel besser lernen. Später kannst du immer noch C lernen umgekehrt würde ich sagen fehlt einem die Grundlage wenn man gleich mit C anfängt. Ich finde es immer wieder lustig wenn jemand schreibst der 2 kb Flash und seine 512 Byte RAM sind zu gering, für ein Programm das in Assembler nur 1/8 so groß ausfällt. Man muss sich hier sehr genau drum Kümmern ob z.b. eine Variable mit dem Wert 64 = 1 Byte nicht als Double Word 4 Bytes verarbeitet wird und auch entsprechend Platz reserviert wird.
MSP430, einen der 2-er Serie mit CodeComposer Studio5, da kann er mit GRACE relativ gut Konfigurieren.
Peter Dannegger schrieb: > Markus schrieb: >> Ist es tatsächlich ein Unterschied ob ich 8 bit oder 32 >> bit programmiere für mein Projekt oben? > > Der Unterschied liegt im Einarbeitungsaufwand. > Ein 8Bitter läuft einfach los. Beim 32Bitter mußt Du erstmal die PLL und > die ganze Takterzeugung usw. programmieren. Das kommt sehr stark auf die IDE an. Bei Crossworks z.B. wählt man einfach nur den µC aus und das Projekt lässt sich direkt compilieren und läuft, ohne das man irgendwas spezifisches einstellen müsste. Mit freeware wie Eclipse ist das ganze natürlich deutlich komplizierter. Trotzdem würde ich auch jedem erstmal einen ATMega empfehlen. Einfach weil z.B. die Komplexität der Funktionen deutlich geringer ist. Es gibt deutlich weniger Konfigurationsmöglichkeiten was die Fehlermöglichkeit stark verringert.
A. B. schrieb: > sorry, aber wem erscheint denn bitte assembler auf den ersten blick > > logischer & einfacher als eine hochsprache?! Demjenigen, der bisher auf der SPS mit der Anweisungsliste programmiert hat. Sieht genau so aus wie ein Assembler, die Befehle sind bloß anders.
Sebastian H. schrieb: > Bei Crossworks z.B. wählt man > einfach nur den µC aus und das Projekt lässt sich direkt compilieren und > läuft, ohne das man irgendwas spezifisches einstellen müsste. Klar kann man das auch alles vor dem Anwender verstecken. Allerdings ist das dann alles erstmal wieder eine "Blackbox", eigentlich nicht viel mehr als Bascom für BASIC-Hasser. ;-) Mit "wissen, was wirklich passiert" hat es jedenfalls nicht mehr viel zu tun. Gut gut, auch ein ARM läuft natürlich erstmal irgendwie und mit irgendeinem Takt los, ohne dass man die PLL anfasst. Trotzdem ist die Komplexität größer. Sowas wie der vorgeschlagene ATmega48 (oder ein beliebigens Pendant eines anderen Herstellers) sind da doch deutlich überschaubarer. 16 ist mehr schrieb: > Schon dieser FUSE > Kram zur Konfiguration ist nicht mehr zeitgemäß. Muss man allerdings eben auch gar nicht anfassen, um damit einfach nur arbeiten zu können. Das Argument der Fuses hält sich einfach nur hartnäckig, weil es sonst nicht viele Argumente gegen einen AVR (für ein Projekt dieser Dimension) gibt. ;-) Ich persönlich würde übrigens so ein Projekt allemal in C anfangen, allerdings bin ich notgedrungen voreingenommen, da ich C seit mehr als 20 Jahren benutze. Den Assemblercode seines Controllers sollte man sehr wohl verstehen (insofern gehe ich mit all denen, die den Assembler wegen des exakten Verständnisses für die Hardware hier empfehlen, mit), aber es ist dann doch noch ein großer Unterschied dazu, auch selbst ein entsprechendes Assemblerprogramm schreiben zu können.
Markus schrieb: > Es gibt sicher einfache Möglichkeiten, sich abrufbare Funktionen zu > programmieren? Ja. > Einen Baustein, welchen man mit einer einfachen > Call-Anweisung ablaufen lassen kann? Ja. > Wie schaut eine einfache bedingte Verzweigung im Assembler aus? > Beispiel. Ist PINB1 = 1 dann springe zu Funktion SendeBusStufe1. Ist > PINB 0 0, überspringe die CALL Funktion und checke PINB2
1 | ;SBIC – Skip if Bit in I/O Register is Cleared |
2 | ;Es wird der nächste Befehl übersprungen, wenn geprüftes Bit 0 ist. |
3 | |
4 | SBIC PINB, 1 |
5 | CALL SendeBusStufe1 ; es kann auch RCALL verwendet werden |
6 | SBIC PINB, 2 |
Gruß Jobst
Der Vormittag und halbe Nachmittag ist bisher drauf gegangen. Aber ein paar Zeilen habe ich geschrieben. Kann mir jemand eine Meinung dazu geben? Funktioniert, oder ist grober Müll den ich da getippt habe? Kann mir jemand noch Hilfestellung geben um dem µC die Baud-Rate beizubringen? die ersten 4 digits im MSB, den rest im LSB, bei 0 angefangen? /* * AssemblerApplication3.asm * * Created: 06.06.2012 09:39:51 * Author: Markus */ .def temp = R18 .equ F_CPU = 1843200 // Takt .equ BAUD = 9600 // Baud // Stackpointer Initialisieren .DEF Stack = R16 LDI Stack, HIGH(RAMEND); OUT SPH,Stack; LDI Stack, LOW(RAMEND); Out SPL,Stack; // Port B 0-7 Ausgang LDI R16, 0xFF; OUT DDRB, temp; // Port C 0-7 PullUps aktivieren OUT PORTC, temp; // Port C 0-7 Eingang LDI R18, 0x00; OUT DDRC, temp; Main: LDI R18, PINC SBRS R18, 1; RCALL UART_Stufe1; RJMP Main // UART Sende Stufe 1 UART_Stufe1: // Init zum Senden lds temp, UCSR0B; sbr temp, (1<<TXEN0); sts UCSR0B, temp; loop: ldi temp, 0x00 sts UDR0, temp rcall warten ldi temp, 0xFF sts UDR0, temp rcall warten ldi temp, 0xFF sts UDR0, temp rcall warten ldi temp, 0x00 sts UDR0, temp rcall warten ldi temp, 0xFF sts UDR0, temp rjmp Main warten: lds temp, UCSR0A sbrs temp, TXC0 rjmp warten ret
Benutze das nächste mal die [ avrasm ]Hier Code[ /avrasm ] - Tags (ohne Leerzeichen) Wieso definierst Du für den Stack ein eigenes Register? temp reicht dafür. > LDI R18, PINC wieso benutzt Du temp nicht? > lds temp, UCSR0B; > sbr temp, (1<<TXEN0); > sts UCSR0B, temp; Du brauchst kein Semikolon am Ende der Zeile. Setze UCSR0B einfach so, wie Du es haben möchtest. Allerdings würde ich die serielle Schnittstelle nur einmal am Programmanfang initialisieren. Am Ende Deiner 'loop:' (welche keine ist - wird die Sprungmarke irgendwo benötigt?) Wartest Du nicht mehr darauf, daß das Byte abgeschickt wurde. Solltest Du aber, denn das Programm ist oben wieder dabei das nächste Byte zu verschicken, obwohl das untere noch gar nicht weg ist. Viel wichtiger finde ich allerdings, daß Du hier mal genau beschreibst, was das Programm wirklich tun soll. Gruß Jobst
Hi >Kann mir jemand eine Meinung dazu geben? Diplomatisch oder brutal? 1. Welcher Controller? Denn für jeden Controller gibt es eine xyzdef.inc-Datei die mir .include "xyzdef.inc" am Anfang des Programms eingefügt werden muss. Sonst kann der Assembler mit z.B. sts UDR0, temp nichts anfangen. 2. >.def temp = R18 >.... >LDI R18, 0x00; Entweder du benutzt dieses def-Gedödel, dann sind die Registernamen tabu. Oder du benutzt nur die Registernamen. Das vermischen endet früher oder später, meist früher, in der Katastrophe. 3. >ldi temp, 0x00 >sts UDR0, temp >rcall warten Codebeispiele für USART-Initialisierung, -Senden und -Empfangen findest du im Datenblatt deines Controllers. MfG Spess
Markus schrieb: > .def temp = R18 > : > LDI R16, 0xFF; > OUT DDRB, temp; Ach ja: Das hier geht im übrigen in die Hose. Gruß Jobst
Ralph schrieb: > Jobst M. schrieb: >> Denn auch wenn man C lernt, empfiehlt es sich mit ASM den Controller >> erst mal kennen zu lernen. > > 1. geht das auch in C ganz gut. Die zusätzliche Schicht, die C hier drüber legt, macht die Sache nicht leichter, sondern oft schwieriger. Und es geht gar nicht so sehr um die Sprache C an sich, sondern vor allem um Eigenheiten des Compilers oder der Standardlibrary. Beispiel: Interrupthandler. Das Datenblatt beschreibt z.B. eine Tabelle mit Adreßzeigern oder JMP-Instruktionen und nennt die Adresse für jeden einzelnen Interrupt. In Assembler liegt genau eine ORG Anweisung zwischen dem Lesen des Datenblatts und der erfolgreichen Anwendung. Wenn man das gleiche in C machen will, muß man sich im Extremfall damit herumschlagen, wie man Code auf feste Adressen bindet und dem Compiler bestimmte Funktions-Prologe und Epiloge vorschreibt. Wenn man Erfahrung mit "C für Controller" hat, sucht man vielleicht gleich zielgerichtet nach dem C-Makro, mit dem man eine Funktion als ISR deklariert. Ganz davon zu schweigen, daß sich Makros und Namen für Interrupts über die Grenzen von Toolchains (und Targets) typischerweise auch noch unterscheiden. Vorteil durch Verwendung von C: Null. > 2. wie tief willst du da in den µC einsteigen ? Normal will man nur so tief einsteigen, daß man die zu verwendende Peripherie gebacken kriegt. Das ist in C genau gar nicht besser als in Assembler. > Mann muss in C gar nicht wissen wie eine Multiplikation einer 32 bit mit > einer 64 bit Zahl auf einem 8 bit µC gemacht wird. Das hat so gut wie gar nichts mit dem µC zu tun. ALUs haben sich seit dem 6502 nur sehr geringfügig weiterentwickelt. Praktisch gar nicht, wenn man von der Wortbreite absieht [1]. Die Implementierung von Arithmetik mit einer größeren Breite als der ALU-Breite ist Grundwissen. Und auch wenn nicht jeder Programmierer solchen Code selber schreibt, so sollten ihm zumindest die Implikationen bezüglich Speicherbedarf und Laufzeit vertraut sein. XL [1] Ja, OK. Es gibt heutzutage Barrel-Shifter und Hardware-Multiplikation. An der Außenansicht der ALU hat das wenig bis nichts geändert.
Jobst M. schrieb: > Viel wichtiger finde ich allerdings, daß Du hier mal genau beschreibst, > was das Programm wirklich tun soll. Sollte das Programm irgendwann Funktionieren soll es folgende Aufgaben lösen: Eingang, 4...20mA -> Digital auflösen. 5,6 mA Schaltstufe 1, 7,2, mA Schaltstufe 2 ... 20 mA Schaltstufe 10 Je nachdem welche Schaltstufe erkannt wird, soll ein 5 Byte langer Befehl über den UART verschickt werden. Die Befehle sind fix, brauchen keine Variablen. Es gibt 10 Verschiedene Befehle, welche sich so aufbauen: 0x00 0xFF 0xC3 var var [Startbyte] [Adressbyte] [Kommandobyte] [Datenbyte] [Checksumme] 8N1 bei 9600 Baud die Befehle unterscheiden sich nur im Datenbyte und Checksumme. Der Rest ist gleich. Mehr nicht. ;) Ich habe den ADC im Code erstmal ignoriert, das ist ne neue Baustelle für mich. MfG Markus Ich bin dankbar für jede Hilfe. Mein Ziel ist es, auf dauer den Code für solche Anwendungen selber ohne Copy und Paste schreiben zu können.
spess53 schrieb: > 1. Welcher Controller? > Denn für jeden Controller gibt es eine xyzdef.inc-Datei die mir die Include Datei hab ich auch mehrfach gelesen. Ich programmiere im Stuido6, ich denke das das Studio die automatisch inkludiert, denn alle Registernamen sind dem Programm bekannt. Controller ATMega 168A
Hi >Ich programmiere im >Stuido6, ich denke das das Studio die automatisch inkludiert, denn alle >Registernamen sind dem Programm bekannt. Stimmt. Aber deswegen benutze ich das Monstrum trotzdem nicht. Bringt für Assemblerprogrammierung keine Vorteile. >Sollte das Programm irgendwann Funktionieren soll es folgende Aufgaben >lösen: >..... Und jetzt zerlegst du das Ganze in schöne kleine Häppchen. Also z.B. - Uart-Initialisierung - 1 Byte senden - Befehl senden - ..... MfG Spess
So. Der kleine Quellcode hat 58 Zeilen bei 1209Byte und erzeugt 230Byte Code. Der große Quellcode (mit Kommentaren etc.) hat doppelte Zeilenzahl und die dreifache Größe. Erzeugt den selben Code. Ist ungetestet. Wenn Du etwas davon sehen möchtest, sag bescheid. Gruß Jobst
A. B. schrieb: > sorry, aber wem erscheint denn bitte assembler auf den ersten blick > logischer & einfacher als eine hochsprache?! Jedem, der mal eine Hochsprachen-Spezifikation komplett durchgelesen hat ;-)
ich sehe die Vorteile des Assemblers darin das ich genau weiß was passiert, wie lange das dauert, wieviel RAM dafür gebraucht wird... Außerdem kann ich einige Sachen ganz gezielt beeinflussen z.B. Programmcounter, Stackpointer, Stack. Bei C ist man da seinem Compiler und dessen Optimierungen ausgeliefert und kann das nie 100%tig sagen. Es sei den man deassembliert das Compilerergebnis, aber dann kann ich gleich mit Assembler arbeiten. Vorteile sehe ich bei einer Hochsprache bei größeren Berechnungen
Thomas O. schrieb: > seinem Compiler und dessen Optimierungen ausgeliefert Klingt ja gerade so als ob der Compiler an allen Ecken und Enden totalen Unfug erzeugen würde. Bei sauberer Programmierung gehen die Fälle in denen es Zweifel gibt doch auf ein Minimum zurück (extrem zeitkritische Geschichten, bei denen es auf jeden CPU-Takt ankommt, jetzt mal außen vor - da mag man mit ASM und genauer Kenntnis der genutzten Befehle und somit CPU-Zyklen besser dran sein).
Die Frage ist falsch formuliert.
Richtig heissen müsste es: "C" oder eine Programmiersprache?
"C" ist immer dann das Mittel der Wahl, wenn das Ergebnis der
Programmausführung bzw. dessen Funktion vollkommen egal ist. Auch wenn
einige pickelige Kellerkinder mit muskulösem rechtem Arm etwas anderes
behaupten, ist es vollkommen unmöglich, mit diesem Treppenwitz bzw.
Aprilscherz der EDV-Geschichte eine funktionierende Anwendung zustande
zu bringen.
...
10.2 Erfinder von UNIX und C geben zu: Alles Quatsch!
In einer Ankündigung, die die Computerindustie verblüffte, haben Ken
Thompson. Dennis Ritchie und Brian Kernighan zugegeben, daß das von
ihnen geschaffene Betriebsystem Unix und die Programmiersprache C ein
raffinierter Aprilscherz sind, der sich über 20 Jahre am Leben
erhalten hat. Bei einem Vortrag vor dem letzten
UnixWorld-Software-Entwicklungsforum enthüllte Thompson:
"1969 hatte AT&T gerade die Arbeit am
GE/Honeywell/AT&T-Multics-Projekt beendet. Brian und ich
experimentierten zu diesem Zeitpunkt mit einer frühen Pascal-Version
von Professor Niklaus Wirth vom ETH-Laboratorium in der Schweiz und
waren beeindruckt von seiner Einfachheit und Mächtigkeit. Dennis
hatte gerade "Der Herr der Klinge" gelesen, eine spöttische Parodie
auf Tolkiens Trilogie "Der Herr der Ringe". Im Übermut beschlossen
wir, Parodien zur Multics-Umgebung und zu Pascal zu verfassen. Dennis
und ich waren für die Betriebsystemumgebung verantwortlich. Wir sahen
uns Multics an und entwarfen ein neues System, das so komplex und
kryptisch wie möglich sein sollte, um die Frustation der
gelegentlichen User zu maximieren. Wir nannten es "Unix" in
Anspielung auf "Multics" und fanden es auch nicht gewagter als andere
Verballhornungen. Danach entwickelten Dennis und Brian eine wirklich
perverse Pascal-Version namens "A". Als wir bemerkten, daß einige
Leute tatsächlich versuchten, in "A" zu programmmieren, fügten wir
schnell einige zusätzliche Fallstricke hinzu und nannten es "B",
"BCPL" und schließlich "C". Wir hörten damit auf, als wir eine
saubere Uebersetzung der folgenden Konstruktion erhielten:
for(;P("\n"),R--;P("|"))
for(e=C;e--;P("_"+(*u++/8)%2))
P("|"+(*u/4)%2)
Der Gedanke, daß moderne Programmierer eine Sprache benutzen würden,
die solch eine Anweisung zuließ, lag jenseits unseres
Vorstellungsvermögens. Wir dachten allerdings daran, alles den
Sowjets zu verkaufen, um ihren Computerfortschritt 20 Jahre und mehr
zu behindern. Unsere Ueberraschung war groß, als dann AT&T und andere
US-Unternehmen tatsächlich begannen, Unix und C zu verwenden! Sie
haben 20 weitere Jahre gebraucht, genügend Erfahrungen zu sammeln, um
einige bedeutungslose Programme in C zu entwickeln, und das mit einer
Parodie auf die Technik der 60er Jahre! Dennoch sind wir beeindruckt
von der Hartnäckigkeit (falls nicht doch Gemeinsinn) des gewöhnlichen
Unix-und C-Anwenders. Jedenfalls haben Brian, Dennis und ich in den
letzten Jahren nur in Pascal und einem Apple Macintosh programmiert
und wir fühlten uns echt schuldig an dem Chaos, der Verwirrung und
dem wirklich schlechten Programmierstil, der von unserem verückten
Einfall vor so langer Zeit ausging."
Namhafte Unix- und C-Anbieter und Benutzer, einschließlich AT&T,
Microsoft, Hewlett-Packard, GTE, NCR und DEC haben vorläufig jede
Stellungnahme abgelehnt. Borland International, ein führender
Anbieter von Pascal- und C-Werkzeugen, einschließlich der polulären
Turbo Pascal, Turbo C und Turbo C++, meinte, sie hätten diesen
Verdacht schon seit Jahren gehegt und würden nun dazu übergehen, ihre
Pascal-Produkte zu verbessern und weitere Bemühungen um die
C-Entwicklung stoppen. Ein IBM-Sprecher brach in unkontrolliertes
Gelächter aus.
(Quelle: Bernhard L. Hayes, NetNews-Gruppe)
Hi Netter Beitrag, Egbert... Irgendwann wollte ich auch mal mit "C" anfangen, nicht auf µC, sondern vorher. Einfach nur, weil es eine Herausforderung gewesen wäre. Als ich mir dann den Syntax ansah, war mir klar: "Das ist eine Herausforderung" ... und so hab ich es gelassen. Sicherlich kommt die halbe Programmiereerwelt damit zurecht und sie hat sich an den Syntax gewöhnt, wie man sich auch an Fremdsprachen gewöhnt hat. Und wenn es sich herausstellen sollte, das "nur C" die Lösung eines Problems bedeutet, na ja, dann würd ich mich auch dadurch kämpfen. Aber solange es die Alternative Assembler gibt, bin ich da noch weit weg von. So, das sollte zur "Sprachempfehlung" reichen. Haben ja auch wirklich genug ihren Senf dazu gegeben. So, Markus, jetzt bist du dran. Lade dir, falls noch nicht geschehen, das AVR Studio herunter und lies und arbeite das Tutorial auf dieser Seite durch. (Links oben unter "AVR) Es hat mir bei meinem Anfang viel gegeben. Wenn du noch ein wenig weitere Hilfe brauchst, vielleicht hilft dir auch der Beitrag "Keine Angst vor Assembler" im Forum "AVR-Praxis.de" in der Rubrik "FAQ". Gruß oldmax
Vielleicht noch ein Hinweis. Bin mit Studio 6 nicht vertraut (Assembler mache ich in Studio 4 und die meisten C Sachen auch), aber der eingebaute Simulator ist gerade in Assembler sehr hilfreich. Er hat zwar seine Macken (vllt. in Studio 6 nicht mehr?), aber der direkte Blick auf Ports, MCU und all das andere Gedödel kann gerade am Anfang sehr hilfreich sein. Im Hintergrund das Datenblatt offenhalten, um da nachzulesen. Ausserdem solltest du dir unbedingt das grosse PDF mit dem AVR Befehlssatz runterladen und griffbereit haben, um das Verhalten von Flags, arithmetischen Operationen usw. zu beobachten. C ist für komplexere Sachen einfach übersichtlicher. Ich habe zwar auch mal ein DMX Pult in Assembler gemacht, aber das würde ich heute nicht mehr tun. Da die heutigen Compiler recht gut optimieren und der Flashspeicher der Chips immer grösser wird, ist Platzbedarf auch nicht mehr so unbedingt das Argument.
Jobst M. schrieb: > So. > > Der kleine Quellcode hat 58 Zeilen bei 1209Byte und erzeugt 230Byte > Code. > > Der große Quellcode (mit Kommentaren etc.) hat doppelte Zeilenzahl und > die dreifache Größe. Erzeugt den selben Code. > > Ist ungetestet. Wenn Du etwas davon sehen möchtest, sag bescheid. > > > Gruß > > Jobst 58 Zeilen? So einfach ist das? Hm. Ne Frage nebenbei, hast du dir dein Wissen selbst beigebracht oder im Studium? Ich würde gern etwas sehen. Nur wo anfangen? Wie hast du deinen Code strukturiert? In der Main Loop nur die Wertvergleiche mit Bedingter Sprunganweisung auf das entsprechende Unterprogramm? An der Codelänge schätze ich, du hast nur ein UART Senden unterprogramm? Wie füttest du die Variablen für die letzen Bytes ein? MfG Markus
Johann L. schrieb: > A. B. schrieb: >> sorry, aber wem erscheint denn bitte assembler auf den ersten blick >> logischer & einfacher als eine hochsprache?! > > Jedem, der mal eine Hochsprachen-Spezifikation komplett durchgelesen hat > ;-) > Wie gesagt, ich habe bisher nur SPS gemacht. Eine Hochsprache und Assembler habe ich nie gelernt. Zwar kann man SPS auch mit C Programmieren, aber darum hab ich bisher immer einen großen Bogen gemacht. Die SPS AWL ist ähnlich dem Assembler aufgebaut, nur hat Assembler das 10 fache an Befehlen und Fallstricken, zb. das ldi,ld,lds .. Die Register gibt es in ner SPS zwar auch, aber in einer anderen Form. Um ein vielfaches kleiner, abgespeckt und benutzerfreundlicher. ;) Bei SPS greift auf jedes Register mit einem Befehl zu.
ich würde mal behaupten, das jeder heutige compiler besser optimiert als 95% der standard-user hier und im allgemeinen...aber vielleicht hab ich auch zu wenig ahnung oder bediene meinen compiler einfach nur richtig. hier wird ja so getan, als ob man da ständig hinterher sein müsste und der compiler nach dem zufallsprinzip irgendwelche compilate ausspucken deren zeitverhalten, flashverbrauch & ramvebrrauch beliebig gewürfelt werden > ich sehe die Vorteile des Assemblers darin das ich genau weiß was > passiert, wie lange das dauert, wieviel RAM dafür gebraucht wird... > Außerdem kann ich einige Sachen ganz gezielt beeinflussen z.B. > Programmcounter, Stackpointer, Stack. klaro...beim 08/15 programm muss ich auch dauernd am stack & programmcountern rumfummeln. evtl. hilft es, sich mal den quelltext eines RTOS anzuschauen...da sind gewisse teile (eben stackfummelei etc.) in asm geschrieben aber der grosse rest doch in C. also irgendwo wird sich ne hochsprache schon bewährt haben... auch in der automobil industrie z.b. wo die programmierung sicherlich wesentlich sicherheitskritischer als bei irgendwelchen led-blinkern, heizungs&temperaturreglern etc. wird C eingesetzt(wenn auch nach besonderen standards ala MISRA usw.) aber klar...man programmiert grössere projekte lieber in ASM wie schon 1960
egbert schrieb: > "C" ist immer dann das Mittel der Wahl, wenn das Ergebnis der > Programmausführung bzw. dessen Funktion vollkommen egal ist. Oje, da hat jemand mal ne gründliche Bauchlandung gemach, weil er zu faul war, die Sprache zu lernen und einfach nur rumgeclickt und rumprobiert hat. Ging mir neulich genauso mit nem Flugzeug: Eingestiegen, paar Knöpfchen gedrückt und Hebelchen umgelegt. Hat schön geblinkt und gebrummt aber das Resultat war komplett zufällig. Scheiss Flugzeug. Wenn du dir mit dem Hammer ständig auf die Finger schlägst, dann ist nicht der Hammer schuld. Also lern erst mal worum es geht oder, anstatt bei jeder sich bietenden Gelegenheit dein unqualifiziertes "C = Zufall" loszulassen.
Hi
Leute, es ist doch völlig egal, in welcher Sprache jemand seine
Controller mit Aufgaben belegt. Auf den Menschen, der die Sprache
anwendet und seine Probleme in Anweisungen hinterlegt kommt es doch
schließlich an. Und wenn anschließend in einem Controller ein völlig
blödsinnig unübersichtlicher Spaghetticode werkelt, wenn der Controller
fehlerfrei seinen Job macht, interessiert's keinen. (vom Nachfolger, der
das Programm pflegen soll mal abgesehen...) Und Markus hat nicht
studiert, (nehm ich mal an) sondern ich vermute mal, eine Laufbahn in
Steuerungstechnik hinter sich. Er kann weder Assembler noch eine andere
Sprache, von daher muss er sowieso von Kleinauf lernen. Allerdings denke
ich, ist ein Steuerungsmensch vom Denken her anders.Bei ihm gehen noch
für die Bits die Lampen an und ein Befehl
LDI R16, 0b01010111
ist für ihn verständlicher wie
LDI Reg_A, ( 1 << WGM12 ) | ( 1 << CS10 )
Auch ich hab's mir in den späten Abendstunden selbst beigebracht und
beim Auftauchen solcher Befehle braucht's ein wenig, diese zu verstehen.
Übrigends weiß ich, das sie nicht vergleichbar sind und völlig
unterschiedliche Ergebnisse liefern, daher braucht's dazu keine
Belehrung. Soll ja auch nur verdeutlichen, das einer, der noch nie vor
einer Programmiersprache gesessen hat, hier schon Probleme bekommt.
@markus
Noch einmal
Ignorier nicht den Hinweis auf das Tutorial, denn da steht zu Baudraten
soetwas drin...1 | ;******************************************************************************** |
2 | ;* Die folgenden Zeilen definieren ein paar Constanten. Diese Werte werden nur * |
3 | ;* einmal vom Compiler zugewiesen. Danach werden sie nicht mehr verändert. * |
4 | ;******************************************************************************** |
5 | .EQU F_CPU = 1000000 ; Systemtakt in Hz |
6 | .EQU BAUD = 9600 ; Baudrate ; Berechnungen |
7 | .EQU UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden |
8 | .EQU BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate |
9 | .EQU BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille |
10 | |
11 | .if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ;max. +/-10 Promille Fehler |
12 | .error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!" |
13 | .endif |
Zeilen,, die mit einem Punkt beginnen sind keine Assembler-Anweisungen sondern Compiler-Direktiven. So setzt er überall, wo er "F_CPU" findet, den Wert "1000000" ein. Werden berechnete Werte zugewiesen, dann sind diese dann auch im Code für den Controller. Z.B. "UBRR_VAL"
1 | ;--------------- Serielle Schnittstelle parametrieren ------------------- |
2 | ;************************************************************************* |
3 | ;* Die Parametrierung ist mit dem Koppelpartner abzustimmen. * |
4 | ;************************************************************************* |
5 | INIT_UART: |
6 | LDI Reg_A, HIGH(UBRR_VAL) ; Baudrate einstellen |
7 | OUT UBRRH, Reg_A |
8 | LDI Reg_A, LOW(UBRR_VAL) |
9 | OUT UBRRL, Reg_A |
10 | ; Frame-Format: 8 Bit |
11 | LDI Reg_A, (1<<URSEL)|(3<<UCSZ0) |
12 | OUT UCSRC, Reg_A |
13 | SBI UCSRB, TXEN ; TX aktivieren |
14 | SBI UCSRB, RXCIE ; Interrupt bei Empfang |
15 | SBI UCSRB, RXEN ; RX (Empfang) aktivieren |
16 | RET |
17 | ;************************************************************************* |
Also,im Tutorial steht noch vieles mehr, was dir hilft, dein Ziel zu erreichen und lass die Diskussion, welche Sprache. Du siehst, das in den über 50 Beiträgen nur eine kleine Zahl wirklich hilfreich ist, weil sich die Mehrzahl darüber streitet, was einfacher zu erlernen ist und was die Firmen heut von ihren Mitarbeitern erwarten. Ich geb dir Brief und Siegel, das ein Spezialist im Assemblieren von Programmen immer noch hoch gefragt ist und er seine Programme ebenfalls in vergleichbarer Zeit wie ein "C"ler erstellt. Ach ja, ich rede hier von Spezialisten, denn das Schreiben macht nicht die Zeit, sondern Konzept erstellen und die Prüfungen. Gruß oldmax
A. B. schrieb: > ich würde mal behaupten, das jeder heutige compiler besser optimiert als > 95% der standard-user hier und im allgemeinen Ich hab etwa 10 Jahre 8051 Assembler gemacht, bin da also ziemlich fit. Und dann habe ich ein C-Projekt übernehmen müssen. Ich erzähl jetzt nicht die ganze Story, aber Fazit: - C braucht etwa 5..20% mehr Flash - C ist oft sogar schneller in der Ausführung - C ist erheblich schneller beim Programm schreiben - C ist wartbar und erweiterbar (Assembler überhaupt nicht) - C ist portabel (Routinen von 8051 nach AVR sind ruckzuck portiert). Insbesondere die Zeiteinsparung ist enorm. Wärend Villarriba (Assembler) noch Geschirr spült, feiert Villabacho (C) schon lange. Auch beeindruckend, man kann ein fremdes C-Projekt erweitern, ohne es neu schreiben zu müssen oder komplett verstanden zu haben. Peter
etwas anderer Ansatz. Bitte um Meinungen, Programmierfehler und Verbesserungen. ADC ist immernoch weggelassen. Dafür "simuliert" Eingangspins. Die Ports wurden absichtlich nicht parametriert. Danke! Markus
1 | /* |
2 | * AssemblerApplication1.asm |
3 | * |
4 | * Created: 07.06.2012 08:11:35 |
5 | * Author: Install |
6 | */ |
7 | |
8 | |
9 | .equ F_CPU = 1843200 |
10 | .equ BAUD = 9600 |
11 | .equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1) ; clever runden |
12 | .equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL+1))) ; Reale Baudrate |
13 | .equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000) ; Fehler in Promille |
14 | |
15 | .if ((BAUD_ERROR>10) || (BAUD_ERROR<-10)) ; max. +/-10 Promille Fehler |
16 | .error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!" |
17 | .endif |
18 | |
19 | .def temp = R16 |
20 | .def cmd = R17 |
21 | .def cs = R18 |
22 | // Init Stackpointer |
23 | |
24 | ldi temp, HIGH(RAMEND) |
25 | out SPH, temp |
26 | ldi temp, LOW(RAMEND) |
27 | out SPL, temp |
28 | |
29 | // Init UART |
30 | |
31 | lds temp, UCSR0B |
32 | sbr temp, 1<<TXEN0 |
33 | sts UCSR0B, temp |
34 | lds temp, UBRR_VAL |
35 | sts UBRR0H, temp |
36 | lds temp, UBRR_VAL |
37 | sts UBRR0L, temp |
38 | |
39 | |
40 | MainLoop: |
41 | |
42 | lds temp, PINC |
43 | sbrc temp, 0 |
44 | rjmp Stufe_0 |
45 | sbrc temp, 1 |
46 | rjmp Stufe_1 |
47 | sbrc temp, 2 |
48 | rjmp Stufe_2 |
49 | sbrc temp, 3 |
50 | rjmp Stufe_3 |
51 | |
52 | |
53 | rjmp MainLoop |
54 | |
55 | |
56 | |
57 | // UART Senden |
58 | |
59 | UART_Send: |
60 | |
61 | rcall checkTXR |
62 | lds temp, 0x00 |
63 | sts UDR0, temp |
64 | rcall checkTXR |
65 | lds temp, 0xFF |
66 | sts UDR0, temp |
67 | rcall checkTXR |
68 | lds temp, 0x9C |
69 | sts UDR0, temp |
70 | rcall checkTXR |
71 | sts UDR0, cmd // Variable aus Stufe_n unterprogramm |
72 | rcall checkTXR |
73 | sts UDR0, cs |
74 | rcall checkTXR |
75 | rjmp MainLoop |
76 | |
77 | checkTXR: // Warteschleife für Fertig-Flag |
78 | ldi temp, UCSR0A |
79 | sbrs temp, TXC0 |
80 | rjmp checkTXR |
81 | ret |
82 | |
83 | |
84 | Stufe_0: |
85 | ldi cmd, 0x80 |
86 | ldi cs, 0x1B |
87 | rjmp UART_Send |
88 | |
89 | Stufe_1: |
90 | ldi cmd, 0x9E |
91 | ldi cs, 0x39 |
92 | rjmp UART_Send |
93 | |
94 | Stufe_2: |
95 | ldi cmd, 0x3C |
96 | ldi cs, 0xD7 |
97 | rjmp UART_Send |
98 | |
99 | Stufe_3: |
100 | ldi cmd, 0x64 |
101 | ldi cs, 0xFF |
102 | rjmp UART_Send |
Code als Anhang, sonst scrollt man sich die Finger wund. Am besten aber nen neuen Thread, da das Thema ja nichts mehr mit "C oder Assembler" zu tun hat. Niemand antwortet gerne nur für eine Person. Daher muß das Topic zum Post passen. Peter
egbert schrieb: > Richtig heissen müsste es: "C" oder eine Programmiersprache? Nein: C, Assembler, oder eine Programmiersprache? ;-)
Markus schrieb: > 58 Zeilen? So einfach ist das? Hm. Wenn Du jetzt nur die 58 Zeilen sehen würdest, würdest Du vermutlich nichts verstehen. Dort sind selbst die Label anonymisiert ;-) > Ne Frage nebenbei, hast du dir dein Wissen selbst beigebracht oder im > Studium? Autodidakt. Ist aber eigentlich doch auch Studium :-D Ich programmiere seit 1982 - da war ich 12. > Ich würde gern etwas sehen. Nur wo anfangen? Wie hast du deinen Code > strukturiert? In der Main Loop nur die Wertvergleiche mit Bedingter > Sprunganweisung auf das entsprechende Unterprogramm? Ich verzweige nicht, ich rechne. Ich ziehe vom gewandelten Wert den Wert für 4mA ab. Sollte ein Überlauf dabei passieren, kann eine Fehlerbehandlung gemacht werden (<4mA). Dann Teile ich den Wert so, daß 20mA genau 10 ergeben. Es sollen doch 10 gleiche Abschnitte sein, wenn ich das richtig verstehe? Dieses Ergebnis multipliziere ich mit 5 (5 Byte pro Datenpaket) und addiere das wiederum zu der Staradresse meiner Wertetabelle. In dieser stehen hintereinander weg die einzelnen Datenpakete. Für die möglichen Werte 11-15 habe ich einfach noch 5 weitere Werte in die Tabelle geschrieben. Die Senderoutine sendet dann ab dieser Adresse einfach fünf Byte. > An der Codelänge schätze ich, du hast nur ein UART Senden unterprogramm? Nö. Steht einmal im Mainloop. > Wie füttest du die Variablen für die letzen Bytes ein? Stehen alle in der Tabelle. Ich sehe hier gerade noch Sparpotential :-D Peter Dannegger schrieb: > Am besten aber nen neuen Thread Dann aber hier verlinken! ;-) Muss los! Gruß Jobst
Hier ist der Thread, wo die konkrete Softwareumsetzung diskutiert wird: Beitrag "Assemblercode Hilfestellung (Anfänger)"
Dominik S. schrieb: > (extrem zeitkritische Geschichten, bei denen > es auf jeden CPU-Takt ankommt, jetzt mal außen vor - da mag man mit ASM > und genauer Kenntnis der genutzten Befehle und somit CPU-Zyklen besser > dran sein). Wer auf solche Fälle stößt, hat ein grundlegendes Problem mit seinem Projekt. Das heißt schlicht und einfach das entweder das Softwaredesign untauglich ist, und / oder der µC zu schwach ist. ==> zu Projektbeginn nicht richtig analysiert WAS eigentlich gebraucht wird um das Projekt bewältigen zu können. Thomas O. schrieb: > ich sehe die Vorteile des Assemblers darin das ich genau weiß was > passiert, wie lange das dauert, wieviel RAM dafür gebraucht wird... > Außerdem kann ich einige Sachen ganz gezielt beeinflussen z.B. > Programmcounter, Stackpointer, Stack. Und beim Autofahren stellst du auch permanent die Ventile neu ein, und änderst während der Fahrt den Luftdruck der Reifen,....... Für was Brauchst du das denn ????? Das kann ein Hochsprachen Compiler bedeutend besser und sicherer verwalten als 99% der selbsternannten Assemblergurus. A. B. schrieb: > auch in der automobil industrie z.b. wo die programmierung sicherlich > wesentlich sicherheitskritischer als bei irgendwelchen led-blinkern, > heizungs&temperaturreglern etc. wird C eingesetzt(wenn auch nach > besonderen standards ala MISRA usw.) Und zwar fast ausschließlich. Ich programmiere beruflich Software für ESP Systeme. Die einzigen Codebereiche die dort in Assembler geschrieben sind, ist der Scheduler des RTOS, und dort auch nur der Teil der die Taskumschaltung auf Registerebene ausführt, sowie die Behandlung von Exceptions wie zb Zugriffe auf ungültige Adressbereiche. Alles in allen weniger als 0,1% der gesamten Codes und warum ist das so ? 1. Assembler lässt sich nicht mit formalisierten Prüfalgorithmen wie zb die MISRA Standards prüfen. ==> Zuverlässigkeit / Sicherheit 2. Die Implementierung und Validierung des Codes dauert viel zu lange im Vergleich zu C ==> Kosten 3. Wechsel des µC, selbst innerhalb einer Familie benötigen ein vielfaches der Arbeit zur Codeanpassung als das in C der Fall ist. ==> Kosten 4. Der C Code lässt sich in Simulationen auch unabhängig des µC prüfen und testen. ==> Zuverlässigkeit / Sicherheit 5. Bedeutend geringere Gefahr für fehlerhaftes Softwareverhalten aufgrund der abstrakteren Programmierung. ( der Compiler wird eine Logik immer identisch ins Assembler übersetzen, wenn das jedes mal von Hand gemacht wird, ist das nicht sichergestellt). ==> Zuverlässigkeit / Sicherheit 6. Der Compiler ist auf den µC optimiert. Die Entwickler des Compilers haben da mit Sicherheit mehr Fachwissen wie sich der µC wann verhält als der Programmierer der meint das er als Einzelperson besser ist als ein ganzes Team das einen qualifizierten Compiler erstellt. ==> Zuverlässigkeit / Sicherheit ==> Assembler nur da wo es keine Alternative gibt. Assembler so Viel wie notwendig, so Wenig wie möglich. Das heißt aber auch, das Assembler für einen Programmierer in solchen µC Systeme kein Fremdwort sein darf. Aber die Masse der Arbeit läuft in C.
Johann L. schrieb: > egbert schrieb: > >> "C" ist immer dann das Mittel der Wahl, wenn das Ergebnis der >> Programmausführung bzw. dessen Funktion vollkommen egal ist. > > Oje, da hat jemand mal ne gründliche Bauchlandung gemach, weil er zu > faul war, die Sprache zu lernen und einfach nur rumgeclickt und > rumprobiert hat. > ... > Wenn du dir mit dem Hammer ständig auf die Finger schlägst, dann ist > nicht der Hammer schuld. > Nett und zutreffend gesagt, ABER Johann L. schrieb: > Also lern erst mal worum es geht oder, anstatt bei jeder sich bietenden > Gelegenheit dein unqualifiziertes "C = Zufall" loszulassen. Glaubst du wirklich bei jemanden der einen ARTIKEL der nun schon vor fast 20 Jahre in einer Computerzeitschrift als APRILSCHERZ veröffentlicht wurde und seit Jahren auf allen Witzseiten mit IT Bezug durchs Netz geistert scheinbar für bare Münze nimmt noch Lernfähigkeit erwarten zu können? Der Originaltext ist im übrigen unter "C Hoax" an zahlreichen Stellen im Netz zu finden... Gruß Carsten
hier mal ein schönes Bsp. lol Beitrag "Problem mit Stackpointer" möge jeder für sich entscheiden wie der Einstieg leichter fällt. :->>>
Na zum Glück muss man auch mit ASM nicht so besch... programmieren :) Aber trotzdem. Einfach mal auf Peter&Ralph hören. Und wie gesagt...wenn man im Hobbybereich Spass an ASM hat, gerne so kompliziert&minimalistisch programmiert wie möglich dann spricht da ja nix gegen. Aber sobald andere Menschen den Quellcode auch verstehen sollen, und evtl. mal ne Änderung durchführen müssen, dann ist ASM sicherlich nicht die zu bevorzugende Sprache
ich denke mal das es unbestritten ist das sich C leichter lesen läßt als ASM. Allerdings hat man bei beiden noch die Möglichkeit Bausteine zu kommentieren. Der Vorteil von C ist ja wohl die Portierbarkeit also kann man leicht auf einen neuen µC oder Mitarbeitet umswitchen. Weitere Vorteile sehe ich in komplexen Berechnungen das ist in ASM dann doch etwas aufwändiger wenn man sehr viele Formeln zu rechnen hat. Einen größeren µC zu nehmen halte ich für die letzte Lösung, lieber sollte man sich Gedanken machen, möglichst sparsam mit Ressourcen umzugehen, dann bräuchten wir heute auch keinen Quadcores um zu vertuschen das das Betriebssystem elend langsam geworden ist. Da heute aber fast jeder C benutzt kommen dann so Kommentar wie, da muss man halt den µC 2-3 Nummern größer wählen. Du begehst 100% keinen Fehler mit ASM anzufangen und später auf C zu wechseln.
Ralph schrieb: > 1. Assembler lässt sich nicht mit formalisierten Prüfalgorithmen wie zb > die MISRA Standards prüfen. ==> Zuverlässigkeit / Sicherheit Dabei darf man nicht vergessen, dass MISRA hauptsächlich Empfehlungen enthält, um die im C-"Standard" enthaltenen Interpretationsfreiräume zu beschränken und damit C überhaupt erst mit MISRA zu einer sauber spezifizierten Programmiersprache wird. Erst mit diesen Nachbesserungen/Beschränkungen wird das Verhalten von C-Compilern überhaupt eindeutig und damit ein vorhersagbares Programmverhalten möglich.
Thomas O. schrieb: > Der Vorteil von C ist ja wohl die Portierbarkeit also kann man leicht > auf einen neuen µC oder Mitarbeitet umswitchen. Ein Vorteil von C ist auch, dass bestimmte Routineoperationen durch den Compiler abgenommen werden, und dieser aufgrund seiner hinterlegten Vorschriften eben in diesen keine eigenen Fehler mehr macht. Die logische Umsetzung eines simplen "if (x > y)" kann im Assembler halt in sowas ausarten wie "überspringe den nächsten Befehl nicht, wenn die Bedingung wahr ist, und benutze als nächsten Befehl einen Sprung, weil dieser ein weiter entferntes Ziel erreichen kann als ein Branch". Bei einer Assemblerprogram- mierung hat man gute Chancen, in so eine doppelte oder dreifache Negation schnell einen Denkfehler einzubauen. > Einen größeren µC zu nehmen halte ich für die letzte Lösung Jein. Du erkaufst damit u. U. einfach Wartungsfreundlichkeit und eine effizientere (im Sinne von: schneller fertig werden) Program- mierung. Wenn der nächstgrößere Controller nur zwei oder drei Euro mehr kostet, du aber stattdessen für das minimalistische Programm statt zehn Stunden Arbeit dann fünfzig Stunden in Assembler programmierst und debuggst, dann würde ich für ein Einzelstück allemal dem nächstgrößeren Controller den Vorzug geben. Wenn man für Serien von 10000+ Stück bauen muss, sieht die Sache natürlich völlig anders aus. A.T. schrieb: > und damit C überhaupt erst mit MISRA zu einer sauber > spezifizierten Programmiersprache wird. Nein, sauber spezifiziert ist sie so auch. MISRA verbietet nur die Nutzung bestimmter Konstrukte, die in der Vergangenheit als Fehlerquellen (der Programmier wohlgemerkt) bekannt geworden sind. (Inwiefern davon vieles noch zeitgemäß ist oder nicht durch verbesserte Warnmöglichkeiten aktueller Compiler ohnehin überflüssig, steht auf einem anderen Blatt geschrieben. MISRA lebt noch auf einem mittlerweile mehr als 20 Jahre alten Standard.) Die Alternative in Richtung Hochsprache wäre wohl stattdessen Ada, um vergleichbare Probleme möglichst von vornherein zu vermeiden.
Thomas O. schrieb: > Einen größeren µC zu nehmen halte ich für die letzte Lösung, lieber > sollte man sich Gedanken machen, möglichst sparsam mit Ressourcen > umzugehen, dann bräuchten wir heute auch keinen Quadcores um zu > vertuschen das das Betriebssystem elend langsam geworden ist. Da heute > aber fast jeder C benutzt kommen dann so Kommentar wie, da muss man halt > den µC 2-3 Nummern größer wählen. nur leider wird dabei oft unter den teppich gekehrt, das heutige betriebssysteme um einiges mehr bieten (komfortfunktionen) das sowas leistung schluckt ist ja normal. selbst das achso effiziente linux macht heute auf nem x486 auch keinen spass mehr(bzw es läuft da nicht mal mehr unbedingt).
A. B. schrieb: > selbst das achso effiziente > linux macht heute auf nem x486 auch keinen spass mehr(bzw es läuft da > nicht mal mehr unbedingt). Du kannst Dir jederzeit aus aktuellen Sourcen einen Kernel konfigurieren/bauen, der aus Deinem 486-25SX mit 4MB RAM das Optimum raus holt. :-) Nur wirst Du keinen solchen Kernel vorkompiliert in einer aktuellen Linux-Distribution finden. :-D
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.