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?
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?
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?
>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.
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?
>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.
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
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
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
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
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
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
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
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 !!
> 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.
