Archiv verlassen und diese Seite im Standarddesign anzeigen : Frage bezüglich TWI bzw. I2C-Pegel
Hallo miteinander,
ich möchte einen Tiny85 als Slave und ein Raspberry Pi 2B+ als Master an einem TWI-Bus betreiben.
Pullup-Widerstände sind ja auf dem Pi-Board schon drauf (nach meinen Messungen sind die gegen 3,3V).
Da die Eingänge vom Pi ja auch nur 3,3V vertragen.
Jetzt meine Frage:
Was genau macht die Hardware im Tiny? Hab ich den TWI-Bus richtig verstanden, dass der eigentlich nur entweder in der Luft hängt oder gegen GND zieht?
Deswegen doch auch die Pullups...
Somit wäre es ja kein Problem den Tiny trotzdem mit 5V zu versorgen (bei 3,3V hätte ich probleme mit der Auslegung von nem Spannungsteiler an nem ADC).
Meinen Code für den Slave möchte ich auf dem hier aufbauen:
https://www.roboternetz.de/community/threads/22452-USI-interface-an-tiny-2313/page2?p=384610&viewfull=1#post384610
(Muss zugeben dass ich den Code noch nicht zu 100% verstanden habe)
Wäre wirklich genial wenn mir da jemande einen Rat geben könnte.:confused:
MfG iBot
wenn du auf der Seite des Tiny PullUp nach 5V verwendest, kann Strom von der 5V Versorgung zu deinem Raspi 3.3V fließen! Das wäre gefährlich! Außerdem würde je nach größe der Widerstände auf beiden Seiten dann ein Idle-Pegel > 3.3V liegen, was die Pins des Raspi beschädigen könnte!
Entweder du stellst sicher, dass deine Tiny damit klarkommt dass du nur 3.3V Pegel als "high" lieferst und verzichtest du PullUps am Tiny (nur bei kurzer Leitung) oder du musst die 3.3V mitbringen und am Tiny dann die PullUp anbringen (nur für größere Leitungslänge benötigt)
Bessere Lösung wäre einen FET als Bidirektionaler Pegelwandler
Falstad
(http://www.falstad.com/circuit/circuitjs.html?cct=$+1+0.000005+10.20027730826997+ 50+5+43%0AR+144+128+144+80+0+0+40+3.3+0+0+0.5%0AR+ 496+128+496+80+0+0+40+5+0+0+0.5%0Ag+144+304+144+33 6+0%0Ar+144+128+144+208+0+4700%0Ar+496+128+496+208 +0+4700%0Ar+272+128+272+208+0+4700%0Ar+368+208+368 +128+0+4700%0Aw+208+208+144+208+2%0Aw+272+208+304+ 208+0%0Aw+320+160+320+128+0%0Aw+272+128+320+128+0% 0Aw+368+128+496+128+0%0Aw+336+208+368+208+0%0Aw+43 2+208+496+208+1%0Aw+272+128+144+128+0%0As+144+208+ 144+304+0+1+false%0Af+320+160+320+208+0+1.5+0.02%0 Aw+208+208+272+208+1%0Aw+368+208+432+208+2%0As+496 +208+496+304+0+1+false%0Ag+496+304+496+336+0%0A)di e 4.7K Rs sind jeweils am Ende der der entsprechenden Leitung
Ist ein N-Channel hier die Symbole
(http://www.falstad.com/circuit/circuitjs.html?cct=$+1+0.000005+10.20027730826997+ 50+5+43%0AR+144+128+144+80+0+0+40+3.3+0+0+0.5%0AR+ 496+128+496+80+0+0+40+5+0+0+0.5%0Ag+144+304+144+33 6+0%0Ar+144+128+144+208+0+4700%0Ar+496+128+496+208 +0+4700%0Ar+272+128+272+208+0+4700%0Ar+368+208+368 +128+0+4700%0Aw+208+208+144+208+2%0Aw+272+208+304+ 208+0%0Aw+320+160+320+128+0%0Aw+272+128+320+128+0% 0Aw+368+128+496+128+0%0Aw+336+208+368+208+0%0Aw+43 2+208+496+208+1%0Aw+272+128+144+128+0%0As+144+208+ 144+304+0+1+false%0Af+320+160+320+208+0+1.5+0.02%0 Aw+208+208+272+208+1%0Aw+368+208+432+208+2%0As+496 +208+496+304+0+1+false%0Ag+496+304+496+336+0%0A)ht tps://en.wikipedia.org/wiki/MOSFET#Circuit_symbols (http://en.wikipedia.org/wiki/MOSFET#Circuit_symbols)
Hallo Ceos,
danke für deine Antwort.
Ok alles klar, wird dann wohl auf einen Pegelwandler hinauslaufen.
Aber nochmal zum Verständnis: Der Tiny gibt zu keinem Zeitpunkt wirklich ein High (5V) auf den Bus oder?
korrekt! aber sicher ist eben sicher :D
zum testen gehts auch so mit nur einem Pull Up nach 3.3V, vll. reicht das ja
oberallgeier
06.09.2016, 12:17
.. einen Tiny85 als Slave und ein Raspberry Pi 2B+ als Master .. Pullup.. auf dem Pi-Board schon drauf ..
wenn du auf der Seite des Tiny PullUp .. verwendest .. oder du musst die 3.3V mitbringen und am Tiny dann die PullUp anbringen (nur für größere Leitungslänge ..PullUps an Master und Slave? Da kenne ich nur ablehnende Meinungen. Kein Wunder, das ist auch nicht die Empfehlung der grundlegenden Spezifikation (THE I2C-BUS SPECIFICATION, VERSION 2.1, JANUARY 2000, Philips Semiconductors).
.. Der Tiny gibt zu keinem Zeitpunkt wirklich ein High (5V) auf den Bus oder?Solche Fragen beantwortet sicher das Datenblatt/I²C-Spezifikation.
.. wird dann wohl auf einen Pegelwandler hinauslaufen ..Ich frage mich, warum der Tiny85 nicht mit 3,3 V betrieben wird. Gibts dafür Gründe in der Beschaltung des tiny? Immerhin ist der tiny85/tiny85V bei 10 MHz bis 2,7V runter spezifiziert (siehe Datenblatt Rev. 2586Q–AVR–08/2013). KÖnnte das nicht Deine Probleme ziemlich einfach lösen ?
Unregistriert
06.09.2016, 12:36
Ok alles klar, wird dann wohl auf einen Pegelwandler hinauslaufen.
Aber nochmal zum Verständnis: Der Tiny gibt zu keinem Zeitpunkt wirklich ein High (5V) auf den Bus oder?
Im angesprochenen Code wird in "Usi_twi_slave_initialise:" mit
SBI PORT_USI, PIN_SCL 'PORT_USI |= (1<<PORT_USI_SCL) // Set SCL high
SBI PORT_USI, PIN_SDA 'PORT_USI |= (1<<PORT_USI_SDA) // Set SDA high
SBI DDR_USI, PIN_SCL 'DDR_USI |= (1<<PORT_USI_SCL) // Set SCL as output
CBI DDR_USI, PIN_SDA 'DDR_USI &= ~(1<<PORT_USI_SDA) // Set SDA as input
der Pullup von SCL (PIN_SCL) eingeschaltet und dann der Pin im DDR auf output geschaltet. Der Pin ist dann ein Ausgang mit High Potential und damit wird Vcc vom Tiny auf den Bus gelegt. Falls der Tiny mit 5V betrieben wird, kommen die auch auf den Bus.
also was die Widerstände angeht ist das doch eine Frage der Leitungslänge oder nicht?
Das mit dem Tiny auf 3.3V betrieben habe ich bewusst weggelassen, weil ich keine Infos dazu habe was der Tiny sonst noch alles steuert ... und die Verlockung die 3.3V aus dem Raspi zu benutzen möchte ich möglichst schnell wieder dämpfen, denn der Regler der diese 3.3V aufbringt ist nicht für übergroße Extralasten ausgelegt wohingegen man die 5V fast unbegrenzt belasten kann
der Pullup von SCL (PIN_SCL) eingeschaltet und dann der Pin im DDR auf output geschaltet. Der Pin ist dann ein Ausgang mit High Potential und damit wird Vcc vom Tiny auf den Bus gelegt. Falls der Tiny mit 5V betrieben wird, kommen die auch auf den Bus.
In den Code habe ich jetzt nicht hineingesehen, aber das ist ein böser Fehler!
Warum zum Geier wird für Slave Init überhaupt die Clock auf Ausgang geschaltet bzw. warum wird der Output für DAta und Clock überhaupt auf high gesetzt?
Wenn es als Slave mit externem Pull Up läuft sollte in alle 4 Zeilen CBI stehen!
Generell macht mir der gesamte I2C part in dem Code sorgen, der klingt überhaupt nicht gach konformen I2C der arbeite die ganze Zeit im Push-Pull Mode und nicht im Pull-Down! Das wird so nicht mit nem Raspi funktionieren ... jetzt tendiere ich doch auch zur Empfehlung den Tiny auf 3.3V zu betreiben!
Pullup-Widerstände sind ja auf dem Pi-Board schon drauf (nach meinen Messungen sind die gegen 3,3V).
Da die Eingänge vom Pi ja auch nur 3,3V vertragen.
Jetzt meine Frage:
Was genau macht die Hardware im Tiny? Hab ich den TWI-Bus richtig verstanden, dass der eigentlich nur entweder in der Luft hängt oder gegen GND zieht?
Deswegen doch auch die Pullups...
So ist es. Die 3,3V reichen nicht als standardkonformes High, da werden 3,5V erwartet. Im praktischen Betrieb wird es aber einfach funktionieren. Bevor du dir die Ohren mit nicht funktionierenden Pegelwandlern brichst, probier es einfach aus. Wenn man so die Threads verfolgt, kommen problematische Pegelwandler viel öfter vor, als zu niedrige High-Pegel.
Manche I2C Controler können auch einen SM-BUS Mode. Da sind die Pegel TTL-kompatibel und passen perfekt für 3,3V CMOS. Ob der Tiny das auch kann, weiß ich nicht. Viele PICs können es.
Somit wäre es ja kein Problem den Tiny trotzdem mit 5V zu versorgen (bei 3,3V hätte ich probleme mit der Auslegung von nem Spannungsteiler an nem ADC).
Das verstehe ich nicht.
MfG Klebwax
- - - Aktualisiert - - -
der Pullup von SCL (PIN_SCL) eingeschaltet und dann der Pin im DDR auf output geschaltet. Der Pin ist dann ein Ausgang mit High Potential und damit wird Vcc vom Tiny auf den Bus gelegt. Falls der Tiny mit 5V betrieben wird, kommen die auch auf den Bus.
Ich kann den Code nicht nachvollziehen, kenne den Chip nicht. Aber ein I2C Device, daß aktiv ein High auf den Bus legt, wird nicht funktionieren. Ein anderes Device kann zu jeder Zeit aktiv auf Low treiben, das kracht dann. Wenn der Code das wirklich so macht, ab in die Tonne.
Bitbangig Code macht das normalerweise so: eine 0 ins interne Latch vom Pin schreiben, dann und erst dann auf Ausgang umschalten. Um die Leitung dann wieder High zu bekommen, den Pin auf Input schalten und der Pullup macht das High. So gibt es keine Konflikte.
MfG Klebwax
Also das mit den 5V hat den Grund dass ich nicht noch mal den Spannungsteiler rumlöten will und noch ein PWM-Kanal mit 5V brauche (da fällt mir ein das kann ich ja mit nem Transistor anpassen...).
So gesehen wäre es eigentlich mit viel Aufwand möglich auf 3,3V umzusteigen.
Das mit dem Programm hab ich mir auch irgendwie deutlich einfacher vorgestellt.
Kenn ihr denn ein Projekt wo das ordenlich realisiert wurde?
Zum TWI bzw. USI-Slave über Bascom gibts ja im Internet doch recht wenig was mich weiter bringt.
Hab in der Zwischenzeit (bevor ich gelesen hab dass der Tiny mit ein High gibt) das Raspberry mit dem Tiny verbunden.
Keine Reaktion vom Tiny.
Pegel hab ich immer am Oszi gehabt, waren nie über 3,3V.
Seh ich das richtig, dass die realisierung mit einem Mega8 deutlich einfacher ist?
http://rn-wissen.de/wiki/index.php/TWI_Praxis
Werde vermutlich meine Platine noch mal überdenken...
Also ich hab jetzt einen Mega8 aufgelötet, alles auf 3,3V umgestellt (auch Spannungsteiler und PWM mit Pegelwandler) und durfte dann feststellen dass ein kleines Drähtchen eine Verbindung zwischen SDA und SCL hergestellt hat, was wohl das Hauptproblem war.
Konnte inzwischen eine Verbindung mit dem Raspberry herstellen.
Danke an alle die mitgedacht haben.
ich kann es bestätigen, zumindest bei 5V Arduinos (Uno und Nano, beide selber getestet) sind weder Level-Shifter noch zusätzliche Pullups nötig, wenn beide am selben Bus hängen und der Raspi Master ist, denn beide 1,8k Pullups des Raspi ziehen ja den Bus bereits auf +3,3V.
Das bestätigen auch Links im Web:
https://oscarliang.com/raspberry-pi-arduino-connected-i2c/
http://blog.oscarliang.net/ctt/uploads/2013/05/RaspberryPI-I2c-Arduino.jpg
Man könnte daher davon ausgehen, dass es auch mit anderen 5V AVRs genau so einfach funktioniert.
Beim Arduino Mega ist es problematischer, weil der selber eingebaute Pullups auf 5V besitzt (sowohl auf dem Chip (die müsste man vorher rauslöten) als auch auf dem Board (die kann man jederzeit in twi.c disabeln) ).
(Anm.: Allerdings gab es i2c-Kommunikationsprobleme, die auf clock stretching durch den Arduino zurückzuführen waren, die der Raspi (in C programmiert) nicht vertrug. Das muss aber nicht für andere AVRs gelten. )
warte warte warte ... der Raspi kann kein Clock Stretching? ... das ist schwach, da les ich mich nochmal genauer zu ein wenn ich Zeit habe
Genau, sag ich doch, zumindest nicht mit dem damaligen Kernel (bis Anfang April dieses Jahres). Dazu gibt es sogar hier im Forum ein Topic.
Das clock stretching wurde wohl durch den AVR Arduino verursacht (was viele auch im raspi Forum für die Ursache der i2c Datenübertragungsfehler hielten), und eben das vertrug der Raspi nicht, daher konnten mal keine großen Datenblöcke auf einmal übertragen werden und ein anderes Mal schmiss der Raspi sogar den Arduino aus seinem i2c Bus und erkannte ihn gar nicht mehr als i2c device unter seiner Busadresse.
Seit dem 10.4. gibt es allerdings einen neuen Kernel, vlt kann der mehr als der vorhergehende, seitdem habe ich die AVRs aber nicht mehr am Raspi-i2c-Bus getestet..
Mit dem Aruino DUE (andere berichteten, glaube ich, auch mit demZero) funkionierte aber vorher schon i2c immer außerordentlich zuverlässig.
ich bezog mich auch auf den "echten" i2c Modus, wie er unter C/C++ mit pigpio und wiringPi benutzt wird (mit Arduino per 100kHz, ansonsten mind. bis 400kHz), der wohl langsamere smbus-Modus als auch Software-Bitbanging waren in dieser Hinsicht toleranter. Auch zum letzteren gab es im besagten Topic Beispiele.
das smbus Protokoll definiert ja clock stretching, logisch dass es da verwendet wird.
Aber ich bin mir ziemlich sicher dass jedwede Hardware i2c Logik (also das peripheral im raspi SoC) auch dazu in der Lage ist aber die I2C-Libs das notwendigeFflag nicht einschalten .... einer der Gründe warum ich meistens doch lieber Bare Metal programmiere wenns ordentlich werden soll, Bibliotheken scheitern immer an DEtails die der Erfinder nicht bedacht hat.
...was erklärt, dass damals schon viele Raspi-"Fachleute" (Gordon Henderson, joan u.a.) das Problem schon kannten, samt möglicher Workarounds, und auch davon sprachen, dass ebenfalls die .org Entwickler das auch schon auf dem Schirm hatten und in "einer der nächsten" Kernel-Upgrades mit ändern wollten. Ich selber verstehe die hardwaremäßigen oder Programmier-technischen Einzelheiten nicht, ich kam nur drauf, dass ich es versuchte PI + Arduino zu verbinden, es aber nicht störungsfrei mit den AVRs funktionierte.
...was erklärt, dass damals schon viele Raspi-"Fachleute" (Gordon Henderson, joan u.a.) das Problem schon kannten, samt möglicher Workarounds, und auch davon sprachen, dass ebenfalls die .org Entwickler das auch schon auf dem Schirm hatten und in "einer der nächsten" Kernel-Upgrades mit ändern wollten. Ich selber verstehe die hardwaremäßigen oder Programmier-technischen Einzelheiten nicht, ich kam nur drauf, dass ich es versuchte PI + Arduino zu verbinden, es aber nicht störungsfrei mit den AVRs funktionierte.
Wenn ich mich recht erinnere ist bzw. war das so:
Der Prozessor im Raspi unterstützt schon Clock stretching, der Treiber ebenfalls. Es gab aber einen Bug im Chip der dazu führt, daß in einem bestimmten Zeitfenster nach dem ACK-Bit das Clock stretching nicht erkannt wurde. Das ist aber nun genau die Stelle, die am kritischsten ist, nach dem ACK-Bit passiert das am häufigsten.
Da der Raspi nicht mein Ding ist, hab ich keinen Link aufgehoben und kann das nicht mehr nachvollziehen. Ob inzwischen der Chip gefixt ist oder eine Reparatur in Software möglich ist, hab ich nicht verfolgt.
MfG Klebwax
das führt uns jetzt zwar von dem 5V/3.3V i2c Problem mit/ohne Pullups u/o Levelshiftern weg, würde aber dann sicher bedeuten, dass es bei einem Chip-Hardware-Bug nicht allein durch ein Jessie-Kernel-Upgrade gelöst werden kann, oder?
Außerdem wäre interessant zu wissen, welche Chips von diesem Bug betroffen waren - da ich den Pi2 habe, mit dem es diese Probleme gab, wäre zu vermuten, dass es dann möglicherweise nicht unbedingt auch mit dem B+ oder Pi3 der Fall ist/war oder sein muss?
das führt uns jetzt zwar von dem 5V/3.3V i2c Problem mit Pullups u/o Levelshiftern weg, würde aber dann sicher bedeuten, dass es bei einem Chip-Hardware-Bug nicht allein durch ein Jessie-Kernel-Upgrade gelöst werden kann, oder?
Außerdem wäre interessant zu wissen, welche Chips von diesem Bug betroffen waren - da ich den Pi2 habe, mitt dem es diese Perobleme gab, wre zu vermuten, dass es dann möglicherweise nicht unebsingt auch mit dem B+ oder Pi3 der Fall ist/war oder sein muss?
Ob das in SW gefixt werden kann, weiß ich nicht. Der Floating Point Bug in einer Version der Pentiums ließ sich in SW umgehen, bis die Chips OK waren. Da ich mich nicht besonders um den Pi und seinen Prozessor gekümmert habe, kann ich nicht mehr sagen.
MfG Klebwax
avr_racer
11.09.2016, 11:32
Hallo miteinander,
ich möchte einen Tiny85 als Slave und ein Raspberry Pi 2B+ als Master an einem TWI-Bus betreiben.
Pullup-Widerstände sind ja auf dem Pi-Board schon drauf (nach meinen Messungen sind die gegen 3,3V).
Da die Eingänge vom Pi ja auch nur 3,3V vertragen.
Jetzt meine Frage:
Was genau macht die Hardware im Tiny? Hab ich den TWI-Bus richtig verstanden, dass der eigentlich nur entweder in der Luft hängt oder gegen GND zieht?
Deswegen doch auch die Pullups...
Somit wäre es ja kein Problem den Tiny trotzdem mit 5V zu versorgen (bei 3,3V hätte ich probleme mit der Auslegung von nem Spannungsteiler an nem ADC).
In der Luft sollte der nicht hängen denn dafür gibs ja die Pullups. Diese werden benötigt da I2C OpenCollector ist, somit sind auch unterschiedliche Versorgungsspannungen der Einzelgeräte möglich. Wenn, wie in deinem Falle Master mit 3,3V und der Tiny mit 5V betrieben wird, ist das unkritisch. Die Pulls hängen für beide an 3,3V und für den Tiny85 bedeutet:
3,3V
Lowpegel 0V - 0,5V
Highpegel 2,5V - VCC
5V
Lowpegel 0V - 0,6V
Highpegel 2,5V - VCC
Auf seite 161 unter Vol / Voh nachzulesen.
Ist zwar nicht die 100% Lösung und man müsste sich mal das LogicLevel des PI's anschauen
Der Tiny85 hat eine USI, die ein wenig mehr an Modes kann. Seite 112 ist mal für die USI beschrieben welche Möglichkeiten bestehn.
http://i2c2p.twibright.com/spec/i2c.pdf
Auf Seite 42 mal die Widerstände und 43 die Möglichkeit 100%kompatibel zu sein.
Meinen Code für den Slave möchte ich auf dem hier aufbauen:
https://www.roboternetz.de/community/...l=1#post384610
(Muss zugeben dass ich den Code noch nicht zu 100% verstanden habe)
Wäre wirklich genial wenn mir da jemande einen Rat geben könnte.
MfG iBot
https://www.roboternetz.de/community/threads/22452-USI-interface-an-tiny-2313/page3
Peter(TOO)
14.09.2016, 02:46
Hallo iBot,
Jetzt meine Frage:
Was genau macht die Hardware im Tiny? Hab ich den TWI-Bus richtig verstanden, dass der eigentlich nur entweder in der Luft hängt oder gegen GND zieht?
Deswegen doch auch die Pullups...
Nennt sich dann wired-OR oder wired-AND, je nachdem wie die Pegel definiert sind.
Technisch hat es den Vorteil, dass es keinen Kurzschluss auf dem Bus geben kann, wenn unterschiedliche Pegel gleichzeitig ausgegeben werden. Zudem kann man Leitungen sparen.
Der Nachteil liegt darin, dass die Buslänge die Geschwindigkeit beeinflusst.
Jede Leitung hat eine Kapazität, je länger um so grösser ist diese. Beim Sprung von 0 auf 1 wird diese Kapazität nur über den PullUp geladen, man bekommt also diese e-Funktion als Spannungsverlauf. Schneller kann man werden, indem man die PullUps oder/oder die Kapazität kleiner macht. Das wird aber schnell unwirtschaftlich.
Beim I2C wird dies z.B. beim Clock-Streching verwendet, da spart man eine Leitung. Der Master gibt den Clock aus. Kommt der Slave nicht mit, zieht er einfach den Clock gegen Masse und verhindert so den nächsten Takt. Der Master erkennt, dass er zwar den Clock auf 1 gesetzt hat, dieser aber immer noch auf 0 liegt. Somit muss der Master dann warten, bis der Clock auf 1 geht.
MfG Peter(TOO)
Eine typische Anwendung war z.B. ein Interrupt-Eingang. Jede Einheit zieht einfach die Leitung gegen Masse, dabei ist es egal wann und wie viele Einheiten angeschlossen sind. Die ISR sucht dann die erste Einheit, welche den Interrupt aktiviert hat, bedient diese und die Einheit hört auf die Leitung nach Masse zu ziehen. War es der einzige Interrupt geht dann die Leitung auch auf 1. Andernfalls stehen noch weitere Interrupts an.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.