Hallo! Hat jemand Erfahrungen mit dem MikroC Compiler? Die Vollversion erscheint mir im Vergleich zu anderen (XC, HI-TECH,..) sehr viel billiger zu sein, wo ist hier der Haken? Ich überlege mir eine Vollversrion für gewerbliche Zwecke zuzulegen. Ich hab auch schon den Compiler-Vergleich-Beitrag im Forum durchstudiert. Hat jemand noch mehr Erfahrung damit (speziell im Vergleich zu den teuren Compilern XC, HI-TECH,..)? Danke!
Der XC-Compiler ist als Vollversion kostenlos und funktioniert wirklich gut, eingebunden in MPLAB X. Erst wenn man die Optimierungsoptionen verwenden möchte, kostet dieser Compiler Geld. Da der Optimierungseffekt aber begrenzt ist (je nach Optimierungseinstellung läuft vielleicht auch ein Teil der Software nicht mehr richtig), probiere vielleicht Deine Projekte erst einmal ohne Optimierung aus.
Ich finde es ein sehr angenehm gemachtes Tool. Ist in Richtung Arduino angehaucht. Es kommen viele 0815 Standart-Libraries mit die nicht quelloffen sind. Anpassungen darin sind damit unmöglich. Ansonsten ist es grafisch ganz gut gemacht, man kommt gut und schnell zum Ziel. Allerdings werden Debug- und Programmerwerkzeuge natürlich nur von Mikroe unterstüzt. ICD, RealICE usw. kannst nicht verwenden.
Bupf schrieb: > Allerdings werden Debug- und Programmerwerkzeuge natürlich nur von > Mikroe unterstüzt. ICD, RealICE usw. kannst nicht verwenden. Das wäre für mich ein KO-Kriterium gegen den Compiler.
horch schrieb: > (je nach Optimierungseinstellung läuft vielleicht auch > ein Teil der Software nicht mehr richtig) Aufgrund der Art und Weise, wie die XC8-Optimierung funktioniert, wage ich das zu bezweifeln. XC8 optimiert nicht wie ein herkömmlicher Compiler direkt am Code, sondern erzeugt erst eine Art Pre-Compilat. Redundanzen in diesem Compilat werden mit Sprungmarken verkürzt. Daher ist bspw. das Auslagern von häufig genutzten Prozessen in eine Unterfunktion in aller Regel auf dem Hi-tech bzw. XC8-Compiler mit Optimierung auch ineffizienter als ein Präprozessor-Makro oder eine Inline-Funktion.
Hmm, danke für die Infos! Das mit den Debug-und Programmierwerkzeugen ist ein ganz hilfreicher Tip... Ich bin neu auf dem Gebiet und das war mir auch noch nicht ganz klar. Wenn ich z.B. die Programmer von Microchip (ICD2 oder PM3) habe, kann ich diese mit der MikroC Entwicklungsumgebung nicht verwenden sondern brauch dafür eigene, richtig? Wenn ich also bereits die beiden oben erwähnten Geräte habe, wäre es sehr sinnvoll, das MPLAB zu verwenden (also einen Compiler, den MPLAB unterstützt) ? Danke!
Frank Bär schrieb: > Aufgrund der Art und Weise, wie die XC8-Optimierung funktioniert, wage > ich das zu bezweifeln. Ich arbeite mit dem XC32-Compiler, damit konnte ich diesen Effekt beobachten. (Zur XC8-Optimierung ziehe ich meine obige Aussage zurück.)
Microchips Compiler für deren 16- und 32-Bit Prozessoren sind Derivate von GCC. Für 8-Bit Prozessoren nicht. Folglich bestehen einige Unterschiede, und man sollte sich vorher verständigen, über welche PICs man sich überhaupt unterhält.
Ulrich schrieb: > Hallo! > > Hat jemand Erfahrungen mit dem MikroC Compiler? Die Vollversion > erscheint mir im Vergleich zu anderen (XC, HI-TECH,..) sehr viel > billiger zu sein, wo ist hier der Haken? Ich überlege mir eine > Vollversrion für gewerbliche Zwecke zuzulegen. Der Haken dabei ist, dass Du keine Microchip-Tools verwenden kannst und keinerlei Support von Microchip bekommst. Wenn es Probleme mit irgendeinem Chip gibt, wird Microchip auf Mikroe zeigen, und die wieder auf Microchip, und Du bist der Arsch bei der Sache. Wenn Du einen der Microchip-Compiler nimmst, kann der Support Dein Problem nachvollziehen und Dir sagen, ob es ein Problem des Compilers, des Chips oder Deines Vorgehens ist. Viele Chip-Bugs werden durch bestimmte Patches in den Microchip-Compilern oder -Bibliotheken (die Du mit dem Microe NICHT benutzen darfst) umgangen. Wie gesagt, bei kommerziellen Produkten ist der Support für mich ein KO-Kriterium. Und der von Microchip ist nicht schlecht im Vergleich zu anderen Herstellern. Und den lässt Microchip sich auch irgendwo bezahlen, und sei es durch Compiler-Lizenzen (die für ein ernsthaftes kommerzielles Projekt niemals ein Problem sein sollten, da werden die CE- und EMV-Tests mindestens eine Zehnerpotenz höher zu Buche schlagen, und zwar für jedes Projekt wieder, während der Compiler mehr oder weniger eine einmalige Anschaffung ist. fchk
horch schrieb: > Frank Bär schrieb: >> Aufgrund der Art und Weise, wie die XC8-Optimierung funktioniert, wage >> ich das zu bezweifeln. > > Ich arbeite mit dem XC32-Compiler, damit konnte ich diesen Effekt > beobachten. (Zur XC8-Optimierung ziehe ich meine obige Aussage zurück.) XC32 ist aber auch ein MIPS-Compiler, der hat mit XC8 kaum Gemeinsamkeiten. Interessant wäre daher ja, ob der TO mit PIC24, dsPIC, PIC32 arbeiten möchte, oder ob PIC10/12/16/18 eher das Zielgebiet sind. Für letzteres ist in jedem Fall der XC8-Compiler das Maß aller Dinge. Über die ~800€ für die Pro-Version muss man nur nachdenken, wenn man winzige PICs mit riesigen Programmen füttern will.
Hi, Ulrich schrieb: > Hallo! > > Hat jemand Erfahrungen mit dem MikroC Compiler? Die Vollversion > erscheint mir im Vergleich zu anderen (XC, HI-TECH,..) sehr viel > billiger zu sein, wo ist hier der Haken? Ich überlege mir eine > Vollversrion für gewerbliche Zwecke zuzulegen. Zum MikroE kann ich selbst nichts sagen, aber dennoch kurz hier meine Wortmeldung da es mir so erscheint als wenn bei deinen Überlegungen einem Trugschluss aufgesessen bist. NAtürlich kann ich mich aber auch Irren. Die Microchip C Compiler sind in der Vollversion natürlich nicht kostenlos wie fälschlicherweise von horch geschrieben. Aber ich denke was er damit ausdrücken wollte ist das die Free Version und die Vollversion sowohl FAST funktionsgleich UND BEIDE voll kommerziell Nutzbar sind. Es gibt auch KEINERLEI Codegrößenbeschränkung bei den Microchip Compilern. Der einzige Unterschied zwischen der Free-Version und der Voll-Version ist die bei der Free Version eingeschränkte Codeoptimierung. Dies fällt aber in der Realität nur so selten ins Gewicht das es sich nur für HighVolume HErsteller lohnt die Vollversion zu kaufen. Die Free Version darf ja AUSDRÜCKLICH unbegrenzt kommerziell eingesetzt werden. Bei vielen anderen Compilerherstellern sieht es anders aus. Rinfach deshalb weil diese vom Verkauf des COMPILERS leben. Microchip hingegen lebt vom Verkauf seiner Controller und der Compilerverkauf ist sicherlich eher ein notwendiges Übel das nötig ist damit die Controller sich einer breiteren Beliebtheit überhautp erfreuen können. Würde man jetzt keine voll einsetzbare Version des Compilers kostenlos bereitsstellen würden die Umsätze der Controller (Langfristig gesehen) sicher einbrechen was deutlich höhere Verluste einbrächte als durch die Mehreinnahmen bei den Compilerverkäufen auch nur annhähernd abfangbar. Daher: Wenn es dir nur um die kommerzielle Verwendbarkeit geht, so ist eine Vollversion der XC Compiler absolut nicht nötig. Gruß Carsten
Ulrich schrieb: > Wenn ich z.B. die Programmer von Microchip (ICD2 oder PM3) habe, kann > ich diese mit der MikroC Entwicklungsumgebung nicht verwenden sondern > brauch dafür eigene, richtig? Meinst du jetzt mit PM3 wirklich den ProMate 3 oder ist das doch nur eine Flüchtigkeitsfehler und PK3 war gemeint. Den ProMate3 würde ich ja niemals als Entwicklungsprogrammer einsetzen. Zuerst einmal ist der ja recht teuer und bietet für diesen Preis in der Entwicklung keinerlei Vorteile wie sie der ebenfall sehr teure RealIce bietet. Man geht also unnötigerweise ein sehr hohes Risiko ein durch einen Verkabelungsfehler/technischen Defekt sehr viel Geld zu verbrennen, wo doch ein 30Euro Gerät gereicht hätte. Darüberhinaus hat der ProMate meines Wissens keine Debugfunktion wie beim 30Euro PK3 schon vorhanden. Es bleibt also ein simpler teurer Programmer. Die Stärken des PM3 liegen im Produktiven Umfeld wo es durchaus darauf ankommen kann ob das Beschreiben eines PICs nun 10 oder doch 20Sekunden dauert. Zudem kann man bei dem die Firmwareprogramme auf SD Karten Speichern und dann am Programmer der in der Produktion steht auswählen ohne das es einen PC oder jemanden in der Bedienung von MPLAB Unterwiesenen braucht. Beim PK3 meine ich das man diesen über ein Komandozeilentool als Programmieradapter in die MikroE Umgebung einbinden konnte. Ob dann aber auch Debuggen so geht ist mir unbekannt - Ich wage es aber zu bezweifeln. Für ICD2/3 sowie dem RealICE kann ich gar keine Einschätzung abgeben. Gruß Carsten
Ulrich schrieb: > Hat jemand Erfahrungen mit dem MikroC Compiler? Schnörkellose Compiler auf Praxis und Produktivität getrimmt. Hab damit schon mehrere Projekte gemacht, und es läuft einfach. MPLAB ist schön und gut wenn man Standardkonform arbeiten will. Das ist für mich aber rein akademisch. Man handelt sich jede Menge overhead ein, für mich ein Krampf. Mich interessiert es nun mal nicht das ich jeden denkbaren Prozessor mit einem riesigen Softwarekomplex mit allen Schikanen bearbeiten kann. Meiner Meinung nach braucht es schon für MPLAB zwei Leute zur Wartung ;-). Mikroe Support ist gut, Fragen werden schnell beantwortet. Einige Besonderheiten sind drin, wenn man die nutzt verliert man einiges an Portabilität. Aber vieles ist gut durchdacht und praxisgerecht. Dokumentiert ist das auch. Das Sie ihre Bench für ihre Debugging Tools optimieren ist durchaus legitim. Machen andere auch nicht anders dafür sind diese preislich fair und auch gut.
Carsten schrieb: > Ich wage es aber zu bezweifeln. > Für ICD2/3 sowie dem RealICE kann ich gar keine Einschätzung abgeben. hab ICD3 PK2 PK3 sowie die Mikroe Debugger für Kit und ARM (JTAG). Benutze ich aber nie. Was ich an Software debugge macht der Simulator bei Mikroe auf Knopfdruck (Source code trace). I/O mache ich mit Messgeräten (DSO und LA usw.)
X-X schrieb: > Ulrich schrieb: >> Hat jemand Erfahrungen mit dem MikroC Compiler? > > Schnörkellose Compiler auf Praxis und Produktivität getrimmt. Hab damit > schon mehrere Projekte gemacht, und es läuft einfach. > > MPLAB ist schön und gut wenn man Standardkonform arbeiten will. Das ist > für mich aber rein akademisch. Man handelt sich jede Menge overhead ein, > für mich ein Krampf. Mich interessiert es nun mal nicht das ich jeden > denkbaren Prozessor mit einem riesigen Softwarekomplex mit allen > Schikanen bearbeiten kann. Verstehe ich an der Stelle nicht. Worin siehst du bei MPLABX Overhead? Was du hier schreibst ist so dermaßen unspezifisch, dass es schon an Trolling grenzt. > Meiner Meinung nach braucht es schon für MPLAB zwei Leute zur Wartung > ;-). Wie bitte? Was ist denn deiner Meinung nach "Wartung" in dem Zusammenhang? Das würde mich tatsächlich mal interessieren.
Frank Bär schrieb: > Verstehe ich an der Stelle nicht. Worin siehst du bei MPLABX Overhead? > Was du hier schreibst ist so dermaßen unspezifisch, dass es schon an > Trolling grenzt. Es geht nicht um MPLAB sondern um den Mikroe Compiler. Wenn du den nicht kennst kennst ist es schwer mein Posting zu verstehen. Ich möchte damit auch nichts gegen MPLAB aussagen. > >> Meiner Meinung nach braucht es schon für MPLAB zwei Leute zur Wartung >> ;-). > > Wie bitte? Was ist denn deiner Meinung nach "Wartung" in dem > Zusammenhang? Das würde mich tatsächlich mal interessieren. Vorsicht Spaß, auch als solcher gekennzeichnet. Mikroe reicht für meine Projekte. Ich bin auch nicht in einem Entwicklerteam oder habe 7 stellige Projektkosten. Da gelten andere Gesetze die Microchip gut abdeckt (jedenfalls besser als einige andere).
Wir benutzten den Mikroe C Compiler für AVRs in der Technikerschule. War ein nettes Spielzeug, mehr aber auch nicht. Ich hatte damals schon mehrere Jahr Programmiererfahrung mit dem GCC und dachte mir immer nur wie man dafür Geld ausgeben konnte. Die Hardware selbst war als Spielwiese in Ordnung. Die schlimmsten Nachteile der IDE waren für mich: - keine quelloffenen Libs --> man konnte erstens nicht zeigen wie etwas programmiert wurde z.B. die Initialisierung der UART. Und man konnte auch nicht nachvollziehen, wenn was nicht funktioniert hat. - Man konnte zwar Funktionen zusammen klappen, aber eine schlechte Idee war es dann den zusammen geklappten Code auszuschneiden und wo anders einzufügen. Wurde irgendwie gerne ab und zu ins Speichernirwana geschickt. Das ganze ist aber schon 4 Jahre her, kann sein das sich da was verbessert hat. Für schulische Ausbildung in Ordnung, aber für ein professionellen Einsatz meines Erachtens nicht zu gebrauchen. Gruß Florian
X-X schrieb: > Frank Bär schrieb: >> Verstehe ich an der Stelle nicht. Worin siehst du bei MPLABX Overhead? >> Was du hier schreibst ist so dermaßen unspezifisch, dass es schon an >> Trolling grenzt. > > Es geht nicht um MPLAB sondern um den Mikroe Compiler. > Wenn du den nicht kennst kennst ist es schwer mein Posting zu verstehen. > Ich möchte damit auch nichts gegen MPLAB aussagen. Du bleibst kryptisch. >>> Meiner Meinung nach braucht es schon für MPLAB zwei Leute zur Wartung >>> ;-). >> >> Wie bitte? Was ist denn deiner Meinung nach "Wartung" in dem >> Zusammenhang? Das würde mich tatsächlich mal interessieren. > > Vorsicht Spaß, auch als solcher gekennzeichnet. > > Mikroe reicht für meine Projekte. Ich bin auch nicht in einem > Entwicklerteam oder habe 7 stellige Projektkosten. XC8 kostet in der Pro-Version knapp 800€ Netto, MPLABX ist kostenlos. MikroE kann in der Demo nur 2k Code erzeugen und kostet in der uneingeschränkten Version 230€. Ich sehe nicht, wo 7-stellige Projektkosten da irgendeine Rolle spielen. Wie gesagt, XC8 ist unlimitiert, abgesehen von der Code-Optimierung, die aber nur für 6-stellige Stückzahlen wirklich sinnvoll ist. Eine Verdopplung des Flash-Speichers kostet bei Microchip 0,06-0,07€. Bis sich da die Pro-Version des Compilers gerechnet hat, muss ich mindestens 11k Stück abnehmen. Insofern sehe ich es eher so, dass MikroE im Normalfall ohne Codelimit 230€ kostet. Dazu braucht man dann noch das Entwicklungstool für ~80€. XC8 + MPLABX kostet nichts, ein ICD3 gibts für 180€, PicKit3 kostet ~70€. In beiden Fällen ist MPlab günstiger. XC8+MPLABX+PicKit3 = 70€ XC8+MPLABX+ICD3 = 180€ MikroE-Demo+MikroProg = 310€ Deine Argumentation erschliesst sich mir damit immernoch nicht.
:
Bearbeitet durch User
Hi, Frank Bär schrieb: ->Im großen und ganzen viel richtiges, ich will nur zwei Stellen ergänzen... > Wie gesagt, XC8 ist unlimitiert, abgesehen von der Code-Optimierung, > die aber nur für 6-stellige Stückzahlen wirklich sinnvoll ist. > Eine Verdopplung des Flash-Speichers kostet bei Microchip 0,06-0,07€. > Bis sich da die Pro-Version des Compilers gerechnet hat, muss ich > mindestens 11k Stück abnehmen. Ich würde sogar sagen das es deutlich mehr als 11 000 Controller sein müssten. Denn die "balkendiagramme" mit denen für die bessere Optimierung geworben sieht sehen schon "Beeindruckend" Unterschiedlich aus, tatsächlich geben die aber ja nicht das Verhältniss der Codegrößen des Endergebnisses sondern nur das Verhältniss der Codeeinspaarung wieder. Wenn nun der Compiler A bei einem Quellcode der ohne jegliche Optimierung 4000 Befehlsworte ergibt es schafft diesen auf 3800 Worte einzudampfen, Compiler B aber im Ergebniss sogar die Verkürzung auf 3600 Befehlsworte schafft, so kann man das dann darstellen das die Optimierung von Compiler A gleich 50 % schwächer ist. Aber Mitnichten reicht das in diesem Beispiel aus um durch Kauf des Besseren Compilers auch nur einen Cent einzusparen. Zumindest wenn man die gängigsten Controller als Grundlage sieht. (Die Speicherabstufungen sind bei Microchip meist ja Zweierpotenzen...) Anders sähre es natürlich aus wenn Compiler A einen Code liefert der 4100 Programmwörter umfasst, Compiler B aber auf 3900 Wörter kommt. Dann könnte man je nach Controller schon mal einen kleineren Nehmen und die <~10ct /Controller sparen. Natürlich ist es sehr stark vom Programmierstil des Anwenders abhängig wie effektiv eine Optimierung tatsächlich einfluss auf die Codegröße nehmen kann. Ein bereits effizient geschriebenes Programm bietet viel weniger Angriffsfläche als ein "was kostet die Welt" Stil, aber auch da ist heute der Unterschied nicht mehr so groß. Da die Microchip C Compiler ja nach der Installation jeweils eine 60 Tage Testphase mit voller Optimierung bieten kann ja jeder für seinen Stil selbst vergleichen. In meinem Fall lag der Unterschied beim Ausgabecode zwischen Free und Full Modus üblicherweise << 10% > PicKit3 kostet ~70€. > ... > XC8+MPLABX+PicKit3 = 70€ Das möchte ich noch berichtigen, Tatsächlich liegen die Kosten nur bei etwa der Hälfte. Das PK3 kostet im Original für Normalnutzer etwa 35 Euro zzgl. Märchensteuer. http://www.microchipdirect.com/ProductSearch.aspx?Keywords=PG164130 Für gewerbliche ist die MwSt. ein durchlaufender Posten, zählt nicht. Für Studenten u.ä. gibt es verschiedene Möglichkeiten noch etwas Rabatt zu bekommen so das die im Ergebniss bei <= 35 Euro mit MwST liegen dürften. Für rein private Bastler (Und alle anderen mit Sparzwang) gibt es zumindest noch die Möglichkeit einen Funktionsidentischen Clon aus Fernost für 20 Euro zu kaufen. > Deine Argumentation erschliesst sich mir damit immernoch nicht. Mir auch nicht. Es ist ja durchaus möglich das DU (X-X) gut mit dem MikroE zurechtkommst und der für dich wirklich die beste Wahl ist. Das aber die MPLAB + C Compiler (bzw. MPLABX + XC) nun irgendwie inneffektiv wären oder irgendeinen wahnsinnigen Overhead verursachen ist definitiv falsch. Letzten Endes gibt es aber den Microchip Compiler zum kostenlosen Download und auch den MikroE in einer freien Version. Man kann also beides ohne Zusatzkosten ausprobieren und sich dann entscheiden. Aus meiner Sicht bietet aber die Lösung "Alles aus einer Hand, damit EIN Ansprechpartner" große Vorteile. Für andere Mag es anders aussehen - man sehe sich ja nur mal die AVR Fans an, da wird von vielen ja gerade die VIELZAHL an Quellen als großer Vorteil gelobt... Gruß Carsten
Da habt ihr einen Vergleich zwischen den einzelnen gängigen C-Compiler in Bezug auf Codegröße etc. http://www.mikrocontroller.net/articles/PIC_C-Compilervergleich
Chris B. schrieb: > Da habt ihr einen Vergleich zwischen den einzelnen gängigen C-Compiler > in Bezug auf Codegröße etc. Vielen Dank für diesen Vergleich und den Aufwand. Für die Compilierzeit ist evtl. der verwendete PC interessant. Carsten schrieb: > Es ist ja durchaus möglich das DU (X-X) gut mit dem MikroE zurechtkommst > und der für dich wirklich die beste Wahl ist. Über wen sonst soll ich schreiben und ist das bei dir anders? Es geht um diesen Compiler, da bin ich professioneller Anwender und sage das Ding taugt was. > Das aber die MPLAB + C > Compiler (bzw. MPLABX + XC) nun irgendwie inneffektiv wären oder > irgendeinen wahnsinnigen Overhead verursachen ist definitiv falsch. Würde ich auch nicht wagen zu behaupten. Bin von Mplab weg weil es mir (ganz persönlich und durchaus im Bewusstsein dessen das es auf diesem schönen Planeten dazu noch andere Meinungen geben könnte) zu aufwendig war. Ständige Änderungen, riesige Downloads instabil und unübersichtlich. MPLAB-X ist da besser, aber eine neue Umgebung und man durfte alles neu lernen. Für mich sind Compiler und IDE kein Selbstzweck sondern ein Werkzeug unter vielen. Das von MikroE ist schlank, handlich, günstig und wird gut gepflegt. Mehr will ich (ganz persönlich und der Meinung das es da völlig andere Bedürfnisse und Meinungen zu geben kann) nicht und mehr brauche ich auch nicht.
Weil ich grade MikroC wieder probiert habe: MikroC - und jeden anderen Compiler auch - kann man ganz bequem mit dem PICkit3 Standalone Tool nutzten, wenn man "Auto Load HEX" aktiviert. Sobald sich das .HEX ändert, also nach jedem Compile-Vorgang wird der PIC automatisch programmiert, und dazu muss man nicht zwischen 2 Programmen hin- und herschalten. Ich selbst nutze MikroC für "RAD"-Projekte (Rapid Application Development, schnell ans Ziel) wie kleine Steuerungen, Timer, ... auf PIC16 und HI-TECH C für PIC18 wenn es um komplexere Projekte geht, wo Bugs oder Abweichungen vom Standard zu erheblichen Problemen führen könnten. Die eingebauten Libraries sind zwar ein Mega-Plus, aber MikroElektronika sollte unbedingt noch die Standardkompatibilität auf das Niveau von HI-TECH bringen.
Frank Bär schrieb: > PicKit3 kostet ~70€. In welchem Universum? Bei Microchipdirect kostet's 32.96€ http://www.microchipdirect.com/ProductSearch.aspx?Keywords=PG164130
X-X schrieb: > Chris B. schrieb: >> Da habt ihr einen Vergleich zwischen den einzelnen gängigen C-Compiler >> in Bezug auf Codegröße etc. > > Vielen Dank für diesen Vergleich und den Aufwand. > > Für die Compilierzeit ist evtl. der verwendete PC interessant. Ich hatte den Test mal gemacht. Der PC war ein Intel Core2Quad Q6600, 40€ Mainboard, WinXP -> maximale 3.5GB RAM, normale SATA-HDD und sofern überhaupt wichtig, ne HIS HD4850 X2 Grafikkarte. Ich hab beides, MPLABX+XC8 und MikroC PRO for PIC. Man hat bei MikroC die Möglichkeit, die PK3CMD.exe zu nutzen, allerdings (leider) mit einer Batch-Datei, dass z.B. aus dem Übergabeparameter "-Ppic18f4550" ein "-P18f4550" macht. [1] Ich nutze primär auch den MikroC Compiler, da ich als Hobbyist daran interessiert bin, für den in meinem Projekt verwendeten PIC ein Programm zu schreiben, so einfach und schnell wie möglich. Aus MEINER Sicht sind die Vor- und Nachteile von MikroC: + gleich vorhandene Libs (über den Bibliotheks"browser" an der Seite leicht zu finden, mit schreibweise etc.). Sehr einfach und ich finde auch sehr viel einfacher als bei MPLABX. Zu jeder "Lib-Klasse" (z.B. USB) gibt es eine Auflistung der Funktionen mit Beschreibung der Argumente etc, sowie, wenn sinnvoll, eine Beispielschaltung inkl. Programm, was auch sehr hilfreich sein kann. ++ Gute, strukturierte und ausreichend Ausführliche Hilfe - finde ich bei XC8 und MPLAB bedeutend schlechter. Über Support kann ich nichts sagen, nur, dass ich bei MikroC noch keinen brauchte. + Konfigurator, mithilfe dessen man sehr einfach alle Konfigbits setzen kann. Mich persönlich nerven diese extrem Lange oder 15-20 Zeilen große Konfiguration in MPLABX... Heißt es jetzt OSC=INTRC oder INTOSC oder.... - Man kann die MC-Tools nicht (vollständig) nutzen. Meines wissens ist das PICKIT3 das einzige aktuelle Tool, dass (durch dessen CMD-exe und extra .bat-Datei) auch genutzt werden kann. - die Libs sind nicht offen. Keine. Einmal hat mich das auch geärgert (war bei I²C, ich hab die Pull-Up-Widerstände nicht reingemacht -> Resultat war ein aufgehängtes Programm, das wohl in einer internen Schleife hing) - in der Frei-Version (was mich nicht betrifft) nur bis 2k Programmgröße. Man macht in ein leeres Programm ein USB_Init(); und schon kann man es nicht mehr kompilieren, da man schon über die 2k ROM gekommen ist. - Manchmal nervend: Die Tabstops sind nicht konstant (orientieren sich an der Zeile darüber) und sind im Nachhinein Leerzeichen. Ich glaube, dass er mit Overhead die Kompabilität zu anderen PICs meint. Ich habe mal ein 4550 mit einer USB-HID Funktionalität programmiert (zum testen), PC-Software mit Visual Studio C#, PIC-Software mit MPLABX+XC8 und MikroC. Bei MikroC war es dank der fertigen Lib und des Beispielprogramms eine Sache von ein paar Minuten. Schnell noch mit dem HID-Deskriptor-Tools eine c-Datei erstellen, mit dem man sehr einfach die VID, PID, Vendor-Name und Product-Name festlegen kann. Bei MPLABX+XC8 hingegen musste ich erst noch die 150MB große MAL (2.5.2013) runterladen und installieren. Ich wollte zwar nur die USB-Libs, aber der ganze Rest war eben auch dabei. Nachdem ich dann die zig Header-Dateien rausgesucht und included habe, wurde ich überschwemmd von Compiler-Errors. Nach insgesamt ein paar Stunden Recherche hab ich dann herausgefunden, dass die Lib wohl noch für den C18 Compiler gemacht war. Ein paar Schlüsselwörter kennt XC8 nicht mehr. Also musste ich mich durch 10+ Header und C-Dateien hangeln und alle Fehler entfernen, wo ich auch erstmal recherchieren musste, wie das geht bzw, wo die Unterschiede zwischen C18 und XC8 sind. Dabei war das absolut ätzende, wohl von X-X gemeinte "Overhead". Zusammen tausende #defines und #ifdefs etc, für jeden Compiler, jedes Demo-Board und jeden PIC, von PIC18 bis PIC32, begleitet von Kommentar-Romanen. Wenn ich die ganzen Dateien für mein PIC18F4550 eingestampft hätte (Kommentar-Romane und Defines etc weg), wäre es MIT SICHERHEIT eine Reduktion von ca 5000-6000+ Zeilen auf ca 100-200, vielleicht auch 300-400 gewesen. Letztendlich habe ich es auch hinbekommen, aber durch das googlen wusste ich, dass ich bei weitem nicht der Einzige war, der das Problem hatte. Die meisten Lösungsvorschläge, die auch von den anderen dann angenommen wurden, war, doch den C18 Compiler zu nehmen. Da hab ich mich aber geweigert. Auch die Deskriptorbeschreibung war etwas gewöhnungsbedürftig. Man musste aus den ganzen Dateien und Zeilen die Zeile finden, in der die IDs stehen. Den Namen konnte man auch ändern, aber 'a', 'l', 'l', 'e', 's' in Häkchen und danach nochmal Zählen, um die Größe anzugeben. Nicht richtig schwer aber schon nervend und unkonfortabel. Ich weiß nicht, wie es mit der neuen MAL aussieht. Ich werde es bald sehen, das nächste USB-Projekt wartet schon. PS: Ich habe einen Ordner, in dem die Installationsdateien von MPLABX, XC8, XC16 und XC32 liegen. Wenn ich im Explorer diesen Ordner öffne, braucht er jedes mal Ewigkeiten (bestimmt so 10-15 Sekunden), um diese Dateien anzuzeigen. Ist das bei euch auch so? PPS: Ich hatte überlegt, für dieses HID-Projekt einen Artikel anzulegen. Das Ziel war, nur mit Freeware eine Verbindung zwischen PC und PIC über USB-HID herzustellen. Man braucht KEINE Treiber und es kann auch mit neuen PCs/Notebooks ohne RS232 und LPT genutzt werden. Da ist mir auch aufgefallen, dass man mit der Free-Version von MikroC nichts mit USB machen kann. Somit bleibt nur MPLABX, XC8, Visual Studio Express und frei verfügbare HID-Lib, alles kostenlos. Hält das wer für Sinnvoll? Ich persönlich musste lange für alles Suchen, dass es einfach und simpel wurde. [1]: http://www.mikroe.com/forum/viewtopic.php?f=88&t=55432
Hab jetzt mit dem Mikroe Compiler ein kommerzielles Projekt gemacht und möchte kurze Rückmeldung geben. Es ist sehr effizient mit dem Compiler zu arbeiten, gerade für mich als C Gelegenheitsautor. Es läuft einfach und das ganze ist praxisorientiert. Michael Skropski schrieb: > - Man kann die MC-Tools nicht (vollständig) nutzen. Meines wissens ist > das PICKIT3 das einzige aktuelle Tool, dass (durch dessen CMD-exe und > extra .bat-Datei) auch genutzt werden kann. Der ICD3 funktioniert auch, aber das Realtime tracen (in MPLAB-V über eine cof Datei) ist ein Krampf. Beide Seiten (Mikroe und Microchip) scheinen kein Interesse zu haben das die Sache funzt. Wenn man den Mikroprog ICE von Mikroe nimmt läuft das im Vergleich zu MPLAB einfach superdupermegaklasse. Proggen und Real time trace im C code mit ein zwei Tastendrücken. Das Proggen ist vom speed her so schnell wie beim PicKit 3, der ICD3 ist gefühlt mindestens doppelt so schnell. Btw. hab einen Mikroprog fest aufgelötet auf einem EasypicPro V7 Board und den ext ICD Eingang als Ausgang genutzt. Damit kann man dann jeden Pic Proggen. > - die Libs sind nicht offen. Keine. Einmal hat mich das auch geärgert > (war bei I²C, ich hab die Pull-Up-Widerstände nicht reingemacht -> > Resultat war ein aufgehängtes Programm, das wohl in einer internen > Schleife hing) Ein Manko, keine Frage > - in der Frei-Version (was mich nicht betrifft) nur bis 2k > Programmgröße. Man macht in ein leeres Programm ein USB_Init(); und > schon kann man es nicht mehr kompilieren, da man schon über die 2k ROM > gekommen ist. Dafür läuft USB sehr einfach wenn man den Compiler kauft. > - Manchmal nervend: Die Tabstops sind nicht konstant (orientieren sich > an der Zeile darüber) und sind im Nachhinein Leerzeichen. hab ich auf feste Leerzeichen gestellt. Wer mir einen Weg zeigt Kommentare in eine feste Spalte zu legen kriegt ein (virtuelles) Bier.
Michael Skropski schrieb: > PPS: Ich hatte überlegt, für dieses HID-Projekt einen Artikel anzulegen. Ich wäre interessiert...
Ich möchte hier auch mal meine Erfahrungen mit mikroe loswerden. Zuerst mal möchte ich sagen, dass ich die Hardware, die sie haben, echt toll finde. Ich habe selber einige Boards zB. EasyPIC6, BigPIC6 und Fusion 7, mikromedia usw. Die sind zum ausprobieren und Entwickeln echt ein Traum und preislich voll in Ordnung. Das mikroProg Programmiergerät finde ich auch in Ordnung und flasht auch ziemlich schnell. Nun zu den Compilern: Es ist auf jeden Fall toll, dass soviele Bibliotheken mitgeliefert werden, nur leider ohne Source-Code. Das finde icht echt schade. Aber: Die IDE finde ich echt grottig. Ich arbeite viel mit Visual Studio von MS und von daher bin ich da sicher etwas verwöhnt. Genau so sollte eine IDE aber aufgebaut sein und funktionieren. Ich habe mit der mikroe IDE immer wieder Probleme. Entweder hängt sie sich auf, stürzt ab, oder der Texteditor macht einfach nicht was er soll. Der Debugger ist auch so eine Sache: Funktioniert zwar, stürzt aber auch recht häufig mit einer "AccessViolation" Exception ab. Außerdem ist auch hier die ganze Bedinung ziemlich mühsam. Variablen müssen umständlich aus einer Liste gesucht werden usw. Ich habe die mikroe Compiler lange Zeit benutzt, spiele aber jetzt auch mit dem Gedanken, auf einen anderen auszuweichen.
Kann ich nicht bestätigen. Der Compiler ist mir noch nie abgestürzt. Auch in dem Forum vom Compiler ist sowas selten zu lesen. Das liegt wohl eher an deinem Rechner.
Vorweg: Wer mit MikroE-Compilern kommerziell entwickeln muss, hat mein volles Beileid. Der Bastler mag in diesem Biotop aus Entwicklungsboards, Peripherie, Compiler und Libraries ja noch einigermassen gluecklich werden. MikroE ist in erster Linie ein auf Gewinn getrimmtes Geschaeftsmodell das aus genau diesen Komponenten zusammengesetzt ist und dem natuerlich Offenheit auf Kosten des Anwenders nur schaden wuerde. Selbst die 'Free-Version' vom XC-8 ist in diesem Sinne professioneller, da sie den Einschraenkungen dieses Mikro(E)kosmos nicht unterliegt.
Möchte hier noch zwei wenig bekannte Tools für die PIC18 einbringen, die ich benutzte und sehr gut finde, auch weil beide open source sind: Cpik Compiler von Alain Hinaus. Bis auf die ROM-Tabellen, die etwas unorthodox sind, funktioniert er für meine Zwecke ausgezeichnet. Openprog. Dieser Programmier funktioniert ausgezeichnet, und hat meinen PicKit3 abgelöst, der mich unter Linux in den Wahnsinn getrieben hat. Habe eine PIC-only Variante ohne Piggy-back Platine gebaut. Nachteil: Kein ICD.
Bitte 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.