C für 8051

[Frank Müller]

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

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]

"Gerald Oppen" <Gerald.Oppen@web.de> schrieb

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]

Frank Müller wrote:

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.

cu, Marco

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

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

 

[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]

C wurde vor etwa 30 Jahren in Auftrag gegeben
Bell Labs hat C nicht offiziell entwickelt.

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

 

[Gerald Oppen]

Frank Müller schrieb:

"Gerald Oppen" <Gerald.Oppen@web.de> schrieb


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.

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]

"Marco Budde" <mb-news-a@linuxhaven.de> schrieb

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]

Marco Budde wrote:

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]

On Sun, 27 Jul 2003 12:31:54 +0200, Gerald Oppen <Gerald.Oppen@web.de>
wrote:

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...

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]

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.



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

 

[Dirk Ruth]

On Sun, 27 Jul 2003 19:04:36 +0200, "Matthias Weißer" <DTMAN@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]

W. Wipfel wrote:

"Tilmann Reh" <tilmann.reh@autometer.de> schrieb im Newsbeitrag
news:3F2232E2.6AE40942@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]

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
wird das manche Compiler nicht davon abhalten eine solche Schreibweise
zu erlauben, aber wenn man das Programm dann portieren muss hat man ein
Problem.

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

 

[Axel Schwenke]

"W. Wipfel" <willi.wipfel@gmx.de> wrote:

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

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.

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

 

[Heinz Saathoff]

Marco Budde schrieb...

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

 

[Matthias Weißer]

Gerald Oppen wrote:

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...

Dann ist der IAR-Compiler kaputt. Selbst als Präprozessormakro wird das vom
GCC nicht aktzeptiert.



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