Hallo Leute, habe vor einen C-Compiler für PICs zu programmieren. Hätte jemand Interesse oder Anregungen und Vorschläge? MfG Michael Saller
Hi, unter dem folgenden Link findest du ein Vergleich zu mehreren Compilern: http://www.informel.de/pic/ccompiler.htm Gruß Fernando
Genau dass ist mein Problem! Entweder sind die Compiler sau-teuer oder sie taugen als Freeware nichts. Kennt jemand den von Microchip? Welche tools brauche ich da wirklich? MfG Michael Saller
Microchip C17 und C18 sind wie der Name schon sagt, C-Compiler für die PIC17- und PIC18-Familie. Die sind aber noch recht neu und kosten auch etwas. Wenn du einen guten C-Compiler haben möchtest, musst du schon einiges investieren. Die Frage ist nun für dich, lohnt sich die Investition langfristig und welche Mikrocontroller willst du eventuell verwenden?
da muss ich dir zustimmen ! für die 16er serie gibt es keinen vernünftigen (gut und leistbar) C- compiler ! also interesse hätte ich auf jeden fall.
Schau dir mal den CCS Compiler an, der ist nach meiner Meinung nach der beste im Preis/Leistungsverhältnis. Den verwende ich auch selbst und bin zufrieden. Aber kann ich nur sagen, es gibt kein perfekten Compiler. Jeder hat seine Stärken und Schwächen. Zeiger können z.B. im CCS Compiler nicht ausgeführt werden. Aber mal ehrlich, ich kenne kein Beispiel für Mikrocontroller wofür ich Zeiger brauche. Die Sonderfunktionen vom CCS sind nach meiner Meinung die besten unter den C-Compilern für die PICs. Das beste Beispiel sind die Sonderfunktionen für die I2C-Schnittstelle. Für den Hitech-Compiler müssen erst diese Funktionen geschrieben werden. Wie gesagt jeder Compiler hat seine Schwächen und Stärken, die der Programmierer hinnehmt und das beste daraus macht.
> Aber mal ehrlich, ich kenne kein Beispiel für Mikrocontroller wofür > ich Zeiger brauche. Keine Zeiger? Wie übergibst du dann z.B. einen String an eine Funktion?
OK, jetzt bin ich entgültig zu dem Entschluss gekommen, selber einen Compiler zu programmieren. Dürfte eigentlich nicht allzu schwer sein!? Wer hat Lust mitzumachen? MfG Michael Saller
Ui, da hast du dir was vorgenommen... willst du komplett bei Null anfangen? Dann behaupte ich einfach mal dass du keine Chance hast - du darfst mir natürlich gerne das Gegenteil beweisen :-) Oder möchtest du einen anderen Compiler auf PIC portieren? Such mal nach "SDCC PIC", offensichtlich hat jemand schonmal was in der Richtung unternommen.
Ich werde dir das Gegenteil beweißen! Er wird zwar sicherlich nicht besser, als ein 500€ Compiler, aber brauchbarer, als jede Freeware.
Das 500€ sollte ein EURO-Zeichen sein. Jetzt hab ich nur noch ein Problem: Wie mach ich den Parser???
Das "€" anstelle des Euro-Zeichens ist ein ziemlich seltsamer IE-Bug. Den Parser würde ich mit lex & yacc machen.
Test: g Ich denk mal du würdest den Compiler dann als Freeware zur Verfügung stellen? Das wär gut :) Der SDCC PIC port ist noch ein wenig buggy... Ich kenne jemanden der gerade einen sehr guten Pascal Compiler für die PICs entwickelt und der hat mittlerweile so ca. 8000 Zeilen Pascal Code (ja der Compiler ist selbst in Pascal geschrieben ;) ) - ich kann mich jetzt auch vertun aber ich glaube soviel wars... Den vertreibt er dann allerdings nicht kostenlos :-/ Was willst du denn für eine Programmiersprache dafür benutzten? Evtl. direkt in MPLAB integrieren - als Plugin? MfG, Dominik S. Herwald http://www.dsh-elektronik.de/
Hi! Test: € Hm. Als Sprache hätte ich C genommen und ich werds warscheinlich in VB programmieren. Mein Compiler - sollte er was werden, ich denke aber schon - wird natürlich Freeware. In die MPLab werd ich ihn nicht integrieren. Ich arbeite selber an einer Entwicklunsumgebung, vorerst nicht mit Debugger. Was meint ihr genau mit "lex & yacc"??? MfG Michael Saller
Hmmm, ein in VB geschriebener C-Compiler ist... eigenwillig. Ich fürchte du unterschätzt den Aufwand für dein Vorhaben um mehrere Größenordnungen. Eine Google-Suche nach "lex yacc" wird dich z.B. zu http://dinosaur.compilertools.net/ führen. Wenn du einen C-Compiler schreiben willst führt daran vermutlich kein Weg vorbei, also arbeite mal ein paar Tutorials durch und schau wie du zurechtkommst. Ein Basic-Interpreter o.ä. ist mit yacc relativ einfach machbar, aber für einen C-Compiler ist schon einiges an Arbeit erforderlich. Wenn du nach "C yacc grammar" suchst solltest du zumindest fertige Grammatikdateien für C finden, aber die Hauptarbeit ist damit noch lange nicht getan.
Also: Ich will zumindest die Entwicklungsumgebung (mit Präprozessor, Scanner und Parser) in VB machen, weils einfach schneller und einfacher geht. Den Compiler selber schreib ich dann als dll in VC.
Das mit der DLL würde ich lassen. Mach es doch einfach so wie es alle Compilerhersteller machen: als Konsolenprogramm. Das ist einfacher als eine DLL, läuft auch unabhängig vom Betriebssystem, und lässt sich problemlos in jeden Editor integrieren.
Hi. @Andreas Schwarz Meinst du mit Konsoleprogramm ein Programm in der Dos-Eingabeaufforderung??? Sowas will ich nämlich vermeidern. Ich mit mit der Enwicklungsumgebung als MDI sowieso schon bald fertig. @Alle Ok. Basic wäre viel einfacher. Auch Pointer wären machbar. Aber alle Datentypen können ein Vorzeichen haben. Soll ich jetzt einfach noch Vorzeichenlose dazuerfinden, oder wäre es dann nicht mehr Basic???
Könnntest das ganze auch in Java machen. Dann wärs zumindest Plattformunabhängig... Ich persöhnlich kann Java nur empfehlen - da hab ich auch mal nen sehr schönes Beispiel für Syntax Highligthting gefunden und MDIs sind damit auch sehr einfach zu realisieren. Ausserdem sehen die Oberflächen vieeel besser aus. Ich persönlich mag kein VB --> M$ und teuer. :P Wenn schon Oberfläche zusammenklicken (schüttelsich ;)), dann Delphi. Ist sehr ähnlich zu VB läuft aber dank Kylix auch unter Linux. MfG, Dominik S. Herwald http://www.dsh-elektronik.de/
Ja, ich meine das was du "DOS-Eingabeaufforderung" nennst. Jeder Compiler ist über ein Konsolenprogramm aufrufbar, ob IAR, Delphi, Borland C++ oder Visual C++. Ein reiner DLL-Compiler wäre nicht mehr als ein Spielzeug. Und überhaupt: es geht hier doch um einen Compiler, oder? Ein Compiler ist ein Programm, das kompiliert, keine VB- oder Java-Oberfläche. Wieso wollt ihr also mit dem unnützen Beiwerk anfangen, wenn vom Compiler an sich noch überhaupt nichts zu sehen ist? Es gibt gute Editoren wie Sand am Meer, ein weiterer ist schlicht überflüssig. Ich meine immer noch dass das Ganze nichts wird, aber wie gesagt, du darfst mich vom Gegenteil überzeugen. Es wäre nett wenn du uns in diesem Thread über deine Fortschritte auf dem laufenden halten würdest.
@Dominik S. Herwald Java kann ich nicht und ich habe absolut keine Ahnung davon. Aber wenn ich ihn als Konsoleprogramm mache, dürfte dass ja kein Problem mehr sein. @Andreas Schwarz OK. Ich mache ihn als Konsoleprogramm, dann aber mit VC++, nicht mit QBasic. Ich könnte ihn dann mit Befehlszeilenparametern aus meinen Editor ausführen. Der Editor ist jetzt eh schon bald fertig. Wenn du sagst, es gibt gute, dann: Wo? Freeware? Mit Treeview (Baumansicht)? Ich hab bis jetzt bei allen meinen Programmen mit der Oberfläche angefangen. Du hast recht! Was nützt sie mir ohne den Kern. Ich wollte ihn ja zuerst als dll machen, und die hilft mir alleine nichts! Deine Idee, ihn als Konsoleprogramm zu machen, erübricht das Ganze. Sicherlich wird er für den Anfang nichts besonderes, aber er lässt sich ja erweitern. @Alle Wie soll ich dass denn jetzt mit den verflixten Datentypen machen??? (s.O.) PS: Warum ich einen Compiler machen will: Ich wollte vor einem Jahr ein Ladegerät bauen. Ich wurde aber beim Programmieren des I2C-Netzes (ca 8 MCUs) und des LCD-Displays mit Assembler schier wahnsinnig. Bis denn Michael Saller
Du hast ein Ladegerät mit 8 MCUs entwickelt. Ist das nicht etwas wahnsinnig. Was hast du mit den ganzen MCUs alles gesteuert? Ein Ladegerät geht auch etwas einfacher. Mit einem Lade IC,einem MCU und vielleicht einen Step-Up IC und ein paar Bauteilen wärst du gut bedient gewesen. Frank
Nein, ich wollte es ja entwickeln, bin aber deswegegen gescheitert. Es soll 4 Kanäle haben. Und eine einfache, schnelle Bedienung. So. Und daher für jeden Kanal einen Steuerungs-MC (es soll gepulst laden) und für alle Kanäle eine Lade-MCU (die die Ladeprogramme enthält). Dann eine Display-Steuerung. Und dann ein RS232-Interface. Und eine kleine MCU, die die Temperatur des Trafos überwacht und den Lüfter des Kühlkörpers regelt. Sicher ist das wahnsinnig aufgebauscht. Wäre dann aber ein HighEnd-Geräd. Es war halt mal so ein Traum für mich, komplizierter gehts ja nicht mehr, und dass hat mich fasziniert. MfG Michael Saller
Aber welche Datentypen soll ich nun machen. Nur die Basic (also mit Vorzeichen) oder auch welche ohne Vorzeichen? Ist Integer bei 8-Bit-MCUs nun 8-Bit breit, oder doch 16???
Es gibt aber schon fertige "Lade-MCU" , den BQ2002 von Texas Instruments. Das ist ein NiCd/NiMH Fast-Charge Management IC. Das IC signalisiert wann die Akkus aufgeladen sind und hat ein Temperatur Sensor Eingang und noch einige andere Features. Die Variante ist güngstiger als mehrere MCU zu verwenden. Wenn es nur zum Basteln ist, kannst du deine Variante machen. Aber wenn es ein Endprodukt werden soll, wird deine Schaltung viel zu teuer. Frank
Hallo Michael !! Ich studier Informatik und hab in den letzten 4 Monaten in einem Praktikum einen relativ einfachen Compiler geschrieben und denke sagen zu können, das du dir da wirklich etwas vorgenommen hast. Warum willst du Datentypen "erfinden" ?? Es gibt das Schlüsselwort "unsigned" welches für vorzeichenlose Datentypen gilt. Du solltest wohl erst mal mit 8/16/32 Bit signed/unsinged int anfangen. Später kannst du ja float/enums hinzunehmen und als Krönung structs/unions und bitfelder... weiterhin solltest du deinen compiler in compiler und linker aufteilen und ein interface zum einbinden von libraries einbauen und später auch ein set stdlib's hinzufügen. Und glaub mir.. Spätestens beim Thema Codeoptimierung wirst du mit den Ohren schlackern.. ;-) Viel Spaß. Andre
Ein Ladegerät mit 8 PICs... aha. Dann sollte man aber erwarten dass das Teil gleich 16 eigentständige Ladekanäle ansteuern kann, über ein Grafikdisplay mit mindestend 240x128 Pixeln verfügt, ne PC Tastatur, ne Maus und ein Funkmodem zum Datenloggen ansteuern kann und nebenbei noch dein Haus automatisiert ;) :P :> Mein Roboter hat zum Steuern ja grade mal drei PICs die über I2C vernetzt sind! Und die haben noch riesige Reserven an I/Os und Rechenleistung... Warum nicht einfach einen PIC16F877? Mit 20MHz ist der schnell genug und hat alles an Hardware onChip was du braucht. 33 I/Os, 8A/D Wandler, MSSP, 2PWM/CCP, UART etc. Das sollte für vier Ladekanäle, ein LCD und nen paar Sensoren plus Tastatur reichen ;) Sollten das nicht genug I/Os und A/Ds sein - was ich mir bei einem Ladegerät fast nicht vorstellen kann - ist egal, du willst ja eh I2C benutzten also einfach nen paar I2C Portexpander und AD/DA Wandler dran und fertig iss. Zum Editor: Also mein Universaleditor unter Kleinweich Betriebssystemen den ich eigentlich für alles einsetzte (bis auf Java - da nehm ich Eclipse) ist Proton. Hat über 40 Syntaxschemen und ist ziemlich komfortabel. Konsolenproggis lassen sich da recht einfach einbinden und auf Hotkeys legen. --> http://www.meybohm.de/ MfG, DSH
@Frank Knüppel Es soll kein Endprodukt werden, nur so aus Spass. Außerdem ist das im Moment gar nicht mein Problem, sondern der verflixte Compiler. @Andre Groß Hi, ích dachte, signed und unsigned gibts nur in C? Von den größeren Datentypen wie Fließkommazahlen, Bittfelder und alle mit 32 Bit bin ich ja eh noch meilenweit entfernt. An Codeoptimierung denke ich auch noch lange nicht. Aber er lässt sich ja erweitern. Aufteilen werde ich ihn auf jeden Fall so weit es geht, und nicht nur in Linker und Compiler. Es soll nicht der weltbeste Compiler auf der Welt werden. Wenn er alle einfachen Befehle, wie Schleifen, Bedingungen, Grundrechenarten und logische Operatoren übersetzen und Therme zerlegen kann reicht mir das. Mein sekundäres Ziel ist eine Entwicklungsumgebung - ...in der ich Projekte mit mehreren Controllern verwalten kann - ...in der ich modular Programmieren kann - ...in der ich Libraries und Makros schreiben und einfach einbinden kann - ...in der ich die Controller gleich Brennen kann - ...die sowohl Assembler und Basic (eigentlich wollte ich ja C) übersetzten kann - ...die (später!) auch simulieren und debuggen kann Aber im Moment ist mein primäres Problem der Compiler.
@Dominik S. Herwald Hi, die Idee mit dem Ladegerät hab ich eh schon lange wieder vergessn. Deinen Editor seh ich mir mal an.
Ich glaube du stellst dir das so einfach vor. Jeder hat seine Schwächen und du willst ein Compiler schreiben, der fast alles können sollen. Firma die speziell nur Compiler entwickeln haben einige Programmierer, die einen "guten" Compiler erstellen. Und du willst ein Compiler mit - einer Entwicklungumgebung das mehrere Controller verwaltet - das Assembler und Basic versteht - Libraries einbindet - simulieren und debuggen kann - und sehr vieles mehr schreiben. Ich glaube du hast keine Ahnung, was das für eine Arbeit ist. Ich hoffe es für dich, das du ein guter Programmierer bist und das hinkriegst. Aber ich denke mal die Entwicklungsumgebung für dein Compiler ist dein geringstes Problem. Der Kern, also der Compiler und Linker wird wirklich eine harte Nuss. P.S. Was bringt dir ein Compiler ohne Codeoptimierung, da würde doch keiner an diesem Compiler ein Projekt verwirklichen. Sorry das ich so ehrlich bin , aber ich glaube einfach du hast dir hier zu viel vorgenommen. Frank
Simulieren und Debuggen will ich ja noch gar nicht. Stimmt, die Entwicklungsumgebung ist bald fertig. Stimmt, der Compiler ist eine harte Nuss. Was verstehst du genau unter Codeoptimierung? - Dass er an einen speziellen Controller angepasst ist??? Sicherlich werde ich den Compiler erstmal für einen speziellen Controller entwerfen.
Ja der Compiler muss speziell für die jeweilige Mikrocontroller Familie geschrieben sein. Es gibt bei fast jedem Compiler ein sogenannten Optimierungslevel, den man einstellen kann, dadurch werden die Programmzeilen durch bestimmte Kriterien (sind zu bei jedem Compiler selbstverständlich unterschiedlich) optimiert. Frank
Unter optimierung versteht man z.B. die optimale Verwendung von Registern, oder das optimieren von Schleifen, indem Sprünge minimiert und invariable ausdrücke aus der schleife genommen werden, und vieles mehr.. Du solltest einen C-Compiler machen, da du dich da an die ANSI-C Richtlinien halten kannst und auch die meisten C programmieren können. Dadurch kannst du auch erst mal einen Compiler machen, der C-Code in Assembler wandelt und die Optimierung des Assemblers und das Linken kannst du fürs erste einem bereits vorhandenen Assembler und Linker überlassen... Wenn das dann mal laufen sollte kannst du die Stufen Assembler und Optimierung einbauen und dann nach ca. 3 - 4 Jahren wenn du soweit bist kannst du mit der Feinarbeit anfangen ;-) Andre.
Ich schau, dass ich erstmal einen einfachen Compiler für eine einfache MCU mache. Basic oder C??? Basic ist einfacher, C logischer. Was jetzt? In C hätte man signed und unsigned - in Basic nicht. Ist C jetzt zu kompliziert oder nicht? Warum sollte der Linker so ein Problem sein??? Was ist genau ein Parser? Die Syntaxüberprüfung nach dem Scanner oder eine Funktion zum Therme-Zerlegen?
Ich würde sagen C. Ein logischer Aufbau ist immer einfacher umzusetzen, auch wenn die Sprache im gesamten mächtiger ist. > Was ist genau ein Parser? Die Syntaxüberprüfung nach dem Scanner > oder eine Funktion zum Therme-Zerlegen? Beides. Die Sache geht Hand in Hand. Du zerlegst die Therme und wenn diese nicht aus den gewünschten Kompnenten bestehen, dann bringst du einen Fehler..
Mal eine grundsätzliche Frage: Wenn Dein Ziel eigentlich die C-Programmierung ist, was hält Dich denn da noch am PIC ? Wie Du hier im Forum sehen kannst, sind die meisten AVR-Leute mit dem AVR-GCC / WINAVR doch sehr zufrieden. Das ist auch kein großes Wunder, da die AVR-Architektur wesentlich leichter optimalen C-Code bewerkstelligen kann als der PIC. Und auch die neuen ATTINY26, ATMEGA8 haben eine riesen Preisrutsch nach unten gemacht, da können höchstens einige OTP-PICs mithalten. Aber kein vernünftiger Mensch geht zu OTPs zurück, wenn er einmal Flashs programmiert hat. Wie Du bemerkt haben wirst, wird das Optimieren beim Compiler als das A und O betrachtet. Den IDE-Schnulli drumherum kannst Du erstmal vergessen, da gibts genügend fertiges. Aber ich schließe mich den anderen an, sowas stampft man nicht so einfach aus dem Boden und erst recht nicht für eine so C-feindliche Architektur, wie den PIC. Das Ladeprojekt habe ich auch im Auge, allerdings mit einem ATMEGA8 für 2 Zellen (2*PWM, 4*ADW). Die PWM deswegen, weil die modernen Akkus schon mal Amperes brauchen und ich keine Lüfter und riesen Trafos haben will. Das ganze dann mit einem weiteren ATMEGA8 auf 4 Zellen kaskadierbar usw. Peter
OK, der C-Compiler für PICs hat sich erledigt. Zu AVR-GCC / WINAVR: Wo gibts die? Freeware? Hab noch nie was mit AVRs gemacht, ich dachte damals nie, dass der Unterschied so groß sei! Der einzige Grund, warum ich mich damals für PICs entschied war, dass es eine gute Homepage für PICs gab. Zum Ladegerät: PWM ist mir schon klar. Aber ich will die Akkus gepulst laden, ich weiß jetzt die Frequenz nicht auswendig, aber da wird geladen, dann kurz entladen, dann eine Pause gemacht und dann wieder geladen. Angeblich ist dass die beste Ladeart. Und dass schafft eine MCU nicht mal mit 2 Kanälen.
"Zu AVR-GCC / WINAVR: Wo gibts die? Freeware?" Geh diese Seite ganz nach oben und lies mal links davon, da sind 2 Links "AVR-GCC". Zum Ladgerät: Ich weiß jetzt nicht, mit wieviel MHz Du pulsen willst, damit der AVR das nicht schafft. Was ich so als Reflexladung kenne, ist 1s laden und 10ms entladen. Daß ich einen MEGA8 für nur 2 Zellen nehmen will hat nicht im entferntesten mit der Rechenpower zu tun, sondern nur mit der Anzahl der PWM/ADW-Kanäle. Und ehe ich da teure externe Komponenten nehme, ist ein 2. MEGA8 eben wesentlich billiger. Peter
Ich wollte ja keine externe Komponenten nehmen, sondern nur MCUs. Ein bisschen Rechenleistung wird aber schon verlangt: RS232, Display... Das hatt sich aber eh schon erledigt, da ich mir vom ELV den Bausatz ALC7000(oder so) bestellt habe.
Hat sich doch noch nicht erledigt. Die ATMegas sind ja der Hammer. Weiß aber noch nicht, ob die 10 Bit ADCs/DACs ausreichen. Das C4-Ladegerät vom Conrad hat 12-Bit Auflösung. Aber dass muss ich hald ausprobieren... Die Kanäle sollen ungefär 2A Leistung haben. Gibts da schon einen Schaltplan?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.