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.
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.
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.
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.
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.
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 ?
@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.
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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
Ich würde vorschlagen, [www.bknd.com] ist ein Versuch wert. Ist zwar nicht umsonst, aber du kannst mit den freien Versionen sogar mittelgrösse Projekte verwirklichen. Die Qualität des generierten Codes ist hervorragend, Math ist toll. Es gibt nur einen Vermutstropfen: keine Libraries. Alles muss von Grund aufgebaut werden. Dabei lernt man aber viel!
VG Emmerich
Arbeite für meine Projekte in C und Basic von Mikroe. Leider auch nichz mehr supported.
Die neue Schiene was die fahren ist einfach nur aufgeblasen, langsam und teuer :-(
Arbeite für meine Projekte in C und Basic von Mikroe. Leider auch
nichz
mehr supported.
Die neue Schiene was die fahren ist einfach nur aufgeblasen, langsam und
teuer :-(
Schau Dir mal den CCSINFO compiler an. Die haben beschränkte Versionen und sonst auch nicht zu teuer.
Ich arbeitete damit seit 2000 in der Firma kommerziell und Hobby. Sie funktionieren ausgezeichnet.
Nur den Command Line compiler brauchst Du (nicht deren IDE) und einen guten Text Editor. Das reicht.
Die laufen auch noch auf älteren Betriebssystemen. Sie haben auch sehr viele Beispiele und Treiber Code in C. Für uns reichten sie dicke aus und wir machten in der Firma Millionen Umsatz in zahlreichen Geräten für die Industrie damit. Ist also gut genug, sollte jemand die Nase rümpfen und aus diesen oder jenen Grund meckern;-)
Gerade gesehen, daß es schon jemand angemerkt hat. Macht nichts.
