Grüß euch alle, bin neu hier im Forum und auf der Suche nach einem (kostenfreien) Compiler (C oder anderee höhere Sprache) + IDE für PIC Controller von Microchip für Hobbyprojekte, es geht um etwas ältere PIC Typen (PIC12Fxxx und PIC16F877 u.ä.). Mir ist nur der C-Compiler von Microchip bekannt, der mir aber sehr umständlich vorkommt, und meines Wissens sind dafür auch keinerlei Bibliotheken verfügbar. Suche für die genannten PIC Typen etwas ähnliches wie die IDE für Arduinos/ESPs, also möglichst auch mit verfügbaren Bibliotheken (z.B. für Kommunikation mit Temperatursensoren, I2C, Modbus, LCD Ansteuerung u.v.m.). Kennt jemand einen solchen oder hat einen Link ? Bin bis auf den Microchip Compiler nicht wirklich fündig geworden. Habe hier im Forum zwar eine Gegenüberstellung und Auflistung von C Compilern für die PICs gefunden, diese ist aber recht alt und zeigt auch nur den Compiler von Microchip als kostenfreien Compiler auf. Kann mir nicht vorstellen, dass für die PICs nicht doch etwas Vergleichbares wie für die ESPs/Arduinos verfügbar ist. Danke euch Euer Berni
Keine Bibliotheken von Microchip verfügbar? Das würde mich doch sehr wundern! Bisher war bei allen PICs die ich verwendet hab, alles komplett verfügbar. Lad dir die IDE (MPLAB-X) von MCHP runter und los gehts. Alles was fehlt wird dann noch nachinstalliert.
Für solche alten PICs, reicht allemal auch MPLAB 8.92 und XC8 V1.45. Wenn du "Arduino" willst, dann kauf dir einen bei Mario&Luigi.
:
Bearbeitet durch User
Cartman E. schrieb: > Für solche alten PICs, reicht allemal auch MPLAB 8.92 und XC8 V1.45. Was ist denn der Vorteil einer alten Entwicklungsumgebung?
Nick schrieb: > Cartman E. schrieb: >> Für solche alten PICs, reicht allemal auch MPLAB 8.92 und XC8 V1.45. > > Was ist denn der Vorteil einer alten Entwicklungsumgebung? Nicht gigantisch aufgeblasen. Für die alten Chips braucht man 99% der -X nicht.
Bernd Laura schrieb: > Bibliotheken (z.B. für Kommunikation mit > Temperatursensoren, I2C, Modbus, LCD Ansteuerung u.v.m.) Naja, DIESE Bibliotheken gibt es bei Microchip nicht, weil es ist eben tatsächlich kein "Arduino". Nick schrieb: > Was ist denn der Vorteil einer alten Entwicklungsumgebung? Eher keiner. Denn die aktuellen Programmer / Debugger sind da nicht enthalten. Und für die "ganz alten" bekommt man keine Treiber Win11 Entweder MPLABX oder nix (--> Arduino).
Klaus F. schrieb: > Naja, DIESE Bibliotheken gibt es bei Microchip nicht, Naja, I2C gibt es GARANTIERT, RS232-Treiber mit Puffer, SPI, ... Ich würde einfach empfehlen MPLAB-X erst mal zu installieren, sich die Treiber anzuschauen und dann zu jammern. Wenns irgendwie spezifische Bauteile sind (die dann eh nur wieder über SPI behandelt werden), gibt es oft auch Beispiele dafür. ModBus? ModBus over TCP/IP gibts von MCHP. Ansteuerung für spezielle Displays gibt es zuhauf im Netz. Die sind leider oft auf Arduino-Niveau und somit eher unbrauchbar. Aber bissl DaBla-Lesen sollte jeder schaffen.
Moin, Ich arbeite seit 1999 mit diesem hier: https://www.ccsinfo.com/compilers.php https://www.ccsinfo.com/downloads.php https://www.ccsinfo.com/downloads/CReferenceManual.pdf Ausser der Demo Version natürlich nicht frei. Gerhard
:
Bearbeitet durch User
Klaus F. schrieb: > Denn die aktuellen Programmer / Debugger sind da nicht enthalten. > Und für die "ganz alten" bekommt man keine Treiber Win11 Ein PicKit2 für die alten PICs kann man sich leicht selbst aufbauen. Das ist alles frei verfügbar. Der Treiber ist ein signierter USB-HID- Treiber. Warum sollte den W11 nicht mögen? > Entweder MPLABX oder nix (--> Arduino). So wie der TO sich anstellt, sollte er wohl besser gleich letzteres ins Auge fassen.
> bin neu hier im Forum und auf der Suche nach einem (kostenfreien) > Compiler (C oder anderee höhere Sprache) + IDE für PIC Controller von > Microchip für Hobbyprojekte, es geht um etwas ältere PIC Typen > (PIC12Fxxx und PIC16F877 u.ä.). Mir ist nur der C-Compiler von Microchip > bekannt, der mir aber sehr umständlich vorkommt, SDCC hat Backends für PIC, diese sind allerdings zur Zeit nicht maintained, weshalb mit mehr Bugs zu rechnen ist. Die von dir genannten PIC12Fxxx und PIC16F877 werden meines Wissens unterstützt. Philipp
Klaus F. schrieb: > Denn die aktuellen Programmer / Debugger sind da nicht enthalten. > Und für die "ganz alten" bekommt man keine Treiber Win11 Komisch, mein Picstart plus läuft nach wie vor. Taugt natürlich nur für die alten µCs.
H. H. schrieb: > Komisch, mein Picstart plus läuft nach wie vor. Taugt natürlich nur für > die alten µCs. Hab eben nachgesehen, was für den PIC16F1575 an Programmern unterstützt wird. Das gilt für PIC12-16F1xxx: ICD 4, ICD 5, PICkit 4, Snap, ICE 4, J-32, PICkit 5, PICkit Basic, J-Link, PM3, Curiosity Starter Kits, SEGGER SAM-ICE Achtung, da sind paar DevBoards mit dabei. Das wäre aber für den Einsteiger sowieso besser. Dann muss er sich nicht auch noch mit seinem vermurksten Board das er weder layouten noch löten kann rumschlagen.
Nick schrieb: > Hab eben nachgesehen, was für den PIC16F1575 an Programmern unterstützt > wird. Den hatte der TE ja ganz speziell erwähnt... > Das gilt für PIC12-16F1xxx: > ICD 4, ICD 5, PICkit 4, Snap, ICE 4, J-32, PICkit 5, PICkit Basic, > J-Link, PM3, Curiosity Starter Kits, SEGGER SAM-ICE Und die meisten eben auch vom ollen Picstart plus.
Ein PicKit2, kann mit passender neuer Soft- und Firmware (PicKitMinus), in seinem Funktionsumfang erheblich aufgewertet werden. ☺
Nick schrieb: > Keine Bibliotheken von Microchip verfügbar? Das würde mich doch sehr > wundern! Bisher war bei allen PICs die ich verwendet hab, alles komplett > verfügbar. > Lad dir die IDE (MPLAB-X) von MCHP runter und los gehts. Alles was fehlt > wird dann noch nachinstalliert. Danke an alle für eure Beiträge. Ich habe mir nun die MPLAB X mit XC8 Compiler installiert. Vor ca. 20 Jahren hatte ich den ersten Kontakt mit den PICs und µCs im allgemeinen, war dann aber irgendwann aus den besagten Gründen auf ESP, Arduino & Co umgestiegen. Mit den PICs weiss man, was man hat, da kann man jedes Register noch kennen lernen; bei den Arduinos ist vieles irgendwie so genial wie magisch - wenn's mal nicht klappt, ist es schwierig, die Ursache zu finden, weil im Hintergrund vieles im Dunkeln ist. Deshalb jetzt wieder "Back to the Roots" --> hello "PIC" . Hatte damals noch den DIY K150 Programmer, der funktioniert jetzt noch. ABER: Ein wichtiger Punkt sind immer noch die fehlenden Bibliotheken (damals wie heute), selbst für Standarddinge wie LCD Ansteuerung :-( @b620ys Nick, wo nimmst du denn alle die Bibliotheken, die du erwähnt hast, her ?
:
Bearbeitet durch User
Bernd Laura schrieb: > @b620ys Nick, wo nimmst du denn alle die Bibliotheken, die du erwähnt > hast, her ? Da hast Du wohl eine andere Vorstellung von "Bibliothek" wie ich. Ich verstehe sowas wie "stddef.h", "string.h" drunter. Wenn Du Treiber meinst. Die finden sich tw. in Beispielen von MCHP. Oder im Netz. Oft bieten auch Hersteller Beispielcode an, oder entsprechende Hinweise finden sich in deren Datenblättern. Selbstgemacht ist besser als vorgekaut.
Nick schrieb: > Da hast Du wohl eine andere Vorstellung von "Bibliothek" wie ich. Ich > verstehe sowas wie "stddef.h", "string.h" drunter. Das sind keine Bibliotheken. Das sind nur Headerfiles. Bibliotheken ("Libraries") heißen *.lib oder *.a (oder, wenn sie dynamisch gelinkt werden, *.dll bzw. *.so). In C++ gibt es "header-only libraries", aber nicht in C.
Harald K. schrieb: > Das sind keine Bibliotheken. Das sind nur Headerfiles. Bibliotheken > ("Libraries") heißen *.lib oder *.a (oder, wenn sie dynamisch gelinkt > werden, *.dll bzw. *.so). Ja, darum heißt es z.B. "stdlib.h" Harald K. schrieb: > In C++ gibt es "header-only libraries", aber nicht in C. Die gibt es auch in C. Muss man einfach nur schreiben. Ich bin mir auch recht sicher, ohne jetzt explízit nachzusehen, dass stddef.h header only ist. Ich schreib auch oft genug Projektspezifische #defines in eine Projekt-header Datei, wenn sie fürs ganze Projekt gültig sind.
Nick schrieb: > Ja, darum heißt es z.B. "stdlib.h" Seufz. Trau Dich mal, und sieh in die Datei 'rein. Ist 'ne Textdatei, da reicht ein Editor. Verstehst Du genug C, um Programmcode von Deklarationen zu unterscheiden?
Harald K. schrieb: > Ist 'ne Textdatei, da reicht ein Editor. Wow! Eine TEXTdatei. Kann man also ohne eine IDE mit 2 GB öffnen. Wenn ich das gewusst hätte! Du kannst auch eine .exe mit einem Texteditor öffnen. Das beweist nichts in Bezug auf "In C gibt es keine header-only". Harald K. schrieb: > Verstehst Du genug C, um Programmcode von Deklarationen zu > unterscheiden? Also header-only? Deklarationen? Das sind überwiegend Macros die zu Code expandieren. Ist aber egal. Header-only ist header-only. Was passiert eigentlich, wenn ich das Buch "The Standard C Library" von P.J. Plauger in die Hand nehme? Bin ich dann einem Betrug aufgesessen? StdLibs gibts ja nicht, laut dir. Gibts auch als PDF für die Knauser: https://raw.githubusercontent.com/TIM168/technical_books/master/C%E8%AF%AD%E8%A8%80/The+C+Standard+Library.pdf Oder den Link verfolge: https://en.wikipedia.org/wiki/C_standard_library Du hast dich mit Deinem "Wissen" ganz schön in eine einsame Nische manövriert.
Nick schrieb: > Du kannst auch eine .exe mit einem Texteditor > öffnen. Auf diesem Niveau darfst Du Dich gerne mit anderen unterhalten. Am Buddelkasten vielleicht?
Harald K. schrieb: > Auf diesem Niveau darfst Du Dich gerne mit anderen unterhalten. Du bist ja ganz schön schnell argumentativ überfordert! Ich vermute, dass Du selbst am Buddelkasten scheiterst.
Nick schrieb: > Du bist ja ganz schön schnell argumentativ überfordert! Es gibt eine ganz klare, seit Jahrzehnten existierende Definition dessen, was bei C eine Library ist. Das ist eine Sammlung von kompilierten Objektdateien. Verarbeitet werden Libraries vom Linker, der alle zu einem Programm gehörenden Objektdateien zusammenpackt und alle dann noch nicht definierten Symbole in den angegebenen Libraries sucht. Eine Library besteht aus einer oder mehreren Objektdateien, kann aber auch vom Linker auf Funktionsebene ausgewertet werden (sofern dieser "function-level linking" unterstützt). Ein wesentlicher Unterschied zwischen dem Linken normaler Objektdateien und Libraries ist der "Härtegrad" der Symboldefinitionen; taucht ein Symbolname in einer Objektdatei und gleichzeitig in einer Library auf, wird letzteres als "schwach" (weak) angesehen und das Symbol aus der Objektdatei verwendet. Eine Headerdatei oder Includedatei enthält nur Deklarationen, Macrodefinitionen etc., aber keinen Code (mit der kleinen Ausnahme von Inline-Code). Headerdateien werden vom C-Präprozessor verarbeitet, und nicht vom Linker. Headerdateien sind lesbarer Text. Im Arduino-Sprech wird jetzt alles "Library" genannt, was nicht bei drei auf den Bäumen ist -- aber: Arduino ist nicht C, sondern C++. Wer das nicht auseinanderhalten kann, wird noch lustige Verständnisprobleme haben. Und wer meint, in C oder auch in C++ "proggen" zu müssen, ohne jemals verstanden zu haben, was eine Headerdatei ist und warum es hilfreich ist, in die auch mal reinzusehen, der will nicht programmieren lernen, der will sein Werkzeug nicht verstehen lernen.
Harald K. schrieb: > aber: Arduino ist nicht C, sondern C++. In C++ ist das aber auch so: Harald K. schrieb: > Eine Headerdatei oder Includedatei enthält nur Deklarationen, > Macrodefinitionen etc., aber keinen Code (mit der kleinen Ausnahme von > Inline-Code). Oder findest du dass eine C++ Library auch einfach eine einzelne Header-Datei sein kann? Wenn ja, warum? Harald K. schrieb: > Es gibt eine ganz klare, seit Jahrzehnten existierende Definition > dessen, was bei C eine Library ist Wo steht die Definition nochmal im C-Standard?
:
Bearbeitet durch User
Harald K. schrieb: > Es gibt eine ganz klare, seit Jahrzehnten existierende Definition > dessen, was bei C eine Library ist. Das Buch von P.J. Plauger existiert seit 1992. Wenn Du einigermassen in C geläufig bist, sollte dir der Name bekannt sein. Alles was Du über .obj-Files vorbringst, hat nichts mit C zu tun. In C werden keine vorkompilierten Dateien definiert, kein Linker. Nur die Sprache. Harald K. schrieb: > Headerdateien werden vom C-Präprozessor verarbeitet, und nicht vom > Linker. Headerdateien sind lesbarer Text. Ist doch völlig egal was der Compiler draus macht. C source ist auch Menschen-lesbar. So what, der C-Compiler liest die Header, liest C-Quelltext. Und hat nichts mit dem Linker zu tun. Linker ist Implementierung der code-Generierung. Nirgendwo ist definiert, dass dazu ein Linker notwendig ist. Und nein, der Präprozessor verarbeitet nicht ausschließlich Header, der Präprozessor ist für die #defines, #include, #if, ... alles was mit '#' anfängt, zuständig. Der Präprozessor verarbeitet genauso .c files. Denn auch da stehen '#' drinnen (hauptsächlich #include). Und das hat absolut nichts mit Linkern zu tun. Er ist nur dafür zuständig einen compilierbaren source durch Erweiterungen/Ersetzungen herzustellen. Es gibt auch Interpreter für C. Die können dann, laut Deiner Definition keine Libraries haben. Haben sie natürlich. Siehe P.J. Plauger. Lies Dir doch bitte selber mal an was eine "C-Bibliothek" (Englisch: Library) ist und verbreite hier bitte nicht so hahnebüchernen Unsinn. Danke.
Harald K. schrieb: Nachtrag: > Und wer meint, in C oder auch in C++ "proggen" zu müssen, ohne jemals > verstanden zu haben, was eine Headerdatei ist und warum es hilfreich > ist, Seltsam! Du unterstellst mir, dass ich keine Header selbst schreibe? Reichlich absurde Unterstellung. Und klar schau ich in die header, wie sonst soll man denn sonst Libraries (oh je!) verwenden können. Was im C-Standard der Libraries definiert ist, schau ich aber lieber in meinem Lieblings-C-Buch nach. Nein, das Kernighan and Ritchie C-Buch hab ich schon lange im Müll entsorgt, denn das ist Müll. Wenn es ganz genau gehen soll/muss, dann schau ich bei P.J. Plauger nach. Das ist die Definition die keine Zweifel hinterlässt.
Unter linux hi-tech c , die Lizernz erlaubt auch kommerzielle Nutzung. Da gibt es massiv libs. Ist aber schwer zu finden.
Nick schrieb: > Wenn es ganz genau gehen soll/muss, dann schau ich bei P.J. Plauger > nach. Das ist die Definition die keine Zweifel hinterlässt. Halten sich denn alle Compiler und Plattformen an das Buch von Plauger, und nicht an den ISO C Standard?
MPLAB Code Configurator (MCC) Classic heiß das Gesuchte, würde ich mal meinen. Für die Alte, die Clasic Variante. https://www.microchip.com/en-us/tools-resources/configure/mplab-code-configurator/classic https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/ReleaseNotes/release_notes_pic10_pic12_pic16_pic18_v1_82_1.pdf
:
Bearbeitet durch User
Bernd Laura schrieb: > Mit den PICs weiss > man, was man hat, da kann man jedes Register noch kennen lernen; Ja, das ist aber bei Arduino & Co. auch nicht anders. > bei den > Arduinos ist vieles irgendwie so genial wie magisch - wenn's mal nicht > klappt, ist es schwierig, die Ursache zu finden, weil im Hintergrund > vieles im Dunkeln ist. Man muß sich eben reinknien. Mit höherer Abstraktion kommt man schneller zum Ziel, aber wenn es hakt, wird es umso komplexer. Das Problem wäre bei einem Arduino auf PIC-Basis mit 'fertigen' Bibliotheken genauso. Mit anderen Worten: der Unterschied liegt nicht zwischen PIC und AVR sondern in der Abstraktionsebene beim Programmieren.
Bernd Laura schrieb: > da kann man jedes Register noch kennen lernen Könnt ihr euch wirklich alle Peripherie-Register von so einem Controller auswendig merken? Inklusive aller Bits?
Nick schrieb: > Wenn es ganz genau gehen soll/muss, dann schau ich bei P.J. Plauger > nach. Das ist die Definition die keine Zweifel hinterlässt. ich habe das von Dir verlinkte PDF heruntergeladen. Kannst Du ein Stichwort geben (oder eine Seite), was Du mit "header-only" meinst? (Den Begriff finde ich so nicht) Dass eine .h-Datei beliebig verwendet werden kann und normalen Code enthalten kann (oder gar nur Fragmente), geschenkt. Dass es bei den Standard-Headern zusätzlich eine Makro-Implementierung geben darf, auch. (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf, Seite 192) Aber eine Implementierung als "Header-only" ist für die Standard-Funktionen prinzipiell nicht möglich. Oder sie wären static parallel für jede Übersetzungseinheit. Dass ein Compiler-Hersteller dies trotzdem macht und entsprechend beschreibt, glaube ich gerne und ich hätte damit auch kein Problem.
:
Bearbeitet durch User
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.