Hallo Zusammen, ich muss mir mal gerade mein Erstaunen über die Unterschiede zwischen der PIC und der Atmel Programmierung in C von der Seele schreiben. Wir haben an der FH einen PIC 12F675 mit CCS C-Compiler programmiert. Nun spiele ich mit einem ATMega32 herum und habe mir das AVR-GCC-Tutorial durch gelesen. Ich bin doch sehr überrascht wie viel Hardware näher bzw. Assembler artiger in C mit GCC programmiert wird. Ich sehe momentan zwar nicht den direkten Vorteil, da ich mich mit dem ATMega aber das nächste halbe Jahr im Praxissemester beschäftigen werde, bin ich zuversichtlich diese bald zu erkennen. ;) Die krassen Unterschiede kommen ja nun aber, soweit ich das erkennen kann, nicht durch die Hardware der Controller an sich, sondern eher durch die Compiler zustande, oder wie seht ihr das? Ich will mal als Beispiel die Interrupt Routinen nennen. Im Tutorial für den GCC findet sich folgendes Fragment: uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) sichern Erinnere ich mich falsch wenn ich denke das der PIC oder CCS-C diese "Sicherungsarbeiten" selbstständig vornimmt? Mir kommt GCC vor wie ein aufgehübschtes Assembler, bei dem man sich doch noch ganz ordentlich um die Hardware Aktionen kümmern muss. Daran finde ich so erstaunlich das eine Programmiersprache ja auch dazu dienen soll Programme portierbar zu gestalten. Dem sind natürlich bei µCs , auf Grund der unterschiedlichen Architekturen und Hardware enge Grenzen gesetzt, dass die Unterschiede aber so krass ausfallen hätte ich nicht gedacht. Wir das Rad bei den Compilern einfach immer wieder neu erfunden oder gibt es gute Gründe für diese großen Unterschiede? Gruß Florian
:
Gesperrt durch Moderator
@ Florian H. (Gast) >ich muss mir mal gerade mein Erstaunen über die Unterschiede zwischen >der PIC und der Atmel Programmierung in C von der Seele schreiben. Erleichtere deine Seele, mein Sohn. ;-) >Ich will mal als Beispiel die Interrupt Routinen nennen. Im Tutorial für >den GCC findet sich folgendes Fragment: > uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister > tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) >sichern >Erinnere ich mich falsch wenn ich denke das der PIC oder CCS-C diese >"Sicherungsarbeiten" selbstständig vornimmt? Macht der GCC auch! Das ist scheinbar ein Vorkriegsfragment. Gibt ne 1 für dich für Mitdenken. >Mir kommt GCC vor wie ein aufgehübschtes Assembler, bei dem man sich >doch noch ganz ordentlich um die Hardware Aktionen kümmern muss. Nanana, lass das mal nciht die grossen Jungs hören. ;-) MFG Falk
Florian H. wrote: > Ich will mal als Beispiel die Interrupt Routinen nennen. Im Tutorial > für den GCC findet sich folgendes Fragment: > uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister > tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) > sichern > Erinnere ich mich falsch wenn ich denke das der PIC oder CCS-C diese > "Sicherungsarbeiten" selbstständig vornimmt? Das macht der GCC in einer ISR auch selbst. Du musst dich also beim Schreiberling obigen Codes beklagen. Vielleicht wollt er ja extra demonstrieren, dass man das auch mittels __attribute__((naked)) selbst zu Fuß erledigen kann? Keine Ahnung, müsstest mal eine URL posten, wo das so geschrieben steht. > Mir kommt GCC vor wie ein aufgehübschtes Assembler, bei dem man sich > doch noch ganz ordentlich um die Hardware Aktionen kümmern muss. Das stimmt nur insofern, als dass C natürlich an sich kein übermäßig hohes Abstraktionsniveau hat. Das hat Vor- und Nachteile: wenn Dennis Ritchie 1970 Java statt C erfunden hätte, würden wir vielleicht heute noch die Betriebssysteme in Assembler schreiben. ;-) Ansonsten ist das Einzige, was GCC einfach überhaupt nicht kann der Umgang mit den verschiedenen Speicherbereichen der Harvard- Architektur. Daher muss man sich um das Handling von ROM-Daten mehr zu Fuß drum kümmern als bei anderen Compilern (auch solchen für den AVR). > Daran finde ich so erstaunlich das eine Programmiersprache ja auch > dazu dienen soll Programme portierbar zu gestalten. Das geht nur über einen vernünftige HAL (hardware abstraction layer), in den man ziemlich viel Arbeit reinstecken darf, wenn er einerseits portabel und andererseits effizient sein soll. Aber es geht, wenn man will.
> Das stimmt nur insofern, als dass C natürlich an sich kein übermäßig > hohes Abstraktionsniveau hat. Das hat Vor- und Nachteile: wenn Dennis > Ritchie 1970 Java statt C erfunden hätte, würden wir vielleicht heute > noch die Betriebssysteme in Assembler schreiben. ;-) oh ja bitte bitte, nicht auszudenken was ein PC bei 1 Ghz dann alles leisten könnte.... Den müßte man dann wohl mit ner Schraubzwinge am Tisch festklemmen ..Grins
Vergiss die Portierbarkeit von C Programmen. Wenn ein Problem fuer einen PIC geloest wurde, so wirst du's nicht fuer n AVR nochmals machen wollen, auch wenn die Peripherie scheinbar identisch ist. Auf'n PC portiert man auch nicht. Dort hat man ganz andere Programmierstile. Umgekehrt von einem PC auf einen Controller geht auch nicht. Dabei seine Trivialitaeten wie Hex nach Binaer ausgenommen. Aber das kann man auch in ASM neu schreiben ohne viel Zeit verloren zu haben.
C portieren? Klar, reinstes ANSI C mit Verzicht auf jegliche Verbindung zur Außenwelt. Nichtmal printf/scanf bringen dich auf einem Mikrocontroller weiter ohne systemspezifischen Code. Ein Portbit setzen ist ohne den bereits erwähnten HAL zu systemspezifisch und damit nicht mehr portabel
Stephan Henning wrote: >> Das hat Vor- und Nachteile: wenn Dennis >> Ritchie 1970 Java statt C erfunden hätte, würden wir vielleicht heute >> noch die Betriebssysteme in Assembler schreiben. ;-) > oh ja bitte bitte, > nicht auszudenken was ein PC bei 1 Ghz dann alles leisten könnte.... Er bräuchte auf Grund der 10mal so vielen Bugs dann nur noch 10 Minuten zum Abstürzen. :-o SCNR...
Jörg Wunsch wrote: > Ansonsten ist das Einzige, was GCC einfach überhaupt nicht kann der > Umgang mit den verschiedenen Speicherbereichen der Harvard- > Architektur. Daher muss man sich um das Handling von ROM-Daten mehr > zu Fuß drum kümmern als bei anderen Compilern (auch solchen für den > AVR). Es gibt noch etwas anderes was er nachweislich nicht so gut kann wie die proprietäre Konkurrenz: Der Erwartungshaltung etlicher Anwender entsprechen, die davon ausgehen, dass der Maschinencode hinten genauso und insbesondere in gleicher Reihenfolge und allen Speicherzugriffen rauskommt, wie der C Code es suggeriert.
Andreas Kaiser wrote: > Jörg Wunsch wrote: > >> Ansonsten ist das Einzige, was GCC einfach überhaupt nicht kann der >> Umgang mit den verschiedenen Speicherbereichen der Harvard- >> Architektur. Daher muss man sich um das Handling von ROM-Daten mehr >> zu Fuß drum kümmern als bei anderen Compilern (auch solchen für den >> AVR). > > Es gibt noch etwas anderes was er nachweislich nicht so gut kann wie die > proprietäre Konkurrenz: Der Erwartungshaltung etlicher Anwender > entsprechen, die davon ausgehen, dass der Maschinencode hinten genauso > und insbesondere in gleicher Reihenfolge und allen Speicherzugriffen > rauskommt, wie der C Code es suggeriert. Wenn man das will braucht man auch keinen Compiler, sondern einen Assembler ;) Ein sehr gutes Beispiel für plattformunabhängigen Code ist (finde ich) die FAT-Implementierung von elm-chan. Da müssen die Funktionen zum Initialisieren und Schreiben/Lesen angepasst werden, der ganze Rest funktioniert ohne Änderungen auf diversen Controllern und PCs.
>> uint8_t tmp_sreg; // temporaerer Speicher fuer das Statusregister >> tmp_sreg = SREG; // Statusregister (also auch das I-Flag darin) >> sichern>> Erinnere ich mich falsch wenn ich denke das der PIC oder CCS-C diese >> "Sicherungsarbeiten" selbstständig vornimmt? >Das macht der GCC in einer ISR auch selbst. Du musst dich also beim >Schreiberling obigen Codes beklagen. Vielleicht wollt er ja extra >demonstrieren, dass man das auch mittels __attribute__((naked)) selbst >zu Fuß erledigen kann? Keine Ahnung, müsstest mal eine URL posten, wo >das so geschrieben steht. Kommentar vom "Schreiberling": Die besagten Zeilen aus dem Tutorial habe ich wahrscheinlich verbrochen. (Jörg: gemeint ist wohl http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial , zumindest gibt es die Zeilen darin). Aber die zitierten Zeilen sind aus dem Zusammenhang gerissen und wurden fehlinterpretiert: Es handelt sich um ein Beispiel, wie man Interrupts zwischen Anweisungen verhindert ("atomar machen") und dabei nicht darauf achten muss, ob Interrupts vorher gesperrt oder freigegeben waren. Die nicht-kopierten Codezeilen und der Plappertext des Artikels erläutern dies auch - hoffentlich, falls nicht gut genug: es ist ein Wiki-Artikel, also jeder kann verbessern. Martin Thomas
Hallo, Kennt jemand von euch ein Converter von Assembly to C programm.Ich bin leider ein null was programmieren angeht aber brauche das unbedingt.ich hoffe dass jemand mir helfen kann.mfg
Hi >Kennt jemand von euch ein Converter von Assembly to C programm.Ich bin >leider ein null was programmieren angeht aber brauche das unbedingt.ich >hoffe dass jemand mir helfen kann.mfg Nein. Lern C oder benutze Assembler. MfG Spess
alex schrieb: > Kennt jemand von euch ein Converter von Assembly to C programm. Ich bin mit Brain v1.0 bist jetzt gut gefahren.
>Daran finde ich so erstaunlich das eine Programmiersprache ja auch dazu
dienen soll Programme portierbar zu gestalten.
Willkommen in der Realitaet. Ein schoener Traum. Ist allerdings kein
spezieller Makel von C. Andere Sprachen haben das auch so.
Allerdings vermarktet nur C diesen Traum so gnadenlos.
spess53 schrieb: > Hi > >>Kennt jemand von euch ein Converter von Assembly to C programm.Ich bin >>leider ein null was programmieren angeht aber brauche das unbedingt.ich >>hoffe dass jemand mir helfen kann.mfg > > Nein. Lern C oder benutze Assembler. > > MfG Spess Hallo Spess, Wie immer: kurz und knackig. ;-) Der arme Kerl will doch nur die Ausgaben des z.B. Ollydebuggers ("Assembly") verstehen. "RTFM" würde ich sagen... ;-) Gruss aus Beijing Elux
@alex: Ist es so schwer, für etwas, was exakt NULL mit dem Threadthema zu tun hat und auch noch lockere sieben Jahre nach der letzten Antwort gefragt wird, einen eigenen Thread aufzumachen? Ihr beraubt Euch mit solch einem Vorgehen nur vernünftiger Antworten.
Thread beobachten
Seitenaufteilung abschalten