PIC-Microcontroller

Es kann schon enervierend sein, nach der Nicht-Funktion in einer Schaltung den Fehler zu suchen!
Dieses gilt ganz sicher auch für den Fall, dass gar kein Fehler vorhanden ist. Tatsächlich war ich über meinen Versuch gestolpert, sorgsam vorzugehen und nach wichtigen Teil-Arbeitsschritten diese gleich zu prüfen, um nicht später in einer angewachsen und komplexeren Umgebung ganz kalt erwischt zu werden. Also wurde beim Erstellen der benötigten Gruppierung – bestehend aus gesamt drei Boards  - zunächst das Erste geprüft, der ,,kell-pic" und auch gleich das darauf laufende Prog. Alles Paletti. Dann das Duo ,,roll-pics", und vor dem Huckepack-Zusammenbau diverse Grundfunktionen jeder Platine. Alles gut. Dann der Huckepack-Bau und das Aufbringen des angepassten Progs und natürlich sollte dieses Huckepack-Duo sofort geprüft werden. Nix gut ! Das war echt nicht gut! Die Hardware war eher unverdächtig, aber das Prog machte, was es wollte, insbesondere verweigerte es die vorgesehene sofort anfängliche Sleep-Phase.

Muss gestehen, dass es mich erfolgreich verwirrte, weil im Simulator alles prima war, und es mir nicht gelingen wollte, den Fehler zu packen. Bis mir nach Einfügungen im Prog und dem Einbau von Kontroll-Leds es so nach und nach dämmerte, dass....
Der empfangende PIC im ,,Roll-Duo" sollte für den Test-Anfang nur auf zwei Ereignisse hin tätig werden, auf zwei Tastendrücke. Der war aber weit fleissiger als erwartet, schließlich schlummerte weiter hinten im Prog die schon für später vorgesehene Routine, welche den Port-Eingang abfragte.
Und dann hatte ich die Rechnung ohne den Wirt namens MAX gestellt! Weil ja nur das frische ,,roll-duo" quasi als frisches Teilprodukt auf evtl. frische Fehler untersucht werden sollte, wurde auch nur dieses Duo in Betrieb genommen. Will sagen: Das Dilemma begründete sich, weil sowohl der Bus als auch die Schaltzentrale als dritte Schaltung nicht mit im Bunde dabei waren. Der unbebusste Eingang des MAX war offen und lag wegen der MAX-Einstellung auf ,,0". Das produzierte dann eine ,,1" vom MAX zum PIC, und dieser arme, aber gute Kerl hielt das für ein Daten-Eingangssignal, wachte - kaum dass er überhaupt in den Schlaf gefallen war - auch sofort schon wieder aus seinem Schlummer auf und schon legte die für später vorgehaltene Bus-Abfrage-Routine los. Und die wartete nach dem Wecksignal auf das erste Daten-Bit und wartete und wartete.......

Hätte ich doch gleich das Dreierpack zusammengefügt, wäre dieser Schlammasel an mir vorüber gegangen. So hatte mir ausgerechnet das Bemühen um sorgfältiges Vorgehen und gründliche Kontrolle von Teilergebnissen diesen Bus- Strich durch die Rechnung gemacht.
Grüße, picass

Mist, flixter! Die Prototypen1-Anlage für die Werkstatt funktioniert in allen Belangen, nun sollten die ersten drei Prototypen2 erstellt werden für den Einbau im Haus, aber nix: es steckt ein Wurm drin! Die Anlage besteht wie beschrieben aus der zentralen Steuereinheit – Arbeitsname: ,,kell" – und den beiden Rundplatinen ,,rollk" und ,,rollp", die huckepack übereinander montiert sind. Als Letztes wurde das Steuerprogramm für den ,,rollk" einprogrammiert, dessen PIC tut auch was, aber leider nicht das Erwünschte. Und dabei ist dessen Prog quasi nur eine nur wenig geänderte Teilmenge desjenigen Progs, welches im Steuer-PIC prima seine Arbeit verrichtet. Die Hardware funktioniert bestens, ist mehrfach getestet, aber im Prog tummelt sich ein Wurm! Voll der Horror das! Im Simulator wurde mehrfach simuliert, und dort läuft alles so wie vorgesehen. Nur im PIC klappts nicht. Is klar, dass die Programm-Entwicklungs-Version die Nummer 13 trägt!
Grüße, picass

Zitat von: vloki am 01.06.2021, 14:41:50 CESTDie MCLR Pins sind aber schon ordentlich beschaltet, bzw. deaktiviert?

Hoffe, wir kommen hier nicht vom Fredthema ab....wäre wohl besser, einen eigenständigen Fred über Empfindlichkeit zu erstellen. Bis dahin...
Grundsätzliches über die Beschaltung von Port-Pinnen fand ich hier, Zitat aus dem PIC18F14k22-Databook:
-"Each of the PORTA pins has an individually controlled weak internal pull-up. When set, each bit of the WPUA register enables the corresponding pin pull-up. When cleared, the RABPU bit of the INTCON2 register enables pull-ups on all pins which also have their corresponding WPUA bit set. When set, the RABPU bit disables all weak pull-ups. The weak pull-up is automatically turned off when the port pin is configured as an output. The pull-ups are disabled on a Power-on Reset."
und
-"MCLR : Active low Master Clear with internal pull-up"

Dazu gibts noch einen Ausschnitt - Text und Bild - aus dem Microchip MPLAB X PICkit 3 User's Guide, in welcher ein extra montierter R zu sehen ist. Der ist in nachfolgender Beschreibung noch mal erwähnt als "Irgendwas in der Größe um 10 kO".
---------------
In meiner Schaltung hatte ich diesen extra-(pull-up)Widerstand an der Vpp/MCLR-Leitung noch nicht installiert. Zudem sind im Programm die Pull-Ups (WPUA-Register) alle abgeschaltet.
Grüße, picass

Der MCLR Pin ist über einen Widerstand an Plus verbunden.
Ich glaub auch nicht das der Controller einen Reset macht.

Zitat von: picass am 31.05.2021, 09:19:13 CEST

Zitat von: Peter am 29.05.2021, 21:47:36 CESTDachte nicht das die Pic Controller so empfindlich sind.

... Dann fand ich raus, dass manchmal schon die Annäherung eines Fingers an den Sende-PIC reichte, um den zur Arbeit zu bewegen.

Die MCLR Pins sind aber schon ordentlich beschaltet, bzw. deaktiviert?

Zitat von: Peter am 29.05.2021, 21:47:36 CESTDachte nicht das die Pic Controller so empfindlich sind.

Deine Problemschilderung erinnert mich an ein irgendwie ähnliches Erlebnis beim Experimentieren mit meiner Rollladenschaltung. Die Prototyp-Anlage aus drei Platinen - zwei davon enthalten je einen PIC - funktionierte, will sagen, der Datentransport via Kabel klappte. Aber gelegentlich startete eine Datenübermittlung vom sendenden PIC, obwohl keine Startbedingung (Taste / Portänderung) vorlag. Dann fand ich raus, dass manchmal schon die Annäherung eines Fingers an den Sende-PIC reichte, um den zur Arbeit zu bewegen. Es half da auch nur wenig, mit einer Hand in der Steckdose - also am Erdungsbügel - zu sein, und dieserart "eigentlich" die Elektrostatik ausgebremst zu haben. Dieses Phänomen habe ich noch nicht im Griff, mag sein, dass der nun bevorstehende Einbau in ein Alugehäuse da weiterhilft.
Grüße, picass

Schock und schwere Not! Da hast du dir aber was Gutes gegönnt! Überlege gerade, ob ich neidisch werden sollte. Aber nein, bislang bin ich mit meinem Schlichtestgerät immer zum Ziel gekommen. Mag sein, dass ich das anders sehen würde, wenn ich mal so'n Leichtgewicht in der Hand gehabt hätte. Wenn ich nicht gerade eine Serienanfertigung von 20 Platinen für meine Rollladensteuerung auf dem Werktisch habe, dann geht es doch eher ruhig zu an meiner Lötfront. Und ich hänge an dem alten Schätzchen....
Grüße, picass

So habe nun den Fehler gefunden, warum falsche Werte geliefert werden.
Es liegt wahrhaftig an der Störung des Senders. Der stört nämlich den Controller und
bringt ihn wohl aus dem Takt. Nachdem ich den Controller abgeschirmt hatte, trat das Problem
nicht mehr auf. Dachte nicht das die Pic Controller so empfindlich sind. Aber nun
läuft es so wie es sein soll.
 

Ich benutze die Weller WX 1 und den Lötkolben WXP 120.
Kosten zwar sehr viel, aber da ich viel löte, hat sich das schon
gelohnt.

Hallo Peter!
Mal so aus Neugierde angefragt: genau welchen Lötkolbentyp verwendest du denn jetzt? Und bei der Gelegenheit: in Verbindung mit welcher Lötstation?
Grüße, picass