SPI to sbus (SHT10) transceiver

[Lars H. (larsho)]

Guten Abend,

nach langer suche werde ich diese Frage mal ins Forum stellen.

Ich würde gerne eine SHT10 (sBus SCK; DATA) mit dem SPI-Bus eines 
Atmega8 verbinden.
Gibt es irgendwelche IC's, mit denen ich die MISO und MOSI Leitung 
zusammenfassen kann.

Habe mal nach transceivern gesucht... aber nur differentielle gefunden.


Den I2C will ich eigentlich nicht verwenden, da dieser als Slave 
betrieben wird.

Vielen Dank für eure Tipps

Lars

[cskulkw (Gast)]

Hallo Lars

ich habe vor kurzem den SHT11 zum laufen gebracht. Aus dem Datenblatt 
hatte ich verstanden, dass das I2C- Protokoll nicht vollständig 
implementiert worden sei. Sprich den Komfort der TWI-Schnittstelle kann 
man nicht nutzen.
Ich habe dann die Bits klappern lassen. Dafür kann ich jetzt den Sensor 
an jeden beliebigen Portpin anschliessen.
Mit SPI funktioniert es gar nicht. Da wirst Du nicht weiter kommen.

[STK500-Besitzer (Gast)]

cskulkw schrieb:
> Mit SPI funktioniert es gar nicht. Da wirst Du nicht weiter kommen.

Geht wohl...
Beim SHT werden die Daten in beide Richtungen auf einer Leitung 
übertragen, wie es bei I²C/TWI üblich ist.
Sensirion wollte sich wohl einfach Lizenzbgebühren sparen - daher ist 
der Bus dem I²C nur sehr ähnlich.
Man muss auf der Controllerseite nur die Daten entkoppeln.
Es spricht ja nichts dagegen, wenn der Controller quasi seine eigenen 
Daten empfängt.
Ich habe sowas vor ein paar Jahren für einen SHT11 mit einem 
74HC125-Gatter gemacht, um den Sensor über einen Satz differentieller 
Leitungen (3 Paare) zu betreiben.
Eine Clockleitung, eine Datensendeleitung und eine Datenempfangsleitung.
Soweit ich mich noch erinnere, hatte ich am Ausgang des Gatters einen 
Pull-Up-Widerstand, Der Eingang lag auf GND und die Datenleitung hat den 
Tri-State-Eingang geschaltet.
Müsste man mal "durchrechnen".
Ich weiß es nicht mehr genau, und die Unterlagen sind inzwischen 
vermutlich mit in die Konkursmasse eines gewissen Fotokonzerns 
übergegangen...

[cskulkw (Gast)]

@ STK500-Besitzer.

O.K. wenn man den entsprechenden Aufwand treibt, dann geht eigentlich 
alles.

Aber ein intelligenter Sensor mit einer standardisierten Schnittstelle 
dient normalerweise dazu, den Benutzer das Leben etwas zu erleichtern.
Insofern habe ich die nicht vollständige Umsetzung des I2C beim SHT1x 
nicht verstanden.

Mittlerweise gibt es ja den SHT21. Dieser kann jetzt auch am 
TWI-interface normgerecht betrieben werden.

Letzlich muß sich Lars entscheiden, ob er zusätzliche Bauteile verwenden 
will oder lieber etwas programmieren möchte. Ich habe mich für das 
letztere entschieden, weil ich dann den Sensor an jedem beliebigen 
IO-Port anschließen kann. Da der Sensor ohnehin nicht zu oft ausgelesen 
werden sollte, um Eigenerwärmung und damit die Verfälschung der 
Messergebnisse zu vermeiden. Deshalb ist die Softwarelösung nicht 
schnell aber ausreichend und flexibel.

Ich gebe jedoch zu, dass ich eine Weile dran gesessen hatte, bis es 
lief.

[STK500-Besitzer (Gast)]

cskulkw schrieb:
> @ STK500-Besitzer.
>
> O.K. wenn man den entsprechenden Aufwand treibt, dann geht eigentlich
> alles.
Bei der Vorgabe SHT10 und SPI wäre das eine Lösung.
Den 74HC125 gibt es in SMD auch als einzelnes Gatter. Dadurch wurde die 
Platine damals nicht wesentlich größer.

>
> Aber ein intelligenter Sensor mit einer standardisierten Schnittstelle
> dient normalerweise dazu, den Benutzer das Leben etwas zu erleichtern.
> Insofern habe ich die nicht vollständige Umsetzung des I2C beim SHT1x
> nicht verstanden.
Da hat Sensirion entweder Probleme mit Lizenzgebühren gehabt, oder einen 
deppigen Entwickler.

>
> Mittlerweise gibt es ja den SHT21. Dieser kann jetzt auch am
> TWI-interface normgerecht betrieben werden.
... immer noch kein SPI.
>
> Letzlich muß sich Lars entscheiden, ob er zusätzliche Bauteile verwenden
> will oder lieber etwas programmieren möchte. Ich habe mich für das
> letztere entschieden, weil ich dann den Sensor an jedem beliebigen
> IO-Port anschließen kann. Da der Sensor ohnehin nicht zu oft ausgelesen
> werden sollte, um Eigenerwärmung und damit die Verfälschung der
> Messergebnisse zu vermeiden. Deshalb ist die Softwarelösung nicht
> schnell aber ausreichend und flexibel.
>
> Ich gebe jedoch zu, dass ich eine Weile dran gesessen hatte, bis es
> lief.
ca. 20 Stunden inkl. Platine...