C für 8051
W. Wipfel
nachdem mich mein neues Buch über C für Mikrocontroller
enttäsucht hat, dachte ich mir, frag doch mal die NG.
Ich suche FÜR ANFÄNGER eine Einführung in C mit der Prämisse
auf Microcontroller der 8051 Reihe. <-----------
Also auch deren speziellen Sachen und MIT Beispielen. <-----------
(wenn es geht mit Erklärung zu den Programmier Beispielen)
Ich habe keinerlei Vorkenntnisse in C (Ass und Basic schon) !
Suche dahingehend gute Links im Netz, die Bücher sind ja dahingehend
nicht zu gebrauchen.
Herzlichen Dank imVoraus!
by W.
Andreas Schwarz
> nachdem mich mein neues Buch über C für Mikrocontroller
> enttäsucht hat, dachte ich mir, frag doch mal die NG.
Darf ich fragen welches Buch das war? Ich habe heute
"Softwareentwicklung in C für Mikroprozessoren und Mikrocontroller" von
Jörg Wiegelmann zur Rezension bekommen, und auf den ersten Blick scheint
das Buch sehr brauchbar zu sein.
> Ich suche FÜR ANFÄNGER eine Einführung in C mit der Prämisse
> auf Microcontroller der 8051 Reihe. <-----------
Hmm, ich wüsste nicht was bei der C-Programmierung für 8051er
grundlegend anders sein sollte als bei anderen Controllern.
Grundsätzlich musst du drei Dinge kennen:
- den Controller den du programmieren möchtest,
- die Programmiersprache,
- den Compiler.
> Ich habe keinerlei Vorkenntnisse in C (Ass und Basic schon) !
Dann wäre der nächste sinnvolle Schritt, dir ein paar C-Kenntnisse
auf dem PC anzueignen. Es gibt einige kostenlose Compiler, z.B. gcc oder
lcc, und C-Einführungen findet man im WWW wie Sand am Meer.
Wenn die ersten beiden Punkte abgehakt sind, reicht es wahrscheinlich
wenn du dir ein paar Beispielprogramme für deinen Compiler anschaust und
damit rumbastelst. Wenn nicht - meld dich hier einfach nochmal (und/oder
in meinem Forum, siehe Signatur).
Gruß
Andreas
--
AVR-Tutorial, über 350 Links
Forum für AVRGCC und MSPGCC
-> http://www.mikrocontroller.net
Evert Vrieze
Free C compiler for 8051.
Mit links zu Projekte
--
Evert Vrieze
tel. +31.40.2128359
"W. Wipfel" <willi....@gmx.de> schreef in bericht
news:3f202a83$0$8751$9b62...@news.freenet.de...
Frank Müller
> nachdem mich mein neues Buch über C für Mikrocontroller
> enttäsucht hat, dachte ich mir, frag doch mal die NG.
>
> Ich suche FÜR ANFÄNGER eine Einführung in C mit der Prämisse
> auf Microcontroller der 8051 Reihe. <-----------
Was willst du da mit C? Der hat doch keinen implementierten
Interpreter, da kommt man doch mit direkten Assembler oder
einen Basic-Compiler wesentlich einfacher zurecht.
Frank
Dirk Ruth
wrote:
Vergiss Bücher, ein einfaches kleines Taschenbucch zum Nachschlagen
über C reicht völlig, wenn Du schon eine Programmiersprache kennst.
Schau Dir einfach die verschiedenen Datentypen an und wofür man die
braucht, bzw. wie Schleifen (welche Schlüsselwörter) aufgebaut sind.
Dann noch ein Kapittel über Zeiger und das war's dann auch schon. Mehr
gibt es in C nicht.
Speziell zum Controller schau Dir einfach die Beispiele an, die der
Compilerhersteller mitliefert oder nimm ein anderes fertiges Programm
und versuche es zu verstehen und nachzuvollziehen.
Wenn Du dabei an irgendeiner konkreten Stelle nicht mehr weiter
kommst, dann melde Dich mit einem Beispiel hier und Dir wird geholfen.
Tschö
Dirk
Gerald Oppen
W. Wipfel schrieb:
> Ich suche FÜR ANFÄNGER eine Einführung in C mit der Prämisse
> auf Microcontroller der 8051 Reihe. <-----------
> Also auch deren speziellen Sachen und MIT Beispielen. <-----------
> (wenn es geht mit Erklärung zu den Programmier Beispielen)
>
> Ich habe keinerlei Vorkenntnisse in C (Ass und Basic schon) !
>
> Suche dahingehend gute Links im Netz, die Bücher sind ja dahingehend
> nicht zu gebrauchen.
Vor ca. einem Jahr war in der Elektor diesbezüglich was mit einem
koatenlosen C-Compiler.
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...
Gerald
jetmarc
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).
Die alten Compiler von Borland gibt es kostenlos per Download. In
jedem Fall solltest Du MSDOS oder win32 "CommandLine" Anwendungen
erstellen, damit eine Naehe zwischen dem 8051 und der PC Umgebung
besteht.
Als Buch taugt jedes gute C Buch ohne 8051-Bezug, ergaenzt durch
die Onlinehilfe Deines Compilers. Ausser den I/O Schnittstellen
gibt es fast keine Unterschiede. Vorsicht vor Buechern mit
"Visual" oder "Windows" im Namen. Falls Du Englisch kannst, hol
Dir "C - The complete Reference" von Osborne. Das bezieht sich
eigentlich auf gar kein Betriebssystem.
Marc
Gernot Fink
einen Basicinterpreter eingebaut.
C ist schon eine gute Wahl z.b. der sdcc.
--
MFG Gernot
Matthias Weißer
Interpreter? Für C? C ist eine Compilersprache. Der Compiler läuft z.B. auf
einem PC und erzeugt eine ASM-Datei die dann vom Assembler und Linker z.B.
in eine HEX-Datei verwandelt wird. Diese spielst du auf den Controller und
gut.
--
Matthias Weißer
matt...@matwei.de
http://www.matwei.de
Frank Müller
> >> nachdem mich mein neues Buch über C für Mikrocontroller
> >> enttäsucht hat, dachte ich mir, frag doch mal die NG.
> >>
> >> Ich suche FÜR ANFÄNGER eine Einführung in C mit der Prämisse
> >> auf Microcontroller der 8051 Reihe. <-----------
> >
> > Was willst du da mit C? Der hat doch keinen implementierten
> > Interpreter, da kommt man doch mit direkten Assembler oder
> > einen Basic-Compiler wesentlich einfacher zurecht.
> >
> Von den Hunderten verfügbaren Varianten hat nicht mal ein Prozent
> einen Basicinterpreter eingebaut.
Drum habe ich da oben auch Compiler geschrieben, heute
verwendet man doch sowieso einen PC zum programmieren,
und da gibt es einige Basic-Compiler, die den Basic-
Quellcode in Assembler umwandeln, den man dann in den
8051 laden kann.
besser kommt man natürlich wenn man gleich in Assembler
schreibt, und nur die Menomic in den Maschinencode
umwandeln läßt.
Frank
Matthias Weißer
> Drum habe ich da oben auch Compiler geschrieben, heute
> verwendet man doch sowieso einen PC zum programmieren,
> und da gibt es einige Basic-Compiler, die den Basic-
> Quellcode in Assembler umwandeln, den man dann in den
> 8051 laden kann.
Basic ist aber eigentlich eine typische Interpretersprache. Es gibt zwar
auch Basic-Compiler für µC aber C ist eigentlich _die_ (Hoch)Sprache für µC.
Holger Petersen
>kostenlosen C-Compiler.
>Die Frage ist noch, warum es ein 8051 sein muss...
DANN darf man bitte auch fragen: "Warum 'C'"!?
>Würde einen Controller wählen, der mit kostenlosen Tools Echtzeit-
>debugging auf Sourcecode und Assemblerebene unterstützt...
Und käme dann eventuell bei FORTH an (und kann trotzdem 8051 oder
anderes wählen).
Hol -Linuxtag-Standdienst mit Nachwirkungen- ger
Holger Petersen
>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 :-)
> 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.
Es gibt mindestens einen C-Interpreter (auf CP/M oder MS/DOS?)!
> 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.
Es gibt mindestens ein Pascal für 8051, das keinen ASM-Quellcode liefert.
Es gibt mindestens BASIC-Interpreter und -Compiler für CP/M und DOS.
Es gibt Basic-(Cross-) Compiler für 8051 als Ziel unter DOS.
es gibt compilierende und interpretierende FORTH-Systeme für fast alle
CPU's.
> Diese spielst du auf den Controller und
>gut.
Mindestens eine FORTH-Version kann über die serielle Schnittstelle debuggen.
Gruss, Holger
Marco Budde
^^^^^^^^^
Bitte den Realnamen setzen, alles andere gilt im Usenet
als unhöflich. Danke.
> nachdem mich mein neues Buch über C für Mikrocontroller
> enttäsucht hat, dachte ich mir, frag doch mal die NG.
>
> Ich suche FÜR ANFÄNGER eine Einführung in C mit der Prämisse
> auf Microcontroller der 8051 Reihe. <-----------
Da wirst Du kein gutes Buch finden. Eine Sprache sollte
man niemals abhängig von einer CPU oder einem OS lernen.
Lerne zuerst die Sprache ANSI C und für den Rest braucht
man kein Buch: wer C programmieren kann, kann jede CPU
in C programmieren (die Erweiterungen des Keil Compilers
für den 8051 sind z.B. relativ klein).
> Also auch deren speziellen Sachen und MIT Beispielen. <-----------
> (wenn es geht mit Erklärung zu den Programmier Beispielen)
Du willst Dir "Kernighan & Ritchie, Programmieren in C,
2. Aufl." kaufen.
> Ich habe keinerlei Vorkenntnisse in C (Ass und Basic schon) !
Dann solltest Du die Sprache zuerst auf einem System mit
einem guten Debugger erlernen: also auf dem PC.
> Suche dahingehend gute Links im Netz, die Bücher sind ja dahingehend
> nicht zu gebrauchen.
Im Netz wirst Du da nichts finden.
cu, Marco
--
S: Minolta: Winkelsucher (VN), VC-9
E-Mail: mb-n...@linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de
Juergen Hannappel
> "Matthias Weißer" <DT...@gmx.de> writes:
>
>
> >Interpreter? Für C? C ist eine Compilersprache.
[...]
> Es gibt mindestens einen C-Interpreter (auf CP/M oder MS/DOS?)!
Es gibt sogar einen (freien) C++-Interpreter:
root.cern.ch/root/Cint.html
--
Dr. Juergen Hannappel http://lisa2.physik.uni-bonn.de/~hannappe
mailto:hann...@physik.uni-bonn.de Phone: +49 228 73 2447 FAX ... 7869
Physikalisches Institut der Uni Bonn Nussallee 12, D-53115 Bonn, Germany
CERN: Phone: +412276 76461 Fax: ..77930 Bat. 892-R-A13 CH-1211 Geneve 23
Thomas Rehm
> Lerne zuerst die Sprache ANSI C
ANSI C (ISO C) kennt beispielsweise keine I/O-Zugriffe, ist eine
reine Intellektuellen-Sprache für Informatiker. Man versuche nur
einmal in den üblichen C-Newsgroups eine Frage nach Portzugriffen
zu stellen... BTDT :->
Für Anfänger empfehle ich vielmehr einen der üblichen Compiler:
Für Jemanden, der vor der Kommandozeile keine Angst hat, ist der
GCC brauchbar (und anspruchsvoll) - hier insbesondere der AVR-GCC,
der wie der Name schon sagt, für die AVR-Controller-Familie
angepasst wurde. Hierfür gibt es zig Beispiele und Sourcen im
Internet und jede Menge Hilfen.
> Du willst Dir "Kernighan & Ritchie, Programmieren in C,
> 2. Aufl." kaufen.
Davon ist heute sehr abzuraten. Abgesehen von der sehr schludrigen
Übersetzung (der Übersetzer konnte kein Deutsch) ist das Kernighan
und Ritchie-"C" eher von historischem Wert. Leider kenne ich noch
kein Standardwerk zu C99 - dem aktuellen C-Derivat, das international
von ANSI und ISO als Standard anerkannt ist - welches heute inzwischen
von fast allen modernen Compilern zumindest teilweise unterstützt wird
(erkennt man u.a. daran, dass Kommentare mit // abgetrennt werden
können, was von C++ übernommen wurde; es gibt aber auch noch andere
nützliche Ergänzungen).
>> Suche dahingehend gute Links im Netz, die Bücher sind ja dahingehend
>> nicht zu gebrauchen.
> Im Netz wirst Du da nichts finden.
Interessante Theorie...
> cu, Marco
Thomas.
Rafael Deliano
> ^^^^^^^^^
> Bitte den Realnamen setzen,
> Du willst Dir "Kernighan & Ritchie, Programmieren in C,
> 2. Aufl." kaufen.
Die Programmiersprache C ist nicht eben leicht erlernbar
und dieses Buch ist als Einführung eher unangenehm.
Es wurde ehdem immer empfohlen, weil es kaum Alternativen
gab.
MfG JRD
W. Wipfel
"Frank Müller" <DW...@t-online.de> schrieb im Newsbeitrag
news:bfpedl$m9u$07$5...@news.t-online.com...
Sorry, ich wollte keine Meinung das ich nun doch kein
C machen soll, sondern Tips wie ich es lernen kann.
Mal davon abgesehen habe ich im Zusammenhang mit
C noch nie von einem Interpreter gehört.
Das ist eher Basic Ecke. C hat Compiler !
Ich habe einen Basic Compiler für 8051, aber mit dem kann
man nun mal nicht alles so realisieren wie man es gern hätte.
Die Flexiblität ist da nicht sooo gut.
Und ASS ist für den Fall zu umständlich.
Wenn ich was mit C anfange will, dann hat das schon seinen Grund,
zumal ich schon geschrieben hatte, daß ich mit mit Basic uns ASS
etwas auskenne......
By W.
W. Wipfel
"Gerald Oppen" <Gerald...@web.de> schrieb im Newsbeitrag
news:3F20508E...@web.de...
>
>
> W. Wipfel schrieb:
> > Ich suche FÜR ANFÄNGER eine Einführung in C mit der Prämisse
> > auf Microcontroller der 8051 Reihe. <-----------
> > Also auch deren speziellen Sachen und MIT Beispielen. <-----------
> > (wenn es geht mit Erklärung zu den Programmier Beispielen)
> >
> > Ich habe keinerlei Vorkenntnisse in C (Ass und Basic schon) !
> >
> > Suche dahingehend gute Links im Netz, die Bücher sind ja dahingehend
> > nicht zu gebrauchen.
>
> Vor ca. einem Jahr war in der Elektor diesbezüglich was mit einem
> koatenlosen C-Compiler.
Danke für den Tip!
Weist du denn noch welche es war ?
> 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 ! ;-)
by W.
W. Wipfel
"Holger Petersen" <h...@kbbs.org> schrieb im Newsbeitrag
news:bfroad$7u5$2...@kbbs.org...
> Gerald Oppen <Gerald...@web.de> writes:
>
> >kostenlosen C-Compiler.
>
> >Die Frage ist noch, warum es ein 8051 sein muss...
>
> DANN darf man bitte auch fragen: "Warum 'C'"!?
Warum denn wohl!?!?!?
Vielleicht weil BASIC zu unflexibel ist und ASS
für diesen Fall zu umständlich ?
> >Würde einen Controller wählen, der mit kostenlosen Tools Echtzeit-
> >debugging auf Sourcecode und Assemblerebene unterstützt...
>
> Und käme dann eventuell bei FORTH an (und kann trotzdem 8051 oder
> anderes wählen).
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 ?!?!?
by W.
W. Wipfel
"Dirk Ruth" <d.r...@expressnet.info> schrieb im Newsbeitrag
news:l8g0ivgpsjkvvj0ha...@4ax.com...
>
> Vergiss Bücher, ein einfaches kleines Taschenbucch zum Nachschlagen
> über C reicht völlig, wenn Du schon eine Programmiersprache kennst.
> Schau Dir einfach die verschiedenen Datentypen an und wofür man die
> braucht, bzw. wie Schleifen (welche Schlüsselwörter) aufgebaut sind.
> Dann noch ein Kapittel über Zeiger und das war's dann auch schon. Mehr
> gibt es in C nicht.
Das mag ja ne nette Idee sein, aber noch keiner (außer extrem begabte)
hat Mathematik wirklich begriffen nur weil er sich
die Formeln angesehen hat.
Etwa Hintergundinfo und Tips sind sicherlich notwendig.
Und bei Programmiersprachen kann man auf deutlich mehr
Ärger stoßen als in der normalen Mathematik.
> Speziell zum Controller schau Dir einfach die Beispiele an, die der
> Compilerhersteller mitliefert oder nimm ein anderes fertiges Programm
> und versuche es zu verstehen und nachzuvollziehen.
> Wenn Du dabei an irgendeiner konkreten Stelle nicht mehr weiter
> kommst, dann melde Dich mit einem Beispiel hier und Dir wird geholfen.
Das ist zwar ein nettes Angebot, aber ich hab meist so viele
Fragen das dies schon in Spam ausarten würde :-)
by W.
W. Wipfel
"Matthias Weißer" <DT...@gmx.de> schrieb im Newsbeitrag
news:bfr3v9$i09mk$1...@ID-76219.news.uni-berlin.de...
> Frank Müller wrote:
> > Drum habe ich da oben auch Compiler geschrieben, heute
> > verwendet man doch sowieso einen PC zum programmieren,
> > und da gibt es einige Basic-Compiler, die den Basic-
> > Quellcode in Assembler umwandeln, den man dann in den
> > 8051 laden kann.
>
> Basic ist aber eigentlich eine typische Interpretersprache. Es gibt zwar
> auch Basic-Compiler für µC aber C ist eigentlich _die_ (Hoch)Sprache für
µC.
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
ich brauch C nun mal wegen der Komplexität der
Aufgabenstellung. BASIC zu unflexibel, ASS zu umständlich
für diesen Fall.....
by W.
W. Wipfel
"jetmarc" <jet...@hotmail.com> schrieb im Newsbeitrag
news:af3f5bb5.03072...@posting.google.com...
> > 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).
Ich will gerade deswegen mit den Dingern das machen,
weil ich micht mit der Hardware einigermaßen auskenne.
Und das ist totz C nun mal bei Programmierung von
Mircrocontrollern notwendig.
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)
By W.
Dirk Ruth
wrote:
>
>"Dirk Ruth" <d.r...@expressnet.info> schrieb im Newsbeitrag
>news:l8g0ivgpsjkvvj0ha...@4ax.com...
>>
>> Vergiss Bücher, ein einfaches kleines Taschenbucch zum Nachschlagen
>> über C reicht völlig, wenn Du schon eine Programmiersprache kennst.
>> Schau Dir einfach die verschiedenen Datentypen an und wofür man die
>> braucht, bzw. wie Schleifen (welche Schlüsselwörter) aufgebaut sind.
>> Dann noch ein Kapittel über Zeiger und das war's dann auch schon. Mehr
>> gibt es in C nicht.
>
>Das mag ja ne nette Idee sein, aber noch keiner (außer extrem begabte)
>hat Mathematik wirklich begriffen nur weil er sich
>die Formeln angesehen hat.
>Etwa Hintergundinfo und Tips sind sicherlich notwendig.
>Und bei Programmiersprachen kann man auf deutlich mehr
>Ärger stoßen als in der normalen Mathematik.
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
(+,-,/,%,*,++,--,>,<,>>,<<) 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.
>
>
>> Speziell zum Controller schau Dir einfach die Beispiele an, die der
>> Compilerhersteller mitliefert oder nimm ein anderes fertiges Programm
>> und versuche es zu verstehen und nachzuvollziehen.
>> Wenn Du dabei an irgendeiner konkreten Stelle nicht mehr weiter
>> kommst, dann melde Dich mit einem Beispiel hier und Dir wird geholfen.
>
>
>Das ist zwar ein nettes Angebot, aber ich hab meist so viele
>Fragen das dies schon in Spam ausarten würde :-)
Nicht doch. Einfach ausprobieren.
Nimm einfertiges Beispiel und fang an es zu ergänzen und abzuändern.
Dabei immer schön auf die Fehler und Warnungen des Compilers
achtgeben.
Tschö
Dirk
Joerg Schlager
> Ich habe keinerlei Vorkenntnisse in C (Ass und Basic schon) !
Schau Dir mal http://courses.iicm.edu/programmieren0/#buch genauer an.
Dieses Teil wird an der TU Graz in der C Einfuehrungsvorlesung
verwendet und ist IMHO sehr brauchbar. Besonderes Augenmerk wird dabei
auf C Stolpersteine gelegt, eingesetzte Entwicklungsumgebung ist
linux/emacs/gcc (aber grundsaetzlich ist der verwendete Code mit jedem
guten C Compiler kompatibel). Weiterer Vorteil des Werks: Es ist gratis
als PDF erhaeltlich *g*
lG
Joerg
Rainer Buchty
Rafael Deliano <Rafael_...@t-online.de> writes:
|> Die Programmiersprache C ist nicht eben leicht erlernbar
|> und dieses Buch ist als Einführung eher unangenehm.
C ist keine Programmiersprache. C ist ein Makroassembler.
Macht man sich das erst mal klar, dann hat man überhaupt keine Probleme
damit :)
Rainer
Aguja
>auf Microcontroller der 8051 Reihe. <-----------
>Also auch deren speziellen Sachen und MIT Beispielen. <-----------
>(wenn es geht mit Erklärung zu den Programmier Beispielen)
>
>
>nicht zu gebrauchen.
Ich weiß nicht, wo Dein Problem ist. C-Tutorials als PDF, HTML, TXT oder
sonst was gibt's massenhaft in allen möglichen und unmöglichen Sprachen
im Netz. So was liest Du, lässt aber in Deinen Programmen dann die Befehle
die mit der Außenwelt kommunizieren wie printf (OK, machen Compiler können
Code erzeugen der mit printf auf ein LCD schreibt) einfach und ersatzlos
weg.
Wie Du dann auf die speziellen 8051-Funktionen (Stack, I/O, UART usw) zu-
greifst, steht in der Anleitung des (und zwar genau des) C-Compilers den
Du benutzt (hättest ruhig schreiben dürfen welcher) - alles andere bringt
Dir nix.
cu,
Aguja (der in den nächsten Tagen den AVR-GCC ausprobieren will)
::Update:: www.PROuC.de ==> Free AVR-, PIC- & 8051-Programmers, Apps & Tips
Stefan Wagner
> 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?
Danke und beste Grüße
Stefan
PS: Ich habe reichlich Entwicklungspraxis in ASM und C mit MCS51 und
Z80, bin aber seit 1994 privat und beruflich aus dem Thema raus.
Tilmann Reh
> 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...
--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de
==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)
Marco Budde
> Die AVR und die PIC sind für C zwar eher geignet,
PICs für C geeignet? Wie kommst Du darauf? Deren uralte
Architektur (aus den 70ern?) ist eigentlich für alles außer
Assembler völlig ungeeignet. Aber auch der 8051 ist für
C IHMO nur bedingt zu gebrauchen (schon solche elementaren
Dinge wie Pointer werden, jedennfalls beim Keil, in
Software emuliert.
> aber
> ich brauch C nun mal wegen der Komplexität der
> Aufgabenstellung. BASIC zu unflexibel, ASS zu umständlich
> für diesen Fall.....
Assembler ist IHMO sowieso nur in sehr wenigen Fällen
heute noch sinnvoll.
Marco Budde
> > 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.
Marco Budde
> > Lerne zuerst die Sprache ANSI C
> ANSI C (ISO C) kennt beispielsweise keine I/O-Zugriffe,
Das ist so pauschal z.B. schon mal völliger Blödsinn. Nicht selten
wird sowas z.B. über bestimmte Memory Adressen gemacht und das
geht sogar mit Standard ANSI C:
unsigned char *video_mem = 0x232323;
video_mem[0] = 0x00;
...
Ansonsten sehen z.B. Portzugriffe sowieso auf jedem System und
bei jedem Compiler anders aus. Aber wenn man bereits ANSI C
kann, ist es kein Problem, sich die dafür notwendigen, proprietären
APIs in 5 Minuten anzueignen:
unsigned char a;
a = inp (0x50);
> ist eine
> reine Intellektuellen-Sprache für Informatiker.
Du solltest Dich vorher bitte mal richtig informieren, bevor Du
einem Einsteiger einen solchen Unfug erzählst. Das wichtigste in
der Entwicklung ist übertragbares Grundlagenwissen. Wer ANSI C
kann, kann eigentlich alle Embedded Systeme ohne große Einarbeitung
programmieren.
Leute, die nur einen bestimmten Compiler wie z.B. Keil kennen,
sind dagegen in der Praxis nicht zu gebrauchen.
> Man versuche nur
> einmal in den üblichen C-Newsgroups eine Frage nach Portzugriffen
> zu stellen... BTDT :->
Nein, das sollte man nicht versuchen, da das dort nicht
hingehört. Nur was hat das jetzt mit dem Thema zu tun?
Sprechen wir hier von irgendwelchem Gehacke oder von einer
prof. Herangehensweise?
> Für Anfänger empfehle ich vielmehr einen der üblichen Compiler:
> Für Jemanden, der vor der Kommandozeile keine Angst hat, ist der
> GCC brauchbar (und anspruchsvoll) - hier insbesondere der AVR-GCC,
> der wie der Name schon sagt, für die AVR-Controller-Familie
> angepasst wurde.
Ach und der gcc ist kein ANSI C/C++ Compiler? Interessante These.
Mal davon abgesehen, daß der gcc für die gewünschte 8051 Ziel-
architektur nicht geeignet ist.
> > Du willst Dir "Kernighan & Ritchie, Programmieren in C,
> > 2. Aufl." kaufen.
> Davon ist heute sehr abzuraten.
Jede, der etwas Ahnung von C-Programmierung hat, wird Dir hier ganz
sicher nicht zustimmen. Das Buch ist nicht ohne Grund die Bibel der
C Programmierer. Weitere Bücher zu C wird man in der Regel nicht
benötigen.
> Abgesehen von der sehr schludrigen
> Übersetzung (der Übersetzer konnte kein Deutsch) ist das Kernighan
> und Ritchie-"C" eher von historischem Wert.
Kannst Du Dich bitte mal informieren? Das Buch beschreibt keineswegs
K&R-C sondern ANSI-C.
> Leider kenne ich noch
> kein Standardwerk zu C99
Wofür brauchst Du im Embedded Bereich bitte C99?
> - dem aktuellen C-Derivat, das international
> von ANSI und ISO als Standard anerkannt ist - welches heute inzwischen
> von fast allen modernen Compilern zumindest teilweise unterstützt wird
ROTFL, na klar. Mal abgesehen vom gcc dürfte es wenige, verbreitete
Compiler geben, die überhaupt was von C99 unterstützen (mal von den
C++ Kommentaren abgesehen).
> Interessante Theorie...
Dazu sage ich jetzt lieber nichts.
Ingolf Pohl
> "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...
Klassisches Entscheidungsproblem, bei Entwicklern, wie bei Chefs:
Chef: Mit was anderem als C könnten wir besser, aber auch schlechter als die
Konkurrenz sein und wir fänden keine "fertigen Programmierer", also C, dann
gehen wir kein Risiko ein...
Entwickler: Mit was anderem als C kann ich gut leben, es gibt sogar
Entwicklungsumgebungen für embedded Systeme, mit denen ich schneller,
interaktiver, komfortabler (sogar mit weniger Fehlern) arbeiten kann (zB.
Forth und Derivate), aber wenn ich einen Job suche, oder wenn ich
"Fremdsourcen" verwenden soll - und ausserdem müsste ich den Chef
überzeugen - dann lieber C ...
Ich hab's schon erlebt, da hat man als Firma ein tolles System zum
Programmieren von heterogenen Multiprozessorsystemen aus DSPs, Controllern
und X86er, aber anstatt das ganze mal vernüftig auszubauen und
voranzutreiben, gibt man die Möglichkeit einfache Systeme zu realisieren
aus der Hand (Konzentration auf Kernkompetenz) und kauft nun mehrere teuere
Entwicklungssysteme inkl. RTOS etc.pp. ein und muß passende Hardware für
den mehrfachen Preis der Eigenentwicklung einsetzen, aber "das macht man ja
heute so": Null Risiko, null Chance besser zu sein als die Konkourrenz...
Was ich eigentlich überhaupt nicht verstehe, ist das sowas wie Forth im
Hobbybereich nicht mehr Verbreitung gefunden hat, man spart sich immerhin
sowas wie'n Emul(g)ator, kann interaktiv sofort in den Register und er
Peripherie der Controller fummeln und sie "begreifen". UPN ist ja wohl kein
Argument...
Ich habe einige Jahre mit einem Foth-ähnlichen Crosscompiler-System DSPs und
Controller programmiert und finde das 1000x schneller und effizienter als
dieser ganze RTOS-Kram mit C-Entwicklungsumgebungen usw...
--
Ingolf Pohl
Rafael Deliano
Weil jemand Compiler entwickeln, dokumentieren, unterstützen muß:
kostenlos geht das nicht. Ein FORTH-System hat auch nie Stückzahlen
um dadurch Kosten zu verteilen. Hobbyanwender wollen aber
billigst/kostenlos. Und haben nicht genug Ahnung ein fig-FORTH per
Listing zu implementieren. Hobbyisten würden aber sicher davon
profitieren, daß FORTH einfach erlernbar ist. Insbesondere
Maschinenbauer, Physiker bleiben deshalb oft an FORTH kleben.
> man spart sich immerhin sowas wie'n Emul(g)ator, kann interaktiv sofort
> in den Register und er Peripherie der Controller fummeln
Gilt nur wo FORTH im Target läuft. Das ist in Einplatinencomputer
mit 8 Bit CPU, externem RAM und EPROM der Fall.
Bei einem EPROM-OTP mangels RAM und weil man keine Programme
compilieren konnte ging das bisher nicht richtig.
Erst wenn man auf z.B. 68HC908GP32 etwa 32k FLASH hat die für
20k FORTH, Assembler, Disassembler und 12k Applikation reichen
und das verwendete FLASH schnell und flexibel quasi wie RAM
programmierbar ist geht wieder was.
Bezüglich der üppigen Produktivität von C: bisher konnte man witzeln,
daß Firma ja beliebig weitere C-Coder einstellen kann, wenn sie nicht
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.
MfG JRD
Andreas Schwarz
> Gerald Oppen <Gerald...@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...
>
MSP430, evtl. auch AVR.
--
AVR-Tutorial, über 350 Links
Forum für AVRGCC und MSPGCC
-> http://www.mikrocontroller.net
Olaf Kaluza
>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
>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
> "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
Rafael Deliano
> wird IHMO alles sehr anschaulich erklärt.
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
> 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
matt...@matwei.de
http://www.matwei.de
Matthias Weißer
> "Matthias Weißer" <DT...@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
jetmarc
> 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
> 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
> On Fri, 25 Jul 2003 23:43:56 +0200, "W. Wipfel" <willi....@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
> (+,-,/,%,*,++,--,>,<,>>,<<) 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 ?
> >Das ist zwar ein nettes Angebot, aber ich hab meist so viele
> >Fragen das dies schon in Spam ausarten würde :-)
>
> Nicht doch. Einfach ausprobieren.
> Nimm einfertiges Beispiel und fang an es zu ergänzen und abzuändern.
> Dabei immer schön auf die Fehler und Warnungen des Compilers
> achtgeben.
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 .... :-)
by W.
W. Wipfel
"Tilmann Reh" <tilma...@autometer.de> schrieb im Newsbeitrag
news:3F2232E2...@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" <h...@kbbs.org> schrieb im Newsbeitrag
news:bfroad$7u5$2...@kbbs.org...
> Gerald Oppen <Gerald...@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.
W. Wipfel
> 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
Den Tip werde ich gern annehmen und ausprobieren.
Ich habe hier ein sehr gutes Buch für C lernen am PC
da, welches sehr verständlich geschrieben ist.
Die Erweiterungen was spez. HW des MC angeht werde
ich dann aus dem wenigher guiten Buch für C für MC
entnehmen...
Man dagegen war ja ASS lernen regelrecht einfach ;-)
by W.
Gerald Oppen
Stefan Wagner schrieb:
> Gerald Oppen <Gerald...@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
wrote:
>
>"Dirk Ruth" <d.r...@expressnet.info> schrieb im Newsbeitrag
>news:b3b3ivs0lrc8dfj0s...@4ax.com...
>> On Fri, 25 Jul 2003 23:43:56 +0200, "W. Wipfel" <willi....@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
>> (+,-,/,%,*,++,--,>,<,>>,<<) 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
Rafael Deliano
> War das nicht mal ein programmiernotbehelf für
> die DEC VEX Kisten ?
VAX kam lang nach C.
MfG JRD
Rafael Deliano
> zu FORTH für Microcontroller gibt...
> Oder erliege ich einem Irrtum ?
MfG JRD
Joachim Riehn
> 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
Frank Müller
> 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.
Das hängt aber eher mit der Entwicklung zusammen, als mit der
Programmiersprache.
Basic war nun mal die erste Programmiersprache die einen größeren
Kreis der Öffentlichkeit zur Verfügung gestellt wurde, und damals,
z.B. im C64, als Interpreter. Natürlich gab es zu der Zeit auch
schon einen Compiler dafür, nur der war nicht kostenlos. Selbst
auf den PC hat man QBasic gehabt, oder hat es noch und den Compiler
QuickBasic mußte man kaufen, deshalb zu sagen daß Basic eine
Interpretersprache ist, ist irgendwie unangebracht, es ist eine
Programmiersprache, ob Compiler oder Interpreter diese Sprache
umsetzen hat damit nichts zu tun.
Frank
Frank Müller
> > 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...
Warum dann nicht gleich in Assembler? So groß ist der
Schritt da nicht mehr, und man kann den Prozessor bis
aufs letzte ausnutzen und hat keine Einschränkungen
durch die Sprache.
Frank
Marco Budde
> 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-n...@linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de
Marco Budde
> Die englische Ausgabe ist eine Bleiwüste ohne
> bildliche Illustrationen
Was willst Du in einem Buch zu einer Programmiersprache
bitte auch mit Illustrationen?
> die Features anhand von
> Beispielen runterleiert.
Was gibt es besseres als Beispiele? Programmierung lernt
man nun einmal durch Praxis und kurze, sinnvolle Beispiele
sind durch nichts zu ersetzen.
> Brodies "Starting FORTH", das offizielle Einführungs-
> buch von FORTH Inc., ist dagegen praktisch ein Comic:
Was will man bitte mit Forth? Ist doch sowieso veraltet.
Einer meiner ehemalige Profs fand seine selbst entwicklte
Sprache Fifth viel besser :).
> 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.
Ein Comics ist hier wohl auch völlig falsch. Das mag
ganz nett sein, um Programmiersprachen an Grundschüler
zu vermitteln, aber sonst?
> Es geht also auch deutlich anders.
Stimmt, deutlich schlechter.
Gerald Oppen
Dirk Ruth schrieb:
>
> while( !P5_3);
>
> wartet solange bis P5_3 High wird (z.B. Taster gedrückt).
Schlechtes Beispiel, eine Programmfortführung sollte man nich von einem
Tastendruck abhängig machen...
Gerald
Rafael Deliano
Es war ein Abfallprodukt der Entwicklung von UNIX.
UNIX wird in deren Kundenzeitschrift "Bell Labs
Record" seit den frühen 70er Jahren bis Ende der
70er Jahre angepriesen ohne daß je das Wort C
fällt. Andererseits sind die Ergebnisse
von Bell Labs selten mit Patenten,
Warenzeichen, trade secret zugenagelt, sodaß
C relativ frei verfügbar war.
FORTH war bis ca. 1979 propriäteres
Produkt von FORTH Inc. und wer sowas wollte
mußte es unter anderem Namen nochmal entwickeln,
vgl IPS.
> und entwickelt vor allem, um eine möglichst
> leicht transportable Sprache (auf verschiedene
> CPU's) zu bekommen.
Um UNIX auf Minicomputern leicht portieren zu
können. D.h.
* relativ grosse Hardware, wenn das auch heute
PC entspricht. Jedenfalls nicht 8 Bit Controller.
* der der wurstelt ist hauptberuflich Programmierer
und arbeitet die ganze Woche mit C. Da kann man
mit undurchsichtiger, aber leistungsfähiger
Sprache glücklich werden.
Leute die nebenbei Löten oder anderes zu tun haben
werden mit einfacheren Sprachen eher glücklich.
MfG JRD
Marco Budde
> Warum dann nicht gleich in Assembler?
Weil ...
*) ... Assembler nicht portabel ist?
*) ... Assembler Listings schlecht wartbar sind?
*) ... Projekte in Assembler deutlicher länger brauchen?
*) ... Assembler in vielen Bereichen keine Vorteile hat?
> So groß ist der
> Schritt da nicht mehr,
ROTFL, das mag vielleicht für die Steuerung einer
Kaffeemaschine noch stimmen, geht aber ansonsten an der
Realität total vorbei.
> und man kann den Prozessor bis
> aufs letzte ausnutzen und hat keine Einschränkungen
> durch die Sprache.
Dafür aber schwerwiegende Nachteile. Da kannst Du lieber
für ein paar Cent eine bessere CPU kaufen.
Gerald Oppen
Frank Müller schrieb:
Weil das mit C komfortabler geht und leichter zu lesen ist.
Ausserdem kann man in C weitgehnst maschinenunabhängig
aber trotzdem Maschinennah programmieren da der Compiler diese
Nähe herstellt, Assembler ist da viel maschinenspezifischer
und der Code lässt sich schlecht portieren. Die Makros
müsste man dan jedesmal neu schreiben.
Gerald
Gerald Oppen
Marco Budde schrieb:
> Was willst Du in einem Buch zu einer Programmiersprache
> bitte auch mit Illustrationen?
Alter Grundsatz: Ein Bild agt mehr als tausend Worte.
Auserdem findet ma n bestimmte Sachen schneller wieder als in
einem Buch auf dem jede Seite praktisch gleich aussieht.
> Ein Comics ist hier wohl auch völlig falsch. Das mag
> ganz nett sein, um Programmiersprachen an Grundschüler
> zu vermitteln, aber sonst?
Völlig falsch würde ich nicht sagen, aber übertrieben sollte
es nicht sein.
Gerald
Frank Müller
> > Warum dann nicht gleich in Assembler?
>
> Weil ...
>
> *) ... Assembler nicht portabel ist?
Wenn jemand irgendwas mit einen 8051 baut dann gehe ich
davon aus, das er da was ganz spezielles vor hat, und
demnach auch eine Software benötigt die nur für diesen
Einsatzzweck gebraucht wird. So eine Software muß nicht
portabel sein.
> *) ... Assembler Listings schlecht wartbar sind?
Das hängt ganz von dem ab, der sie schreibt.
> *) ... Projekte in Assembler deutlicher länger brauchen?
Das kommt ganz darauf an was man braucht, und wie gut man
sich mit der Programmieung auskennt.
> *) ... Assembler in vielen Bereichen keine Vorteile hat?
Und die wären?
> > So groß ist der
> > Schritt da nicht mehr,
>
> ROTFL, das mag vielleicht für die Steuerung einer
> Kaffeemaschine noch stimmen, geht aber ansonsten an der
> Realität total vorbei.
Für was setzt man wohl einen 8051 ein? Damit wird doch
hier kaum einer einen PC-Emulator bauen wollen...
Frank
Ingolf Pohl
> Was will man bitte mit Forth? Ist doch sowieso veraltet.
> Einer meiner ehemalige Profs fand seine selbst entwicklte
> Sprache Fifth viel besser :).
Vielleicht ist "MayLi" nicht immer verständlich, aber hinter seinem Fifth
steckt ein ganz einfacher und plausibler Ansatz, den ich mehr im Sinne von
Systementwicklung aus SW und HW verstanden habe...
Du wirst Dich wundern, aber ich habe Fifth sehr gerne eingesetzt, mit keinem
Tool ist es mir bisher so leicht gefallen interaktiv heterogene
Mehrprozessorsystem aus PC, uC und DSPs zu programmieren. Mit keinem System
konnte ich bisher so schnell die zu programmierende HW beherrschen.
Das schöne an Fifth war/ist, dass man nicht für jeden Prozessor im System
ein RTOS braucht, dass es auf das wesentliche beschränkt ist und trotzdem
objektorientierte Ansätze, Parallelprozessing und Multiprozessing mitbringt
... Das schlechte (und im Grunde das KO) war die Dokumentation und der
nicht mehr zeitgemäße Editor (=IDE)...
Und das System war/ist äußerst effizient. Wir haben mit einem sehr kleinen
Kernteam sowohl Hardware als auch Software entwickelt, immerhin mit 21 DSPs
und einem uC als Master. Während des Entwickelns war der PC als
zusätzlicher eingener Knoten am System angeschlossen und stand zur
Auswertung und für Testprogramme ebenfalls in Fifth programmierbar zur
verfügung. Durch die einfache Programmierung konnte auch eine relativ
einfache Hardwarestruktur verwendet werden und vor allem genau auf die
Bedürfnisse der Anwendung angepasst werden.
Heute verwendet die Firma drei Entwicklungssysteme, eines für den PC
(MS-C++), eines für den embedded Controller (VXWorks und C(++)) und eines
für die DSP Kaufkarten. Das neue System ist "State of the Art", es
verwendet PCI-Interfaces, wo vorher einfache Schnittstellen liefen, es
verwendet Kaufkarten mit einer Funktionsanhäufung, die nicht gebraucht
werden. Die verwendeten Betriebsysteme und Libraries erfordern, dass die
Hardware passend zur Software ausgesucht/erstellt wird, denn tief in dem
gekauften Softwerk etwas ändern zu wollen ist kaum möglich...
Im Ganzen kann das neue System etwas mehr (kein Wunder, mehr DSPs, die
schneller sind), braucht doppelt so viel Platz, 10 mal mehr Energie und
kostet ein zig-faches. Der eingesetzte embedded Controller (heute PPC mit
700MHz und lausiger I/O-Karte) ist nicht schneller in der
Interruptverarbeitung, Taskswitching oder Generierung von Steuersignalen
als der damalige Controller (C167 mit 20MHz)...
Das führt zu solchen Stilblüten, dass man neuerdings Alles, was unter
einigen ms Antwortzeiten braucht in FPGAs versteckt, vorher hat der
Controller das nebenbei gemacht...
Ganz zu schweigen von dem lausigen Support der diversen
Tool/Hardware-Lieferanten, "da hat man ja Anspruch drauf, schließlich hat
man ja teure Lizenzen gekauft"...
Solch eine Entwicklung der Entwicklungen habe ich übrigens in völlig
verschiedenen, branchenfremden Firmen beobachten können.
Mir stellt sich nach meiner Fifth-Grenzerfahrung nun die Frage, welches
moderne Programmiersystem, bestehend aus Programmiersprache und
Entwicklungsumgebung mir folgendes bietet:
- eine einfache Sprache für alle Prozessoren (Zielsystem und steuernder PC)
- Unterstützung von heterogenen Mehrprozessorsystemen
- Unterstützung von Multiprozessing
- Einfache OOP Elemente (wäre schön)
- RTOS inklusive (meist ja eh nur 'ne Hauptschleife)
- interaktive Ausführbarkeit von Funktionsteilen
d.h. Programmstück schreiben, per Knopfdruck compilieren ins
Zielsystem übertragen und ausführen lassen, damit sind folgende
Vorteile verbunden:
- man gewöhnt sich an kleinere Programmteile sofort zu testen, was
die spätere Fehlersuche erleichtert
- man kann Controller und Peripherie besser erforschen/begreifen
- man kann schon beim Kurztest Laufzeiten der Programmteile abschätzen
- billig, so daß auch kleine Firmen und Ing.Büros das Zeug kaufen können.
- Es muß UNKOMPLIZIERT und EINFACH sein! Ich möchte nicht so ein
Herrschaftswissen erforderndes System. Um einfache, sichere Systeme
entwickeln zu können, müssen die Tools einfach beherrschbar sein.
Genau hier kommen wir zum eigentlichen Problem, der Preis. Wenn ich mir die
Preissituation für moderne Entwicklungssysteme so ansehe (10-25kEuro für'n
modernen Arbeitsplatz mit Windriver Produkten), dann ist klar, dass man
keine flexible Hardware mehr entwickelt, denn wenn man einmal für eine
Zielplattform investiert hat, dann muß man dabei bleiben...
Die Entwicklungssysteme und RTOSs sind so kompliziert (zum Teil
komplizierter als die eigentliche Anwendung), dass man nicht mehr HW/SW und
noch mehr in Personalunion machen kann. Das ist auch so gewollt,
schließlich muß die Firma ja noch sehr viel Geld für Schulung ausgeben, so
dass die Kundenbindung schließlich in Abhängigkeit endet...
Es wäre eigentlich mal an der Zeit, dass sich was an den konservativen
Entwicklngsmethoden ändert, wieso muß das immernoch so umständlich sein?
Von Emulgator und Geschmacksverstärker will ich gar nich reden...
Gruß aus Kiel
Ingolf
PS: Ich will hier niemanden missionieren ;-)
--
Ingolf Pohl
Dirk Ruth
wrote:
Würde ich so grundsätzlich nicht stehen lassen. Hängt sehr stark von
der Anwendung ab, die ich in diesem Beispiel extra nicht ausgeführt
habe.
Oder was sollte z.B. ein Controller machen, der darauf wartet, das das
Gerät eingeschaltet wird (Standby -> On). Ok er könnte selbst im
Standby sein und auf externe Interrupts warten ...
Tschö
Dirk
Matthias Weißer
> P1.0 = 1;
> bzw.
> P1.0 = 0;
> schreiben kann.
Bei welchem Compiler? Da '.' eigentlich ein C-Operator ist sollte einem das
von jedem C-Compiler um die Ohren gehauen werden. P1_0 ist die Notation die
ich kenne.
--
Matthias Weißer
matt...@matwei.de
http://www.matwei.de
Dirk Ruth
On Sun, 27 Jul 2003 19:04:36 +0200, "Matthias Weißer" <DT...@gmx.de>
wrote:
>Gerald Oppen wrote:
>> P1.0 = 1;
>> bzw.
>> P1.0 = 0;
>> schreiben kann.
>
>Bei welchem Compiler? Da '.' eigentlich ein C-Operator ist sollte einem das
>von jedem C-Compiler um die Ohren gehauen werden. P1_0 ist die Notation die
>ich kenne.
Geht schon. Auch der 8051 hat ein paar Register, die bitadressierbar
sind. Einfache eine Struktur auf das Register setzen ...
Tschö
Dirk
Gerald Oppen
Dirk Ruth schrieb:
> Würde ich so grundsätzlich nicht stehen lassen. Hängt sehr stark von
> der Anwendung ab, die ich in diesem Beispiel extra nicht ausgeführt
> habe.
> Oder was sollte z.B. ein Controller machen, der darauf wartet, das das
> Gerät eingeschaltet wird (Standby -> On). Ok er könnte selbst im
> Standby sein und auf externe Interrupts warten ...
Schön dass Du Deine Fragen schon selber gut beanwortest :-)
Gerald
Gerald Oppen
Matthias Weißer schrieb:
> Gerald Oppen wrote:
>
>>P1.0 = 1;
>>bzw.
>>P1.0 = 0;
>>schreiben kann.
>
>
> Bei welchem Compiler? Da '.' eigentlich ein C-Operator ist sollte einem das
> von jedem C-Compiler um die Ohren gehauen werden. P1_0 ist die Notation die
> ich kenne.
Geht z.B. beim IAR-Compiler für den NEC78k...
Gerald
Andreas Schwarz
>
> "Tilmann Reh" <tilma...@autometer.de> schrieb im Newsbeitrag
> news:3F2232E2...@autometer.de...
>> 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
In diesem Fall ist "Beschränktheit" IMHO das bessere Wort.
> fragt man nich wirklich ob C ne echte Programmiersprache ist.
C mag für den Anfänger etwas kryptisch aussehen, aber wenn man sich
daran gewöhnt hat kann man (besonders mit µCs) viel effektiver arbeiten
als in Basic, Pascal & Co. Im Gegensatz zu diesen Sprachen ist C nicht
als Lernsprache gedacht, und das sieht man halt.
--
AVR-Tutorial, über 350 Links
Forum für AVRGCC und MSPGCC
-> http://www.mikrocontroller.net
Andreas Schwarz
> Gerald Oppen wrote:
>> P1.0 = 1;
>> bzw.
>> P1.0 = 0;
>> schreiben kann.
>
> Bei welchem Compiler? Da '.' eigentlich ein C-Operator ist sollte einem das
> von jedem C-Compiler um die Ohren gehauen werden.
Wenn P1 eine Union mit einem Bitfeld ist, dann sollte zumindest etwas
wie P1.bit0 gehen. Ich bin mir nicht ganz sicher ob auch Zahlen als
Namen für Bitvariablen in ISO C erlaubt sind, vermutlich nicht. Sicher
wird das manche Compiler nicht davon abhalten eine solche Schreibweise
zu erlauben, aber wenn man das Programm dann portieren muss hat man ein
Problem.
Rainer Buchty
Weil gerade dieser kleine Unterschied ein Programm besser lesbar macht.
int foo(char a, char b)
{
return (a+b)*(a-b)
}
läßt sich dann doch wesentlich leichter begreifen als ein
PSHS A,B
LDA -1,S
ADDA ,S
LDB -1,S
SUBB ,S
MUL
LEAS 2,S
RTS
wobei 6809 Assembler dann doch zu den angenehmeren seiner Zunft gehört.
In 8051 will ich mir das gar nicht vorstellen.
Rainer
Axel Schwenke
>
> "Tilmann Reh" <tilma...@autometer.de> schrieb im Newsbeitrag
> news:3F2232E2...@autometer.de...
>>
>> dahingestellt...
>
> Da sage ich 100% ACK !
> Wenn man die leichtigkeit eines BASIC dagegen stelt
Die Ziele sind halt verschieden. Die Evolution von C ist eng mit der
von UNIX verknüpft und eigentlich sollte C nicht mehr sein, als ein
extrem portabler Makroassembler. Vielleicht nicht besonders komfor-
tabel, aber dafür rattenschnell.
Ach ja: <http://www.leo.org/information/freizeit/fun/auto.html>
XL
--
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau
Gerald Oppen
Frank Müller schrieb:
> Wenn jemand irgendwas mit einen 8051 baut dann gehe ich
> davon aus, das er da was ganz spezielles vor hat, und
> demnach auch eine Software benötigt die nur für diesen
> Einsatzzweck gebraucht wird. So eine Software muß nicht
> portabel sein.
Mann muss ja nicht gleiche ein komplettes Projekt portieren
wollen, obwohl das auch passieren kann wenn man feststellt
dass der 8051 doch ungeeignet ist. Aber auch so gibt es schon
viele Module die man immer wieder brauchen kann und in Assembler
ein neuschreiben bedeuten würden...
>>*) ... Assembler Listings schlecht wartbar sind?
>
>
> Das hängt ganz von dem ab, der sie schreibt.
Unsinn, Assembler brauch viel mehr Codezeilen für die Du viel
länger brauchst um sie zu lesen und in denen viel mehr Fehler stecken
können.
>>*) ... Projekte in Assembler deutlicher länger brauchen?
> Das kommt ganz darauf an was man braucht, und wie gut man
> sich mit der Programmieung auskennt.
Auch hier gilt: Assembler benötigt viel mehr Codezeilen...
>>*) ... Assembler in vielen Bereichen keine Vorteile hat?
> Und die wären?
Unpassende Frage... Assembler bringt Vorteile wenn man haargenau
mit der Befehlszykluslänge rechnen muss, das ist aber eher selten
und sollte man meiden da man sonst bei kleinsten änderungen wieder
alles neu abstimmen darf.
> Für was setzt man wohl einen 8051 ein? Damit wird doch
> hier kaum einer einen PC-Emulator bauen wollen...
Zwischen PC-Emulator und Kaffeemschine liegt noch eingiges dazwischen,
da fällt auch noch was für den 8051 ab.
Gerald
Marco Budde
> > *) ... Assembler nicht portabel ist?
> Wenn jemand irgendwas mit einen 8051 baut dann gehe ich
> davon aus, das er da was ganz spezielles vor hat, und
> demnach auch eine Software benötigt die nur für diesen
> Einsatzzweck gebraucht wird. So eine Software muß nicht
> portabel sein.
Da ist teilweise bei solche Billig-uC was dran. Bei anderen
komplexeren Geschichte, wie man sie heute häufig im Embedded
Bereich findet, stimmt das so aber ganz sicher nicht mehr.
> > *) ... Assembler Listings schlecht wartbar sind?
> Das hängt ganz von dem ab, der sie schreibt.
Im Industriebereich arbeiten meistens mehrere Leute an einem
IC. Da man sich für jeden uC einen eigenen Assembler aneignen
muß, kann man sich leicht vorstellen, wie das am Ende
aussieht. Div. Firmen haben dann auch noch die tolle Idee,
ihre eigenen Cores zu designen, die einen eigenen
Assembler benötigen. Krank.
Und wartbar bedeutet halt auch: ein in C geschriebenes
uC Programm kann jeder C-Programmierer ohne Probleme ändern.
Bei Assembler sieht das ganz anders aus.
> > *) ... Projekte in Assembler deutlicher länger brauchen?
>
> Das kommt ganz darauf an was man braucht, und wie gut man
> sich mit der Programmieung auskennt.
Das möchte ich stark bezweifeln.
> > *) ... Assembler in vielen Bereichen keine Vorteile hat?
> Und die wären?
Assembler macht IHMO nur im Algorithmen Bereich heute überhaupt
noch Sinn. SIMD bzw. MAC Einheiten lassen sich halt am besten
in Assembler ansteuern. Ganze Projekte würde ich im Leben nicht
freiwillig in Assembler schreiben. Wofür auch? Eine Verzweigung
kannst Du in Assembler auch nicht besser schreiben als in C.
> > ROTFL, das mag vielleicht für die Steuerung einer
> > Kaffeemaschine noch stimmen, geht aber ansonsten an der
> > Realität total vorbei.
>
> Für was setzt man wohl einen 8051 ein?
Für leider sehr viele Bereiche, siehe z.B. die ganze 8051 mit
eingebautem USB Core.
> Damit wird doch
> hier kaum einer einen PC-Emulator bauen wollen...
Man kann sich manchmal nur wundern, wo alles 8051 Cores
verbaut werden :). Dabei ist dessen Architektur für größere
Sachen IHMO völlig ungeeignet.
Heinz Saathoff
> Und wartbar bedeutet halt auch: ein in C geschriebenes
> uC Programm kann jeder C-Programmierer ohne Probleme ändern.
> Bei Assembler sieht das ganz anders aus.
Das aber nur bei den hardwareunabhängigen Programmteilen. Sobald die
Peripherie in's Spiel kommt, muß sich der C-Programmierer schon mit der
Bedeutung einzelner Register zur Steuerung der Hardware auskennen.
Der Anteil der hardwarenahen Routinen nimmt aber mit zunehmender
Codegröße ab.
- Heinz
Gerald Oppen
Heinz Saathoff schrieb:
Das sind aber zwei paar Stiefel ob ich ich die Hardwarearchitektur
eines uC oder dessen Assembler kennen muss...
Ersteres ist unabhängig von der verwendeten Programmiersprache und muss
ich auf jeden Fall kennen, letzteres interessiert mich in der Regel
nicht wenn ich in C programmiere. OK, nachvollziehen können sollte
man schon was der Compiler produziert wenns mal klemmt...
Gerald
Joachim Riehn
> * der der wurstelt ist hauptberuflich Programmierer
> und arbeitet die ganze Woche mit C.
> werden mit einfacheren Sprachen eher glücklich.
Es ist aber auch nicht einfach, konkret etwas zu
Willi Wipfel zu sagen. Er spricht in einem Posting
ausdrücklich von der "Komplexität seiner Aufgabenstellung".
Baut er Roboter ? Vielleicht ist dann Forth die bessere
Wahl. Das kann ich nicht beurteilen. Oder müssen
Messwerte ausgewertet werden ?
Ausserdem war von den vielen Registern des Atmel-AVR die
Rede und dem blossen Akku der 8051er. Trotzdem kann
man aber deswegen doch effektive Compiler bauen. Diese
Bemerkung war wohl nur in Blaue hinein gesprochen.
Probleme bereitet der Stack der 8051er, dem enge
Grenzen gesetzt sind.
Mit Grüssen
Joachim Riehn
Joerg Wunsch
>... Auch die Konkurrenz
>(DOS, Windows) wurde in C programmiert meines
>Wissens.
Windows ja (zumindest die aktuellen, Win2.x und vermutlich auch
3.x wohl eher noch nicht), DOS ist noch Assembler.
Das wesentliche Verdienst von C war es, die Implementierung von
Betriebssystemen aus der Assembler-Mottenkiste auf die Ebene einer
Programmiersprache zu heben. Ob man das da nun als ,,Hochsprache''
bezeichnen will, sei dahingestellt. Hardwarenähe und möglichst
effektive Umsetzung (siehe auch Bitfelder und so'n Kram) waren
notwendig dafür, auch das fast nicht vorhandene Laufzeitsystem ist
dafür praktisch fast eine Bedingnung (war es zumindest vor 25 Jahren,
als C entstanden ist). Rein zufällig ähneln heutige MCUs wohl doch
recht stark den Minicomputern von vor 25 Jahren, so daß sich C dort
auch als effektive Waffe der Wahl herausstellt.
--
J"org Wunsch Unix support engineer
joerg_...@interface-systems.de http://www.interface-systems.de/~j/
Rafael Deliano
> recht stark den Minicomputern von vor 25 Jahren,
daß es gut auf PDP11 läuft, weil das ehedem als zukunfts-
weisende Hardware galt.
Dann kippt das Ganze aber um: Leute die neue CPUs
entwickeln machen erstmal Benchmarks mit den
vermutlichen Applikationen ihrer Kunden.
Wenn die in C geschrieben sind, compilieren sie
besser, wenn man nicht allzusehr vom status quo
abweicht. Im Bereich PCs ist also jegliche Innovation
bezüglich Computerarchitektur sicher verhindert.
MfG JRD
Heinz Saathoff
> > Rein zufällig ähneln heutige MCUs wohl doch
> > recht stark den Minicomputern von vor 25 Jahren,
> Halte ich nicht für Zufall. C wurde so geschrieben,
> daß es gut auf PDP11 läuft, weil das ehedem als zukunfts-
> weisende Hardware galt.
Was man auch schön an den Pointern mit Predekrement und Postinkrement
sieht. Ließ sich direkt auf einen Maschinenbefehl umsetzen.
> Dann kippt das Ganze aber um: Leute die neue CPUs
> entwickeln machen erstmal Benchmarks mit den
> vermutlichen Applikationen ihrer Kunden.
> Wenn die in C geschrieben sind, compilieren sie
> besser, wenn man nicht allzusehr vom status quo
> abweicht. Im Bereich PCs ist also jegliche Innovation
> bezüglich Computerarchitektur sicher verhindert.
Aber das mit Sicherheit nicht wegen C!
Wenn es auf die gute Implementierbarkeit von C angekommen wäre, hätte
IBM beim Entwurf des PCs die Motorola 68000 verwenden müssen. Die waren
vom Instruktionssatz und der Registerarchitektur deutlich besser als der
8086. Beim 8086 musste C sogar erweitert (verschlimmert) werden, damit
man mit der segmentierten Architektur auf C-Ebene arbeiten konnte
(_near/_far). Auch die nicht vorhandenen Universalregister machten C
Implemntieren eher das Leben schwer, genau wie der der seperate IO-Bus
des 8086.
Heute lebt die Architektur immer noch in den Pentiums weiter. Fluch der
Rückwärtskompatibilität.
- Heinz
Matthias Weißer
Dann ist der IAR-Compiler kaputt. Selbst als Präprozessormakro wird das vom
GCC nicht aktzeptiert.
Matthias Weißer
> Matthias Weißer wrote:
>> Gerald Oppen wrote:
>>> P1.0 = 1;
>>> bzw.
>>> P1.0 = 0;
>>> schreiben kann.
>>
>> Bei welchem Compiler? Da '.' eigentlich ein C-Operator ist sollte
>> einem das von jedem C-Compiler um die Ohren gehauen werden.
>
> Wenn P1 eine Union mit einem Bitfeld ist, dann sollte zumindest etwas
> wie P1.bit0 gehen. Ich bin mir nicht ganz sicher ob auch Zahlen als
> Namen für Bitvariablen in ISO C erlaubt sind, vermutlich nicht. Sicher
Eben. Variablennamen die mit Zahlen beginnen sind nicht gültig.
Rafael Deliano
> IBM beim Entwurf des PCs die Motorola 68000 verwenden müssen.
gebastelt, wie schon gesagt wurde.
Für die Entscheidung von IBM gab es wohl zwei Gründe:
* vom 68000 gab es nur die CPU, aber noch keine Peripheriebausteine.
Der ältere 8086/88 hatte kompletten Chipsatz.
* der 68000 war zu Minicomputer-artig: er hätte einige schlappe
Systeme am unteren Ende von IBM diskreditiert. Man wollte ein
verkrüppeltes Gerät. Unabhängig davon, daß es teuer war.
Details finden sich in:
Bradley "The Creation of the IBM PC" Byte September 1990
5 Seiten, kann ich scannen. Wird man allerdings die Fotos
vom WireWrap Breadboard nichtmehr richtig erkennen können.
C war 1981 schon deshalb kein Thema, weil Intel gerade seinen IAPX432
als 32 Bit "objektorientierten" Prozessor explizit für Ada ( damals
noch nichtmal fertigsstandardisiert ) und als 68000-Killer auf den
Markt gebracht hatte: war durch das Pointergewurstle so langsam daß
er praktisch nach der Bemusterung schon wieder abgekündigt wurde.
MfG JRD
Heinz Saathoff
> > Wenn es auf die gute Implementierbarkeit von C angekommen wäre, hätte
> > IBM beim Entwurf des PCs die Motorola 68000 verwenden müssen.
> * vom 68000 gab es nur die CPU, aber noch keine Peripheriebausteine.
> Der ältere 8086/88 hatte kompletten Chipsatz.
> * der 68000 war zu Minicomputer-artig: er hätte einige schlappe
> Systeme am unteren Ende von IBM diskreditiert. Man wollte ein
> verkrüppeltes Gerät. Unabhängig davon, daß es teuer war.
> Details finden sich in:
> Bradley "The Creation of the IBM PC" Byte September 1990
> 5 Seiten, kann ich scannen. Wird man allerdings die Fotos
> vom WireWrap Breadboard nichtmehr richtig erkennen können.
Scannen brauchst Du's nicht unbedingt. Das mit dem Chipsatz kann ich
nicht ganz als Argument verstehen, da der 68000 ja eine recht flexible
Busstruktur hatte, wo auch alte 8-bit Peripherie angeschlossen werden
konnte. Hatte Motorola wohl genau aus dem Grunde gemacht.
Kann aber ja auch sein, daß Intel eben alles liefern konnte, während IBM
sonst einen Mix von Motorola/Intel/Sonstige hätte verbauen müssen? In
dem von Dir genannten Buch wird sicherlich dazu auch was stehen, neben
dem, was Du hier schon angedeutet hast.
- Heinz
Rafael Deliano
der IC-Hersteller direkt mit Kunden zusammen. Der Kunde
will nicht viele Zulieferer und er will aufeinander
abgestimmte, risikofreie Lösung. Man kann nicht Motorola
und Intel mit an den Tisch setzen und sie sollen
z.B. Karten offenlegen welche ICs in Entwicklung
sind und wieweit sie bei bestimmten ICs im Preis
nachgeben.
MfG JRD
Bertram Geiger
http://www.reed-electronics.com/tmworld/index.asp?layout=article&articleid=CA187350
--
Bertram Geiger, Graz - Austria
Oliver Tonn
ohne irgendwelche Programmierkenntnisse würde ich mir erstmal ein
allgemeines C/C++ Buch besorgen, als Einstieg.
In der Technikerschule haben wir da entsprechende Bücher eingesetzt, die
Titel kann ich bei Bedarf gerne mal nachreichen.
Ich habe selber ein 8051-Entwicklungssystem auf dem ich z.Z. in Assembler
programmiere, aber wohl auch bald mal in C.
Wegen der besseren Erweiterbarkeit habe ich die Hardware der BBS Winsen/Luhe
( www.goblack.de ) im Einsatz und als Entwicklungssoftware den uC51 von
Wickenhäuser ( www.wickenhaeuser.de ). Die "Demoversion" erlaubt Projekte
von maximal 8kByte Codegröße, was meistens reicht. Außerdem ist die
Vollversion auch nicht so teuer. Der C-Compiler erstellt aus dem Quellcode
einen ziemlich guten Assemblercode.
Bei Bedarf kann ich gern noch mehr Infos geben.
Gruß Oliver
"W. Wipfel" <willi....@gmx.de> schrieb im Newsbeitrag
news:3f22f1ef$0$30261$9b62...@news.freenet.de...
>
> "Matthias Weißer" <DT...@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.
>
>