www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik I2C EEPROM schreiben beschleunigen


Autor: Confus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute

Will das schreiben von EEPROMS (I2C) beschleunigen, indem ich nach dem 
Stop Kommando das ACK abfrage.Wenn ich 10mS Verzögerung reinbaue (nach 
dem Stop) funktioniert es einwandfrei. Nur mit der Abfrage funktioniert 
es nicht.
Prozessor ist ein PIC18F2550.
Die Folgende Funktion wird nach dem letzten Stopp aufgerufen:

Sub Procedure WaitForI2CAck
    Soft_I2C_Sda_Direction = 1
    timeout = 0
    delay_us(100)
     while  Soft_I2C_Sda = 0
        timeout = timeout + 1
        if timeout = 500 then
           reset
        end if
        clrwdt
        delay_us(100)
    wend
end sub

Jemand eine Lösung dafür?

Autor: tt2t (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die typischen EEPROMs brauchen nur 3-5 msec zum Schreiben. Die 
ACK-Abfrage ist eigentlich die gängige Methode, um die meiste Speed 
herauszukitzeln.

Warum nimmst Du nicht die I2C-Hardware, die geht bei den PICs doch sehr 
gut?

Autor: Confus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider kann ich die Konfiguration mit dem Hardware I2C nicht benutzen.
Hat irgendjemand einen Code, welcher arbeitet? (Compiler ist mal egal)
Eigentlich müsste nach dem Stop doch der Slave SDA solange LOW halten, 
bis dieser das schreiben beendet hat. Oder irre ich mich da?

Autor: bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Leider kann ich die Konfiguration mit dem Hardware I2C nicht benutzen.

Warum nicht? Warum willst du dann überhaupt I2C benutzen?

>Eigentlich müsste nach dem Stop doch der Slave SDA solange LOW halten,
>bis dieser das schreiben beendet hat. Oder irre ich mich da?

Ja, und zwar ganz gewaltig. Wenn du mehrere Slaves am I2C
hast würde dein beschäftigter Slave den Bus komplett totlegen
solange er beschäftigt ist. Beim ACK Polling sendet man
eine Anfrage an den Slave (komplett mit Adresse usw.).
Solange er beschäftigt ist gibt er kein ACK.

Autor: Confus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weil es ein fertiges board ist, auf dem der HArdware I2C durch 
irgendeinen blöden RS232-USB Chip belegt ist. Ja richtig gelesen. Der 
PIC18F2550 hätte nämlich schon USB !!! Leider muss ich dieses Board 
benützen :-( Da war bei der Entwicklung ein richtiger "Profi" dran 
beteiligt. Ansonsten hätte ich es sowieso mit Hardware I2C gemacht.

Also nochmals ein Lesekomando schicken, und dann auf SDA warten. Habe 
ich da richtig verstanden?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Weil es ein fertiges board ist, auf dem der HArdware I2C durch
>irgendeinen blöden RS232-USB Chip belegt ist.
>Ja richtig gelesen. Der
>PIC18F2550 hätte nämlich schon USB !!! Leider muss ich dieses Board
>benützen :-( Da war bei der Entwicklung ein richtiger "Profi" dran
>beteiligt. Ansonsten hätte ich es sowieso mit Hardware I2C gemacht.

Was war denn das für ne Pappnase? RX, TX liegen auf RC7,RC6.
SCL, SDA auf RB0, RB1. Wird UART auch per Software gemacht?
Was für ein Schwachsinn. Dabei hätte man schön CDC über das
USB Interface machen können. Code gibts bei Microchip.

Ich empfehle ein Redesign der Platine.

>Also nochmals ein Lesekomando schicken, und dann auf SDA warten. Habe
>ich da richtig verstanden?

Fast, Lesekommando mehrmals schicken bis kein NACK mehr kommt.

Autor: bingo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
falls Du Software-RS232 hat, ist das doch easy: ändere die RS232-Pins 
auf Pins, die nix mit I2C zu tun haben und mach Hardware I2C

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Confus schrieb:
> Also nochmals ein Lesekomando schicken, und dann auf SDA warten. Habe
> ich da richtig verstanden?

Nein.

Busy Test geht so:
1. Start senden
2. Adresse + W senden
3. ACK lesen
4. if ACK gehe zu 7.
5. Stop senden
6. gehe zu 1.
7. Stop senden
Ende


Peter

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
>
> Busy Test geht so:
> 1. Start senden
> 2. Adresse + W senden
> 3. ACK lesen
> 4. if ACK gehe zu 7.
> 5. Stop senden
> 6. gehe zu 1.
> 7. Stop senden
> Ende

Ich würde den ACK bis zu einem Timeout abfragen und erst dann stoppen 
und wiederholen.
Und ich warte nach einem Takt auf SCL auch darauf, daß ACK wieder zurück 
genommen wird.


Gruß

Jobst

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jobst M. schrieb:
> Ich würde den ACK bis zu einem Timeout abfragen und erst dann stoppen
> und wiederholen.

Die Pulszeiten ergeben sich automatisch aus dem Timing des EEPROM 
(100kHz, 400kHz oder 1MHz).
Das ACK muß anliegen, nachdem SCL = high ist. Eine Änderung des SDA bei 
SCL = high ist nämlich nur für Start oder Stop erlaubt.


Jobst M. schrieb:
> Und ich warte nach einem Takt auf SCL auch darauf, daß ACK wieder zurück
> genommen wird.

Ist daher auch nicht nötig.


Peter

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich warte ja auch auf ACK, damit ich SCL setzen kann ;-)

Habe schon Chips gehabt, bei denen das nötig war. Frag mich aber bitte 
nicht, welche das waren. Ich weiß es nicht mehr.


Gruß

Jobst

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jobst M. schrieb:
> Habe schon Chips gehabt, bei denen das nötig war.

Glaub ich Dir nicht.
Alle EEPROMS müssen mindestens das 100kHz Timing können.
D.h. nach 4,7µs SCL low muß das ACK stabil anliegen.

Du hast warscheinlich ein schnelleres Timing verwendet, aber das kann 
nicht jeder EEPROM. Da muß man sich schon nach dem Datenblatt des EEPROM 
richten.


Peter

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter, ich finde das Ding nicht mehr. :-/
Das war irgendein uriger ADC. Vermutlich auch nicht so ganz I²C-konform.
Timing war aber ehr langsamer, als zu schnell.

Aber da ich immer ein wenig paranoid bin, schleife ich so einen Mist 
ewig mit.


Gruß

Jobst

Autor: Hallöle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun will ich genau das selbe Feature in meine SW einbinden, damit das 
schreiben schneller geht. Kann aber auch nur mit Software I2C arbeiten 
:-(

Habe ich das jetzt richtig verstanden?

Sub Procedure WaitForI2CWriteComplete
     TimeOutCounter = 0                        'Timeoutcounter auf 0 
setzen
     Soft_I2C_Start                            'I2C Start senden
     Soft_I2C_Write(168)                       'I2C Kommando = schreiben
     Soft_I2C_Sda_Direction = 1                'SDA auf Eingang schalten
     Soft_I2C_SCL_Direction = 0                'SCL auf Ausgang schalten
     Soft_I2C_SCL = 0                          'SCL auf Low ziehen
     Delay_uS(10)                              '10 uS warten
     Soft_I2C_SCL = 1                          'SCL auf High ziehen
     Delay_uS(10)                              '10 uS warten
     Soft_I2C_SCL = 0                          'SCL auf Low ziehen
     while Soft_I2C_Sda = 0                    'Auf Ack warten
           clrwdt                              'Watchdog befriedigen
           Timeoutcounter = Timeoutcounter + 1 'Timeoutcounter 
hochzählen
           if Timeoutcounter >= 200 then       'Wenn Timeout >= 200mS
              Reset                            'Prozessor neu starten
           end if
           Delay_mS(1)                         'Eine mS warten
     wend                                      'I2C Stopp
     Soft_I2C_Stop
end sub

Autor: Thorsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das kann gar nicht funktionieren. Du musst IMMER 20mS warten, bevor du 
das nächste Byte schreiben kannst. Auch bei Pagewrite. Also wenn du 
32Byte per Pagewrite schreibst, musst du auch jedesmal 20mS warten. 
Solch Leute wie ihr seit einfach zu faul das Datenblatt zu lesen. Darum 
belästigt ihr ernsthaft Entwickler. Ich bin wiedermal dafür, das man 
sich in diesem Forum anmelden muss !!

Autor: usuru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du musst IMMER 20mS warten

wieso 20 msec ?? Die EEPROMS von ATMEL, MICROCHIP und ST brauchen alle 
weniger als 5 msec zu schreiben, meistens sogar nur 2-3 msec (bei 5V). 
Und das Abfragen des ACK ist doch easy.

Autor: avr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Abfragen ist hier bei Microchip gut erklärt:

http://ww1.microchip.com/downloads/en/AppNotes/01028B.pdf

avr

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thorsten schrieb:
> Ich bin wiedermal dafür, das man
> sich in diesem Forum anmelden muss !!

... sprach ein Gast ...


Gruß

Jobst

Autor: 2ter Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hallöle

Nein. So wie Peter es im Pseudo-Code geschrieben hat, wird es gemacht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.