MCP23017 + PCA9515 Erfahrung + 400.00 kHz?

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hi

    ich habe kürzlich versucht einen MCP23017 hinter einen PCA9515 zu betrieben und das mit 400.000 kHz.
    Im Datenblatt des PCA9515 steht schon, dass es möglicherweise nicht funktioniert aufgrund von Verzögerungen durch den IC.
    Bei mir läuft die Kommunikation nicht zuverlässig und somit scheint die Kombination nicht verwendbar.
    Zwischen 100.000 und 400.000 kHz scheint es beim I2C keine Zwischenstufen zu geben.
    Hat jemand ähnliche Erfahrungen gemacht?

    Einmal editiert, zuletzt von evil (27. Juli 2015 um 07:19)

  • Ich deute Dein "nicht zuverlässig" mal so, dass es mal läuft und mal nicht. Oder läuft es gar nicht? Ich nehme an, Du betreibst die Schaltkreise am Raspberry Pi, oder? Der I2C ist nicht für lange Busleitungen ausgelegt, nach ein paar Zentimetern ist Schluss. Die Frequenz ist beinahe frei wählbar, da Du sie über DT einstellen kannst.

  • Nicht zuverlässig: Von 10 mal funktionierts es ein mal für ein paar Kilobyte - dann gibts irgendwann einen I2C Fehler und der IC ist nicht mehr da.
    (nur ein mal probiert)

    ca. 20 cm
    400.000 kHz ohne pca9515 funktioniert anstandslos bei gleichen Leitungslängen und Programm.


    Habe 300.000 per DT eingestellt war dann aber nach reboot auf 100.000.
    Automatisch zusammengefügt:
    IC weg hatte ich übrigens auch mal als ich "Kurzschlüsse" (470 Ohm Sicherheitswiderstand, aber dürfte die 3v3 Leitung in die Knie gezogen haben) auf den IOs vom MCP gemacht habe

    Einmal editiert, zuletzt von evil (27. Juli 2015 um 13:55)

  • Das der IC weg ist, kenne ich auch von Störungen durch die Verkabelung. Das Verhalten ist allerdings ungewöhnlich, da der 9515 ja nur repeated. Wozu willst Du das den Später nutzen. Es kann ja auch sein, dass der 9515 empfindlicher ist als der MCP23017. hast Du schon mal versucht den ganz dicht an den Raspi zu bringen und das Kabel erst dahinter länger zu machen?

  • Hallo allerseits,

    ich weis - es entspricht nicht ganz Eurem Setup - dennoch habe ich heute (motiviert durch Eure Unterhaltung) meinen MCP23017 per 75cm Flachbandkabel an den Raspi gehängt und auf 400kHz laufen gelassen (die softwareseitige Pollfrequenz ist 100 Hz). Zwar kann ich keine quantifizierten Aussagen zu eventuellen Fehlern geben (ich habe wg. Zeitmangel keine extra Logs in die SW eingebaut), dennoch läuft meine Heizung (die steuert der Raspi nämlich teilweise) seit etwa 8 Stunden immer noch. Wäre noch anzumerken, daß ich bei o.g. Verkabelung noch nicht mal den Bus terminiert habe.

    Im Forum werden desöfteren Stimmen laut, der I2C Bus würde nur über Zentimeter funktionieren. Wie ist denn in solchen Fällen die Verkabelung ausgeführt? Welche Störgrößen koppeln denn da ein? Induktive, kapazitive...? Ich kann diese Probleme noch nicht mal feststellen, wenn ich die Flachbandleitung um Schaltnetzteile wickle (einen EMV Meßplatzes hab' ich nicht daheim :) ). AD Wandler liefern bei dieser Art von Störung ohne explizite Gegenmaßnahmen bereits wunderbar breite Abtasthistogramme. Die I2C Bus scheint es jedoch absolut kalt zu lassen?!
    Auch wenn das Flachbandkabel noch weit weg von einer optimalen Schirmung ist, so hat man beim Raspi zumindest sichergestellt, daß SDA und SCL pfostensteckermäßig schön in die Versorgungsleitungen eingebettet sind. Insofern beruhigt das die beiden Leitungen vermutlich ein wenig.

    Was mich also interessiert wäre, wie ich Störungen gezielt (am besten realitätsnah - ähnlich den Bedingungen eines Schaltschrankes) einkoppeln kann. Experimente der Einkopplung per Frequenzgenerator und Kondensator sind hier also nicht gemeint.

    Noch ein Punkt. Warum muß man eigentlich den MCP23017 mit 400kHz betreiben? Der Nachteil - nicht alle Chips vertragen diese Frequenz oder werden zumindest spannungshungrig (d.h. kommen dann mit 3,3V evtl. nicht mehr aus und benötigen 5V, was das HW Design dann ändert). Auf der anderen Seite sehe ich aber auch keinen Vorteil. Was nützt mir eine so hohe Busfrequenz, wenn der Scheduler meistens im Bereich von 1ms arbeitet, jedoch unter Last auch Ausreißer bis 60ms zu verzeichnen sind? Mir erschließt sich nicht der Anwendungsfall, der auf der einen Seite eine extrem hochperformante HW fordert, diese aber SW seitig nicht deterministisch bedienen kann?!
    Ich habe im Umkehrfall schon überlegt, den Bus explizit langsamer als die standardmäßigen 100kHz zu takten.

    Es wäre schön, Ihr hättet einen Antwort auf die eine oder andere Frage. Mir sind solche Dinge auch schon öfters durch den Kopf gegangen und ich schmore ein wenig in meinem eigenen Saft. Zuletzt bei der Messung der Drehzahl einer Turbine. Hier war die Forderung, jitterarm und jeweils pro Umdrehung die Drehzahl ermitteln zu können. Der Scheduler hat mir da ganz schön in die Suppe gespuckt. Letztendlich kann ich das zwar nicht verhindern, jedoch zumindest erkennen, sodaß doch noch eine ganz brauchbare Lösung herauskam.

    Schöne Grüße aus dem Süden...

    schnasseldag

  • Servus schnasseldag,
    Deine Fragen vermag ich jetzt zwar nicht beantworten.


    ...
    ... Letztendlich kann ich das zwar nicht verhindern, ...
    ...


    Verhindern nicht, aber minimieren ... ich hatte kürzlich -> hier <- mal was ausprobiert ... das könnte für Dich in diesem Zusammenhang ganz interessant sein.


    ...
    Schöne Grüße aus dem Süden...
    ...


    ach ... sieh an ...
    Pfiadi ausm Chiemgau,
    -ds-

  • Hi schnasseldag,

    ich will aus dem System das Maximum herausholen das geht. Das macht mir sehr großen Spaß und dabei macht man Erfahrungen die nicht überall stehen.
    Ich lese Speicher aus, Geschwindigkeit und Zuverlässigkeit sind essentiell.
    Der Sprung von 100.000 auf 400.000 vervierfacht die Übertragungsgeschwindigkeit.

    Du liest mit 100 Hz also 10ms Daten. Ich lese im optimalen Setting zur Zeit mit 125 µs (entspricht kanpp 1 MB/min).
    Immer noch zu langsam wie ich finde, aber akzeptabel und mehr ist bei I2C kaum möglich.
    Nun will ich aber den Speicher mit 5V statt 3.3V ansprechen - aber das klapp scheinbar nicht. Wollte nur mal nachfragen ob jemand da auch Erfahrungen in dem Bereich hat.

    Für mich ist das Ergebnis des ganzen nun, dass I2C nicht gut geeignet ist und ich werden meine Test Richtung SPI fortsetzen.
    Von SPI erhoffe ich mir:
    - Leiche Umsetzbarkeit von 3.3 und 5 V Pegel
    - mehr Geschwindigkeit, optimalerweise ~7 MHz
    - 100% Zuverlässigkeit

    Mal sehen wies wirklich ist.

    RT ist für mich kein Thema da würde ich dann wohl mit anderer Hardware arbeiten.
    Rein rechnerisch komme ich bei einem Setting auf 233 µs pro Zyklus und erreiche real 259 µs also dürfte der Scheduler kein Problem sein (zumindest wenn der Pi sonst nix macht, bei real sind ja auch noch andere Operationen dabei).
    Brechung:

    1 Byte setzen 28 Bit
    1 Byte setzen 28 Bit
    2 Byte lesen 37 Bit
    -------------------------
    Ges: 93 Bit
    93 / 400.000 = 233 µs

    (Hoffe mal die Rechnung passt)

    Einmal editiert, zuletzt von evil (27. Juli 2015 um 23:11)


  • ich weis - es entspricht nicht ganz Eurem Setup - dennoch habe ich heute (motiviert durch Eure Unterhaltung) meinen MCP23017 per 75cm Flachbandkabel an den Raspi gehängt und auf 400kHz laufen gelassen (die softwareseitige Pollfrequenz ist 100 Hz). Zwar kann ich keine quantifizierten Aussagen zu eventuellen Fehlern geben (ich habe wg. Zeitmangel keine extra Logs in die SW eingebaut), dennoch läuft meine Heizung (die steuert der Raspi nämlich teilweise) seit etwa 8 Stunden immer noch. Wäre noch anzumerken, daß ich bei o.g. Verkabelung noch nicht mal den Bus terminiert habe.

    Wie ist denn Dein Setup? Bei mir ist ohne zusätzliche Hardware nach 15 cm Schluss. Ich habe viele Schaltvorgänge ca. 10 pro Minute) und nach einer gewissen Zeit (unbestimmt) läuft der Bus nicht mehr. Bei zusätzlichen MCP23017 am gleichen Bus spinnt der komplett, nach wenigen Schaltvorgängen (oder auch wen die Pumpe vom Kühlschrank angeht, oder ich das Licht ausschalte) werden die Adressen nicht mehr erkannt. Erst nach einem Reset geht es weiter. Der I²C-Bus ist gemäß Datenblatt kapazitiv empfindlich. Den maximalen Wert der Leitungskapazität habe ich jetzt gerade nicht im Kopf, aber es gibt einen.

  • Hallo raspiprojekt,


    Wie ist denn Dein Setup?

    Anwendungen gibt es mehrere, die aber dem gleichen Setup folgen. Raspi-GPIO -> Flachbandkabel -> Hubo-Platine (u.a.) mit MCP23017. Die Platine selbst kann wiederum mehrfach kaskadiert (also hintereinandergeschaltet) werden. Zur Kaskadierung hatte ich zunächst auch das Flachbandkabel favorisiert, komme allerdings mehr und mehr zum Schluß, daß sich im Schaltschrank eine geschirmte Litze "nativer" anfühlt.

    Zunächst mal einige Bilder:

    Im einfachsten Fall handelt es sich um einen Pi B oder Pi B+, welcher über ein etwa 14cm Flachbandkabel mit dem MCP23017 des Hubo verbunden ist. Das Ganze sitzt im gleichen Hutschienengehäuse. D.h. Störstrahlung von CPU/Netzwerkcontroller auf das Flachbandkabel sind nicht auszuschließen.

    (Das im vorliegenden Fall per 1wire 2 DS18x20 Temperatursensoren und ein Eeprom angeschlossen sind, ist jetzt mal nebensächlich).

    Im zweiten Beispiel sind zwei Hubos per "Draht" kaskadiert. Bei der Verbindung zwischen Raspi und Hubo handelt es sich um vormals erwähntes 75cm Flachbandkabel. Die Stromversorgung erfolgt sternförmig. Schaut man ganz genau hin, so erkennt man, daß die Masse ebenfalls geschlauft ist, wenngleich sie bereits sternförmig vom Netzteil verteilt wird. Das ist prinzipiell falsch und sollte vermieden werden (ich war lediglich zu faul, nochmals neue Bilder zu schießen - dieses Bild hatte ich jedoch bereits).

    Der letzte Hubo besitzt eine I2C Real Time Clock (DS3231) sowie ein I2C Eeprom. Angenehm ist, daß das 2€ China-Produkt gleich mit Abschlußwiderständen auf SDA/SCL daherkommt, sodaß man nicht extra löten muß, wenn die Leitungslängen größer werden. Wie dem auch sei - es gibt auch Installationen, in denen 4 Hubos kaskadiert sind und wo keine Busterminierung notwendig war...

    Und nun zum Testsetup (bitte nicht in solch einer Freiverdrahtung nachbauen!!!) in meiner Heizung. Animiert durch Euren Beitrag habe ich meinen Pi B nun seit 5 Tagen mit 400kHz (Standard ist sonst 100kHz) über vorgenanntes 50cm Flachbandkabel am Hubo laufen. Die Pollfrequenz der Software auf dem I2C-Bus beträgt 100Hz. Der Raspi liest dabei die Relaiskontakte der SPS über den Hubo ein und gibt sie 1:1 auf Hubo Relaisausgängen wieder aus. Geschaltet werden dabei Heizungspumpen und der Brenner des Gaskessels. Die Lasten sind vergleichsweise niedrig (220V/60W induktiv).

    Fazit:
    Egal ob Flachbandkabel oder "Draht" - der I2C-Bus hat mir keine allzugroßen Schwierigkeiten bereitet (Die größere Herausforderung war es, den Analogkonverter von Störungen freizuhalten, sodaß die 12Bit Auflösung = 0,6mV/Digit auch tatsächlich rauschfrei eingelesen werden können. Viele Boards mit teilweise noch höherer Auflösung scheitern hier - aber das ist eine andere Geschichte.).
    Die Leitungskapazitäten halte ich von untergeordneter Bedeutung. Flachbandkabel (AWG28) hat so zwischen 50pF und 100pF bei 1m Länge. Die I2C Spec benennt bei 3,4MHz SCL Takt eine Kapazität von 100pF. Bei 1,7Mhz sind es immerhin schon 400pF (4m Länge). Mit 100kHz liegen wir nochmals um den Faktor 17 darunter. Natürlich sind das nur Zahlen. Dennoch bemesse ich sekundären Störungen im praktischen Betrieb eine viel höhere Relevanz bei, als der reinen Leitungslänge. Das war auch ein Grund, weswegen ich beim Hubo neben der Flachbandkabelkaskadierung die per "Draht" (dann natürlich geschirmt und nicht wie auf dem Bild zu sehen in Freiflug) dazugebaut habe.

    Wenn Du nun in Probleme schlitterst, (potentialfrei?) einen Kühlschrank zu schalten, dann muß der Hund tiefer vergraben sein (Anzahl der Busteilnehmer, Kompatibilität der Teilnehmer untereinander, ggf. mehrere Master, Pegel...). Wo genau, daß läßt sich allerdings per Ferndiagnose nicht sagen. Da hilft nur die akribische Suche, so man Muße und Not hat, das Problem überhaupt lösen zu müssen... ;)

    Anbei noch ein Link zur I2C Spec und für "Heizungsbauer" der Beitrag zur Heizungssteuerung.

    Schöne Grüße

    schnasseldag

  • Fazit nach 7 Tagen bei 400kHz Bustakt und Setup nach "Bild 3" (Heizungssteuerung, s.o.) - das Wasser ist nach wie vor warm, ergo der I2C Bus läuft noch.

    Ich habe nun versucht, die obere Grenze der Busfrequenz auszutesten.

    Bei 1MHz wird der MCP23017 zwar noch erkannt, jedoch schlägt die Buskommunikation fehl. In diesem Fall hat es auch nicht geholfen, einen Abschlußwiderstand (indirekt über das DS3231 Uhrenmodul) zu setzen (die Uhr und das Eeprom wurden erkannt, getestet habe ich diese beiden Komponenten aber nicht weiter).

    Den Bus habe ich nun auf 900kHz gesetzt und er läuft erst mal (sowohl mit, als auch ohne Abschlußwiderstand). Mal sehen, wann das Wasser kalt ist...

  • Laut Datenblatt vom MCP funktionert I2C nur bis 400 KHz bei 3.3 V. Bei mir geht mit 1 MHz gar nix (Chip wird nicht erkannt).
    Verwende zur zeit auch nach dem PCA9515 3.3V da das aktuelle setting nicht für 5 V geeigent ist.
    schnasseldag Hat das ganze für mich auch eine Relevanz?
    100 Hz liegt weit unter dem Timimg das ich benötige/verwende.
    Kabellängen kann ich im Testaufbau kaum verkürzen, naja vielleicht löte ich da noch was um.


  • Bei 1MHz wird der MCP23017 zwar noch erkannt, jedoch schlägt die Buskommunikation fehl. In diesem Fall hat es auch nicht geholfen, einen Abschlußwiderstand (indirekt über das DS3231 Uhrenmodul) zu setzen (die Uhr und das Eeprom wurden erkannt, getestet habe ich diese beiden Komponenten aber nicht weiter).

    Den Bus habe ich nun auf 900kHz gesetzt und er läuft erst mal (sowohl mit, als auch ohne Abschlußwiderstand). Mal sehen, wann das Wasser kalt ist...

    Kannst Du mir mal einen Tipp geben, was Du mit Abschlusswiderstand meinst. Bist Du ganz sicher, dass Du in diesem Fall den Begriff richtig verwendest? Im Zusammenhang mit dem I²C-Bus ist mir dieser Begriff ausser hier noch nicht begegnet.

  • Hi evil,


    Laut Datenblatt vom MCP funktionert I2C nur bis 400 KHz bei 3.3 V. Bei mir geht mit 1 MHz gar nix (Chip wird nicht erkannt).


    Ja, das ist richtig. Ich will auch nicht unbedingt zur Nachahmung empfehlen, einen Chip weit außerhalb seiner Spec zu verwenden. Mir geht es lediglich darum ein Gefühl dafür zu entwickeln, wie weit man den Chip ausreizen kann und ggf. nachzuvollziehen, warum raspiprojekt hier zu ganz anderen Schlüssen kommt. Wie schon geschrieben - persönlich würde ich den Bus eher niedriger takten, als zu hoch... Wenn man höhere Geschwindigkeit will, dann ist es sicherlich nicht richtig, die Taktfrequenz eines I2C Busses weiter zu erhöhen. Man sollte dann lieber die Technik überdenken...


    Verwende zur zeit auch nach dem PCA9515 3.3V da das aktuelle setting nicht für 5 V geeigent ist.
    schnasseldag Hat das ganze für mich auch eine Relevanz?
    100 Hz liegt weit unter dem Timimg das ich benötige/verwende.
    Kabellängen kann ich im Testaufbau kaum verkürzen, naja vielleicht löte ich da noch was um.

    Ohne nähere Informationen, was Deine Applikation am Ende eigentlich machen soll, ist es schwer Dir hier zu helfen. Oben schreibst Du, Du willst Speicher auslesen. Hm, der Raspi hat RAM. Vermutlich liegt der Speicher dann wohl "remote". Dann kann man auch ein 1wire Eeprom nehmen. 1wire Leitungslängen wirst Du ohne Klimmzüge per I2C nie erreichen (wenn überhaupt). Das ist zu langsam? Dann würde ich die Werte eben puffern und nur einmal beim Startup der Software lesen?! Man muß schnell schreiben können? Dann wäre Eepromtechnologie vermutlich auch nicht angebracht - ganz unabhängig vom verwendeten Busmodell.

    Also beschreibe doch mal bitte kurz, was Deine Anwendung machen soll. Dann kann man das Problem gesamthaft anschauen und endet nicht in Lokaloptimierungen, die zusammengenommen aber kein gutes Konzept ergeben.

    Schöne Grüße

    schnasseldag


    PS: Kurzes Zwischenupdate - nach einer Uptime von knapp 7 Stunden ist das Duschwasser (bei 900MHz Bustakt) noch warm. Warten wir mal ab... :s
    Automatisch zusammengefügt:


    Kannst Du mir mal einen Tipp geben, was Du mit Abschlusswiderstand meinst. Bist Du ganz sicher, dass Du in diesem Fall den Begriff richtig verwendest? Im Zusammenhang mit dem I²C-Bus ist mir dieser Begriff ausser hier noch nicht begegnet.


    raspiprojekt: Sorry, der Begriff Abschlußwiderstand ist wirklich irreführend. Danke für die Klarstellung! Ich meine damit die Möglichkeit eines weiteren (bzw. alleinigen - externen) Pullups. Die internen Pullups des Raspi für SDA/SCL sollten mit 1,8k zwar eigentlich genügend "klein" dimensioniert sein, jedoch ließen sich im Grenzfall über das Uhrenmodul nochmals 4,7k dazuschalten - mithin der Widerstand auf 1,3k senken. Bei grenzwertigen Leitungskapazitäten mag das im Einzelfall helfen.


  • raspiprojekt: Sorry, der Begriff Abschlußwiderstand ist wirklich irreführend. Danke für die Klarstellung! Ich meine damit die Möglichkeit eines weiteren (bzw. alleinigen - externen) Pullups. Die internen Pullups des Raspi für SDA/SCL sollten mit 1,8k zwar eigentlich genügend "klein" dimensioniert sein, jedoch ließen sich im Grenzfall über das Uhrenmodul nochmals 4,7k dazuschalten - mithin der Widerstand auf 1,3k senken. Bei grenzwertigen Leitungskapazitäten mag das im Einzelfall helfen.

    Kein Sorry notwendig, hätte ja sein können, dass es da was gibt, was an mir vorbeigegangen ist. Ich baue ja auch einige Sachen mit I²C, allerdings habe ich bei beinahe jedem Projekt Probleme mit der Kabellänge. Inzwischen bin ich der Meinung, dass die Pullups die auf dem RasPi verlötet sind zu klein sind. Ich habe einen alten B seziert und die Widerstände auf 10k gesetzt und schon sieht die Wellenform bedeutend besser aus. Aber da bin ich gerade dran und werde mich, wenn ich dazu weitere Erkenntnisse habe nochmal äußern.

  • Hi raspiprojekt,


    Inzwischen bin ich der Meinung, dass die Pullups die auf dem RasPi verlötet sind zu klein sind. Ich habe einen alten B seziert und die Widerstände auf 10k gesetzt und schon sieht die Wellenform bedeutend besser aus.

    Ha, man lernt eben nie aus. Ich hatte die 1,8k aus irgendwelchen Internetquellen und nahm an, daß diese Broadcom-intern ausgeführt sind, wie bei dem Rest der GPIO-Pins. Ist aber weit gefehlt. Aus den Pi-Schaltplänen >> hier << geht eigentlich klar hervor, daß sie extern bestückt sind. Hm, gut möglich, daß der Broadcom dennoch weitere interne (50k) Pullups/~downs auch für diese Pins hat, welche dann bei externer 1,8k Beschaltung allerdings fast irrelevant wären. Vielleicht hat man aber auch Serien des Pi (aus welchen Gründen auch immer) einfach mal mit sehr hohen Widerständen bestückt und wollte die Chargen nicht verschrotten (merkt ja eh' fast niemand :( )?! Das wäre zumindest eine Erklärung für die BUS-Probleme.

    Schöne Grüße in den Norden

    schansseldag

  • Hallöchen,


    PS: Kurzes Zwischenupdate - nach einer Uptime von knapp 7 Stunden ist das Duschwasser (bei 900MHz Bustakt) noch warm. Warten wir mal ab...

    So, ich glaube, daß war genug des Wartens. Nach 6 Tagen scheint der I2C-Bus bei 900kHz Takt immer noch zu laufen. Reopen's oder Retries bei fehlgeschlagenen read/writes sind nicht im Code drin. D.h. würde ein write, welches Brenner und/oder Pumpe schaltet nicht funktioniert haben, dann hätte ich das phänomenologisch über kaltes Duschwasser eigentlich merken müssen?! Dem war aber nicht so...

    Ich habe den Bus jetzt mal auf 10kHz heruntergetaktet (ist kein Schreibfehler). Das ist eigentlich der für mich relevantere Wert, wenn ich mit 100Hz kommuniziere.

    Noch eine kleine Nebeninfo meines hier verwendeten Pi B:
    900kHz Bustakt -> 14% CPU Load der App
    10kHz Bustakt -> 6% CPU Load der App

    D.h. ein Mehr von 8% CPU Load für ein Delta von 890kHz I2C-Bustakt. Zur Erinnerung, die Lese- und Schreibgeschwinidgkeit der App liegt weiterhin konstant bei 100Hz. D.h. die CPU hat applikationsseitig eigentlich nicht mehr oder weniger zu tun. Woher kommt also der Anstieg? Auch reden wir hier von einem I2C Controller und nicht vom Bitbanging durch die CPU (und selbst dann stünde da immer noch die bustaktunabhängige und konstante Belastung durch die App).

    Mir sagt das, daß gewisser Kerneltreibercode im Takt des Bus-Controllers ausgeführt wird - nur welcher? Pollt der Kerneltreiber den Busmaster?
    Übrigens - weitere I2C Slave Module gibt's nicht am Bus, lediglich den einen MCP23017.

    Schöne Grüße

    schnasseldag

  • Ich sehe hier leider keine verwertbaren Informationen weil ich denke, dass meine Probleme mit dem IC PCA9515 zusammenhängen und nur sekundär mit dem I2C.
    Ich lese bis zu 16 MB ROM Daten aus.
    Werde bei Gelegenheit (das kann daueren) eine Anleitung verfassen.

    Obwohl was ist nun der optimale Pullup-Widerstand? Ich glaub ich hab mit 10K angefangen und mich auf 2,2 K runtergearbeitet - das Ergebnis war immer gleich (sekundär Seite PCA9515).
    Ich dachte ein kleine Widerstand ist besser da die Flanken dadurch steiler werden - oder gibts da was anderes zu bedenken.

    Einmal editiert, zuletzt von evil (12. August 2015 um 13:36)


  • Ich sehe hier leider keine verwertbaren Informationen weil ich denke, dass meine Probleme mit dem IC PCA9515 zusammenhängen und nur sekundär mit dem I2C.


    Das mag für Dich und Deinen eingesetzten Repeater stimmen. Nachdem es allerdings jede Menge Leute gibt, welche den MCP 23017 direkt am Raspi betreiben, dienen die Tests für den einen oder anderen vielleicht doch als Orientierung.


    Ich lese bis zu 16 MB ROM Daten aus.


    Ich wußte gar nicht, daß es I2C ROM's dieser Größe gibt?! Und wenn es sich um ein reines ROM (oder doch EEPROM?) handelt - wieso speicherst Du den Inhalt dann nicht einfach in einer Datei und liest diese dann daraus?


    Obwohl was ist nun der optimale Pullup-Widerstand? Ich glaub ich hab mit 10K angefangen und mich auf 2,2 K runtergearbeitet - das Ergebnis war immer gleich (sekundär Seite PCA9515).


    Ich fürchte, da mußt Du Dich wohl oder über mal intensiv mit dem Datenblatt des Chips auseinandersetzen. Er treibt den I2C Bus ja nicht ganz nach der I2C Spec.


    Ich dachte ein kleine Widerstand ist besser da die Flanken dadurch steiler werden - oder gibts da was anderes zu bedenken.


    Flanken gibt's in zwei Richtungen. Und Du verbesserst damit wohl die passive High-Flanke, bürdest den Ausgängen der Chips am Bus jedoch auf, gegen diesen Strom gegen Low zu ziehen.

  • ja, villeicht hilft es anderen den Repeater zu vermeiden ;-).
    Die ROMS sind parallel wozu sollte ich sonst den MCP benötigen.
    Naja, wie bereits geschieben werde ich bei Gelegenheit auf SPI wechseln, damit hat sich das Thema für mich hoffentlich erledigt.

    Einmal editiert, zuletzt von evil (15. August 2015 um 14:23)

  • Nur um mein Miniexperiment zumindest zu einem vorläufigen Abschluß zu bringen...


    Ich habe den Bus jetzt mal auf 10kHz heruntergetaktet (ist kein Schreibfehler). Das ist eigentlich der für mich relevantere Wert, wenn ich mit 100Hz kommuniziere.

    Auch bei 10kHz I2C Clock und konstant 100Hz Abtastrate lief der Raspi 4 Tage anstandslos durch und bediente Boiler und Brenner (über den MCP23017/ULN2803/Relais).
    Für weiterreichende Versuche mit dediziert gesetzter Buskapazität, variierenden Taktraten und extra geschnitztem Testprogrämmli fehlt mir derzeit leider die Zeit.

    So long...

    schnasseldag

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!