Der real existierende i2c-Bus / Lochraster im Weltraum

[olaf]

Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:

>Wo findest Du so einen Reset bei RS-232 oder SPI?

Bei SPI reseten sich die Statemachines wenn du mit CS rumwackelt. Das
ist deutlich robuster. Ausserdem hast du kein Opendrain mit Pullup, also auch
weniger Stoerwarscheinlichkeit.

Olaf

 

[olaf]

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:

I2C wurde seinerzeit von den Holzschuhträgern für modulare Glotzen
entwickelt und da sprechen wir nicht von etlichen Metern.

Ich glaube ich hab es das erste mal in einen der alten Video2000
Kisten gesehen. Da kommen doch bestimmt auch schon 2m zusammen.

>I2C ist für einfachste Aufgaben OK, aber ansonsten Mist.

Kann man nicht ganz so einfach sagen.

Die meisten Probleme mit I2C kommen weil die Programmierer auf
Arduinolevel Murks zusammenschustern. Wenn im Source sowas steht...

while(I2C_Ready == TRUE);

....dann ist der Supergau bereits vorprogrammiert. Ich denke das sind 90%
aller Probleme. wenn man sich dessen bewusst ist, Fehler erkennt, den Master
neu initialisiert und vorher mal ein paar Takte raushaut damit Slaves den Arsch
wieder hochbekommen die SDA runterziehen dann laeuft es in 99% aller Faelle gut.

Das restliche 1% sind dann devices die sich weghaengen und dabei SCL runterziehen.
Ein Beispiel dafuer sind LM75 in der ersten Version. (die wurden mal verbessert!)

Aber natuerlich fuer Anwendungen die 24/7 laufen sollen wuerde ich I2C
auch nicht verwenden.

Olaf

 

[olaf]

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:

Ein Klemmender I2C Busteilnehmer blockiert aber u.U. Senden und
Empfangen und hat in der Regel auch keinen CS durch den er sich
deaktivieren ließe.

Es gibt mittlerweile auch welche die haben einen internen Timeout. Da
gibt es dann eine minimale Taktfrequenz fuer SCL. Und geben tut es das
weil den Herstellern auch schon aufgefallen ist das I2C nicht so ganz
das gelbe vom Ei ist.

Olaf

 

[Eric Bruecklmeier]

Am 25.10.2019 um 19:17 schrieb olaf:

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:

Ein Klemmender I2C Busteilnehmer blockiert aber u.U. Senden und
Empfangen und hat in der Regel auch keinen CS durch den er sich
deaktivieren ließe.

Es gibt mittlerweile auch welche die haben einen internen Timeout. Da
gibt es dann eine minimale Taktfrequenz fuer SCL. Und geben tut es das
weil den Herstellern auch schon aufgefallen ist das I2C nicht so ganz
das gelbe vom Ei ist.

Ich verstehe nicht so ganz, warum man krampfhaft versucht, I2C
aufzubohren, anstatt gleich was vernĂźnftiges zu nehmen...

 

[Eric Bruecklmeier]

Am 25.10.2019 um 19:11 schrieb olaf:

Eric Bruecklmeier <usenet@nerdcraft.de> wrote:

I2C wurde seinerzeit von den Holzschuhträgern fßr modulare Glotzen
entwickelt und da sprechen wir nicht von etlichen Metern.

Ich glaube ich hab es das erste mal in einen der alten Video2000
Kisten gesehen. Da kommen doch bestimmt auch schon 2m zusammen.

I2C ist fĂźr einfachste Aufgaben OK, aber ansonsten Mist.

Kann man nicht ganz so einfach sagen.

Die meisten Probleme mit I2C kommen weil die Programmierer auf
Arduinolevel Murks zusammenschustern. Wenn im Source sowas steht...

while(I2C_Ready == TRUE);

...dann ist der Supergau bereits vorprogrammiert. Ich denke das sind 90%
aller Probleme. wenn man sich dessen bewusst ist, Fehler erkennt, den Master
neu initialisiert und vorher mal ein paar Takte raushaut damit Slaves den Arsch
wieder hochbekommen die SDA runterziehen dann laeuft es in 99% aller Faelle gut.

Ändert aber nichts daran, daß auch Störungen als START interpretiert
werden...

Das restliche 1% sind dann devices die sich weghaengen und dabei SCL runterziehen.
Ein Beispiel dafuer sind LM75 in der ersten Version. (die wurden mal verbessert!)

Aber natuerlich fuer Anwendungen die 24/7 laufen sollen wuerde ich I2C
auch nicht verwenden.

Eben! Das war eine Entwicklung für Jubelelektronik und da paßts auch -
obwohl die Glotzen von Philips großer Mist sind ;-).

 

[Gerrit Heitsch]

On 10/25/19 8:17 PM, Eric Bruecklmeier wrote:

Eben! Das war eine Entwicklung für Jubelelektronik und da paßts auch -
obwohl die Glotzen von Philips großer Mist sind ;-).

WĂźrde ich so nicht sagen... FĂźr Retrokram habe ich noch eine
RÜhrenglotze von denen, hat RGB-, FBAS- und S-Video-Eingänge. Gekauft
2002, funktioniert immer noch einwandfrei.

Gerrit

 

[Hans-Peter Diettrich]

Am 25.10.2019 um 19:13 schrieb olaf:

Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:

Wo findest Du so einen Reset bei RS-232 oder SPI?

Bei SPI reseten sich die Statemachines wenn du mit CS rumwackelt. Das
ist deutlich robuster. Ausserdem hast du kein Opendrain mit Pullup, also auch
weniger Stoerwarscheinlichkeit.

DafĂźr sollen lt. Wikipedia nicht alle SPI Devices ihren Ausgang
erwartungsgemäß abschalten.

DoDi

 

[Eric Bruecklmeier]

Am 25.10.2019 um 20:50 schrieb Gerrit Heitsch:

On 10/25/19 8:17 PM, Eric Bruecklmeier wrote:

Eben! Das war eine Entwicklung für Jubelelektronik und da paßts auch -
obwohl die Glotzen von Philips großer Mist sind ;-).

WĂźrde ich so nicht sagen... FĂźr Retrokram habe ich noch eine
RÜhrenglotze von denen, hat RGB-, FBAS- und S-Video-Eingänge. Gekauft
2002, funktioniert immer noch einwandfrei.

Ich meine schon eher die neueren Flachglotzen - aber ich bin halt auch
geprägt, mir ist der Laden einfach grundunsympatisch...

 

[Klaus Butzmann]

Am 26.10.2019 um 10:42 schrieb Eric Bruecklmeier:

Ich meine schon eher die neueren Flachglotzen - aber ich bin halt auch
geprägt, mir ist der Laden einfach grundunsympatisch...

Bei mir abivalent,
Valvo war immer sehr bastlerfreundlich beim Datenblattversand, aber der
5 Pf Drehknopf von Radiorekorder war dann auch an teuen Messgeräten
verbaut. Es gab aber auch sehr pfiffige Schaltungen.


Butzo

 

[Eric Bruecklmeier]

Am 26.10.2019 um 11:55 schrieb Klaus Butzmann:

Am 26.10.2019 um 10:42 schrieb Eric Bruecklmeier:

Ich meine schon eher die neueren Flachglotzen - aber ich bin halt auch
geprägt, mir ist der Laden einfach grundunsympatisch...
Bei mir abivalent,
Valvo war immer sehr bastlerfreundlich beim Datenblattversand, aber der
5 Pf Drehknopf von Radiorekorder war dann auch an teuen Messgeräten
verbaut. Es gab aber auch sehr pfiffige Schaltungen.

Jenun, meine Meinung basiert auf der Erfahrung als Mitarbeiter...

 

[Klaus Butzmann]

Am 26.10.2019 um 11:59 schrieb Eric Bruecklmeier:

> Jenun, meine Meinung basiert auf der Erfahrung als Mitarbeiter...
Klar,
ist (war?) aber ein grosser Laden.

Je nach Abteilung findet man einen Laden toll oder katastrophal


Butzo

 

[Eric Bruecklmeier]

Am 26.10.2019 um 12:06 schrieb Klaus Butzmann:

Am 26.10.2019 um 11:59 schrieb Eric Bruecklmeier:

Jenun, meine Meinung basiert auf der Erfahrung als Mitarbeiter...
Klar,
ist (war?) aber ein grosser Laden.

Je nach Abteilung findet man einen Laden toll oder katastrophal

Hmmm, bei Philips und seinen Nachfolgern gibts da schon recht klare
Tendenzen - aber sicher gibts dort auch Ecken, wo es weniger Schlimm ist.

 

[Gerald Oppen]

Am 25.10.19 um 20:14 schrieb Eric Bruecklmeier:

Am 25.10.2019 um 19:17 schrieb olaf:
Eric Bruecklmeier <usenet@nerdcraft.de> wrote:

  >Ein Klemmender I2C Busteilnehmer blockiert aber u.U. Senden und
  >Empfangen und hat in der Regel auch keinen CS durch den er sich
  >deaktivieren ließe.

Es gibt mittlerweile auch welche die haben einen internen Timeout. Da
gibt es dann eine minimale Taktfrequenz fuer SCL. Und geben tut es das
weil den Herstellern auch schon aufgefallen ist das I2C nicht so ganz
das gelbe vom Ei ist.

Ich verstehe nicht so ganz, warum man krampfhaft versucht, I2C
aufzubohren, anstatt gleich was vernĂźnftiges zu nehmen...

Weil es einfach ist. Man kann masterseitig ohne Hardwareänderung
(fast)beliebig weitere Teilnehmer dran hängen. Bei SPI muss man dafßr
immer zusätzlich eine CS-Leitung pro Teilnehmer schaffen. Andere Busse
haben in der Regel noch größere Hardwareanforderungen.

Gerald

 

[Gerald Oppen]

Am 25.10.19 um 20:17 schrieb Eric Bruecklmeier:

...dann ist der Supergau bereits vorprogrammiert. Ich denke das sind 90%
aller Probleme. wenn man sich dessen bewusst ist, Fehler erkennt, den
Master
neu initialisiert und vorher mal ein paar Takte raushaut damit Slaves
den Arsch
wieder hochbekommen die SDA runterziehen dann laeuft es in 99% aller
Faelle gut.

Ändert aber nichts daran, daß auch Störungen als START interpretiert
werden...

Und wo ist dabei das Problem?
OK, wenn man ein ständiges Rauschen auf der Leitung hat das per Zufall
zum einen oder anderen gĂźltigen Protokoll fĂźhrt mag das ein Problem
werden kĂśnnen. Dann hat man aber schon grundlegend bei der
Hardwareauslegung etwas falsch gemacht.


Gerald

 

[Gerald Oppen]

Am 22.10.19 um 09:55 schrieb Holm Tiffe:

Warum versuchst Du Sowas nicht drahtlos zu lĂśsen, es gibt da IMHO
fertige Module wie dieses Node-MCU Zeuch mit Netzwerkprotokollen die
auch in der Lage sein sollten die Daten eines Sensors der gerade nicht
in Reichweite ist, weiter zu reichen.

Ich habe zur Heizdatenerfassung/Regelung mal Sowas vor, mir wäre der
Aufwand nachträglich Strippen zu ziehen zu hoch.

Zur Datenerfassung kann man so was machen, zur Regelung wĂźrde ich kein
Funk einsetzen wollen. Jedenfalls nicht fßr Geräte die länger als 1-2
Jahre genutzt werden sollen. Die Vergangenheit hat gezeigt dass man
immer damit rechnen muss das eine FunklĂśsung unbrauchbar wird weil z.B.
ein neues Mobilfunknetz aufgebaut wird mit dem die verbaute Funktechnik
nicht mehr klarkommt. Oder die VerschlĂźsselung nicht mehr ausreichend
ist,...

Gerald

 

[Gerald Oppen]

Am 22.10.19 um 08:48 schrieb Holm Tiffe:

Ein defekter Wehenschreiber stellt einfach die Arbeit ein, der schreibt
normalerweise keine falschen Wehen...

Die Annahme ist nicht zulässig.
Das Gerät ist "sicher", wenn es im Fehlerfall die Arbeit einstellt - OK.
Das muss aber keineswegs der Fall sein. Denkbar sind auch Fehler wie er
zeichnet die Ausstrahlungen des daneben stehenden Handys auf.

Gerald

 

[Gerald Oppen]

Als Basis wßrde ich sowas wie FHEM nehmen. Der Trend geht immer stärker
zu "SmartHome" was auch immer der einzelne darunter versteht.
Wichtig ist darauf zu achten dass FHEM & Co auch ausfallen dĂźrfen ohne
dass die Grundfunktionen verloren gehen, also der Lichtschalter
funktioniert, der Rolladen sich bedienen lässt und die Heizung im
sinnvollen Bereich läuft.
I2C fßr Temperatursensoren kann man nehmen bei wenigen Metern Buslänge.
Wenn man ein paar Messwerte verloren gehen spielt das bei einer Heizung
keine Rolle - sowieso bei einer sehr trägen Fußbodenheizung.
OnWire Sensoren sind die alternative. Die Daten kann man dann auf einem
"LAN-Client" Gruppenweise zusammen fassen. Da tut es ein leicht
modifizierter NET-IO von Pollin z.b. - inzwischen gibt es da sicher auch
moderneres. Nur per WLAN wĂźrde ich die Regelung nicht laufen lassen -
Bedienung ist was anderes, als vom Tablett aus konfigurieren.
Aussagen wie "ich brauch keine grafische Oberfläche" halte ich nicht fßr
zeitgemäß. Die bekommt man heute quasi geschenkt und helfen sehr das
ganze Bedienbar zu halten wenn man sich mal die Sommersaison Ăźber nicht
mehr mit seiner Heizung beschäftigt hat.


Gerald

 

[Wolfgang Allinger]

On 26 Oct 19 at group /de/sci/electronics in article h1intgFd1voU1@mid.individual.net
<Gerald.Oppen@web.de> (Gerald Oppen) wrote:

Am 25.10.19 um 20:14 schrieb Eric Bruecklmeier:
Am 25.10.2019 um 19:17 schrieb olaf:
Eric Bruecklmeier <usenet@nerdcraft.de> wrote:

 >Ein Klemmender I2C Busteilnehmer blockiert aber u.U. Senden und
 >Empfangen und hat in der Regel auch keinen CS durch den er sich
 >deaktivieren ließe.

Es gibt mittlerweile auch welche die haben einen internen Timeout. Da
gibt es dann eine minimale Taktfrequenz fuer SCL. Und geben tut es das
weil den Herstellern auch schon aufgefallen ist das I2C nicht so ganz
das gelbe vom Ei ist.

Ich verstehe nicht so ganz, warum man krampfhaft versucht, I2C
aufzubohren, anstatt gleich was vernünftiges zu nehmen...

Weil es einfach ist. Man kann masterseitig ohne Hardwareänderung
(fast)beliebig weitere Teilnehmer dran hängen. Bei SPI muss man dafür
immer zusätzlich eine CS-Leitung pro Teilnehmer schaffen. Andere Busse
haben in der Regel noch größere Hardwareanforderungen.

Und bei OneWire brauchste nicht mal son Aufstand.


Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Gerald Oppen]

Am 20.10.19 um 22:47 schrieb Ralph Aichinger:

Das ist doch sowieso irrelevant bei I2C, da die "Busteilnehmer" dafĂźr nicht
eigentlich adressierbar sind - manche Bausteine bieten zwar 2 oder 4 per
Jumper einstellbare Adressen, aber ansonsten sind die "Adressen" beim I2C
eher Bausteinkennungen, d.h. jeder IC hat eine typenspezifische "Adresse",
so daß es kaum möglich ist, mehrere baugleiche ICs am selben Bus zu
betreiben. Und soviele unterschiedliche Sensortypen, daß man damit ein
echtes Bussystem aufbauen kĂśnnte, gibt's fast garnicht.

Kann man nich z.B. in jedem AVR die Adresse setzen? Im schlimmsten Fall
verpaßt man dann jedem Busteilnehmer einen zusätzlichen AVR davor.

I2C Multiplexer gibt es.
Ja nach Anwendung bietet es sich auch an auf dem AVR den I2C per reiner
Software zu implementieren und mehrere unabhängige I2C Schnittstellen zu
schaffen.

Gerald