Hallo Leute, ich brauche Eure Hilfe. Ich hab ein Modul fix fertig aufgebaut, bei welchem ich den PIC 18F45K80 verwende. Heute habe ich versucht, zu Testzwecken ein kleines Programm raufzuladen welches die StatusLED (diese hängt direkt auf RB0) blinken lassen soll. Zum Programmieren hab ich auf dem Modul einen eigenen ICSP-Stecker vorgesehen. MCLR, PGC, PGD wurden über 47 Ohm Widerstände auf den Stecker gelegt. MCLR bekam noch einen 1k PullUp, da dieser auch anderweitig benötigt wird. Während des Programmierens sind die ICSP-Pins definitiv vom Rest der Schaltung getrennt. Die empfohlenen Mindestbeschaltung des µC habe ich eingehalten - sogar der VDDCORE/VCAP hat seinen 100nF C bekommen. Das Problem nun ist, dass der Pickit 3 meine MCU nicht erkennt. (Fehlermeldung: No device detected.) Um auszuschließen, dass evtl der µC das Zeitliche gesegnet hat, habe ich einen anderen (nagelneuen) direkt an meinen Programmer angeschlossen ... das selbe Problem. Um weiters auszuschließen, dass eventuell der Pickit 3 kaputt is, habe ich mal ein paar andere µC zu programmieren versucht. 12F675 - ging einwandfrei 16F723 - ging einwandfrei Bei meinem Pickit 3 handelt es sich um einen Originalen von Microchip, gekauft etwa vor einem Jahr und recht selten verwendet. Als Software verwende ich PICkit 3 V3.10 Eingestellt habe ich die 18F_K_ Device Family Sollte doch eigentlich alles passen, oder hab ich irgendetwas übersehen?? Vielen Dank!! LG Christian
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. Falls Du nicht das PicKIt3 Manual hast, hier ist der Link dazu: https://ww1.microchip.com/downloads/en/DeviceDoc/51795B.pdf Ich habe vor ein paar Jahren auch mit dem K80 und ICD2 gearbeitet. Dazu brauchte man beim ICD2 einen Adapter um die Vpp Spannung von 13V auf 8.5V zu erniedrigen. (Widerstand und TL431 auf 8,5V programmiert). Das ist beim PicKit3 nicht notwendig. Versuche mal die Vpp Spannung bei Programmieren zu messen. Beim K80 muss sie im angesprochenen Zustand um 8.5-9V liegen. Für den K80 muss man angeblich mindestens MPLAB V8.53 verwenden. Versuche es mal. Wenn nicht klappt melde Dich wieder und ich werde meine alte Board suchen und ausprobieren. Ich arbeitete damals mit MPLAB 8.92. Allerdings habe ich auf der Bord nur die 6-poligen RJ12 Buchse für den ICD2 drauf. Da müsste ich was für den Pickit3 basteln. Viel Erfolg, Gerhard
Sollte VCAP nicht 1uF sein ? Warum die 47 Ohm Widerstände in der Leitung ? Versuchsweise mal rausnehmen.
Nachtrag: Ich habe meine Bord mit einem 18F46K80 am PicKit3 und ICD2 (mit AC164112 Adapter) unter MPLAB V8.92 angeschlossen und es funktionierte alles. Das ICD3 funktioniert allerdings nicht unter MPLAB V8.92 (W10X64). Unter MPLAB X IPE funktionieren sowohl das PicKit3 und ICD3.
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.
Angehängte Dateien:
-
ICSP-Beschaltung.png
14 KB
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.
Also, wenn ich Du wäre;-) würde ich jetzt MPLAB V8.92 oder die neueste X IPE UND Driver Switcher installieren und testen ob es damit geht. Das wäre prinzipiell die Referenz Konfigurierung vom Hersteller. Erstens, zeigen die Programme den Zustand der Kommunikation vom PC mit dem PK3 an und auch ob die ID vom uC korrekt ausgelesen werden kann. Allerdings kann ich aus Deinen Beiträgen nicht entnehmen ob Windows oder ein Linux bei Dir im Einsatz ist. 100K am Vclr/Vpp Pin sollten bezüglich Programmierzugang nichts ausmachen und lediglich die Störsicherheit der Gesamtschaltung verschlechtern. Zum Glück kann man die größeren PICs nicht wie AVRs verfusen. Die 47 Ohm an den PGC/PGD sollten wie schon erwähnt nichts ausmachen. Sonst fällt mir im Augenblick nichts ein und es ist Zeit für Frühstück und Kaffee;-) Nachtrag: 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.
:
Bearbeitet durch User
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 Christian, Christian schrieb: > Hallo Gerhard, > > vielen Dank für Deine Antworten. > Ich werde das mit den Vorgeschlagenen Programmen probieren. Gut! Bin mal gespannt was die MPLAB SW von dem Ganzen hält;-) > > 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. Da habe ich deswegen noch nie nachgeschaut. Aber trotzdem ist es immer gut sich wie im PicKit3 User Manual an deren Hinweisen zu richten. Prinzipiell könntest Du Dir übrigens drei IO Pins einsparen wenn Du den Schalter als Widerstandsspannungsteiler ausführst und den AN8 als Analog Eingang. Dann wertet der uC nur die ADC Spannung ratiometrisch aus. Machen viele Leute. Man muss nur die Widerstandswerte zweckmäßig errechnen um gleichmäßige Spannungsunterschiede zwischen den einzelnen Stellungen zu gewährleisten. > > 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. Wenn das stimmt, dann sollte es allerdings wenig ausmachen. Aber w.g. ist es nicht ideal. Lies aber trotzdem das Kapitel 7 im Pickit3 Manual durch und vergleiche es mit Deinen Einstellungen. Mit MPLAB bekommst Du auch explizite Fehler Codes. Da könnte zur Diagnostik behilflich sein um nicht im Dunkeln zu tasten (Chapter 9) 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: (Paragraph 2.4.3) "... The recommended source of power is external and derived from the target application. In this configuration, target VDD is sensed by the debugger to allow level translation for the target low voltage operation. If the debugger does not sense voltage on its VDD line (pin 2 of the interface connector), it will not operate."
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.
Hallo Christian, danke für die weiteren Erklärungen. Naja, ich denke man könnte die Analogschalter Erfassung schnell genug beim Einschalten zuverlässig zu Laufen zu kriegen. Der ADC ist ja schnell und in einer Sekunde kann ein uC viel anstellen. Und meistens können die Elektroteil so lange warten bis der uC Zeit für sie hat. Normalerweise sollten ja alle Leistungstreiber sich im Reset Zustand befinden und nicht automatisch anlaufen. Solange der ADC zur Schaltererfassung ratiometrisch arbeitet spielen etwaige Startup Spannungs-Transienten solange sie im erlaubten Bereich bleiben keine große Rolle und man dürfte das zuverlässig in die Praxis umsetzen können. Aber Du kennst ja Deine HW besser als ich, also wirst Du schon Deine Gründe gehabt haben. Sonst wäre extra IO mittels SPI und Schiebe-Register denkbar. Die Schalter Ablesung geht dann in us. Mache ich auch oft um kaum benützten IO zu sparen. Es ist schade wenn z.B. viele IO Leitungen nur beim Einschalten gelesen werden und dann verschwendet sind. Da ist ein 30ct SR (HC165 o.ae.) billiger. Naja. Berichte später bezüglich PK3 wenn Du zum Testen Gelegenheit hattest. 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. Gruß, Gerhard P.S. Scheinst auch ein Österreicher zu sein wie ich sehe;-)
:
Bearbeitet durch User
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
Christian schrieb: > Das ist übrigens das Modul um welches es geht. Hallo Christian, Deine Bord ja allerliebst aus. Naja. Arbeite mal mit MPLABX IPV und versuch mal den uC mit dem PK3 auszulesen. Die SW funktioniert nicht schlecht. Beim ersten Lauf musst Du erst mal ADVANCED MODE in SETTINGS frei machen damit den Inhalt des uC auslesen kannst. Dass Password ist "microchip" (steht eh dort) Dann siehst Du ein Panel wie im Bild IPV1. Im Tool Feld muss dann PicKit3 S No: BUR????? zu sehen sein. Dann drücke die CONNECT Taste. Dann siehst Du die Text Responses vom IPV. Jedenfalls hast Du einen Anhaltspunkt wie das funktionieren soll. Wenn der uC Zicken macht bekommst Du hoffentlich nützliche Fehler Meldungen die bei der Fehlersuche behilflich sein können. Also viel Erfolg. Bin übrigens ehemaliger OE aus Tirol. Zur Zeit lebe ich ca. 113 Grad WEST und 53 Grad Nördlich wo die Winter saukalt sind und der Zeitunterschied 8 Std. ist;-) Gruss, Gerhard P.S. Die e-Mail kannst Du in Einstellungen ändern. Das sollte möglich sein.
:
Bearbeitet durch User
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.
Christian schrieb: > 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. Na, dann bin ich ja gespannt. OK. Viel Erfolg. Gruß, Gerhard
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!!
Hallo Christian, Danke und freue mich für Deinen Erfolgsbericht. 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. Naja, kann vorkommen. Aber mit IPE konntest Du die Klippe offensichtlich umschiffen. Die IPE ist ja ganz intuiv und leicht bedienbar. Es ist auch möglich, daß da irgendwo ein kleiner Fehler in den Programmierdateien existiert. Mir ist aufgefallen, daß IPE keine neue FW in den PK3 runter lädt wenn man zwischen 45K80 und 46K80 umschaltet. Das bedeutet, daß die Programmierprozeduren gleich sind und nur Device Daten vielleicht unterschiedlich ist. Aber damit mußte ich mich noch nie befassen und ist Spekulation. Wie findest Du übrigens BCB? Läßt sich damit gut arbeiten? Ist ja interessant, daß BCB PICs und AVRs zusammen unterstützt. Die Doku ist ja sehr detailliert. Ich verwende übrigens den amerikanischen CCS PIC Compiler einfach weil wir den in der Firma verwenden und ich ihn gewohnt bin. Ich vermute, daß die Microchip-C Compiler auch gut funktionieren obwohl nach Ablauf der Trialperiode die Optimierungen gesperrt bleiben. Jedenfalls, alles Gute dann, weiterhin, Grüße, Gerhard
:
Bearbeitet durch User
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!!
Christian schrieb: > Gerhard O. schrieb: >> Ist... Ja, ich meinte GCB. Danke für die weiteren Erklärungen. Übrigens, die ältere MPLAB V8.92 unterstützt die K Serie der PICs. Da kann man angeblich auch mit einer Commandline arbeiten. Das alte MPLAB ist viel schlanker als die X Generation. Ja, diese Probleme können nervig sein. Mit BASIC arbeite ich schon lange nicht mehr. Habe zwar vor langer Zeit auf HP Rechnern mit Rocky Mountain HP BASIC anfänglich gelernt und bin später auf TurboPASCAL und TURBOC umgestiegen. Wir machten damals viel mit HP-IB Steuerung vieler Meßgeräte und dafür funktionierte HP-BASIC (HP200/9000) sehr gut. Und in der neuen Firma wo ich heute noch bin wird intern nur C verwendet. Da muß man sich halt anpassen;-) Jedenfalls freue ich mich, daß Dein Problem eine Lösung gefunden hat und wünsche Dir jedenfalls ruhigere Fahrwasser. Grüsse, Gerhard ...
:
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.