Hallo, sehe ich das richtig, dass es für die dsPic33FJ von Microchip keine freien Compiler bzw. kostenlos nur Demo-Versionen mit Einschränkungen gibt? Microchip hat die MPLAB XC Compiler, frei optimiert der nicht oder nur kaum. Sonst habe ich noch mikroC, Hi-Tech C-Compiler, IAR und CCS gefunden, alles kommerziell. Die MPLAB-X IDE von Microchip habe ich vorhin runtergeladen aber als ich gelesen habe, dass die auf Netbeans basiert und JRE braucht ist mir die Laune zum experimentieren erstmal vergangen und ich würde das tendenziell eher wieder löschen wollen anstatt es zu installieren.
Und nun ? Das kostenlose Hersteller Tool gefällt Dir nicht und das der professionelle Compiler in der kostenlosen Version schlechter optimiert findest Du frech. Was machen wir da jetzt ?
Michael Knoelke schrieb: > Was machen wir da jetzt ? Vielleicht nen Tipp geben, dass ich was übersehen habe?
Nun, ist das denn für Dich ein Problem, dass die freie Version nur schwach optimiert? Privat habe ich hier welche von denen laufen, da stört mich das nicht. Wenn Du wirklich Performance bis zum letzten brauchst, ist das natürlich was anderes. MPLAB-X (zumindest meine Installation von vor einem Jahr) bringt seine eigenes JRE mit, das vollkommen lokal existiert. Es installiert Dir auch nicht ungewollterweise ein Browser PlugIn, falls das Deine Sorgen sind. Die JRE wird nur von MPLAB-X verwendet und taucht sonst in Deinem System nicht auf.
Rudolph R. schrieb: > Vielleicht nen Tipp geben, dass ich was übersehen habe? Okay, Du hast übersehen das Du mit den kostenlos zur Verfügung stehenden Tools sehr weit kommst und Dich die Einschränkung wahrscheinlich niemals stören wird. Ausserdem hast Du übersehen das Du jederzeit die Möglichkeit hast durch den käuflichen Erwerb die Einschränkungen aufzuheben. Weiterhin hast Du übersehen das es Dir jederzeit frei steht einen andern Controller zu verwenden dessen Toolchain mehr nach Deinem Geschmack ist.
Florian V. schrieb: > Nun, ist das denn für Dich ein Problem, dass die freie Version nur > schwach optimiert? Ich weiss es noch nicht wie schwer sich das auswirkt. Daher habe ich das ja auch in meinem ersten Post lediglich neutral dargestellt und nicht negativ bewertet. Wenn der Unterschied so gross wäre wie dem GCC für AVR bei dem der Code zwischen -O0 und -O3/-Os ganz erheblich anders ist, das würde mich schon stören. Microchip gibt ja selber auch an, das die Standard Version 20-25% besser optimiert und die Pro Version sogar 50% besser optimiert als die Free Version - wieviel davon auch immer Marketing-Geblubber ist. > MPLAB-X (zumindest meine Installation von vor einem Jahr) bringt seine > eigenes JRE mit, das vollkommen lokal existiert. Okay, hatte nur was von JRE installieren gelesen. Habs jetzt installiert und es läuft, sieht auf den ersten Blick okay aus und mit dem XC Compiler in der Demo-Version konnte ich auch sofort ein leeres Default-Projekt kompilieren. Michael Knoelke schrieb: > Okay, Du hast übersehen das Du mit den kostenlos zur Verfügung stehenden > Tools sehr weit kommst und Dich die Einschränkung wahrscheinlich niemals > stören wird. Nein, habe ich nicht, 25% bzw. 50% schlechter optimieren klingt nach einer Einschränkung die zum Problem werden kann. > Ausserdem hast Du übersehen das Du jederzeit die Möglichkeit hast durch > den käuflichen Erwerb die Einschränkungen aufzuheben. Nein, habe ich nicht, statt 900€ für nen Compiler auszugeben würde ich aber eher die Plattform wechseln. Die Hardware ist fertig, ich könnte mich darauf einarbeiten was ich auch gewillt bin mir anzuschauen. Aber die Hardware muss eh gefixt werden, dabei kann auch gleich der Controller mit raus fliegen. > Weiterhin hast Du übersehen das es Dir jederzeit frei steht einen andern > Controller zu verwenden dessen Toolchain mehr nach Deinem Geschmack ist. Nein, habe ich auch nicht übersehen, danke. Die Frage war doch ganz einfach gestellt, das suche ich, das habe ich gefunden, stimmt das so. Also es gibt für die dsPic33FJ keinen freien Compiler ohne Einschränkungen, ist das richtig?
Rudolph R. schrieb: > Also es gibt für die dsPic33FJ keinen freien Compiler ohne > Einschränkungen, ist das richtig? ja. Wobei auch ich sagen kann, dass das für Dich kein Problem sein sollte. Das spielt eher für die Massenproduktion eine Rolle, wo man dann ggf den nächst kleineren Typen aus der Serie nehmen kann und dadurch pro Stück 50 Cent oder so spart. Und 50 Cent mal 10k sind auch 5000€, und dann ist auch eine Compilerlizenz drin. Das ist alles. Bei Einzelstücken nimmst Du einfach den größten Controller aus der Serie, und gut ist. Inzwischen gibts neben dsPIC33F auch dsPIC33E mit 140 MHz statt 80 MHz und bis zu 512k Flash und 52k+4k RAM, und die sind in der Regel pinkompatibel. Du hast also reichlich Luft nach oben. fchk
Frank K. schrieb: > ja. Okay, danke. > Wobei auch ich sagen kann, dass das für Dich kein Problem sein sollte. > Das spielt eher für die Massenproduktion eine Rolle, wo man dann ggf den > nächst kleineren Typen aus der Serie nehmen kann und dadurch pro Stück > 50 Cent oder so spart. Und 50 Cent mal 10k sind auch 5000€, und dann ist > auch eine Compilerlizenz drin. Das ist alles. Naja, nicht ganz, das zielt eher auf den Speicher-Ausbau ab, wenn es danach geht ist der Baustein sowieso zu gross ausgelegt. Nur wenn von 40 MIPS ohne Optmierung nur 10 MIPS übrig bleiben, dann nützt es auch wenig wenn der nächste Typ in der gleichen Serie mehr Speicher hat... > Inzwischen gibts neben dsPIC33F auch dsPIC33E mit 140 MHz statt 80 MHz > und bis zu 512k Flash und 52k+4k RAM, und die sind > in der Regel pinkompatibel. Danke für den Tipp! Wobei die Strom-Aufnahme von dem Ding im Moment auch eines von mehreren Probleme ist - und wie das meiste andere ziemlich sicher durch die Software verursacht. :-) > Du hast also reichlich Luft nach oben. Weiss ich nicht, wenn es jetzt nicht reicht wird es dann auch eng. :-)
Rudolph R. schrieb: > Wenn der Unterschied so gross wäre wie dem GCC für AVR bei dem der Code > zwischen -O0 und -O3/-Os ganz erheblich anders ist, das würde mich schon > stören. Du bekommst in der freien Version -O1. Schön sieht das ganze in Assembler allerdings immer noch nicht aus...
Vielleicht der hier? http://www.mikroe.com/mikroc/dspic/ Included demo license enables up to 6144 bytes of FREE output code. Supported microcontrollers of dsPic33FJ64 dsPIC33FJ64GP202 28 64 80 8192 dsPIC33FJ64GP204 44 64 80 8192 dsPIC33FJ64GP206 53 64 80 8192 dsPIC33FJ64GP206A 64 64 80 8192 dsPIC33FJ64GP306 53 64 80 16384 dsPIC33FJ64GP306A 64 64 80 16384 dsPIC33FJ64GP310 85 64 80 16384 dsPIC33FJ64GP310A 100 64 80 16384 dsPIC33FJ64GP706 53 64 80 16384 dsPIC33FJ64GP706A 64 64 80 16384 dsPIC33FJ64GP708 69 64 80 16384 dsPIC33FJ64GP708A 80 64 80 16384 dsPIC33FJ64GP710 85 64 80 16384 dsPIC33FJ64GP710A 100 64 80 16384 dsPIC33FJ64GP802 28 64 80 16384 dsPIC33FJ64GP804 44 64 80 16384 dsPIC33FJ64GS406 64 64 100 8192 dsPIC33FJ64GS606 64 64 100 9216 dsPIC33FJ64GS608 80 64 100 9216 dsPIC33FJ64GS610 100 64 100 9216 dsPIC33FJ64MC202 28 64 80 8192 dsPIC33FJ64MC204 44 64 80 8192 dsPIC33FJ64MC506 53 64 80 8192 dsPIC33FJ64MC506A 64 64 80 8192 dsPIC33FJ64MC508 69 64 80 8192 dsPIC33FJ64MC508A 80 64 80 8192 dsPIC33FJ64MC510 85 64 80 8192 dsPIC33FJ64MC510A 100 64 80 8192 dsPIC33FJ64MC706 53 64 80 16384 dsPIC33FJ64MC706A 64 64 80 16384 dsPIC33FJ64MC710 85 64 80 16384 dsPIC33FJ64MC710A 100 64 80 16384 dsPIC33FJ64MC802 28 64 80 16384 dsPIC33FJ64MC804 44 64 80 16384
Hatte ich auch, das Problem, vor gut zwei Jahren. Beitrag "PIC Port I/O mit HiTech C" Ich habe dann auch mit dem Compiler von www.mikroe.com gearbeitet, super Teil, absolut schnörkellos, guter Code und nicht buggy. Kann mich der Empfehlung oben also anschließen. Cheers Detlef
Rudolph R. schrieb: > Nur wenn von 40 MIPS ohne Optmierung nur 10 MIPS übrig bleiben, dann > nützt es auch wenig wenn der nächste Typ in der gleichen Serie mehr > Speicher hat... Na das ist ja wohl Unsinn. Der GCC erzeugt mit Sicherheit nicht durchschnittlich vierfach schneller Code durch Optimieren. Bei kleineren Programmen wird man garnichts merken, die libc, der Startupcode ist immer der selbe. Wenn du mal etwas wirklich lohnendes hast, kannst du ja mal die 30 Tage Testversion aktivieren und sehen, was da wirklich rauskommt. Ich schalt ab und an mal -O1 ein, mehr um zu sehen, ob ich sauber programmiert habe und das Programm noch läuft. Aber Portpins setzen, SFRs lesen oder Integer multiplizieren wird nicht wirklich schneller. Kürzer als ein Takt gehts nun mal nicht. Schlechte Algorithmen kriegt auch ein Optimizer nicht gerettet. MfG Klaus
Klaus schrieb: > Na das ist ja wohl Unsinn. Nein, Spekulation, Lesen und so, da steht "wenn". Was hast du an "Ich weiss es noch nicht wie schwer sich das auswirkt." nicht verstanden? > Der GCC erzeugt mit Sicherheit nicht > durchschnittlich vierfach schneller Code durch Optimieren. Da ich die Info noch nicht hatte, dass die freie Version mit -O1 arbeitet musste ich von -O0 ausgehen. Vom AVR weiss ich, dass der bei -O0 ein vielfaches an Code erzeugt, zum Beispiel werden die Bit-Manipulations Befehle sbi/cbi bei -O0 nicht verwendet. Vielleicht nicht ganz Faktor vier sondern nur drei oder so, aber mehrere Assembler Befehle statt nur einem zu verwenden macht den Controller langsamer. Jetzt habe ich die Info, dass der mit -O1 optmiert und sehe das deutlich entspannter. X4U schrieb: > Vielleicht der hier? > > http://www.mikroe.com/mikroc/dspic/ Ich weiss jetzt, dass der Code den ich mir mal ansehen soll mit einer alten MPLAB Version und entsprechend älterem Compiler erstellt wurde. Ich konnte vorhin auch einfach das alte Projekt in MPLAB-X importieren. Habs nicht mehr im Kopf, 6k könnten aber knapp werden, das Projekt nutzt scheinbar eine Microchip CAN-Lib und eine Lib zur Simulation eines EEPROMs im FLASH. Aber danke für den Tipp!
Rudolph R. schrieb: > Ich weiss jetzt, dass der Code den ich mir mal ansehen soll mit einer > alten MPLAB Version und entsprechend älterem Compiler erstellt wurde. > Ich konnte vorhin auch einfach das alte Projekt in MPLAB-X importieren. Da macht ein anderer Compiler erst mal wenig Sinn. Microchip compiler gibt es als Testversionen . Auch den MPLAB® XC Compiler pro kannst du von kostenlos auf 60 Tage lang pro. hochdrehen. > http://www.mikroe.com/mikroc/dspic/ > Habs nicht mehr im Kopf, 6k könnten aber knapp werden, Lizenzkosten ca. 250€ einmalig.
X4U schrieb: >> Habs nicht mehr im Kopf, 6k könnten aber knapp werden, > > Lizenzkosten ca. 250€ einmalig. Im Moment gibt es aber noch Null Budget dafür, da pssen auch nur 250€ nicht rein. :-) Und ich habs mal durchlaufen lassen, laut Anzeige des Compilers werden 26k Flash gebraucht. Wofür auch immer, 1 CAN, 1 ADC, 1 DAC, ein paar I/Os, EEPROM-Simulation. Das SRAM ist auch quasi voll. Hat MPLAB-X eigentlich kein Programmier-Dialog-Fenster? Hab vorhin noch mit einem 16F88 und einem PICkit3 rumgespielt. Ein einfaches Auslesen zum Beispiel der Chip-ID scheint nicht möglich zu sein? Einfach mal eben so ein vorhandenes .hex File kann man auch nicht brennen? Die Möglichkeit ein .hex zu Importieren habe ich gefunden, wenn das alles ist geht es ja kaum noch umständlicher. Und hatten die PICs nicht auch Fuse-Bits zum einstellen? Wo werden die eingestellt? Wo kann ich sehen wie ein bereits vorhander PIC eingestellt ist?
Rudolph R. schrieb: > wenn das > alles ist geht es ja kaum noch umständlicher. doch bestimmt. Vermutlich in der nächsten Mplab Version :-). Wenn du nur ein Hex flashen willst ist der Pickit 3 Standalone Progger die weitaus bessere Wahl. Microchip hat den natürlich discontinued und im Archiv versteckt. Dafür gibt es jetzt den IPE. Die komplizierte Variante für alle die nach Mauskilometern und Tastenklicks bezahlt werden. >> Lizenzkosten ca. 250€ einmalig. > > Im Moment gibt es aber noch Null Budget dafür, da pssen auch nur 250€ > nicht rein. :-) Macht auch keinen Sinn wenn ein Mplab Projekt existiert. Außerdem sind die ganzen Mikroe Produkte viel zu effizient. Das holst du zu schnell wieder rein (es sei denn du wirst als Praktikant beschäftigt. Deine anderen Fragen sind eher was für neue Threads.
>Hat MPLAB-X eigentlich kein Programmier-Dialog-Fenster?
mplab_ipe heisst das bei mplabx mitgelieferte Programmiertool.
Rudolph R. schrieb: > Und hatten die PICs nicht auch Fuse-Bits zum einstellen? Wo werden die > eingestellt? Wo kann ich sehen wie ein bereits vorhander PIC eingestellt > ist? Normal im Quellcode. Je nach Compiler per #pragma config (z.B. XC8) oder _CONFIG1(), _CONFIG2(),... Makros. (XC16/XC32) Im Hexfile sind die Config Words ganz hinten in den letzten Words. fchk
:
Bearbeitet durch User
X4U schrieb: > Pickit 3 Standalone Progger Danke für den Tipp, das Teil ist zwar auch nicht prall aber besser als das IPE. Das man IPE scheinbar nicht aus MPLAB heraus starten kann finde ich ziemlich seltsam, dass man mit dem IPE scheinbar die Fuse-Bits nicht auslesen oder gar einstellen kann noch seltsamer. Ausserdem kann ich mit IPE zwar den Baustein Auslesen, das ausgelesene dann aber nicht exportieren. Der PICkit3 V3.10 programmer liest den Baustein, zeigt den Inhalt an, FLASH und HEX und auch die Fuse-Bits kann man sich anzeigen lassen, Export in .hex klappt ohne Probleme. Wobei die Fuse-Bits extrem stumpf ohne jede Erklärung angezeigt werden. Beim Beenden des Tools bekomme ich unter Windows7 eine Fehlermeldung, es lässt sich einfach nicht beenden - nur abschiessen über den Task-Manager. Die Toolkette ist soweit erstmal kein Grund in Zukunft nicht mehr Atmel zu benutzen. :-)
Rudolph schrieb: > Das man IPE scheinbar nicht aus MPLAB heraus starten kann finde ich > ziemlich seltsam Wozu willst du das aus dem MPLAB heraus starten. Wenn man in MPLAB Arbietet ist die IPE doch gar nicht nötig, man kann auch direkt aus MPLAB falshen. > dass man mit dem IPE scheinbar die Fuse-Bits nicht auslesen Was interessieren die eigentlich die Fusebits, beim nächsten Falshen sind sie eh weck/überschrieben. > gar einstellen kann noch seltsamer. Wieso willst du die Fuses extra einstellen, schreib einfach die paar Zeilen config in deinen Quellcode und es hat sich. Das ist nicht wie bei den ATmegas wo man die getrennt noch mal einstellen muss. > Ausserdem kann ich mit IPE zwar den Baustein Auslesen, das ausgelesene > dann aber nicht exportieren. Das muss an dir liegen, bei mir geht's problemlos: File -> Export -> Hex
Rudolph R. schrieb: > Wenn der Unterschied so gross wäre wie dem GCC für AVR bei dem der Code > zwischen -O0 und -O3/-Os ganz erheblich anders ist, das würde mich schon > stören. Vergleiche niemals -O0 (abgeschalteter Optimierer) mit irgend einer Optimierungsstufe. Vergleiche machen erst ab -O1 Sinn. Nebenbei: Wenn Du flink bist, kannst Du die volle Optimierung nutzen. 60 Tage Evaluierung der PRO Version ist möglich.
PICianer schrieb: > Wozu willst du das aus dem MPLAB heraus starten. Weil einfach nur flashen etwas sehr dünn ist? >> dass man mit dem IPE scheinbar die Fuse-Bits nicht auslesen > Was interessieren die eigentlich die Fusebits, beim nächsten Falshen > sind sie eh weck/überschrieben. Ich habe hier einen PIC16F88 in einer Schaltung und will an dem Ding mal exemplarisch rumspielen ohne die Schaltung kaputt zu machen. Dafür will ich auch wissen, wie der Stein jetzt konfiguriert ist. >> gar einstellen kann noch seltsamer. > Wieso willst du die Fuses extra einstellen, schreib einfach die paar > Zeilen config in deinen Quellcode und es hat sich. Das ist nicht wie bei > den ATmegas wo man die getrennt noch mal einstellen muss. Das kann man bei den ATMegas auch über den Quellcode machen. Ich habe nur wieder vergessen wie das geht weil die Einstellung über die GUI so gut funktioniert das ich den anderen Weg nicht brauche. >> Ausserdem kann ich mit IPE zwar den Baustein Auslesen, das ausgelesene >> dann aber nicht exportieren. > Das muss an dir liegen, bei mir geht's problemlos: > File -> Export -> Hex Mehr als in dem Programm klicken kann ich nicht, ich mache ein "Read", das läuft auch durch wie man in dem "Output" Feld sehen kann. Dann gehe ich auf File -> Export und muss feststellen, dass "Hex" ausgegraut ist.
Rudolph schrieb: > Wobei die Fuse-Bits extrem stumpf ohne jede Erklärung angezeigt werden. Ein wenig viel verlängt. Der Pickit ist ein Progger, kein reverse engeneering tool. > Beim Beenden des Tools bekomme ich unter Windows7 eine Fehlermeldung, es > lässt sich einfach nicht beenden - nur abschiessen über den > Task-Manager. Bei mir läuft es, evtl. mal neu installieren. Was hast du mit dem Hex File eigentlich vor? Da ist doch bestenfalls der Maschinencode und die config drin. Rudolph schrieb: > Das kann man bei den ATMegas auch über den Quellcode machen. Das geht auch in den IDE's für Microchip controller. Aber wozu brauchst du das wenn du ein Projektfile hast? Rudolph schrieb: > ich mache ein "Read", > das läuft auch durch wie man in dem "Output" Feld sehen kann. > Dann gehe ich auf File -> Export und muss feststellen, dass "Hex" > ausgegraut ist. Dann ist evtl. die code protection gesetzt. Was siehst du denn im Hex Fenster? Alles 00 oder FF?
X4U schrieb: > Rudolph schrieb: >> ich mache ein "Read", >> das läuft auch durch wie man in dem "Output" Feld sehen kann. >> Dann gehe ich auf File -> Export und muss feststellen, dass "Hex" >> ausgegraut ist. Hab noch mal nachgeschaut. Beim Pickit 3 kannst du ich das Hexfile auch exportieren wenn code protection gesetzt ist. Dann sind im Fenster Program Memory nach dem auslesen alle Bytes auf 00. Version 3.10 mit OS Firmware 2.00.05 (für Pic 18).
> Hat MPLAB-X eigentlich kein Programmier-Dialog-Fenster? > Hab vorhin noch mit einem 16F88 und einem PICkit3 rumgespielt. dsPic33 und PIC16 sind schon ein großer Unterschied. Du wirst es wissen. Wollte es nur erwähnt haben, da der Thread eine merkwürdige Wendung nimmt. Meine Angaben sind auf einen dsPic33 bezogen Ich gehe aber davon aus, dass es allgemeine Menüpunkte sind und so auch beim PIC16 gelten. 'Project Properties' 'Run Main Project' > Ein einfaches Auslesen zum Beispiel der Chip-ID scheint nicht möglich zu > sein? Auf was manche Wert legen... (Hatte ich bei anderen Umgebungen eher selten.) Im Falle meines dsPIC33 zeigt das Debugger Fenster dieses beim Connecten an, welches durch 'Run' bzw. 'Debug' ausgelöst wird. > Einfach mal eben so ein vorhandenes .hex File kann man auch nicht > brennen? Dürfte erst gehen, wenn er den Chip erkannt hat. Aber im Prinzip ist es ein Compiler/Debugger, kein Flash tool. D.h. er ist darauf ausgelegt, das compilierte Programm zu flashen. Dann wäre da noch: 'Project Configuration' -> Conf->Loading Dort kann man auch ein eigenes hex-File angeben, statt des übersetzten Files. > Die Möglichkeit ein .hex zu Importieren habe ich gefunden, wenn das > alles ist geht es ja kaum noch umständlicher. Warum nicht die MPLAB-X IPE? Wurde bei mir zusammen mit dem Compiler/Debugger installiert und ist meines Wissens das Falsh Tool, was Du suchst. > Und hatten die PICs nicht auch Fuse-Bits zum einstellen? Wo werden die > eingestellt? Wo kann ich sehen wie ein bereits vorhander PIC eingestellt > ist? Zum sehen: Windows->PIC Memory Views Ich setze diese im Source code. (dsPic33) Dann kann ich verschiedene Projekte bearbeiten ohne dass mir diese verlorengehen.
Ich hab auch mit den 16-Bit PICs gearbeitet, öfter als Hobby aber auch auf Arbeit. Dieser ganze Hick Hack mit dem Compiler und der Optimierung hat mich dabei auch gestört. Ich würde deshalb jedem empfehlen, lieber gleich ein Cortex M3 oder M4 von z.B. ST zu verwenden. STM32F4xx finde ich persönlich am besten, wenn mal mehr Leistung gefragt ist als ein AVR bieten kann.
Ich merke schon ich hinke hier arg hinterher... :-( Rudolph schrieb: >>> dass man mit dem IPE scheinbar die Fuse-Bits nicht auslesen >> Was interessieren die eigentlich die Fusebits, beim nächsten Falshen >> sind sie eh weck/überschrieben. > > Ich habe hier einen PIC16F88 in einer Schaltung und will an dem Ding mal > exemplarisch rumspielen ohne die Schaltung kaputt zu machen. > Dafür will ich auch wissen, wie der Stein jetzt konfiguriert ist. IPE: Was Du mit Fuse-Bits meinst dürfte das Configuration Memory sein und das ist im Advanced Mode zugänglich.
Rudolph schrieb: >>> dass man mit dem IPE scheinbar die Fuse-Bits nicht auslesen >> Was interessieren die eigentlich die Fusebits, beim nächsten Falshen >> sind sie eh weck/überschrieben. > > Ich habe hier einen PIC16F88 in einer Schaltung und will an dem Ding mal > exemplarisch rumspielen ohne die Schaltung kaputt zu machen. > Dafür will ich auch wissen, wie der Stein jetzt konfiguriert ist. Es gibt bei den PICs keine speziellen Fuses nach AVR-Art. Was es gibt, sind Config-Words. Die befinden sich im ganz normalen Flash, ganz hinten in den letzten Zellen und werden beim Einschalten in die Konfigurationsregister kopiert. Wenn Du also das Flash komplett ausliest, hast Du automatisch die Config Words mit dabei, ohne irgendwelche zusätzlichen Klimmzüge. Eine Sonderbehandlung wie bei AVR mit speziellen ISP-Befehlen gibts hier nicht. Ja, ich weiß. Es ist alles neu für Dich, und das Nicht-Wissen nervt Dich einfach, weil Du aktuell wenig produktiv bist. Das ist in einer fremden Umgebung normal und ändert sich automatisch, wenn Du weißt, wo die einzelnen Sachen sind und wie man die Aufgaben "richtig" angeht. Aber nur weil es Dir im Moment fremd ist, ist es nicht gleich automatisch scheiße. fchk
X4U schrieb: >> Wobei die Fuse-Bits extrem stumpf ohne jede Erklärung angezeigt werden. > > Ein wenig viel verlängt. Der Pickit ist ein Progger, kein reverse > engeneering tool. Eigentlich nicht, man kann zwar was damit einstellen, weiss aber Datenblatt nicht mal ansatzweise was man überhaupt einstellt. > Bei mir läuft es, evtl. mal neu installieren. Ist doch gerade erst neu installiert. > Was hast du mit dem Hex File eigentlich vor? Da ist doch bestenfalls der > Maschinencode und die config drin. Nichts besonders, einfach mal reinsehen. X4U schrieb: >> ich mache ein "Read", >> das läuft auch durch wie man in dem "Output" Feld sehen kann. >> Dann gehe ich auf File -> Export und muss feststellen, dass "Hex" >> ausgegraut ist. > > Dann ist evtl. die code protection gesetzt. Was siehst du denn im Hex > Fenster? Alles 00 oder FF? Das bezog sich auf das IPE welches gar kein Fenster für die Daten hat. Mit dem PICkit Programmer läuft das alles. Und nein, die Code-Protection ist nicht gesetzt. Steffen Rose schrieb: > dsPic33 und PIC16 sind schon ein großer Unterschied. Das macht zum Rumspielen nichts, das Board mit dem PIC16 habe ich halt hier, das Board mit dem dsPIC33 bekomme ich frühestens nächste Woche in die Finger wie ich heute erfahren habe. Leider ist der ebenfalls vorhandene Quellcode für den PIC16 nicht mit MPLAB kompatibel und ich habe sogar Zweifel ob der zu dem Board passt. Naja, ungepflegtes Open-Source Projekt halt, wenn man schon was geschenkt bekommt sollte man sich nicht so laut beschweren. :-) Aber einfach mal durchkompilieren und ins Board flashen ist nicht. Frank K. schrieb: > Es gibt bei den PICs keine speziellen Fuses nach AVR-Art. Was es gibt, > sind Config-Words. Die befinden sich im ganz normalen Flash, ganz hinten > in den letzten Zellen und werden beim Einschalten in die > Konfigurationsregister kopiert. Ah, okay. Frank K. schrieb: > Ja, ich weiß. Es ist alles neu für Dich, und das Nicht-Wissen nervt Dich > einfach, weil Du aktuell wenig produktiv bist. Das ist in einer fremden > Umgebung normal und ändert sich automatisch, wenn Du weißt, wo die > einzelnen Sachen sind und wie man die Aufgaben "richtig" angeht. Aber > nur weil es Dir im Moment fremd ist, ist es nicht gleich automatisch > scheiße. Nö, das nervt mich gerade nicht weil ich noch gar nicht versuche irgendwie produktiv zu sein, ich spiele da nur so mit rum. Erstmal ein bisschen umschauen und durchschütteln was so geht, so nebenbei. Dann werde ich mir mal ansehen was das Programm nach der Beschreibung machen sollte und ein bisschen darin stochern was es wirklich macht.
Rudolph schrieb: > X4U schrieb: >>> ich mache ein "Read", >>> das läuft auch durch wie man in dem "Output" Feld sehen kann. >>> Dann gehe ich auf File -> Export und muss feststellen, dass "Hex" >>> ausgegraut ist. >> >> Dann ist evtl. die code protection gesetzt. Was siehst du denn im Hex >> Fenster? Alles 00 oder FF? > > Das bezog sich auf das IPE welches gar kein Fenster für die Daten hat. Advanced Mode Evtl. ein paar Häkchen in Production Mode setzen. Dann gibts View -> Show Memory. In dem View kann man dann Program Memory usw. auswählen.
Rudolph schrieb: >>> Wobei die Fuse-Bits extrem stumpf ohne jede Erklärung angezeigt werden. >> >> Ein wenig viel verlängt. Der Pickit ist ein Progger, kein reverse >> engeneering tool. > > Eigentlich nicht, man kann zwar was damit einstellen, weiss aber > Datenblatt nicht mal ansatzweise was man überhaupt einstellt. Meiner einer hat das noch nie beachtet. Die Configuration wird ja aus dem Hex file übernommen. Das setting machst du in der IDE. Das bitfiddeln mit dem Progger ist eher eine Notlösung. Für einen newbie sicher nicht erste Wahl. Schau doch mal den auf den Code configurator. Selber hab ich ihn aber noch nicht genutzt. http://www.microchip.com/pagehandler/en_us/devtools/code_configurator/home.html > Naja, ungepflegtes Open-Source Projekt halt, wenn man schon was > geschenkt bekommt sollte man sich nicht so laut beschweren. :-) > Aber einfach mal durchkompilieren und ins Board flashen ist nicht. Nach meiner eher leidvollen Erfahrung macht es mehr Sinn sich das selbst "from scratch" anzueignen. Aber ich kenne deinen Code halt nicht.
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.