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.
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
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.
Das Abfragen ist hier bei Microchip gut erklärt: http://ww1.microchip.com/downloads/en/AppNotes/01028B.pdf avr
Thorsten schrieb: > Ich bin wiedermal dafür, das man > sich in diesem Forum anmelden muss !! ... sprach ein Gast ... Gruß Jobst
@Hallöle Nein. So wie Peter es im Pseudo-Code geschrieben hat, wird es gemacht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.