C-Compiler für PIC-µCs?

Hallo!

Ein Bekannter von mir sucht einen kostenlosen C-Compiler für PIC-µCs. Ich hatte ihm zwar AVRs empfohlen, weil es dort einen GCC-Port gibt, aber er möchte PICs nutzen. Tja, ein wenig rumgegooglet brachte mir gnupic.org (AnyC und SDCC, beides Sourceforge-Projekte) und Infos über einen JAL-Compiler ein, aber irgendwas fertiges scheint es nicht zu geben. Auch die englische Wikipedia war nicht umfangreicher.

War das alles oder habe ich ein fertiges, nutzbares Open-Source Projekt übersehen?

MfG, Maik Schmidt

Reply to
Maik Schmidt
Loading thread data ...

So, jetzt klappts...

B. Kmudsen Data CC5X-Compiler. Laesst sich in das MPLab integrieren und tut ganz gut.

Ist eine Free- oder Eval, weiss nicht. Die Mathe ist beschraenkt und der Codeumfang (1/2k) auch. Aber das ist ja nicht so wild.

gruesse, achim

Reply to
Joachim Ebel

Wie kann man freiwillig eine so kranke Architektur wie die PICs benutzen :-)?

Architekturen wie die PICs sind für C-Compiler völlig ungeeignet. Im Prinzip sind eigentlich alle 8-Bit-CPUs für Hochsprachen nicht wirklich geeignet.

Wenn man richtig C/C++ im Embedded Bereich machen will, würde ich eher sowas wie die neue ARM-Serie von Philips nehmen. Klein und leistungsfähig und vor allem eine vernünftige 32 Bit Architektur.

Gruß, Marco

--
E-Mail: mb-news-blinuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de
Reply to
Marco Budde

"Joachim Ebel" schrieb:

Die Beschränkung lässt sich legal umgehen, indem man Module benutzt, die anschließend durch den Linker zusammengestzt werden. Das ist etwas unkomfortabel und der Code wird dadurch komplexer, bleibt aber noch beherrschbar. Im manual wird das genau beschrieben.

Der C18 von Microchip hat (soweit ich mich erinnere) keine Beschränkung, aber ist nur als Timebomb-Version kostenlos zu haben.

MfG, Bernd

Reply to
Bernd Maier

"Marco Budde" schrieb:

Ist der denn hobby-tauglich?

Gibts Einzelstücke zu kaufen?

Braucht man ein teures Programmiergerät?

Sind freie IDE und Compiler verfügbar?

Sind Packages >= TQFP zu haben?

Gibt es ein Community im Web?

MfG, Bernd

Reply to
Bernd Maier

Bernd Maier schrieb:

Hobbytauglich - IMHO ja. Einsteigertauglich - IMHO nein.

Zumindest bei Segor

Nein. Bootloader per RS232

GCC + IDE nach Wahl

TQFP mit 0,5er Pitch. Aber es gibt auch Minimodule wie z.B.

formatting link

Eine sehr aktive Yahoo-Gruppe.

Insgesamt ein interessanter Chip für den fortgeschrittenen Hobbyisten.

--
Matthias Weißer
matthias@matwei.de
 Click to see the full signature
Reply to
Matthias Weißer

Ja, ist nicht so ein fetter ARM wie die StrongARMs oder OMAPs. Wirklich für den Embedded Bereich optimiert.

Als DIP-Modul auf jeden Fall, such mal bei Google.

Nö.

Hallo? Es handelt sich um einen ARM-Prozessor, dafür gibt es alle Tools der Welt (z.B. den gcc, z.B. Linux als OS). Die ARMs stecken zur Zeit in fast allen modernen Embedded Geräten.

Glaube nicht, aber es gibt ihn fertig aufgelötet.

Für ARM :-)? Sicher.

cu, Marco

--
E-Mail: mb-news-blinuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de
Reply to
Marco Budde

Marco Budde schrieb:

[ARM-Serie von Philips]

und zum Debuggen?

Kann ich bei laufendem Programm ohne Nebenwirkungen Speicher (Variablen) auslesen und modifizieren?

Servus

Oliver

*) daß "modifizieren" dann doch eine "Nebenwirkung" ist, war mir natürlich klar.
--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz

Das interessantere könnte sein, daß der bis zu 64kByte SRAM hat. Da lohnt es sich die Kröte mit den krummen Versorgungsspannungen zu schlucken. Für viele Applikationen würde es weniger Prozessor und weniger als die 128kByte FLASH auch tun, aber 1k Byte SRAM reichen nicht.

Nachteil ARM:

  • maue Codedichte des 32 Bit Befehlssatzes ( drum hat er auch gleich 128kByte FLASH ). War mal für PC-Boards gedacht wo extern beliebig viel DRAM dranklebt. Das das Nachschieben des 16 Bit Schrumpf- befehlssatzes eine wirkliche Lösung ist glaube ich nicht. Ich vermute aber, das man in FORTH z.B. Bytecode verwenden kann der interpretiert wird. Bei 60MHz sollte das für viele Programmteile ausreichend schnell sein. Vom Speicherverbrauch dann eventuell kompakter als JSR-threaded auf 8 Bit CPU. "P-Code" wurde auch schon in Microsoft C++ verwendet um Code kleiner zu bekommen.

Vorteil ARM:

  • der Core wird wohl langfristig verfügbar bleiben. Bei den anderen 16/32 Bit embedded CPUs wäre ich mir da nicht so sicher.
  • auch in Assembler angenehm programmierbar. Da mangelts bei manchen DSPs ( offene Piplines usw. ) oft. Benchmark-Zahlen der Hersteller bezüglich was ein Chip angeblich kann besagen in der Praxis wenig wenn Anwender das Ding nicht programmieren kann. Würd mich nicht wundern wenn ARM in Signalverarbeitung in praktischen Applikationen manchen DSP schlägt.

MfG JRD

Reply to
Rafael Deliano

du logst dich über dein serielles Terminal auf der Console ein und arbeitest direkt auf dem ARM... (wenn man mal über die Hürde gekommen ist da das Betriebssystem läuft) :-)))

Gruß Alex

Reply to
Alex Wenger

"Alex Wenger" schrieb:

[ARM-Serie von Philips debuggen]

das meinte ich ausdrücklich nicht mit "ohne Nebenwirkungen".

Ich meine etwas wie das BDM-Interface des 68HC(S)12. Damit kann ich bei laufendem Programm Speicher lesen und schreiben, ohne das Programm zu beeinflussen. Das BDM-Interface macht das während ungenutzter Buszyklen *).

Das ist absolut genial, weil ich über einen vierpoligen Stecker (GND, Vcc, Reset, BDM) den BDM-debugger an ein Zielsystem anschließe, und dann alle Variablen quasi in Echtzeit beobachten und modifizieren kann. Ferner den anderen "üblichen" Kram (Breakpoints, single step...) und natürlich auch Flash programmieren.

Mit Betriebssystem und Konsole komme ich bei meinen Anwendungen nicht weit.

Servus

Oliver

*) für den unwahrscheinlichen Fall, das der nicht auftritt, "klaut" es einen Zyklus. Dann gibt es doch eine Beeinflussung, aber minimal.
--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz

Laut Datenblatt haben die Philips LPC21xx EmbeddedIce/EmbeddedTrace-Unterstützung 'drin, das sollte also mit einem der üblichen ARM7-Debugger gehen. Ich habe jetzt nicht den Überblick, ob es da schon was kostenloses gibt.

cu Michael

Reply to
Michael Schwingen

Ich könnte mir vorstellen, daß das mit dem gdb remote funktionert.

cu, Marco

--
E-Mail: mb-news-blinuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de
Reply to
Marco Budde

Michael Schwingen schrieb:

und damit kann ich unbemerkt auf Speicher zugreifen, während das Programm läuft?

das darf ruhig Geld kosten, mein HC(S)12-Debugger liegt auch bei über

2000EUR (die Leute ärgern mich aber gerade...).

Im Augenblick habe ich mit dem HCS12 noch genügend Rechenleistung und Speicher.

Aber wenn es mal schneller/größer werden sollte, wäre ein LPC... vom Preis/Leistungs-Verhältnis sehr interessant.

Servus

Oliver

--
Oliver Betz, Muenchen (oliverbetz.de)
Reply to
Oliver Betz

Keine AHnung, *wie* unbemerkt das ist. Beim XScale läuft auf dem Target ein spezieller Interrupthandler, der mit dem Debugger kommuniziert - kostet also ein paar Taktzyklen. Ich weiß nicht, wie das beim ARM7 genau aussieht.

cu Michael

Reply to
Michael Schwingen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.