Ich spiele ein wenig mit einem dsPIC33FJ64 rum, wie bringt man die zum
Schlafen?
Also konkret habe ich ein deutlich dickeres Programm das ich nicht
posten kann und das nur in Interrupts und DMA arbeitet, die Schleife in
der main() ist aber leer und das halte ich für keine gute Idee.
Sowas hier verbrennt ja maximal Taktzyklen:
1
int main(void)
2
{
3
4
....
5
6
while(1);
7
}
Sowas in der Art habe ich als Base-Line und mal den Strom gemessen.
Dann habe ich mal versucht, den Controller in Idle zu bringen:
1
int main(void)
2
{
3
4
....
5
6
while(1)
7
{
8
Idle();
9
}
10
11
}
Was man halt so an Makros findet.
Nur, an der Strom-Aufnahme ändert das rein garnichts.
Okay, vielleicht kommt das ja wirklich nie aus den Interrupts raus,
also mal mit Sleep probieren:
1
int main(void)
2
{
3
4
....
5
6
while(1)
7
{
8
Sleep();
9
}
10
11
}
Das müsste eigentlich den Controller lahm legen weil dann kein Takt mehr
da ist, sowas wie ein Timer-IRQ kann dann nicht mehr passieren, oder ADC
oder sonst was.
Das ändert nur ebenso wenig was an der Strom-Aufnahme was mir den
Verdacht aufdrängt, dass das so garnicht funktioniert. :-)
Nur, wie macht man das dann richtig?
Die Application-Note von Microchip hat mich nicht weiter gebracht weil
dort keine konkrete Implementierung beschrieben ist.
Das Idle() und Sleep() sind auch nur Makros, okay.
Das Datenblatt hat ein ganzes Kapitel zum Thema Power-Saving-Modes und
ein Dutzend Register mit denen du Takt und Peripherie abschalten kannst.
Da setzt du erst mal diverse Register und dann rufst du den PWRSAV
Maschienenbefehl auf.
Noch einer schrieb:> Das Datenblatt hat ein ganzes Kapitel zum Thema Power-Saving-Modes
Ach, echt jetzt? Da wäre ich garnicht drauf gekommen.
Das ist genau was die Idle() und Sleep() machen - scheint sich nur nicht
im mindesten auszuwirken.
Ingo schrieb:> 300g Hammer
Da bin ich bei Dir, die Datenblätter von Microchip gefallen mir bisher
garnicht.
Die IDE ist auch für die Tonne.
Genauso wie Tools wie das PICkit3.
Da suche ich vorhin verzweifelt den Fehler in meiner Verdrahtung weil
ich weder aus MPLAB-X noch aus dem IPE Kontakt zum Controller bekomme.
Nach einem Hinweis hier im Forum habe ich dann mal die alte Stand-Alone
Programmier-Anwendung benutzt und die hat den Controller sofort
gefunden.
Das geht garnicht wenn die Tools nicht funktionieren.
Rudolph R. schrieb:> Da bin ich bei Dir, die Datenblätter von Microchip gefallen mir bisher> garnicht.> Die IDE ist auch für die Tonne.> Genauso wie Tools wie das PICkit3.
Über das PICkit und die IDE kann man selbstverständlich geteileter
Meinung sein, aber die Datenblätter sind gut. Zumindest besser als jene
von ST.
Wegen dem Idle:
Du musst natürlich schon schauen, wie lange der wirklich im Idle ist und
wie lange er in deinen Interrupts herumrödelt. Wenn er nie idled, dann
sparst du natürlich auch keinen Strom.
Dazu gibts einen Trick: Setz dir zwei identische Timer auf, einer zählt
im Idle, einer nicht (ist nur ein Flag in der Config des Timers, dass
setzten muss). Wenn du die vergleichst, bekommst du einen Wert heraus,
wie lange der µC im Idle ist. So eine CPU-Load Anzeige halt.
Und nimm ein Oszi + Shunt zum Messen der Stromaufnahme, kein Multimeter.
Die Stromaufnahme eines controllers mit idle ist nicht wirklich
konstant. Nur ein wirklich hochwertiges Multimeter oder ein Oszilloskop
werden da was sinnvolles anzeigen.
WehOhWeh schrieb:>aber die Datenblätter sind gut.
Ich habe ja auch nicht geschrieben, dass die Datenblätter schlecht sind,
sondern das ich sie schlecht finde, wichtiger Unterschied.
> Wenn er nie idled, dann sparst du natürlich auch keinen Strom.
Aus dem Grund bin ich ja auch auf Sleep gegangen, da sollte der
Controller nicht rauskommen können.
> Und nimm ein Oszi + Shunt zum Messen der Stromaufnahme,
An dem Punkt ist mir die absolute Strom-Aufnahme egal und ich schaue mir
das nur auf dem Netzteil an.
Wenn der Unterschied zwischen 100%, Idle und Sleep nicht auf dem
Netzteil zu sehen ist dann wären die Power-Save Modi ihren Namen nicht
wert.
Hallo,
du musst die Peripherie über die PMDxbits abschalten.
Achte darauf, dass du beim wake up die Configbits der abgeschalteten
Peripherie wieder konfigurieren musst!
So ist es bei meinem Programm möglich von 400mW auf 20mW zu kommen.
Rudolph R. schrieb:> die Datenblätter von Microchip gefallen mir bisher> garnicht.> Die IDE ist auch für die Tonne.> Genauso wie Tools wie das PICkit3.Rudolph schrieb:> An dem Punkt ist mir die absolute Strom-Aufnahme egal und ich schaue mir> das nur auf dem Netzteil an.
Du solltest mal aufhören, über dein Werkzeug zu meckern und lernen, es
richtig zu benutzen!
Die Dokumentation von Microchip ist super. Willst du ein
Negativbeispiel, so nimm einen MSP430.
Jede IDE ist natürlich anders und gewöhnungsbedürftig. Das MplabX gibts
für lau, und dafür ists verdammt gut!
Und das PicKit3 ist vom Preis/Leistungsverhältnis auch nicht schlecht.
Ich hab schon mehr leute über den ICD3 meckern gehört, der locker das
dreifache kostet.
Wenn du dann auch noch die Stromaufnahme mit deinem Netzteil misst,
welches eine Messungenauigkeit von +-100mA haben kann, dann solltest du
dir GANZ GENAU überlegen, wo das Problem liegt.
Lern dein Equipment zu benutzen, und deine Ergebnisse werden besser!
Rudolph schrieb:> Aus dem Grund bin ich ja auch auf Sleep gegangen, da sollte der> Controller nicht rauskommen können.
Nicht ganz richtig. Viele Interrupts laufen auch im sleep, sonst wäre
das ja ziemlich sinnbefreit und müsste "headshot" oder so heißen. Laufen
tun z.B. Pinchange, diverse Timer und die RTCC.
Details findest du bei "wakeup sources".
Dazu wäre noch zu prüfen:
- Ruft der überhaupt in idle() oder sleep() wirklichwirklichecht auf?
- Sind bei deinem Projekt vielleicht einige Voraussetzungen für sleeep
nicht gegeben?
- Läuft der Watchdog?
- wird ein Interruptflag nicht zurückgesetzt?
Es kann oft sehr einfache Ursachen haben...
Rudolph R. schrieb:> Ach, echt jetzt? Da wäre ich garnicht drauf gekommen.
Okay, ich weiß wie es Dir geht, an dem Punkt war ich auch schon.
So genervt das ich vor Wut hätte platzen können.
Das hilft Dir aber nicht, bei den PICs schon garnicht.
Mit dem MPLABX und den PICKIT ist nicht alles besser geworden im
Vergleich zu MPLAB 8 und ICD, soweit korrekt.
Die Datenblätter sind eigentlich gut.
Die haben nur die Microchip Krankheit das die alles entscheidende
Information die alle Deine Probleme löst irgendwo auf 730 Seiten Family
Referenz oder 300 S. Datasheet stehen. Wenn Du alles drei mal komplett
gelesen hats wirst Du es schon finden ...
Ja, das ist krank aber tatsächlich immer noch besser als das was andere
Hersteller einem zumuten.
Die ganzen LIBs und Beispielcodes funktionieren in den überwiegenden
Fällen, manchmal aber auch nicht.
Manchmal sind Header Dateien falsch oder es funktioniert nicht für
MPLABX.
Es bleibt Dir nichts anderes als Dich ganz tief in die Register
einzulesen und Stück für Stück das zu setzen was Du verstehst.
Erstmal alles andere weglassen.
Wenn auch das nicht geht, in die Register schauen ob das wirklich
gesetzt wurde.
Manches wird nur über Beschreiben eines Registers mit Sicherheitscode +
enger Zeitablauf für das eigentliche Setzen geregelt.
Wird dazwischen ein IRQ ausgelöst oder der Compiler optimiert das
kaputt, dann wird das entprechende Register einfch kommentarlos nicht
beschrieben.
Nach solchen kleinen Gemeinheiten mußt Du bei den PICs immer schauen.
Die PICs faszinieren mich immer wieder mit ihrem Funktionsumfang, aber
das dann wirklich zum Laufen zu bekommen ist dann oft eine unsägliche
Quälerei aus Abhängigkeiten und 'eigentlich schon, aber...'
Da die bisherigen Konstruktiven Hinweise auch nur geraten waren habe ich
das vorhin mal anders ausprobiert, siehe Anhang.
Ich habe ein neues Projekt aufgemacht, eine leere Datei reingeworfen und
das bisschen was nach Basis-Konfiguration aussah aus dem alten Projekt
rüber kopiert.
Damit ist quasi keine Peripherie konfiguriert.
In der while() habe ich jetzt die drei Makros Nop(), Idle() und Sleep()
drin.
Und siehe da, wenn ich jeweils eines aktiviere erhalte ich:
Nop(): 102 mA
Idle(): 74 mA
Sleep(): 44 mA
Natürlich ist das für die ganze Platine, das macht aber nichts, man
sieht einen deutlichen Unterschied, das reicht schon.
Also ja, scheinbar war das doch der richtige Weg, das bewirkt aber als
Zusatz in der Anwendung die ich damit manipulieren wollte trotzdem
nichts.
Das Problem liegt in der Anwendung und nicht in der Methode den
Controller schlafen zu schicken.
Little Basdart schrieb:> Du solltest mal aufhören, über dein Werkzeug zu meckern und lernen, es> richtig zu benutzen!
Warum? Es war wieder nicht möglich, das Programm über MPLAB-X und
PICkit3 in den Controller zu flashen: Connection Fail
Sowas ist als Tool einfach wertlos.
Little Basdart schrieb:> Wenn du dann auch noch die Stromaufnahme mit deinem Netzteil misst,> welches eine Messungenauigkeit von +-100mA haben kann, dann solltest du> dir GANZ GENAU überlegen, wo das Problem liegt.
Warum erdreistest Du Dich, meine akzeptierte Mess-Ungenauigkeit in Frage
zu stellen welche ich nicht einmal angegeben habe?
Und es tut mir Leid wenn Dein Netzteil so schlecht ist, mein TOE 8952
ist da schon etwas präziser.
WehOhWeh schrieb:>> Aus dem Grund bin ich ja auch auf Sleep gegangen, da sollte der>> Controller nicht rauskommen können.>> Nicht ganz richtig. Viele Interrupts laufen auch im sleep, sonst wäre> das ja ziemlich sinnbefreit und müsste "headshot" oder so heißen. Laufen> tun z.B. Pinchange, diverse Timer und die RTCC.
Die Schaltung hat aber keine externen Wakeup Quellen, das habe ich nicht
dazu geschrieben.
Timer dürften auch nur welche mit asynchronem, also externen Takt,
laufen.
Michael Knoelke schrieb:> So genervt das ich vor Wut hätte platzen können.
Ich habe da jetzt Null Druck hinter, ich schaue nur so unverbindlich auf
ein älteres Projekt drauf das vielleicht oder auch nicht aufpoliert
werden könnte.
Das war mal eine Diplom-Arbeit.
Das erste was mir aufgefallen ist war die leere Schleife in der main().
Und dann der Satz, dass die Software "Interrupt gesteuert" ist.
Naja, Studenten, unter "Interrupt gesteuert" verstehe ich schon was
anders als "kommt aus dem Interrupt nie raus". :-)
Da ist auch nicht so viel dran an dem µC.
Ein CAN, zwei ADC Kanäle belegt, ein DAC am SPI, ein paar digitale
Inputs und Outputs.
Das da ein PIC drin ist sehe ich als Gelegenheit was neues zu machen.
Aber ich muss das eben nicht machen und stecke daher auch nicht soviel
Zeit da rein.
Rudolph R. schrieb:> Es war wieder nicht möglich, das Programm über MPLAB-X und> PICkit3 in den Controller zu flashen: Connection Fail
Hab gerade noch mal versucht was zu finden.
Solche Probleme sind seit mindestens 2011 bekannt und eine echte Lösung
habe ich noch nicht gefunden.
Einfach nur schlecht.
Rudolph R. schrieb:> Einfach nur schlecht.
Atmel, Microchip, STM, TI, Silabs ....
Bei jedem einzelnen ist irgendwas an den Tools, Datasheets, Chips so
kaputt das es mir die Zornesröte ins Gesicht treibt und trotzdem benutze
ich die.
Mach kein Drama daraus.
Rudolph R. schrieb:> Warum? Es war wieder nicht möglich, das Programm über MPLAB-X und> PICkit3 in den Controller zu flashen: Connection Fail>> Sowas ist als Tool einfach wertlos.
vielleicht solltest du mal die Beschaltung der Programmierschnittstelle
ueberpruefen (design guide) bevor du hier Unsinn verzapfst.
Ich habe diverse Tools und Software beinahe teaglich im Einsatz und bin
von der Zuverlaessigkeit begeistert.
PS: Die neue Version MPLABX 3.0 hat gerade beim debuggen/programmieren
nochmal deutlich an Performance zugelegt.
lg Heiner
Heiner schrieb:> vielleicht solltest du mal die Beschaltung der Programmierschnittstelle> ueberpruefen (design guide) bevor du hier Unsinn verzapfst.
Lesen und so, weiter oben steht doch, dass ich zuerst den Fehler in der
Verdrahtung gesucht habe bis ich nochmal das veraltete Standalone
Programmier-Tool ausprobiert habe, und damit kann ich den Controller
flashen.
Wie hätte ich auch sonst den Strom messen können?
Windows 7, 64 Bit, PICkit3 an einem USB-Hub mit Netzteil, USB2,
Admin-Rechte.
Und alles was von MPLAB-X kommt ist: Connection failed
Es gibt nicht mal einen Hinweis welche Verbindung gemeint ist, zum
Progger oder vom Progger zum Target.
Welcher Part davon ist jezt Unsinn?
Rudolph R. schrieb:> Welcher Part davon ist jezt Unsinn?
Das Du ungeduldig und extrem vorgespannt bist.
Ich mußte bei meinem PICkit bei der ersten Inbetriebnahme über MPLAB 8.x
die Firmware auf eine Version flashen ab der MPLABX erst damit umgehen
konnte.
Ja, das ist nicht schön, aber seit dem ist alles gut.
Microchip befindet sich gerade im Wechsel zwischen zwei Toolchains und
schleppt das alte nur soweit mit wie es sein muß obwohl das neue noch
nicht ganz läuft.
Das sorgt manchmal für Reibungsverluste, aber damit kann man leben.
Microchip schenkt Dir viel mit kostenloser Software und preiswerten
Tools ohne im Gegenzug Mondpreise für die Chips zu nehmen.
Dafür darf man auch mal den Ärger runterschlucken.
Erzähl uns doch mal bitte was Du sonst immer benutzt was so ausgereift
ist das Dich diese kleinen Ärgernisse so aus der Bahn werfen.
Michael Knoelke schrieb:> Das Du ungeduldig und extrem vorgespannt bist.
Das ist nur Deine falsche Interpretation von dem was ich schreibe.
> Ich mußte bei meinem PICkit bei der ersten Inbetriebnahme über MPLAB 8.x> die Firmware auf eine Version flashen ab der MPLABX erst damit umgehen> konnte.> Ja, das ist nicht schön, aber seit dem ist alles gut.
Das ist ein interessanter Hinweis dem ich nachgehen werde, aber dieser
Hinweis sollte aus MPLAB-X oder dem IPE kommen.
> Microchip befindet sich gerade im Wechsel zwischen zwei Toolchains und> schleppt das alte nur soweit mit wie es sein muß obwohl das neue noch> nicht ganz läuft.
Ähem, MPLAB-X ist inzwischen in der dritten Version angekommen und wie
man nachlesen kann haben seit mindestens 2011 verschiedene Anwender
Probleme mit dem PICkit3.
Zugriff auf ein ICD2 hätte ich auch gehabt, das wurde aber mit MPLAB-X
begraben, das ICD3 war mir zum Rumspielen zu teuer.
Rudolph R. schrieb:> Ähem, MPLAB-X ist inzwischen in der dritten Version angekommen
Ja, wird langsam benutzbar aber der Wechsel wird sich wohl auch noch
über ein paar weitere Jahre hinziehen.
Ich war auch nicht glücklich darüber das ich meinen ICD 2 wegwerfen
kann, aber ich sehe ein das die alten Tools an einem Punkt angekommen
waren an dem Micrchip ein paar alte Zöpfe abschneiden mußte.
Ich würde gerne behauten das die anderen das besser machen, aber von STM
gibt es gleich mal garnichts was derart komplett wäre und Atmel hat sich
mit seinem tollen neuen und vollkommen komatösen AVR Studio auch keine
Freunde gemacht.
Mein 350$ AVR ONE der mein universeller Problemlöser sein sollte bekommt
teilweise Breakpoints nicht mit obwohl nachgewiesener Maßen (PIN debug)
der Code durchlaufen wurde. Auch sonst hat der magische Aussetzer die
den eigentlich wertlos machen.
STM ist nur nutzbar weil ich eine kommerzielle IDE (IAR) verwende und
die Finger von allem lasse was ausser Chip und Doku von STM kommt.
Renesas etc. hat da gleich mal nicht nötig sich überhaupt um kleine
Entwickler zu bemühen.
Die MC51 Silabs haben 'von hinten durch die Brust ins Auge' Hardware on
Board, der dabeiliegende Keil fängt an echt komische Moves zu machen
wenn es an die Kapazitätsgrenzen geht und die IDE ist echt kranker
absturzanfälliger Kram.
Ich habe auch schon oft Galle gespuckt bei den PICs, aber es nützt ja
nix.
Nochmal: Was kennst Du perfektes in diesem Bereich ?
Rudolph R. schrieb:> Ähem, MPLAB-X ist inzwischen in der dritten Version angekommen und wie> man nachlesen kann haben seit mindestens 2011 verschiedene Anwender> Probleme mit dem PICkit3.
Wie man hier in diesem Forum täglich lesen kann, haben verschiedene User
immer mal wieder Probleme mit ihrem AVR ISP Programmer. Meistens
Anfänger in ihrem Bereich. Über die vielen 10000 Anwender, die keine
Probleme haben, liest man nichts.
Im wirklichen Leben ist es genauso. Unfälle stehen in den Nachrichten,
aber die vielen problemlosen Auto-/Bahn-/Etceterafahrten bleiben
allesamt unerwähnt.
fchk
Michael Knoelke schrieb:> Nochmal: Was kennst Du perfektes in diesem Bereich ?
Wofür überhaupt vergleichen?
Die kochen alle nur mit Wasser, manche mit Wasser aus dem Fluss, andere
mit Wasser aus dem Teich.
Die Aussage, bei XXX funktioniert das viel besser hift überhaupt nicht
bei der Lösung des Problems.
Das andere es hinbekommen aus der eigenen IDE heraus mit den eigenen
Tools die eigenen Mikro-Controller zu flashen schürt allerdings eine
gewisse Erwartungs-Haltung. :-)
Rudolph R. schrieb:> WehOhWeh schrieb:>>> Aus dem Grund bin ich ja auch auf Sleep gegangen, da sollte der>>> Controller nicht rauskommen können.>>>> Nicht ganz richtig. Viele Interrupts laufen auch im sleep, sonst wäre>> das ja ziemlich sinnbefreit und müsste "headshot" oder so heißen. Laufen>> tun z.B. Pinchange, diverse Timer und die RTCC.>> Die Schaltung hat aber keine externen Wakeup Quellen, das habe ich nicht> dazu geschrieben.> Timer dürften auch nur welche mit asynchronem, also externen Takt,> laufen.
Lt. Datenblatt deines PIC kann jeder Interrupt den sleep-Modus beenden.
Sollte ein Flag nicht zurückgesetzt werden, würde er somit nie schlafen.
Das Projekt kann - dank Nested Interrupts - trotzdem funktionieren.
Ich würd mal folgendes probieren:
- Mal einen Breakpoint auf sleep() setzen und die Flags anschauen (IFSx
Register).
Natürlich kann auch der Watchdog noch Probleme machen.
Man könnte auch einfach alle Interrupts vor dem sleep() ausschalten,
aber das macht keinen Sinn, höchsten für einen Test.
Das alles gilt selbstverständlich auch für idle().
WehOhWeh schrieb:> Ich würd mal folgendes probieren:
Erstmal habe ich ja, was ich wissen wollte, ein in die bisher leere
while(1) eingefügtes Idle() oder Sleep() wirkt sich nicht aus.
Grundsätzlich funktioniert es aber den Controller mit Idle() oder
Sleep() schlafen zu schicken, die Vorgehensweise war richtig.
Der nächste Schritt wird dann sein einen Überblick zu bekommen was die
Software überhaupt macht, dann wird sich schon klären, warum die
scheinbar nie aus dem Interrupts raus kommt.
Na okay, vorher vielleicht noch, den PICkit3 zum Laufen bekommen. :-)
Rudolph R. schrieb:> Die Aussage, bei XXX funktioniert das viel besser
Hat keiner gesagt.
Die Aussage war eher: Bei allen anderen ist das auch nicht besser.
Rudolph R. schrieb:> Das andere es hinbekommen aus der eigenen IDE heraus mit den eigenen> Tools die eigenen Mikro-Controller zu flashen schürt allerdings eine> gewisse Erwartungs-Haltung. :-)
Und wer schafft das ?
Ich meine, mit allen Mikrocontroller und allen Tools auf einer rein
kostenlosen Basis, denn damit vergleichst Du gerade.
Rudolph R. schrieb:> Wofür überhaupt vergleichen?
Weil das bescheidener macht sich der Realität der vergleichbaren
Toolchains zu stellen.
Man hat immer die Wahl zur Keil, IAR, Cosmic, Raisonance etc. zu gehen,
einen hohen Betrag über den Tresen zu schieben und dann auch einen guten
Support zu erwarten.
Auch da wird man des öfteren hören das der tolle neue Chip von
Hersteller XY noch nicht voll unterstützt wird und man gerne auf das
nächste kostenpflichtige Update warten kann oder für eine Phantastillion
in kleinen gebrauchten Scheinen auch bevorzugt behandelt wird.
Nochmal: Ich finde das auch nicht schön, aber das ist kein Microchip
Problem, sondern eher ein allgemeines. Die kostenlosen Tools sind ein
Marketing Werkzeug. Man kann dabei bleiben und sich dem unvermeidlichen
fügen, selber ein open source Werkzeug unterstützen oder jemanden dafür
bezahlen das er sich bereits die Mühe gemacht hat.
Offensichtlich gibt es für die von Dir beobachteten Probleme einen
Workarround mit denen alle leben konnten die den dsPIC / PICkit 3
verwenden, denn sonst wären die Verkaufszahlen bei null und die
Produktlinien eingestellt.
Ich werde jetzt also den Pfad der Diplomatie verlassen und es mit dem
Worten des allseits geschätzen Little Basdart ausdrücken:
> Du solltest mal aufhören, über dein Werkzeug zu meckern und lernen, es> richtig zu benutzen!
Sieh an, heute morgen konte MPLAB IDE v3.00 doch mit dem PICkit3
kommunizieren, alles gleich, bis runter zum USB-Kabel und dem Anschluss.
Dann habe ich den Controller eingestellt, auf "Manual Download Firmware"
gestellt und es wurde "Firmware type....dsPIC33F/24F/24H" gebrannt.
Connecting to MPLAB PICkit 3...
Currently loaded firmware on PICkit 3
Firmware Suite Version.....01.37.15
Firmware type..............dsPIC33F/24F/24H
Target voltage detected
Target device dsPIC33FJ64GP706A found.
Device ID Revision = 300a
Und jetzt klappt es auch aus MPLAB-X v3 heraus zu flashen.
War das mein Fehler, habe ich das Werkzeug falsch benutzt?
Nein, die Software hat versagt, sowohl beim Zugriff auf das Tool als
auch bei der erzeugten Fehler-Meldung.
Ich bin nicht mal sicher, ob ich erfolgreich einen Workaround benutzt
habe oder ob das heute morgen nicht zufällig einfach so funktioniert
hat.
Also ich kann deinen Ärger mit den Microchip Tools überhaupt nicht
verstehen. Ich verwende das ICD3 sowie das Pickit3 täglich mit MPLAB8
und MPLABX zusammen mit allen erdenklichen Pictypen (PIC16 bis PIC32).
Das funktioniert alles wunderbar, sofern die Referenzgrundbeschaltung
des Pics von Microchip (siehe Datenblatt) verwendet wird. Das
Programmierkabel sollte jedoch kurz gehalten werden und kein USB-Hub
verwenden! Auch der schnelle Wechsel zwischen IDEs und unterschiedlichen
Pics funktioniert tadellos. Ich habe sogar oft das MPLABX doppelt
geöffnet und kann das gleiche Programmiergerät aus beiden IDEs
verwenden. Ganz selten muss man mal die USB-Verbindung trennen, aber das
habe ich schon bei allen Herstellern erlebt.
Pic User schrieb:> Also ich kann deinen Ärger mit den Microchip Tools überhaupt nicht> verstehen.
Tja, ist aber so passiert, was soll ich sagen, MPLABX ist einfach mal
dran gescheitert dem PICkit3 die richtige Firmware zu verpassen.
Und dann hat es jetzt wieder einwandfrei funktioniert eine Platine mit
einem PIC16F88 anzuschliessen, die Firmware wurde umgeflasht, läuft.
Ich hoffe nur, das bleibt jetzt so. :-)
Thread beobachten
Seitenaufteilung abschalten