Bitte um Hilfe - Pickit 3 erkennt PIC18F45K80 nicht

Sollte VCAP nicht 1uF sein ?
Warum die 47 Ohm Widerstände in der Leitung ?
Versuchsweise mal rausnehmen.

Stefan schrieb:
> Sollte VCAP nicht 1uF sein ?
> Warum die 47 Ohm Widerstände in der Leitung ?
> Versuchsweise mal rausnehmen.

Stimmt, VCAP hab ich tatsächlich viel zu klein gewählt, sollte 
tatsächlich 10uF sein.

Die 47 Ohm muss ich drinnen lassen, um ausreichend gegen ESD geschützt 
zu sein. Das Datenblatt schreibt dazu, dass alles unter 100 Ohm 
unproblematisch ist.

Gerhard O. schrieb:
> Für den K80 muss man angeblich mindestens MPLAB V8.53 verwenden.

Ich hab vergessen zu erwähnen, dass ich MPLAB nicht verwende. Ich habs 
zu Beginn mal versucht, aber ich bin nicht zusammenkommen. Ich 
programmiere und kompiliere daher in GCB. Die HEX-File spiele ich dann 
mit der Pickit 3 Software auf den Controller. So hat‘s bisher bei all 
meinen anderen Projekten auch geklappt. Nur der 18F45K80 will nicht.

Müsste es eigentlich funktionieren, wenn ich den 18f45k80 direkt an den 
Pickit, ohne zusätzliche Bauteile anschließe?? So hab ichs nämlich mit 
dem nagelneuen gemacht.

Gerhard O. schrieb:
> 1KOHM zwischen Vdd und MCLR ist zu niedrig. Microchip empfiehlt 4.7-10K.
> Auch aufpassen dass kein C an VCLR ist. Siehe Figure 2-5 in der
> unterstehenden Link.

Stimmt, 1K ist laut Datenblatt zu wenig. Da hab ich mich aber auch 
vertan, in Wirklichkeit hab ich da eh einen 100k drinnen, was wiederum 
zu hoch ist, aber zumindest der sollte dann nicht das Problem sein. 
Trotzdem um auch das auszuschließen, wird der morgen gegen einen 10k 
getauscht.

Am MCLR sind keinerlei Cs beschalten.

Im Anhang ist ein Ausschnitt der ICSP-Beschaltung.

Hallo Gerhard,

vielen Dank für Deine Antworten.
Ich werde das mit den Vorgeschlagenen Programmen probieren.

Gerhard O. schrieb:
> Der Schalter S1 mit den 1K nach Masse gefällt mir nicht. Auf alle Fälle
> beim Anschluß des PK3 nicht den Schalter auf die beiden Leitungen zum
> PK3 legen. Vermeide Positionen 2/4.

Anders konnte ich es aufgrund zu weniger I/Os nicht lösen. Ich hab‘s mir 
aber durchgerechnet. Alleine vom Strom und der Belastbarkeit, sind die 
Ausgänge vom Pickit als auch vom uC stark genug um gegen den 1K 
Widerstand zu treiben.

Normalerweise werde nur ich derjenige sein werde, der Firmware Updates 
durchführt. Ich selbst kann und werde mich daran halten nur bei z.B. 
Adresse 0 zu programmieren. Trotzdem werde ich es auch bei Adresse F 
testen um die Funktionalität im Worst Case ebenfalls zu erfahren. Wie 
gesagt, der resultierende Stromfluss wird dem Pickit schon mal nix 
ausmachen.

Hallo Gerhard,

Gerhard O. schrieb:
> Prinzipiell könntest Du Dir übrigens drei IO Pins einsparen wenn Du den
> Schalter als Widerstandsspannungsteiler ausführst und den AN8 als Analog
> Eingang.

Lustig, mir wurde tatsächlich auch bereits der Gedanke an etwas 
ähnliches, nämlich ein R2R Netzwerk nahegelegt.
R2R geht natürlich nicht, da es meines Wissens nach keine 0...F 
Drehcodierschalter mit High/Low-Ausgang gibt, was definitiv notwendig 
wäre.

Aber, so habe ich damals darauf geantwortet.
Darin ist auch der Grund, weshalb ich diesen Ansatz nicht weiter 
verfolgt habe.

> Oder man nimmt R2R für das Einlesen von 4 Bits am ADC.

An sowas ähnliches dachte ich auch.
Geht aber nur als Spannungsteiler mit dazuschaltbaren Widerständen.
Dabei würde ich einen exponentiellen Spannungsverlauf für die einzelnen
Adressen erhalten, und dass könnte ein Problem werden (Siehe weiter
unten), weshalb ich die Idee letztendlich verworfen habe.

Realisiert hätte ich es so:

10k als PullUp.
und am Drehcodierschalter folgende Werte schaltbar gegen Masse:
Bit 0 2k2
Bit 1 3k3
Bit 2 4k7
Bit 3 6k8

Daraus ergibt sich ein variabler Spannungsteiler mit folgenden
Verhältnissen.

Adresse   -   Spannungsteiler
F         -   10k : 895R
E         -   10k : 1k227
D         -   10k : 1k508

usw.

Die Analogspannungen würden wie folgt aussehen:

Adresse    -   Spannung
F          -   0,4107...V
E          -   0,5019...V
D          -   0,6552...V

Zwischen den beiden größten Verhältnissen ergibt sich rechnerisch der
geringste Spannungssprung das wären dann zwischen Adresse F und E nur
91,2mV

Das könnte ich zwar bereits mit einem 8 Bit A/D-Wandler ausreichend
genau abfragen, allerdings wird die Adresse des Moduls unmittelbar nach
Einschalten der gesamten Anlage abgefragt und gespeichert. Die ganzen
Ventile die da Schalten und Motoren die sich in dem Moment drehen, der
Hauptcontroller der bootet, ... über all diese Einflüsse auf meine
dadurch vielleicht geringfügig schwankende 5 Volt Versorgung, von den
EMV- Effekten mal ganz abgesehen, wollte ich echt nicht nachdenken. (Die
gesamte Anlage wird dummerweise auch aus einem gemeinsamen 24V Trafo
versorgt) Einfach die Startroutine meines Controllers zu verzögern war
mir da zu wenig Sicherheit und alles andere hätte, noch zusätzlich zum
Programmieraufwand der Min/Max-Spannungs-array der Adressen, mehr
Aufwand bereitet, als die jetzige Lösung.

Ich war einfach zu faul, mich auf weitere Problemstellungen einzulassen 
:)

Gerhard O. schrieb:
> Fast habe ich es vergessen: Den PK3 unbedingt die Vdd sehen zu lassen.
> Also nicht vergessen mit anzuschließen. Ohne Vdd funktioniert das PK3 IO
> nicht:

Darauf habe ich noch vergessen zu antworten:

Auf die VDD hab ich aber tatsächlich nicht vergessen.
für all meine Module verwende ich ein Programmierkabel, welches VDD und 
VSS vom Target mit dem Pickit verbindet. Entweder, wie Du richtig 
angemerkt hast, um die VDD zu messen, oder wie auch oft in meinem Fall, 
den Controller auch ohne Modulversorgung zum Programmieren zu bestromen.

Gerhard O. schrieb:
> Normalerweise sollten ja alle Leistungstreiber sich im Reset Zustand
> befinden und nicht automatisch anlaufen.

Für die Endstufen auf meinen Modulen ist diese Bedingung auch erfüllt. 
Wie sich das mit den anderen verbauten Teilen, welche nicht aus meinem 
Hause stammen verhält, könnte ich zwar erheben, nachdem sich das Setup 
allerdings ohne dass ich davon Kenntnis erlange immer wieder ändern 
wird, muss ich auf maximalen Störabstand spielen.

Gerhard O. schrieb:
> Sonst wäre extra IO mittels SPI und Schiebe-Register denkbar.

Auch daran habe ich gedacht.
Aus Platzgründen - in Wirklichkeit hätt ich's aber schon irgendwo 
untergebracht - und weil der ICSP-Port NUR beim Raufspielen der Firmware 
(also alle paar Jahre mal, wenn die Module zurückkommen und ein Update 
benötigen) verwendet wird, war eine Doppelverwendung in dem Bereich 
naheliegender. Nachdem ich obendrein einen negativen Einfluss auf die 
ICSP-Funktionalität nahezu ausschließe hab ich mich nicht weiter um eine 
alternative Lösung bemüht.

Gerhard O. schrieb:
> Ist ja eigentlich komisch, dass der K80 so viele Zicken macht. Mein
> damaliges Projekt mit dem K80 lief auf Anhieb mit dem ICD2 und jetzt mit
> PK3 auch getestet.

Was mir zwischenzeitlich noch aufgefallen ist. Ich verwende den Pickit 3 
standalone mit der Software "PICkit™ 3 Programming App and Scripting 
Tool V3.10" Diese wurde mittlerweile durch IPE ersetzt. Auf irgendeiner 
Seite fand ich dann noch eine nicht offizielle Liste aller unterstützten 
µCs und der 18F45K80 war nicht vertreten. Ich hoffe mal, dass es nur 
daran liegt, dann sollte ich nämlich bei der Umsetzung Deines 
Vorschlages erfolgreich sein.

Gerhard O. schrieb:
> Berichte später bezüglich PK3 wenn Du zum Testen Gelegenheit
> hattest.

Sehr gerne … das wird aber erst morgen Abend geschehen, vorher komm ich 
leider nicht dazu.


Gerhard O. schrieb:
> P.S. Scheinst auch ein Österreicher zu sein wie ich sehe;-)

Normalerweise verrät mich sonst immer mein Dialekt.
Ich nehme an, diesmal war es mein Versehen, dass ich beim Usernamen 
meine E-Mailadresse angab :)
Ich kann das wohl nicht mehr ändern, aber vielleicht kann es ein 
Moderator für mich erledigen, nicht dass mich auf meiner neuen 
E-Mailadresse gleich unzählige Spambots über die neuesten Produkte aus 
schlüpfrigem Hause informieren.

Aber ja, ich bin Steirer - Grazer genauer gesagt.

LG
Christian

Das ist übrigens das Modul um welches es geht.

Vielen Dank Gerhard für Deine Grandiose Hilfe!!

Da muss es dann einfach klappen.
Wie gesagt, ich werde es morgen Abend mal testen und Dir hinterher 
berichten.

Du bist schon der zweite Exösterreicher den ich in den letzten Wochen 
kennenlernte und welcher dorthin verzogen ist. Also nicht genau dort, 
aber eben dasselbe Land.

Hallo Gerhard,

So, wie versprochen kommt hier nun ein Update.

Zunächst mal, JA, mittlerweile hat der Verbund geklappt.

Eigentlich schon fast peinlich, zugeben zu müssen, dass es ein ganz 
banaler
Grund war, warum es nicht funktionierte. So wie in einem meiner letzten 
Posts bereits erwähnt, keimte in mir die Vermutung, dass die Software, 
mit welcher ich arbeitete, den 18F45K80 nicht unterstützt.

Und so war es letztendlich dann auch. Die Software kannte wohl die 
18F_K_ Produktfamilie, das Familienmitglied 45K80 allerdings schon nicht 
mehr. Da es den 45K80 ja schon einige Jahre am Markt gibt, kam mir diese 
Ursache zunächst nicht in den Sinn.

mit IPE klappte es dann!!

Vielen Dank für Deine tolle Hilfe!!

Gerhard O. schrieb:
> Ist eigentlich doch
> etwas überraschend weil ich mir die BCB Sachen und Device Liste
> durchgesehen hatte un der F45K80 darin vor kam und mir nichts
> Ungewöhnliches dabei gedacht habe. BCB hatte offensichtlich mit dem
> Kompilieren selber kein Problem. War dann nur die Programmier-SW für den
> PK3 die den K80 nicht (richtig) unterstützte.

Wenn Du mit BCB GCB (Great Cow Basic) meinst, dann reden wir vom 
gleichen. Es stimmt, dass der 45K80 in der device list vorhanden ist. Es 
funktioniert auch, ihn zu programmieren, wenngleich man sich zumindest 
bei diesem µC mit einigen Compilerproblemen herumschlagen muss. Was zwar 
lästig, aber nicht weiter schlimm ist, funktioniert beispielsweise die 
implementierte Basicsyntax zum Beispiel HPWM X, X, X nicht richtig (das 
Problem hab ich gerade mit dieser Funktion) umschiff ich das ganz 
einfach, indem ich halt das Datenblatt zur Hand nehme und selbst die 
Register bearbeite, die ich dazu brauche.

Gerhard O. schrieb:
> Es ist auch möglich, daß da irgendwo ein kleiner Fehler in den
> Programmierdateien existiert.

Nö, das Problem war tatsächlich nur, dass der 45K80 nicht unterstützt 
wurde, und zwar weil es von Haus aus vermutlich nicht vorgesehen war. 
Die Software die mitunter beim PK 3 dabei war, wurde von der IPE ersetzt 
und wurde seither ziemlich sicher nicht mehr erweitert. Sie funktioniert 
also noch für die Controller die vor dem launch von IPE schon 
unterstützt wurden. Alles was zu diesem Zeitpunkt nicht berücksichtigt 
war, blieb auch weiterhin unberücksichtigt.

Gerhard O. schrieb:
> Wie findest Du übrigens BCB? Läßt sich damit gut arbeiten?

Ich persönlich arbeite gerne mit GCB.
Es hat mir vor etwa einem Jahr bei einem zeitkritischen Projekt den Hals 
gerettet. Ich hatte damals von Programmieren nicht die geringste Ahnung. 
Mein Programmierer den ich zur Programmierung meiner Module hatte fuhr 
in den Urlaub ohne dass ich vorher den Quellcode bekam :(. Mit der guten 
Dokumentation und der intuitiven Schreibweise gelang es mir, mir von 
Freitagmitternacht bis Montagmittag Basic ausreichend selbst 
beizubringen, damit ich mir so den gesamten Quellcode empirisch 
zusammenzustöpseln und den damaligen Auftrag fristgerecht fertig machen 
konnte.

Natürlich ist es halt "nur" Baisc. Langfristig will ich jedenfalls auf C 
umsteigen, aber im Moment hab ich nicht die Zeit, mir auch noch C 
ausreichend gut selbst beizubringen.

Vielen Dank!!
Dir auch alles Gute!!