PIC16F1825 - I2C Acknowledge Problem?

Hallo
Hier mal eine Routine für das EEPROM 24C02.

I2C1_Wr(0xA2)          ' send byte via I2C (device address + W)
  I2C1_Wr(2)             ' send byte (address of EEPROM location)
  I2C1_Wr(0xAA)          ' send data (data to be written)
  I2C1_Stop()            ' issue I2C stop signal

  Delay_100ms()

  I2C1_Start()           ' issue I2C start signal
  I2C1_Wr(0xA2)          ' send byte via I2C  (device address + W)
  I2C1_Wr(2)             ' send byte (data address)
  I2C1_Repeated_Start()  ' issue I2C signal repeated start
  I2C1_Wr(0xA3)          ' send byte (device address + R)
  LATB = I2C1_Rd(0)      ' Read the data (NO acknowledge)
  I2C1_Stop()            ' issue I2C stop signal

Peter.

Hallo Peter

Erstmal Danke für die schnelle Reaktion.

Ich habe Deinen Code verstanden. Das ist jedoch nur der Ablauf zum 
schreiben oder lesen des EEPROMs.

Mein Problem ist jedoch warscheinlich die Auswertung des Acknowledge 
Signals, um zu sehen das der Slave auf dem BUS überhaupt (unter dieser 
Adresse) existiert.

Wie gesagt kann ich eine richtige oder auch eine falsche Adresse senden. 
Das Oszillogramm sieht immer gleich aus.

Wenn ich aber kein Acknowledge vom EEPROM empfange, weil die Adresse 
falsch ist, müsste das Programm in "I2C_warte" hängen bleiben.
Ich werte das Interrupt Flag des I2C Modules des PIC aus.

void I2C_warte (void)
  {
  while (!SSP1IF) continue;  // Warten bis fertig
  SSP1IF = 0;      // Interrupt Flag wieder löschen
  __delay_us (10);    // Test
  }
Wo ist der Wurm drin?

Hallo  Test (Gast)

Der Interrupt für das I2C-Modul wird garicht konfiguriert und es wird 
auch kein Interupt ausgelöst bzw abgearbeitet. Es wird nur das Flag 
ausgewertet.

Manfred F. schrieb:
> Ich vermute das es an meiner Auswertung des Acknowledge liegt, weis aber
> nich weiter.

WO wertest Du das ACk den aus?
Das Result des I2C_write_byte() ignorierst Du ja fleissig.

/regards

P.S: Bevor Du PICs probierst wäre es evtl sinnvoll erst mal zu lernen, 
wie man Src-code postet. Ein .png ist da selten sinnvoll, insbesondere 
wenn es komplizierter wird.

Andreas H. schrieb:
> WO wertest Du das ACk den aus?
> Das Result des I2C_write_byte() ignorierst Du ja fleissig.

Ach ja. Hatte ich übersehen (dawn .png^^):
Deine I2C_write_byte() ist ja auch noch buggy.

Nimm lieber Diese, geklaut von 
https://aticleworld.com/interfacing-eeprom-with-pic-microcontroller-i2c-based/:

1

// Function Purpose: I2C_Write_Byte transfers one byte

2

bit I2C_Write_Byte(unsigned char Byte)

3

{

4

    SSPBUF = Byte;    // Send Byte value

5

    while(!SSPIF);    // Wait for it to complete

6

    SSPIF = 0;      // Clear the flag bit

7

8

    return ACKSTAT;    // Return ACK/NACK from slave

9

}

Dann bekommst du Du das ACK Bit als Ergebnis zurück.

/regards

Manfred F. schrieb:
> Wenn ich aber kein Acknowledge vom EEPROM empfange, weil die Adresse
> falsch ist, müsste das Programm in "I2C_warte" hängen bleiben.

Das wäre ein schlechter Bus, wenn er hängen bleiben könnte. Er liest ein 
NACK ein, welches Du auswerten solltest.

Hallo

Erstmal Danke an Alle die geholfen haben.

McMix schrieb:
> So wie ich die I2C Implementation beim Pic verstanden habe, wird das
> SSP1IF Flag immer gesetzt, wenn das Byte versendet und das Ack
> eingelesen wurde -
> unabhängig vom Zustand des ACK-Bits.
> Ob eine positves Ack wmpfangen wurde, sieht man dann im Zustand des
> ACKSTAT- Bits im SSP1CON2-Register.

Ich habe nochmal das DB des PIC studiert. Du hast Recht, Der Empfang des 
ACK-Bits wird in ACKSTAT abgelegt.

Ich habe mein Prog dementsprechend geändert, aber nun hängt es immer 
wenn ich ACKSTAT auf low überprüfe. Als wenn von Slave (EEPROM) kein 
Acknowledge gesendet würde.

uxdx schrieb:
> PEIE im INTCON sollte gesetzt sein.

ok, habe ich gemacht, ändert aber nix.

> Anbei meine seit langem funktionierenden I2C-Routinen für den
> PIC16F1825, zwar in ASM, aber wohl verständlich. Da ASM, müssen ggf.
> BANK-Befehle gesetzt werden, das macht C ja automatisch.

Danke dafür. Dies entspricht genau meinen C-Routinen. Allerdings kann 
ich nicht erkennen wo Du das ACK auswertest. genau wie bei mir wertest 
Du bei jeder Aktion das Interrupt Flag SSPIF aus. Wenn Du mal Dein 
EEPROM aus der Fassung ziehst müsste das Programm trotzdem weiter 
laufen, da das SSPIF Flag vom PIC gesetzt wird und Acknowledge nicht 
geprüft wird.

mh schrieb:
> Hast du mal überprüft, ob dein Code mit dem Inhalt des DB
> übereinstimmt?25.6.6.4 Typical Transmit Sequence

ok, habe ich gemacht. EEPROM schreiben entspricht meiner Meinung nach 
Punkt 25.6.6.4.

Andreas H. schrieb:
> WO wertest Du das ACk den aus?
> Das Result des I2C_write_byte() ignorierst Du ja fleissig.

ok, Eine Auswertung des ACK habe ich nun implementiert. Nun hängt das 
Programm genau dort.

> P.S: Bevor Du PICs probierst wäre es evtl sinnvoll erst mal zu lernen,
> wie man Src-code postet. Ein .png ist da selten sinnvoll, insbesondere
> wenn es komplizierter wird.

Ich will mich bessern ;-)
Aber wie geht das?

reminder schrieb:
> Ich muss bei jedem IC ein Abblock-C von VCC nach GND anschliessen.

Vorne am Steckbrett sitzt ein 10uF Tantal und ein 100nF Keramikkondi. 
(Sieht man auf dem Foto nicht)
Ich habe nun trotzdem nochmal je IC einen 100nF Keramikkondensator 
parallel zur Stromversorgung geschaltet (man waren die teuer).

Also lange Rede kurzer Sinn: Die Auswertung des Inetrruptflgs klappt 
einwandfrei. Dann kann ich jedoch das EEPROM aus der Fassung ziehen und 
es läuft totzdem.
Versuche ich ACK auszuwerten bleibt das Prog dort hängen.
:-(((

Manfred F. schrieb:
> ok, Eine Auswertung des ACK habe ich nun implementiert. Nun hängt das
> Programm genau dort.

Warum willst Du es denn dort hängen lassen?
Nach einem NACK sendest Du noch ein STOP und meldest der aufrufenden 
Instanz, daß die Aktion fehlgeschlagen ist.
Nach einem Schreiben ist der EEPROM für ~5ms nicht mehr ansprechbar, 
d.h. dann ist ein NACK korrekt.

Manfred F. schrieb:
> Andreas H. schrieb:
>> WO wertest Du das ACk den aus?
>> Das Result des I2C_write_byte() ignorierst Du ja fleissig.
>
> ok, Eine Auswertung des ACK habe ich nun implementiert. Nun hängt das
> Programm genau dort.
>
Naja, ohne Code ist das mühseliges Rumraten.

Nur falls das noch nicht aufgefallen ist: Das ACK ist **low-activ**, 
d.h. ein gültiges ACK ist 0V, ein NACK ist 5V (oder was auch immer die 
benutzte I2C Spannung ist, also da wo die PullUps dranhängen)

Manfred F. schrieb:
> Andreas H. schrieb:
>> P.S: Bevor Du PICs probierst wäre es evtl sinnvoll erst mal zu lernen,
>> wie man Src-code postet. Ein .png ist da selten sinnvoll, insbesondere
>> wenn es komplizierter wird.
>
> Ich will mich bessern ;-)
> Aber wie geht das?

Entweder die Files als Anhang an die Mail dranhängen (da gibts einen 
Button. Suchen hilft ... ;) oder den Code mit den entsprechenden Tags 
direkt einfügen. Die Tags findest Du unter 
https://www.mikrocontroller.net/articles/Formatierung_im_Forum.

Peter D. schrieb:
> Warum willst Du es denn dort hängen lassen?
> Nach einem NACK sendest Du noch ein STOP und meldest der aufrufenden
> Instanz, daß die Aktion fehlgeschlagen ist.
> Nach einem Schreiben ist der EEPROM für ~5ms nicht mehr ansprechbar,
> d.h. dann ist ein NACK korrekt.

Das habe ich auch noch nicht verstanden ;)

/regards

Hallo,

ich habe mir den Code auch mal angesehen. Ich arbeite mit dem XC8.
Ich musste an der Stelle vor jedem Write ein I2CIdle(); einbauen, dann 
lief es. Ich kann Dir meine LIB für den PIC18F46K80 zusenden. Bitte 
schreibe mir eine PN dann schicke ich Sie Dir zu.

Ingo

Ingo S. schrieb:
> Hallo,
>
> ich habe mir den Code auch mal angesehen. Ich arbeite mit dem XC8.
> Ich musste an der Stelle vor jedem Write ein I2CIdle(); einbauen, dann
> lief es. Ich kann Dir meine LIB für den PIC18F46K80 zusenden. Bitte
> schreibe mir eine PN dann schicke ich Sie Dir zu.
>
> Ingo

Hallo Ingo
Datei ist angekommen

Danke schon mal im Voraus.

Habe Heute leider kaum Zeit und schau Morgen mal rein.

Schöne Grüße und Dankeschön.