PIC, I2C - Reaktionszeit auf SSP-Interrupt

Brainy Gast #1318772 
Hallo Forengemeinde,

ich benutze zwei PIC18F8520, zwischen denen ich Daten über I2C 
austausche.
Lesen und Schreiben funktioniert gut, bloß ist beim Schreiben die 
Reaktionszeit des Slave auf ein Address-Match oder ein Datenbyte mit 150 
us m.E. viel zu lang.
Das ist die Zeit, die ich gemessen habe zwischen dem ACK-Signal des 
Slave (das kommt ohne Verzögerung nach dem Address- bzw. Datenbyte des 
Masters) und dem Aufruf der Interrupt-Routine.
Beim Read-Request des Masters kommt die Interrupt-Routine bereits nach 
wenigen Mikrosekunden.
Das Verhalten ist natürlich bei allen Baudraten gleich.
Der Master ist mit 25 MHz und der Slave mit 1,8432 MHz getaktet.

Kennt jemand so ein Verhalten?
Ist das eine normale Reaktionszeit, liegt es an der niedrigen Taktrate 
des Slave?

Gruß
Brainy
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Langsamer Modus Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Melden Danke
Bernhard_ Gast #1318850 
Ohne einen Quellcode lässt sich darüber nicht allzuviel sagen. Aber: 
Funktionsaufrufe innerhalb einer ISR (auch wenn nicht verwendet) zwingen 
zumindest den C18 Compiler zu einem ÄUSSERST ineffizienten Stackhandling 
mit langer Latenzzeit. Einfach simulieren...
Antwort Zitieren Bearbeiten Löschen Melden Danke
Zwirbeljupp Gast #1318860 
1,8432 MHz ist jetzt aber auch nicht gerade wahnsinnig schnell.
Da dauert ein Befehl schon mal allein 2,2 µs.
Wie wird denn dei Verzögerung bei Dir gemessen? Setzt Du in der ISR 
einen Pin auf High/Low?
Antwort Zitieren Bearbeiten Löschen Melden Danke
Brainy Gast #1318900 
Genau, in der ISR als erstes einfach einen Port auf high setzen.
1,8432 MHz sind natürlich nicht schnell, aber in der Zeit kann er ja ca. 
60 Instruktionen durchführen. Und das halte ich für ziemlich viel.
Antwort Zitieren Bearbeiten Löschen Melden Danke
Brainy Gast #1318912 
@Bernhard_:
Ich verwende den HiTech PICC-18 STD Compiler und rufe innerhalb der ISR 
tatsächlich eine SSP-Handler-Funktion auf.
Ich werde in Kürze mal testweise das SSP-Handling ohne Interrupt 
durchführen.
Antwort Zitieren Bearbeiten Löschen Melden Danke
Zwirbeljupp Gast #1318940 
> 1,8432 MHz sind natürlich nicht schnell, aber in der Zeit kann er ja ca.
> 60 Instruktionen durchführen
Dann schau mal ins Assemblerlisting. Es würde mich nicht wundern, wenn 
der PIC diese 60 Instruktionen als Overhead in der ISR verbrät (Register 
sichern usw...)
Antwort Zitieren Bearbeiten Löschen Melden Danke
Brainy Gast #1319868 
Ich habe mir im Assembler-Listing den Overhead beim Interrupt angesehen 
und es stimmt, es werden für's Hin und Zurück jeweils 42 Instruktionen 
verbraten, incl. 50% NOPs(!).
D.h. ich werde für meine Anwendung Interrupts vermeiden, denn Polling 
kann ich mir in dem Fall leisten.
Und einen schnelleren Clock werde ich mir auch leisten. ;-)

Bernhard_ und Zwirbeljupp, vielen Dank für Eure Unterstützung, Ihr habt 
mir schnell geholfen!

Brainy
Antwort Zitieren Bearbeiten Löschen Melden Danke
Thread beobachten

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 17 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.