I2C auf 16F876A klappt nicht

[RoboHolIC]

Hallo an alle, die bis hierher mitgedacht und sich bemüht haben.

Jetzt werde ich den Spieß umdrehen und versuchen, die funktionierende Kombination durch Chiptausch und Codeanpassung auf 16F876A umzustricken ...
... Ich bin gespannt und werde berichten.

Uuups - der Spieß hat sich gedreht, nur nicht so wie ich es mir vorgestellt hatte. Der angedeutete Testfall findet nicht statt, weil das für den 16F886 entwickelte Platinchen aus der Grabbelkiste dem 16F876A nicht den benötigten externen Taktgeber/Schwinger bieten kann. Da fällt mir doch glatt der technische Fortschritt auf die Füße ...

Natürlich könnte ich den Lötkolben anheizen, die Teilekiste auspacken und loslegen:

Dieses Problem ist "Hobby" innerhalb des Hobbies - im Grunde unwichtig, aber Aufgeben ist keine Art, mit solchen Problemen umzugehen, oder?

Aber angesichts eines Restbestands von zwei Stück 16F876A vielleicht wiederum doch ...

Gute Nacht wünscht
RoboHolIC

[Andre_S]

Hallo RoboHolIC!

Vor der Umstellung auf 18F422 und später dsPIC30F5013 haben wir den 16F876 in allen unseren Steuerungen eingesetzt.
Das es jetzt bezüglich der Version A Unterschiede im MSSP Modul oder dessen Initialisierung gibt hab ich erst mal nicht in Erinnerung, zumindest der 16F876 wurde von uns in sehr vielen Geräten verbaut. Dei A gabs wohl Unterschiede im flashen und der Geschwindigkeit.
Bei allen arbeitet der I²C-Bus zwecks Kommunikation mit Speicherbaustein, RTC und steckbarer Speicherkarte ohne Probleme. Der Bus ist somit auf die Größe des Platinenlayouts beschränkt und wird nicht extern weitergeführt.
Allerdings bediene ich diesen auf Grund der Umweltbedingungen (Freifeldeinsatz) und nicht benötigter höherer Geschwindigkeit, von vorn herein nicht mit maximaler Busgeschwindigkeit der Komponenten, sondern soweit ich mich erinnern kann mit ca. 125Khz. (MC mit 4Mhz)

Grundvoraussetzung um wirklich „effektiv“ helfen zu können, wäre sicherlich die Offenlegung der Quellcodes bezüglich Initialisierung und Kommunikation deinerseits, zumindest um so möglichen Fehlerquellen innerhalb der Programmierung ausschließen zu können.
Meine Quellen sind ebenfalls in Assembler, aber eventuell hast Du den Fehler inzwischen auch lokalisieren können…


Gruß André

[Siro]

Hallo RoboHolIC

Ich hab jetzt nicht ganz verstanden warum Du das RC3 Bit einmal auf Input und dann wieder auf Output setzt, das ist doch die Clockleitung
aber genau da könnte der kritische Punkt sein.

wenn Du mit dem BCF oder BSF Befehl arbeitest, liest der Controller den "gesamten" Port, also "ALLE" Bits vom C-Port (READ)
und speichert sie irgendwo zwischen. Dann wird das entsprechende "einzelne" Bit gesetzt oder gelöscht. (MODIFY)
Dann wird der zwischengespeicherte Wert zurück an den Port geschrieben. !! ALLE 8 Bits (WRITE)
Das Problem: Hat der Controller ein High auf einem anderen Bit gelesen, wird dieses Bit nun auch High gesetzt,
obwohl man dieses Bit garnicht anfassen wollte. Das bedeutet Du möchtest nur ein Bit verändern im TRIS Register aber
es ändern sich unter Umständen auch andere Bits, die man garnicht verändern wollte. Dann stimmt plötzlich zum Beispiel die Richtung IN/OUT nicht mehr

Ich habe mir um das zu vermeiden oft eine Variable angelegt und NUR Änderungen mittels BCF und BSF in dieser Variablen getätigt.
dann den gesamten Wert (8 Bit) auf den Port geschrieben.

Das ist natürlich nur eine Vermutung dass der Fehler daher rührt.
Bankselect ist ebenso "SEHR" wichtig, wie witkatz schon schrieb.
Das waren auch zu 99 Prozent meine Softwareprobleme.

Siro