PIC? In C? Prust! Die Architektur der PIC's ist älter als die der 8051er.
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 snipped-for-privacy@matwei.de
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.
Schreib ich irgendwas von Betriebsystem? Hast du das z.B. übersehen? Natürlich kann ein Compiler auch in deinem Kopf "laufen"
Mag sein. Wird der heute _ernsthaft_ eingesetzt?
Klar findet man immer Beispiele bei denen das nicht so ist. Aber macht das Sinn in einer kurzen Antwort das alles zu erwähnen? Auch hier gilt: Bei 95% aller heutigen C Compiler läuft es nach obigem Schema Compiler->Assembler->Linker
-- Matthias Weißer snipped-for-privacy@matwei.de
Ok, ich erlag einem Irrtum! Sacktuch und Asche über mich ! ;-)
Selbst
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.
"Tilmann Reh" schrieb im Newsbeitrag news: snipped-for-privacy@autometer.de...
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.
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.
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
y = P5; P5=y;
Meist ist dann noch jedes einzelne Bit auf dem Port nochmals extra definiert.
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).
Wird eher weniger sein als bei Assembler, da der Compiler schon viele falsche Dinge erkennt, die Dein Assembler völlig ignoriert.
Tschö Dirk
W. Wipfel schrieb: > man fragt sich wirklich ob C ne echte Programmiersprache ist. > War das nicht mal ein programmiernotbehelf für > die DEC VEX Kisten ?
Unbefangene Leserinnen und Leser bekommen nun aber wirklich einen völlig schiefen Eindruck von der Sprache C. Vor einigen Wochen hatten wir Grundsatz- diskussionen über C. Diese Diskussion war wirklich interessant, weil man gegensätzliche Standpunkte kennen lernen konnte.
Das Betriebssystem UNIX mit seinen Varianten und C wurden parallel entwickelt und sie gehören zusammen. Das Rückrat des Internet wird von UNIX-Rechnern gestellt. Auch die Konkurrenz (DOS, Windows) wurde in C programmiert meines Wissens. Die überheblichen Kommentare über C erinnern an den Schildbürger, der sich den Ast absägt, auf dem er sitzt.
C wurde vor etwa 30 Jahren in Auftrag gegeben und entwickelt vor allem, um eine möglichst leicht transportable Sprache (auf verschiedene CPU's) zu bekommen. Es ist von vornherein klar, dass ein gewisser Kompromis geschlossen werden musste. Es gibt halt viele gute Compiler für C für die verschiedensten Plattformen.
Es würde vielleicht Sinn machen, über die "Top Five" zu diskutieren. Die Sprachen, die sich gegenseitig ergänzen und die man am ehesten lernen sollte, meine ich.
Aber ich halte es für eine Gespenster-Diskussion, nur eine einzige Sprache heilig zu sprechen, oder eine einzige Sprache als "Trouble-Maker" zu mobben.
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
Weil ...
*) ... Assembler nicht portabel ist?*) ... Assembler Listings schlecht wartbar sind?
*) ... Projekte in Assembler deutlicher länger brauchen?*) ... Assembler in vielen Bereichen keine Vorteile hat?
ROTFL, das mag vielleicht für die Steuerung einer Kaffeemaschine noch stimmen, geht aber ansonsten an der Realität total vorbei.
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
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.Um UNIX auf Minicomputern leicht portieren zu können. D.h.
MfG JRD
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
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
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 snipped-for-privacy@matwei.de
Geht schon. Auch der 8051 hat ein paar Register, die bitadressierbar sind. Einfache eine Struktur auf das Register setzen ...
Tschö Dirk
In diesem Fall ist "Beschränktheit" IMHO das bessere Wort.
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
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
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:
XL
-- Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau
Dann ist der IAR-Compiler kaputt. Selbst als Präprozessormakro wird das vom GCC nicht aktzeptiert.
-- Matthias Weißer snipped-for-privacy@matwei.de
Rafael Deliano schrieb: > * der der wurstelt ist hauptberuflich Programmierer > und arbeitet die ganze Woche mit C. > Leute die nebenbei Löten oder anderes zu tun haben > 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
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_wunsch@interface-systems.de http://www.interface-systems.de/~j/
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. 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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.