www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Erstaunen über Unterschiede von PIC und Atmel


Autor: Florian H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stephan Henning (stephan-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Nullpainter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Clifford (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mthomas (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
>> 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

Autor: alex (Gast)
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: karl (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
alex schrieb:
> Kennt jemand von euch ein Converter von Assembly to C programm.
Ich bin mit Brain v1.0 bist jetzt gut gefahren.

Autor: Dampfnilp (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
>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.

Autor: Reiner O. (elux)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
@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.

Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.