Forum: Mikrocontroller und Digitale Elektronik MikroC Compiler für PIC


von Ulrich (Gast)


Lesenswert?

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!

von horch (Gast)


Lesenswert?

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.

von Bupf (Gast)


Lesenswert?

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.

von horch (Gast)


Lesenswert?

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.

von Frank B. (f-baer)


Lesenswert?

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.

von Ulrich (Gast)


Lesenswert?

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!

von horch (Gast)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

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

von Frank B. (f-baer)


Lesenswert?

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.

von Carsten (Gast)


Lesenswert?

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

von Carsten (Gast)


Lesenswert?

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

von X-X (Gast)


Lesenswert?

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.

von X-X (Gast)


Lesenswert?

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

von Frank B. (f-baer)


Lesenswert?

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.

von X-X (Gast)


Lesenswert?

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

von Florian K (Gast)


Lesenswert?

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

von Frank B. (f-baer)


Lesenswert?

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
von Carsten (Gast)


Lesenswert?

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

von Chris B. (dekatz)


Lesenswert?

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

von X-X (Gast)


Lesenswert?

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.

von Student (Gast)


Lesenswert?

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.

von PICkit3 (Gast)


Lesenswert?

Frank Bär schrieb:
> PicKit3 kostet ~70€.
In welchem Universum?
Bei Microchipdirect kostet's 32.96€
http://www.microchipdirect.com/ProductSearch.aspx?Keywords=PG164130

von Michael S. (rbs_phoenix)


Lesenswert?

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

von X-X (Gast)


Lesenswert?

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.

von Max H. (hartl192)


Lesenswert?

Michael Skropski schrieb:
> PPS: Ich hatte überlegt, für dieses HID-Projekt einen Artikel anzulegen.
Ich wäre interessiert...

von Daniel P. (peini7)


Lesenswert?

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.

von udo (Gast)


Lesenswert?

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.

von ... (Gast)


Lesenswert?

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.

von Pascal (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.