Für einige Projekte suche ich einen C-Compiler für diverese dsPICs und PIC18Fxxxx. Macht es Sinn, sich mit dem C30-Compiler zu beschäftigen oder gibt es bessere Alternativen? Gruß Damaskus
dsPIC30, PIC24,PIC33 C30 Compiler PIC18 C18 Compiler Bis auf diversen Optimierungen, lohnt es sich schon diese Compiler zu nutzen. Gruß Sascha
hallo jo, ich arbeite auch schon ein paar jahre mir C18 und C30. Die sind soweit ok. Gerhard
Wenn du einen Compiler für PIC18 und PIC30 suchst, wirst du Pech haben. Das sind zwei sehr verschiedene Architekturen mit entsprechend verschiedenen Compilern. Der C30 ist übrigens nichts anderes als ein um eine spezielle Optimierung bereicherter GNU-Compiler. Ich hatte mir den C30 Mitte letzten Jahres mal angesehen und war ziemlich prompt über einen bösen Bug gestolpert. Anfang diesen Jahres gab es dann eine verbesserte Version.
Wobei der C18er Compiler recht eigenartige Verhaltensweisen an den Tag legt, wenn nicht sogar Bugs. Nennen möchte ich mal: 1. Wenn man bei einer Funktion mit Rückgabewert die Rückgabe mit return (x) vergisst gibt es keine Warnung geschweige denn einen Fehler. Da wird einfach mal irgendwas zurückgegeben. 2. Bei Zuweisung einer int-Zahl in eine long-Variable werden die höherwertigen Bytes mit FF beschrieben. Seltsam... Das wird dann ein ganz anderer Wert. Beispiel: b=0x1234, long a=b -> a=0xFFFF1234 3. printf: Zuweisung einer signed(!) int-Variable z.B. mit x=-100 -> Ausgabe per printf(%d) liefert 65436! 4. Diese Zuweisung funktioniert NICHT!: int = (int)char[0]<<8 + char[1]; Diese funktioniert: int = (int)char[0]<<8 | char[1]; Die erste Variante geht normalerweise bei anderen Compilern. Im Gegensatz zum Keil-Compiler sind das Welten. Steffen
@Steffen Hildebrandt hallo ich habe sicher schon 20 Projekte mit einem PIC18 und dem C18-Compiler abgewickelt und keine Probleme gehabt. Ich habe auch schon mit dem Keil-Compiler gearbeite (Atmel 80c52 irgendwas ind C167), Aber ich könnte nicht sagen, dass der C18 schlechter ist als der Keil-Compiler. Wobei beide Firmen die Eigenschaft haben sehr häufig updates zu liefern, bei dem sich dann auch mal ein Bug einschleicht. Solche Bugs werden aber nach meiner Erfahrung von Microchip schnller behoben als von Keil. Gerhard
@Gerhard Aber schon der erste Punkt ein ein gravierender Fehler! Das wurde in keinem Update bisher behoben und führt zu ärgerlichen Fehlersuch-Runden, die nicht sein müssten. Auch die anderen Sachen sind nicht ohne. Es gibt Eigenheiten des Compilers, dass eher an unwichtigen statt an wichtigen Stellen gewarnt wird. Von fehlenden Fehlern mal abgesehen. Aber egal, muss man sich halt durchwurschteln. :-) Steffen
also ich hab mich beruflich ueber ein Jahr mit C18 und C30 beschaeftigt. Ich bin da eher auf Steffens Linie. Die Compiler sind schon etwas merkwuerdig. Die lassen waehrend der compile time einige Sachen ungemeldet durchgehen und spaeter merkt man, dass der Compiler Gruetze macht. Wenn man z.B. zwar eine Header datei einbindet, nicht aber die Library wo die eigentliche Routine drinsteht meckert der Compiler nicht. Im Programm wird dann einfach nichts gemacht. Wenn du den GCC gewohnt bist wirst du enttaeuscht sein. Der GCC ist viel viel besser.
Tim wrote:
> Wenn du den GCC gewohnt bist wirst du enttaeuscht sein.
Vom C30 Compiler?
von beiden, C18 und C30. Ich konnte bei den Microchip Dingern keinenwirklichen Unterschied voneinander feststellen. GCC ist besser, darum bastel ich auch lieber mit AVRs: da gibts nen GCC fuer und auch sonst viele freie Tools. Bei Micrichip muss man immer mit dem MPlab rummachen und deren bloede Programmierer kaufen. Aber trotz PICs haben wir es bei der Urban Challenge auf den zweiten Platz geschafft :)
Ich fragte deshalb, weil der C30 ja letztlich auch nur eine GCC Version ist, mit zusätzlich eingebauten proprietärem Optimizer. Die MPlab kannst du dir auch ersparen, der Compiler lässt sich von der Command Line nutzen, also auch beispielsweise in PN einbauen. Selbstbau-Programmierer für PICs gibt's grad so wie für AVR, angefangen vom Parallelport bis zum ICD2-Nachbau. Nur dass der ICD2 auch debuggen kann, was bei Atmel für etliche Devices nur mit dem 300€ Teil geht.
Ein Nachtil hat der C30: er benutzt keinen einzigen DSP-typischen befehl. D. h. wenn du hardwaremäßige Schleifenunterstützung und weitere tolle Assemblerbefehle nutzen willst, musst du es selbst codieren.
ich hab auch haeufiger die Erfahrung gemacht, dass ein Programm lief, wenn ich es im normalen Programmiermodus kompiliert habe. Hab ich dann in den Debugmodus gewechselt lief das selbe Programm nicht mehr. Hab keine Ahnung ob das am Compiler, MPlab oder am ICD2 kag. Aber das sind eben Dinge die unnoetig Nerven kosten.
Der C30 basiert doch glaube ich auf GNU-Geraffel, wie soll das vernünftig funktionieren.
> ... lief das selbe Programm nicht mehr.
Ggf. muß eine Fuse anders eingestellt sein oder die Limitations wurden
nicht beachtet. Mehr Fehlerquellen konnte ich zu diesem Problem bisher
nicht ausmachen.
Den C30-Compiler kenne ich nicht. Ihr verwechselt das jetzt nicht mit dem PIC32-Compiler? Das ist ein GCC für den MIPS mit Microchip-Optimierungen. Ich hab gerade nochwas zum C18 gefunden... printf kann z.B. kein float. Okay, muss auch nicht sein, kann man auch eine selbtsgeschriebene Funktion zur Ausgabe hernehmen. Der Compiler hält es aber nichtmal für nötig eine Warnung auszugeben, wenn man %f in printf verwendet -> seltsam. Muss man erstmal ins Messer laufen. Okay, wenn man einige dieser Sachen dann kennt geht es schon, andere Compiler haben halt andere Macken. Aber mein Lieblingsconplier ist er nicht wirklich ;-). Steffen
Steffen Hildebrandt wrote: > Ihr verwechselt das jetzt nicht mit dem PIC32-Compiler? Definitiv nicht. > Das ist ein GCC für den MIPS mit Microchip-Optimierungen. Der C30 auch. Nicht jedoch der C18. > printf kann z.B. kein float. Das wiederum interessiert den Compiler selbst rein garnicht, sondern ist Bestandteil der Bibliothek. Eine Newlib für C30 wäre wohl auch kein Hexenwerk, nur vielleicht grösser als den PIC30 Kunden lieb ist. > wenn man %f in printf verwendet -> seltsam. Eigentlich geht es den Compiler einen Sch..dreck an, was der Anwender in den Formatstring von printf reinschreibt. Da gilt genau genommen Schrott rein Schrott raus, und bei vielen Compilern ist es auch exakt so. GCC ist immerhin so freundlich, den Formatstring auf offensichtliche Inkonsistenzen zu überprüfen. Aber das geschieht ohne Wissen über die konkrete Implementierung von printf, in der Annahme, die entspräche dem in C Libraries üblichen. Und zwar erfolgt dies im maschinenunabhängen Teil von GCC. Dessen Entwickler können beim besten Willen nicht wissen, dass Microchips Implementierung von printf() unvollständig ist.
PS: Fehlt dem printf wirklich die Ausgabe von Fliesskommadaten, oder muss man nur die richtige Version der Library an Land ziehen? Vom C30 habe ich das nicht im Kopf, bei AVR muss man sich einfach die richtige Library suchen, sonst kriegt man den gleichen Effekt.
Okay, so bewandert bin ich mit den Internas von Compilern nicht. Wenn das erst mal kein grundsätzlicher Fehler ist ists okay, aber eine Warnung wäre zumindest angebracht. Compiler und Lib stammen von Microchip, da sollten sie ihren Kram doch ganz gut kennen. printf kann kein %f bzw. floating-point, steht in der Doku auch so drin. Wenn man es weiss ists kein Problem, aber gerechnet hab ich damit erstmal nicht. Steffen
Steffen Hildebrandt wrote: > Wenn das erst mal kein grundsätzlicher Fehler ist ists okay, aber eine > Warnung wäre zumindest angebracht. Compiler und Lib stammen von > Microchip, da sollten sie ihren Kram doch ganz gut kennen. Nicht der ganze Compiler ist von Microchip, nur der Codegenerator. Das ist im GCC organisatorisch getrennt und der maschinenabhängige Teil ist vergleichsweise klein. Und ist der einzige Teil, der für eine neues Zielsystem neu geschrieben wird (vermutlich: man kopiert sich Teile von von einem möglichst vergleichbaren bestehenden Target und ferkelt darin herum). Allzu viel Ahnung vom maschinenunabhängigen Löwenanteil des Compilers muss man dafür wahrscheinlich garnicht haben. Beim Compiler für den PIC32 war es einfacher: Da dieser einen MIPS Kern hat, war die GCC Version dafür schon 2 Jahrzehnte vor dem Controller da.
Aha, interessant. Klar, beim neuen MIPS-Compiler (PIC32) ists etwas einfacher. Der ist sicher schon recht ausgefeilt. Naja, was solls. Muss ich mich weiter mit dem C18-Compiler rumärgern. Steffen
Ich möchte ein Projekt starten und hab verschiedene PIC miteinander verglichen. Die PIC24-Familie von Microchip sieht für mich am besten aus (nebenbei, bin totaler Beginner was PIC angeht... ). Meine Frage: brauche ich den C30-Compiler oder gehts auch anders? Danke in Voraus
Geht auch anders. Es gibt andere Compiler (€€€) oder Assembler. Das einzige was mich am C30 ziemlich stört ist der fehlende Support für C++, aber das ist eher eine Marotte von mir als ein ernstes Kriterium für die Praxis.
Danke für sie schnelle Antwort. Es ist eben so: Ich möchte in C programmieren, das es ein grösseres Programm werden soll. Daher möchte ich assemblerzeugs von vornherein ausschliessen. Jetz wenn ich den €€€ oder gcc etc. nehmen würde, wie sieht das aus wegen dem Brennen des PIC. Muss ich da auf Produkte des Herstellers greifen? anderst gesagt, wenn ich das HEX file vom compiler bekomme, ist das Problem gelöst wegen der HW die den PIC mit den PC verbindet? bitte nicht verzweifeln wenn meine frage unsinnig ist, bin ABSOLUTER BEGINNER in PIC anwendungen, habe bis jetzt nur ganze lernsysteme programmiert Danke im Voraus
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.