C für 8051

[Marco Budde]

Rafael Deliano wrote:

Du willst Dir "Kernighan & Ritchie, Programmieren in C,
2. Aufl." kaufen.
Die Programmiersprache C ist nicht eben leicht erlernbar

Hängt vom Grundlagenwissen und von Lehrmaterial ab.

und dieses Buch ist als Einführung eher unangenehm.

Warum?

Es wurde ehdem immer empfohlen, weil es kaum Alternativen
gab.

Ich würde dieses Buch uneingeschränkt empfehlen. Es
wird IHMO alles sehr anschaulich erklärt.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-a@linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de

 

[Andreas Schwarz]

Stefan Wagner wrote:

Gerald Oppen <Gerald.Oppen@web.de> wrote:
Die Frage ist noch, warum es ein 8051 sein muss...

Würde einen Controller wählen, der mit kostenlosen Tools Echtzeit-
debugging auf Sourcecode und Assemblerebene unterstützt...

das würde mich auch interessieren. Welche Controllerfamilien wären das?

MSP430, evtl. auch AVR.

--
AVR-Tutorial, über 350 Links
Forum für AVRGCC und MSPGCC
-> http://www.mikrocontroller.net

 

[Olaf Kaluza]

Tilmann Reh <tilmann.reh@autometer.de> wrote:

A propos C: "Millionen fliegen können nicht irren."
C ist zur Zeit eben Mode, ob es eine "gute" Sprache ist, sei mal
dahingestellt...

Zur Zeit? Ich wuerde mal sagen das diese Sprache mittlerweile die
groesste Konstanz und Haltbarkeit hat. Irgendwelche anderen Sprachen
werden immer mal kurz Mode und verschwinden dann wieder.

Lachen muss ich z.B immer ueber den alle 1-2 Jahren stattfindenden
Smalltalk Artikel in der C't bevor wieder alles im Tiefschlaf versinkt.


Olaf


--
D.i.e.s.S. (K.)

 

[Olaf Kaluza]

Rafael Deliano <Rafael_Deliano@t-online.de> wrote:

fertig wird, denn es gibt ja genug. Heute darf der einzelne C-Coder
wohl eher auf 10 Stunden Tag und Samstagsschicht machen, weil kein
Geld mehr da ist ganze Rudel von Programmierern zu beschäftigen.

Dazu gehoeren immer zwei. :-]

Olaf


--
D.i.e.s.S. (K.)

 

[Joachim Riehn]

W. Wipfel wrote:

"jetmarc" schrieb im Newsbeitrag
Ich habe keinerlei Vorkenntnisse in C (Ass und Basic schon) !
Dann solltest Du nicht direkt (alleinig) mit dem 8051 anfangen.
Wenn etwas nicht klappt, weisst Du sonst nicht warum. Auf jeden
Fall parallel auch einen Compiler auf dem PC benutzen, wo Du
ausfuehrliche Meldungen anzeigen kannst (gerade am Anfang).

Hallo Willi,
vor einigen Wochen hast du ziemlich genau dieselbe Frage
gestellt und ziemlich genau die gleichen Antworten
erhalten. Die Sprache C beisst nicht, kratzt nicht und
verursacht meines Wissens keinerlei körperliche
Schmerzen.
Wenn du C auf einem PC-Compiler lernst, wirst du
nach spätestens 30 Minuten einfache Bit-Manipulationen
durchführen. Du wirst sehr schnell motiviert sein.
Es ist wirklich egal, ob du dir deine Bitmuster
auf dem Bildschirm ausgeben lässt oder später
auf den 8051er Ports.

Ich will gerade deswegen .. das machen, weil ich
mich mit der Hardware einigermaßen auskenne.

Um so besser! Um eines kommst du halt nicht herum:
Du musst halt bei einigen einfachen Programm-Schnipseln
sehen, wie dein 8051-Compiler in Assembler
übersetzt (um ein Gefühl für den Compiler zu bekommen).

Gruss
Joachim Riehn

 

[Marco Budde]

Tilmann Reh wrote:

C ist zur Zeit eben Mode,

In der Mode? Diese Sprache ist über 20 Jahre alt. Modesprachen
sind eher Java (inzwischen wieder out) und C#.

ob es eine "gute" Sprache ist, sei mal
dahingestellt...

Für den Embedded Bereich ist C eine gute Sprache. Auf
anderen System dann durch C++ ersetzt.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-a@linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de

 

[Rafael Deliano]

"Kernighan & Ritchie, Programmieren in C, 2. Aufl."
Ich würde dieses Buch uneingeschränkt empfehlen. Es
wird IHMO alles sehr anschaulich erklärt.
Die englische Ausgabe ist eine Bleiwüste ohne

bildliche Illustrationen die Features anhand von
Beispielen runterleiert.
Brodies "Starting FORTH", das offizielle Einführungs-
buch von FORTH Inc., ist dagegen praktisch ein Comic:
da treiben sich SWAP-Drachen und Scharfrichter rum.
Dergestalt, daß sich Hochschullehrer in den USA geweigert
haben es in Einführungskursen für FORTH zu verwenden,
weil es ihre akademiologische Würde angekratzt hätte.
Es geht also auch deutlich anders.

MfG JRD

 

[Matthias Weißer]

W. Wipfel wrote:

Bei RISC Architektur (AVR, PIC) mag das ja stimmen....
aber was 8051 angeht war es so nicht geplant.
Die Dinger kamen auf den Markt bevor C so richtig
erwachsen war.
Die AVR und die PIC sind für C zwar eher geignet, aber

PIC? In C? Prust!
Die Architektur der PIC's ist älter als die der 8051er.

ich brauch C nun mal wegen der Komplexität der
Aufgabenstellung. BASIC zu unflexibel, ASS zu umständlich
für diesen Fall.....

Und ich schrieb ja das C _die_ Hochsprache für ľC ist. Alles andere ist
Flickwerk. Ob C jetzt für 8051 geeignet ist oder nicht es wird verwendet.
Und so schlecht sind die C-Compiler für 8051 dann auch wieder nicht. Selbst
mit dem SDCC kann man ganz passabel arbeiten.



--
Matthias Weißer
matthias@matwei.de
http://www.matwei.de

 

[Matthias Weißer]

Holger Petersen wrote:

"Matthias Weißer" <DTMAN@gmx.de> writes:


Interpreter? Für C? C ist eine Compilersprache.

"C" ist eine Programmier-Sprache. Ob diese Sprache als Compiler,
Interpreter (oder mix) realisiert wird ist zweitrangig (und 'nur'
für die Ausführungs-Geschwindigkeit wesentlich

Aber C wird zu mindestens 95% Prozent (eher gegen 100%) compiliert und nicht
interpretiert. Es mag aber auch für C Interpreter geben was aber eher
ungewönlich ist. Für BASIC ist das alles andere als ungewöhnlich.

Der Compiler läuft z.B. auf
einem PC

Schon doppelt ungenau: Ein 'PC' mag zwar _heute_ einen
'IBM-kompatiblen' Rechner implizieren, muss es aber nicht. Und über
das Betriebssystem *auf* diesem 'PC' sagt das gar nix aus.

Schreib ich irgendwas von Betriebsystem? Hast du das z.B. übersehen?
Natürlich kann ein Compiler auch in deinem Kopf "laufen"

Es gibt mindestens einen C-Interpreter (auf CP/M oder MS/DOS?)!

Mag sein. Wird der heute _ernsthaft_ eingesetzt?

und erzeugt eine ASM-Datei die dann vom Assembler und Linker z.B.
in eine HEX-Datei verwandelt wird.

Auch das ist nicht zwingend. Es gibt (gab) Compiler, die alles in
einem Schritt erledigten. Und es gab solche ('tiny-C' auf CP/M) die
einen stan- dardmässig mitgelieferten Assembler bemühten und keinen
Linker brauchten. Ausser PIP.COM analog zu "COPY /B Start.bin +
Programm.bin programm.com") Ähnlich hat es Turbo-Pascal unter CP/M
und auch DOS gemacht.

Klar findet man immer Beispiele bei denen das nicht so ist. Aber macht das
Sinn in einer kurzen Antwort das alles zu erwähnen? Auch hier gilt: Bei 95%
aller heutigen C Compiler läuft es nach obigem Schema
Compiler->Assembler->Linker



--
Matthias Weißer
matthias@matwei.de
http://www.matwei.de

 

[jetmarc]

Es gibt dazu ja spez. C Erweiterungen für die entsprechende
Hardware und auch Dinge die man z.b. mit dem 8051 machen kann,
mit dem AVR aber so z.B. nicht. (und umgekehrt)

Ich vermute, Du sitzt einem Irrtum auf. Es gibt (zum Glueck) nur
sehr wenige echte Erweiterungen, zumindestens sofern Du die ganze
Bandbreite der Compiler betrachtest. Manche machen da unruehmliche
Ausnahmen. Im grossen und ganzen aber beschraenken sich die
Erweiterungen aber auf:

1. Sog "intrinsic functions", also Funktions-Makros die das inline
Ausfuehren von wichtigen Assembler-Befehlen wie SEI/CLI ermoeglichen
(bei den meisten CPUs ist die Liste mit diesen beiden Befehlen auch
schon wieder zu ende).

2. Keywords fuer detailiertere Speicherzuweisung als vom PC gewohnt,
zB "flash" oder "xram". Das erspart viel Aerger mit dem Linker.

3. Keywords fuer besondere Funktionstypen - meistens beschraenkt
sich das auf ein Wort wie "monitor" mit dem man eine Funktion
interrupt-fest macht. Der Compiler rettet dann innerhalb der
Funktion ALLE Register anstatt nur die ueblichen. Bei manchen
CPUs gibt es auch noch ein "reentrant" Keyword, und/oder eines
um in Funktionen wie main() ueberhaupt keine Register zu retten
(waere nur totes RAM).

4. Je nach Compiler werden die I/O Register der CPU auf eine andere
Art eingebunden, mittels spezieller Keywords. Das braucht Dich aber
anfangs gar nicht zu belasten, denn die Compiler kommen in der Regel
schon mit fertigen Include Files fuer die gaengigen Typen.


Alles in allen brauchst Du also nur etwa 10 zusaetzliche Keywords
ueber den ANSI Standard hinaus zu kennen, um sogar solch komplexe
Projekte wie zB Echtzeit-Multitasking Betriebssysteme entwickeln
zu koennen.

Deshalb halte ich die Onlinehilfe des Compilers fuer ausreichend.
Statt die Auswahl der Buecher auf die wenigen zu beschraenken, die
sich mit 8051 UND C befassen, solltest Du meiner Meinung nach
lieber ein wirklich gutes C Buch aussuchen und den Rest aus der
Onlinehilfe ergaenzen. Immerhin koennte es Dir sogar passieren
dass ein 8051 spezifisches Buch mit einem anderen Compiler arbeitet
als Du, und dann waeren die aufgelisteten Keywords eh hinfaellig.

Marc

 

[W. Wipfel]

"Matthias Weißer" <DTMAN@gmx.de> schrieb im Newsbeitrag
news:bfukud$j8ite$1@ID-76219.news.uni-berlin.de...

W. Wipfel wrote:
Bei RISC Architektur (AVR, PIC) mag das ja stimmen....
aber was 8051 angeht war es so nicht geplant.
Die Dinger kamen auf den Markt bevor C so richtig
erwachsen war.
Die AVR und die PIC sind für C zwar eher geignet, aber

PIC? In C? Prust!
Die Architektur der PIC's ist älter als die der 8051er.

Ok, ich erlag einem Irrtum!
Sacktuch und Asche über mich ! ;-)

ich brauch C nun mal wegen der Komplexität der
Aufgabenstellung. BASIC zu unflexibel, ASS zu umständlich
für diesen Fall.....

Und ich schrieb ja das C _die_ Hochsprache für ľC ist. Alles andere ist
Flickwerk. Ob C jetzt für 8051 geeignet ist oder nicht es wird verwendet.
Und so schlecht sind die C-Compiler für 8051 dann auch wieder nicht.
Selbst
mit dem SDCC kann man ganz passabel arbeiten.

Klar, aber C ist besser dran, wenn es genügend Register wie
beim AVR zur Verfügung hat.
Beim 8051 geht ja fast alles über den Akku !
Das kann ne Hochsprache schon mal etwas ins Schwitzen bringen....

Ich hätte mit AVR mal angefangen, aber dann werden ganze Myriaden
von MCs abgekündigt und neue rangebracht, nachdem man
endlich die Übersicht über die Dinger hatte.
Ich bleib bei den 8051, da bleibt alles beim alten........
(hoffe ich zumindest)
Und abkündigen des alten Industriestandards hat sich ja
meines Wissens noch kleiner getraut....


by W.

 

[W. Wipfel]

"Tilmann Reh" <tilmann.reh@autometer.de> schrieb im Newsbeitrag
news:3F2232E2.6AE40942@autometer.de...

"W. Wipfel" schrieb:

Ich WILL C lernen und KEIN Forth.
Das war doch anhand der Betreff Zeile sehr einfach zu erkennen!
Wobei das doch eh schon im Museum liegt, oder wer
prorgrammiert noch damit ?!?!?

Blödsinn.

A propos C: "Millionen fliegen können nicht irren."
C ist zur Zeit eben Mode, ob es eine "gute" Sprache ist, sei mal
dahingestellt...

Da sage ich 100% ACK !
Wenn man die leichtigkeit eines BASIC dagegen stelt
fragt man nich wirklich ob C ne echte Programmiersprache ist.
War das nicht mal ein programmiernotbehelf für
die DEC VEX Kisten ?

by W.

 

[W. Wipfel]

"Holger Petersen" <hp@kbbs.org> schrieb im Newsbeitrag
news:bfroad$7u5$2@kbbs.org...

Gerald Oppen <Gerald.Oppen@web.de> writes:

Und käme dann eventuell bei FORTH an (und kann trotzdem 8051 oder
anderes wählen).

Ich möchte Bezweifeln das es noch Bücher
zu FORTH für Microcontroller gibt...
Oder erliege ich einem Irrtum ?

(ich meine Bücher die man auch noch kaufen kann)

by W.

 

[Gerald Oppen]

Stefan Wagner schrieb:

Gerald Oppen <Gerald.Oppen@web.de> wrote:

Die Frage ist noch, warum es ein 8051 sein muss...

Würde einen Controller wählen, der mit kostenlosen Tools Echtzeit-
debugging auf Sourcecode und Assemblerebene unterstützt...


Hallo Gerald,

das würde mich auch interessieren. Welche Controllerfamilien wären das?

MSP430 hat da interssantes zu bieten.
Lies Dir auch mal die Threads zum M16C durch, mit dem habe ich auch vor
kurzem angefangen. Sehr leistungsfähig und mit viel internem Ram vefügbar.

Gerald

 

[Dirk Ruth]

On Sat, 26 Jul 2003 23:30:58 +0200, "W. Wipfel" <willi.wipfel@gmx.de>
wrote:

"Dirk Ruth" <d.ruth@expressnet.info> schrieb im Newsbeitrag
news:b3b3ivs0lrc8dfj0sdbhl2tjjrtujt9757@4ax.com...
On Fri, 25 Jul 2003 23:43:56 +0200, "W. Wipfel" <willi.wipfel@gmx.de
wrote:

Also da überschätzt Du das ganze völlig. Du hast Doch geschrieben,
dass Du schon mal programmiert hast.

Du brauchst: für den Anfang:
Definitionen, Deklarationen, Schleifen(Kopf- Fußgesteuert). Arithmetik
(+,-,/,%,*,++,--,>,<,>>,<&lt Logik(|,&,^,!)(später noch Pointer)und
ein paar Funktionsaufrufe aus stdlib,h, string.h evtl. noch stdio.h.

Alles andere ist compiler-/prozessorspezifisch und dürfte kaum in
einem Buch zu finden sein. Dafür gibt's dann die Beispiele dazu.


Das war ja auch nicht unbedingt der Stein des Anstoßes...
Ich meinte gerade die Besonderheiten...
Etwas was im ASS völlig normal ist.
Ports einlesen, Daten an Ports ausgeben.
Div Bits oder Pins vergelichen.
Das was in Ass einfach ist, stellt meines Achtens für
einen Anfänger in C keine einfaches Unterfangen dar....

Oder seh ich da was völlig falsch ?

Es hängt davon ab, wie Dein Compiler arbeitet (spezifisch) und was Dir
der Hersteller schon mitliefert.

Meist gibt es irgendwo eine sfr.h (special function register) die
eingebunden wird. Da stehen dann so Sachen drin wie:

#define P5 0x20

d.h. dass P5 als Adresse 0x20 (z.B. Port5 ist ein Register, dass auf
Adresse 0x20 liegt) definiert wird usw.

entspricht::
EQU P5 0x20

Ports einlesen, Daten an Ports ausgeben.

y = P5;
P5=y;

Meist ist dann noch jedes einzelne Bit auf dem Port nochmals extra
definiert.

Div Bits oder Pins vergelichen.

if( P5_2)

Testet ob Pin 2 auf Port 5 == 1 ist.
Oder z.B.

while( !P5_3);

wartet solange bis P5_3 High wird (z.B. Taster gedrückt).

Werd mal ausprobieren. Hab ja einen 89S8252 mit div LEDs und
Tasterchen und Matrix LCD zum ausprobieren.
Die gute alte Trial and Error Methode.

Mal sehen ob ich auch mit den sicherlich massenhaft
von Anfängern produzieren Fehlermeldungen was anfangen kann.
Ich hab sicherlich 80% Produktivität, zumindest was
Fehlermeldungen angehen wird ....

Wird eher weniger sein als bei Assembler, da der Compiler schon viele
falsche Dinge erkennt, die Dein Assembler völlig ignoriert.


Tschö
Dirk

 

[Gerald Oppen]

W. Wipfel schrieb:

Danke für den Tip!
Weist du denn noch welche es war ?

Reads51 von Riegel oder Rigel, Anfang 2002 gab es dazu einen
mehrteiligen Kurs in der Elektor

Die Frage ist noch, warum es ein 8051 sein muss...


Weil ich mich an die Dinger gewöhnt habe und es nun mal
der Industriestandard ist.
Ich will nicht wegen C mit AVR oder PIC anfangen müssen.
Man hat ja nicht die ICs für umsonst gekauft ! ;-)

Die paar Euro für den Chip selber sollten eigentlich nicht
ausschlaggebend sein. Beim MSP430 und M16C kannst Du mit kostenlosen
Tools Sourcecode Single-Step im System debuggen und mit geringstem
Hardwareaufwand vom PC direkt in den Chip programmieren.
Damit kann man sich das leben sehr vereinfachen.
OK, ich muss zugeben meine letzten 8051 Projekte waren auf einem
80535 mit externem"FensterEprom", seit dem hat sich auch beim 8051
ein bischen was getan, aber so ganz aktuell ist der wohl nicht mehr...

Gerald

 

[Gerald Oppen]

Holger Petersen schrieb:

Die Frage ist noch, warum es ein 8051 sein muss...

DANN darf man bitte auch fragen: "Warum 'C'"!?

Weil C eine maschinennahe Hochsprache ist - oder wie an anderer Stelle
ausgedrückt keine Programmiersprache sondern eine Macrodefinition...

C ist einfach "die" Sprache im embedded-Bereich mit den typischen
Mikrokontrolleranwendungen nachdem vieles für Assembler zu
unübersichtlich geworden ist.

Und käme dann eventuell bei FORTH an (und kann trotzdem 8051 oder
anderes wählen).

Spielt nicht wirklich eine Rolle in dem Bereich und findet kaum
Unterstützung. Für praktisch alle aktuellen uCs findet man massenhaft
APNs und sonstige Unterstützungen vom Hersteller in C, aber mit Forth
wird man sich schwertun.

Gerald

 

[Gerald Oppen]

W. Wipfel schrieb:

Ich hätte mit AVR mal angefangen, aber dann werden ganze Myriaden
von MCs abgekündigt und neue rangebracht, nachdem man
endlich die Übersicht über die Dinger hatte.
Ich bleib bei den 8051, da bleibt alles beim alten........
(hoffe ich zumindest)
Und abkündigen des alten Industriestandards hat sich ja
meines Wissens noch kleiner getraut....

Die einzelnen Controller-Typen die Du gerade in Deinem Projekt
verwendesk können aber genau so abgekündigt werden.
Wenn Du halbwegs kontrollergerecht struckturiert in C programmiert
hast kannst Du Deine Software auch ganz schnell auf einen anderen
Typ portieren.

Gerald

 

[Gerald Oppen]

W. Wipfel schrieb:

Ich meinte gerade die Besonderheiten...
Etwas was im ASS völlig normal ist.
Ports einlesen, Daten an Ports ausgeben.
Div Bits oder Pins vergelichen.
Das was in Ass einfach ist, stellt meines Achtens für
einen Anfänger in C keine einfaches Unterfangen dar....

Oder seh ich da was völlig falsch ?

Ja, denke ich schon.
Üblicherweise bindest Du einfach ein *.h - File ein dass die
Definitionen für Deinen Controller enthält, also z.B. welche
Adresse ein Port hat. Manche Entwicklunssysteme erlauben auch die
Auswahl des Controllertyps über ein Menü.


Wenn Du jetzt einen Port setzen oder löschen willst geschieht
das einfach durch

P1 = 0x01; // Portpin 1.0 setzen
P1 = 0x00; // Portpin 1.0 löschen

Die anderen Portpins werden hiermit natürlich alle auf 0 gesetzt.
Will man das vermeiden verwendet man etwas Bitarithmetik.
Manche System wie der 8051 können natürlich auch Bitweise angesprochen
werden so dass man hier direkt

P1.0 = 1;
bzw.
P1.0 = 0;
schreiben kann.

Schau Dir einfach mal den C-Einsteigerkurse mit dem Rigel-Compiler
im der Elektor Anfang 2002 an, dann dürfte Dir vieles schnell klar
werden.


Gerald

 

[Joachim Riehn]

W. Wipfel schrieb:

man fragt sich wirklich ob C ne echte Programmiersprache ist.
War das nicht mal ein programmiernotbehelf für
die DEC VEX Kisten ?

Unbefangene Leserinnen und Leser bekommen nun aber
wirklich einen völlig schiefen Eindruck von der
Sprache C. Vor einigen Wochen hatten wir Grundsatz-
diskussionen über C. Diese Diskussion war wirklich
interessant, weil man gegensätzliche Standpunkte
kennen lernen konnte.

Das Betriebssystem UNIX mit seinen Varianten und C
wurden parallel entwickelt und sie gehören
zusammen. Das Rückrat des Internet wird von
UNIX-Rechnern gestellt. Auch die Konkurrenz
(DOS, Windows) wurde in C programmiert meines
Wissens. Die überheblichen Kommentare über C
erinnern an den Schildbürger, der sich den
Ast absägt, auf dem er sitzt.

C wurde vor etwa 30 Jahren in Auftrag gegeben
und entwickelt vor allem, um eine möglichst
leicht transportable Sprache (auf verschiedene
CPU's) zu bekommen. Es ist von vornherein
klar, dass ein gewisser Kompromis geschlossen
werden musste. Es gibt halt viele gute Compiler
für C für die verschiedensten Plattformen.

Es würde vielleicht Sinn machen, über die
"Top Five" zu diskutieren. Die Sprachen,
die sich gegenseitig ergänzen und die
man am ehesten lernen sollte, meine ich.

Aber ich halte es für eine Gespenster-Diskussion,
nur eine einzige Sprache heilig zu sprechen, oder
eine einzige Sprache als "Trouble-Maker" zu mobben.

C ist zur Zeit eben Mode ...

Luft zu atmen ist vielleicht zur Zeit auch gerade
"in Mode". Wer mit dem Fortschritt geht, atmet
vielleicht lieber "Ekstasy-Dämpfe". Nein danke.

Mit Gruss
Joachim Riehn