Software I2C will mit PIC16F88 nicht richtig

[bernd h. (Gast)]

Hallo,

ich will auf einem PIC16F88 ein Software I2C realisieren, da der SSP 
schon mit SPI belegt ist. So, zunächst hatte ich das Sample von Hi-Tech 
genommen, man muss das rad ja nicht immer neu erfinden. Das 
funktionierte nicht, und irgendwo hatte ich gelesen, dass der Code 
fehlerbehaftet sei. Ich habe mittlerweile mehrere Codes gefunden, und 
keine hat funktioniert. nehmen wir mal als Beispiel den Code von dieser 
Seite: http://www.electronicslab.ph/forum/index.php/topic,4679.0.html

Eigentlich muss ich nur noch die Pins definieren. Bei mir sieht dieser 
Teil dann so aus:

 #define SCL             RA7
 #define SCL_TRIS        TRISA7
 #define SDA             RA6
 #define SDA_TRIS        TRISA6

Um vorweg mögliche andere Fehler auszuschließen: Was ich ansteuern will 
ist ein RDS processor, der TDA7333. Dazu habe ich ein kleines Platinchen 
gemacht, wo dieser drauf sitzt. Verbinde ich diese an eine I2C Leitung, 
die von einem PIC24 mit Hardware I2C gesteuert wird, antwortet mein 
Platinchen brav. Will sagen, hardwaremäßig sollte alles in Ordnung sein. 
Sowohl beim PIC24 als auch beim PIC16 sind 10k Pull ups an den Clock- 
und Datenleitungen.

Mit dem Oszi sehe ich mit dem PIC24 als Master folgendes: Gebe ich die 
richtige Adresse ein, setzt der Slave (in diesem Fall der TDA7333) SDA 
auf LOW, der Master erkennt dies erwartungsgemäß, und gibt den Bus mit 
Setzen der SCL auf HIGH wieder frei. Anschließend wird dann auch SDA auf 
HIGH gesetzt. Gebe ich die falsche Adresse ein, bleibt SDA auf HIGH, der 
Master belässt somit die SCL auf LOW.

So, mit dem PIC16F88 verhält sich immer so, als würde sich der Slave 
nach Senden der richtigen Adresse erwartungsgemäß quasi zurückmelden, 
auch wenn ich die falsche Adresse schicke! Timings und Signale scheinen 
zu stimmen, aber irgendwie kommt immer nur Müll heraus. Was stimmt hier 
nicht? Wahrscheinlich übersehe ich irgend eine Banalität...

[Stephan (Gast)]

http://www.sprut.de/electronic/pic/grund/i2c_soft.htm

[bernd h. (Gast)]

Aha, ok, es scheint mir, als hätte ich zwar bidirektionale I/O-Ports 
ausgewählt, aber im datenblatt sehe ich nun, dass RA6 und RA7 den Input 
nur analog entgegennehmen, wohingegen digitale vorausgesetzt werden.

[bernd h. (Gast)]

Hmm, nö, leider nicht. Abgesehen davon, dass ich per ANSEL eh' schon 
alle Inputs als digitale definiert hatte, habe ich mit RB6 und RB7 das 
gleiche Problem. Bleiben nur noch RB3 und RB5 als Testkandidaten übrig, 
aber ich schätze, das wird auch nichts bringen.

[bernd h. (Gast)]

Sieht immer noch alles prima aus, bis auf die Tatsache, dass mir der 
Slave keinen ACK gibt. :( Keine Ideen?

[Stephan (Gast)]

Der PIC16F88 kann mit seinem eingebauten Teil keinen Master-Modus (s. 
Datenblatt 3.Seite bzw. Page 1, mehr auch ab Page 92), nur Slave! 
Deswegen habe ich Dir ja auch den Link mit dem Software-I2C geschickt. 
Das läuft bei mir auch auf einem 16F88

[bernd h. (Gast)]

Hi Stephan,

aber ich bin ja schon von Anfang an dabei, I2C mit Software machen zu 
wollen, und genau das funktioniert nicht! Da hat mir der Link leider 
auch nicht geholfen. :(

Hast Du Deinen 16F88 mit Assemlber gefüttert? Ich bin mit C unterwegs, 
und alle Softwarelösungen (drei oder vier an der Zahl) machen's nicht. 
Da muss bei mir ein anderes Problem vorliegen, das ich aber grad nicht 
blicke. Hardware ist eigentlich ok, wie bereits erwähnt, weil der Slave 
an einem anderen Controller mit Hardware I2C definitiv funktioniert.

Am Oszi sieht alles vom Timing her gut aus, nur sehe ich eben, dass der 
Slave bei der neunten Clock SDA nicht auf LOW zieht, also kein Ack. (?!)

grüße
bernd

[holger (Gast)]

>Am Oszi sieht alles vom Timing her gut aus, nur sehe ich eben, dass der
>Slave bei der neunten Clock SDA nicht auf LOW zieht, also kein Ack. (?!)

Falsche Adresse gesendet? Oder die Bits in der falschen Reihenfolge?
Neben ADCON/ANSEL sollte man auch immer ein Auge auf ein
möglicherweise vorhandenes CMCON (Komparatoren) habe.
Dann macht man I2C auch nicht über die Portregister sondern
über die TRIS Register.

Ansonsten kann dir ohne kompletten Code wohl kaum jemand helfen.

[Dieter W. (dds5)]

> ...dass der Slave bei der neunten Clock SDA nicht auf LOW zieht, also
> kein Ack. (?!)

Das könnte daran liegen, dass der Data-Pin noch auf Output eingestellt 
ist.
Sollte aber von der Soft-I2C Routine richtig angesteuert werden.

Bei den Original I2C Pins macht das nichts, da die open Collector 
Konfiguration haben.

[Tony R. (tony)]

Hast Du denn die Eingänge auf die digital Eingänge umgeschaltet? Die 
werden standartmäßig analog initialisiert... Im Anhang die nötige Init 
laut Datenblatt. Ansonsten bitte mal die ganze ASM uppen.

[bernd h. (Gast)]

JIPPPIIIIIEEEEE!!!

Also, mal vorweg, der Code ist im Link oben. ;) Was ich hätte noch 
einfügen können war die init.h. Ob ich die betroffenen Portpins auf IN 
oder OUT setze, ist egal, weil das I2C per TRIS arbeitet (siehe Link). 
Mit Herumspielen an den Adressbits habe ich überhaupt erst 
herausgefunden, dass das software i2C nicht funktionierte. Ich hatte 
also immer wieder zwischen richtiger und falscher Adresse hin- und 
hergeswitcht. ANSEL hatte ich bereits auf 0x00 gestellt.

Was aber geholfen hat, war, den Komparator und die AD explizit auf OFF 
zu stellen! Danke an euch alle und speziell an Holger mit seinen Tipps, 
die die Lösung brachten!!!!!!