I2C-Bus an uC ohne passenden Anschluß

  • Thread starter Dschen Reinecke
  • Start date
D

Dschen Reinecke

Guest
Hi!

ich habe einen uC, der keinen passenden Anschluß für I2C hat. Kein
Problem, ich habe da mir was gebastelt, was klappt, möchte aber noch
wissen, was denn das Optimum wäre.

Da irgendewie das Umschalten einen I/O-Pins zur Laufzeit nicht richtig
klappte habe ich einenn Pin als Ausgang genommen und diesen über einen
1k-ohm-Widerstand mit einem Eingang und dem EEPROM verbunden. Da ich das
mit einem Entwicklingsboard gemacht habe hat jeder I/O-Pin noch einen
8k2-ohm-pull-up-widerstand:

--------o---- +5V
| |
R R
8 8
k k
2 2
| |
SDA out -----R1k0----o-------+---- EEPROM SDA
| |
SDA in --------------o--------

Ciao Dschen

--
Dschen Reinecke

=== der mit dem Namen aus China ==
http://WWW.DSCHEN.DE mailto:usenet@dschen.de
 
Dschen Reinecke schrieb:

ich habe einen uC, der keinen passenden Anschluß für I2C hat. Kein
Problem, ich habe da mir was gebastelt, was klappt, möchte aber noch
wissen, was denn das Optimum wäre.

Da irgendewie das Umschalten einen I/O-Pins zur Laufzeit nicht richtig
klappte [...]
Da wäre vielleicht zunächst mal zu klären, *warum* das nicht klappte.
Normalerweise ist das nämlich der gängige Weg, I2C mittels zwei
Portpins zu realisieren.
Also: welcher uC, welches Problem?

--
Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Maß.
http://www.autometer.de

==================================================================
In a world without walls and fences, who needs Windows and Gates ?
(Sun Microsystems)
 
Sauberer wäre eine Schottkydiode BAT41 z.B.

--+-- 5V
|
R1
|
in --+------ EEPROM
A
K
out --+


MfG JRD
 
Olaf Kaluza wrote:


Da wäre vielleicht zunächst mal zu klären, *warum* das nicht klappte.
Normalerweise ist das nämlich der gängige Weg, I2C mittels zwei
Portpins zu realisieren.
Also: welcher uC, welches Problem?

Fujitsu ľC, irgendwie klappte es nicht mit der Datenübertragung. Ich
hatte es heute In der Zeit zwischen 3h und 6h Nachts bemerkt. Es kann
sein, daß es auch ein problem meiner Leistungsfähigkeit war. Aber meine
Lösung klappt :)

Nach einem Umschalten der I/O hat er immer ein Hi gelesen :-(


Ich weiss das er soetwas eingebaut hat,
aber tu mal so als ob das nicht der Fall waere....
Bin ich mit dem 'er' gemeint? Mir ist der Sinn Deiner Zeilen irgendwie
nicht ganz klar.

Ciao Dschen

--
Dschen Reinecke

=== der mit dem Namen aus China ==
http://WWW.DSCHEN.DE mailto:usenet@dschen.de
 
Dschen Reinecke <usenet@dschen.de> wrote:

Ich weiss das er soetwas eingebaut hat,
aber tu mal so als ob das nicht der Fall waere....

Bin ich mit dem 'er' gemeint? Mir ist der Sinn Deiner Zeilen irgendwie
nicht ganz klar.
Wenn du eine I2C Schnittstelle irgendwo eingebaut hast dann koenntest
du gemeinst sein, sonst wohl eher nicht...

Olaf



--
D.i.e.s.S. (K.)
 
Olaf Kaluza wrote:


Ich weiss das er soetwas eingebaut hat,
aber tu mal so als ob das nicht der Fall waere....

Wenn du eine I2C Schnittstelle irgendwo eingebaut hast dann koenntest
du gemeinst sein, sonst wohl eher nicht...

Jetzt ist mir der Sinn Deiner Zeilen klargeworden...

Ich hatte gedacht Du meintest mich mit 'Du' und ich hätte soetwas (= den
Mega8) irgendwo eingebaut.

Ich ziehe mein Posting hiermit förmlich zurück. :)

Ciao Dschen

--
Dschen Reinecke

=== der mit dem Namen aus China ==
http://WWW.DSCHEN.DE mailto:usenet@dschen.de
 
Sebastian Voitzsch <Sebastian.Voitzsch@t-online.de> wrote:

Der mega162 hat kein Hardware-I2C eingebaut; es funktioniert mit der
Software-Lösung wunderbar; insbesondere reichen die internen PullUps.
Ich habe eine Softwareloesung in C die ich sowohl im Palmpiloten,
MCS51 und auch AVR verwende. Als ich auf dem Mega8 umgestiegen bin
wollte ich die dort auch verwenden um moeglichst schnell zu
Ergebnissen zu kommen.
Das hat da aber nicht funktioniert. Ursache war der interne
Pullup-Widerstand der Ports. Der ist zu stark als das ein I2C Ic den
runterziehen konnte. Also muss man den abschalten. Dies geschieht aber
durch beschreiben des Ausgangspins. Dadurch kommt es beim umschalten
vom Schreib in den Lesebetrieb einer Portleitung kurzeitig zu einem
Fehlimpuls den mein PCF8574 fehlgedeutet hat.

Macht aber nichts da der eingebaute I2C-Bus im Mega8 eine tolle Sache
ist und man den nach wenigen Minuten ans laufen bringen kann.

BTW: Benutzt hier einer Ponyprog? Das Programm hat wohl noch einen Bug
und brennt die Fuses fuer den Quarzoszillator am Mega8 invertiert.

Olaf

--
D.i.e.s.S. (K.)
 
Dschen Reinecke <usenet@dschen.de> wrote:
Rafael Deliano wrote:

Sauberer wäre eine Schottkydiode BAT41 z.B.

--+-- 5V
|
R1
|
in --+------ EEPROM
A
K
out --+


Danke!

koennte es sein, dass die diode falschherum eingezeichnet ist?
ich denke, *in* und *out* bezeichnen den port des uC.

gruesse, achim
 
--+-- 5V
|
R1
|
in --+------ EEPROM
A
K
out --+

koennte es sein, dass die diode falschherum eingezeichnet ist?
A = Anode , K = Kathode.
out=5V : Diode sperrt ; in = mittels R1 5V
out=0V : Diode leitet ; in = 0,4V

Wenn man das Signal für out in Software invertiert könnte man
auch BS107 Fet verwenden, dann hätte man sauberen Pegel 0V.

MfG JRD
 
Rafael Deliano wrote:
--+-- 5V
|
R1
|
in --+------ EEPROM
A
K
out --+

koennte es sein, dass die diode falschherum eingezeichnet ist?
A = Anode , K = Kathode.
out=5V : Diode sperrt ; in = mittels R1 5V
out=0V : Diode leitet ; in = 0,4V

Wenn man das Signal für out in Software invertiert könnte man
auch BS107 Fet verwenden, dann hätte man sauberen Pegel 0V.
Man koennte auch folgendes nehmen:

10 KOhm
___
+----|___|--- +5V
|\ G1 |
Out1 -----------| )----*------------ SDA
|/ |
| 10 KOhm
In 1 ------------------+ ___
+-|___|--- +5V
|\ G2 |
Out2 -----------| )-------*--------- SCL
|/

G1 = G2 = 1/6 74LS07

Wer gerne invertiert kann auch den 74LS06 nehmen.
Open-Collector ist hier wichtig.

Gerrit
 
Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:

Man koennte auch folgendes nehmen:

10 KOhm
___
+----|___|--- +5V
|\ G1 |
Out1 -----------| )----*------------ SDA
|/ |
| 10 KOhm
In 1 ------------------+ ___
+-|___|--- +5V
|\ G2 |
Out2 -----------| )-------*--------- SCL
|/

G1 = G2 = 1/6 74LS07

Wer gerne invertiert kann auch den 74LS06 nehmen.
Open-Collector ist hier wichtig.
Man sollte dabei aber beachten, dass manche I2C-Bausteine die Taktrate
herabsetzen, indem sie die SCL-Leitung einige Zeit festhalten. Deshalb
muss auch für SCL eine Rückführung am Puffer G2 vorbei zu einem Eingang
des Microcontrollers führen. Die Beschaltung muss also genauso sein, wie
für SDA. Es sind damit am Microcontroller vier I/O-Pins notwendig.



Grüße,

Günther
 
Günther Dietrich wrote:

Danke allen für die Hinweise!


Man sollte dabei aber beachten, dass manche I2C-Bausteine die Taktrate
herabsetzen, indem sie die SCL-Leitung einige Zeit festhalten. Deshalb
muss auch für SCL eine Rückführung am Puffer G2 vorbei zu einem Eingang
des Microcontrollers führen. Die Beschaltung muss also genauso sein, wie
für SDA. Es sind damit am Microcontroller vier I/O-Pins notwendig.
Ich verwende serielle EEPROMS 24Cxxx, in keiner deren Datenblätter habe
ich entsprechendes gelesen. Was für Bausteine verfahren so?

Ciao Dschen

--
Dschen Reinecke

=== der mit dem Namen aus China ==
http://WWW.DSCHEN.DE mailto:usenet@dschen.de
 
Dschen Reinecke wrote:

Ich verwende serielle EEPROMS 24Cxxx, in keiner deren Datenblätter habe
ich entsprechendes gelesen. Was für Bausteine verfahren so?
Dieses als Stretching bezeichnetes Verfahren ist Bestandteil des
I2C Standards, so daß jeder I2C Slave so verfahren kann.

Einige EEPROMs machen das IHMO z.B., während sie einen Block
wegschreiben.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-a@linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de
 
"Günther Dietrich" <guenther_dietrich@despammed.com> wrote:

Bausteine, die der Spezifikation für I2C entsprechen. Nicht alle. Es
muss auch nicht im jeweiligen Datenblatt erwähnt werden (sollte aber).
Es steht ganz einfach in der I2C-Spec drin, dass ein langsamer Baustein
den Takt auf diese Weise bremsen kann, wenn er ihm zu schnell ist.
Ja. Es gibt aber nur sehr, sehr wenige Bausteine die dies wirklich tun
(praktisch kenne ich gar keinen). Insbesondere die genannten EEPROMs
bremsen nicht den Takt herunter, sondern verzögern lediglich den
ACK-Impuls, wenn sie etwas Bedenkzeit brauchen.

Wenn man nicht gerade einen I2C-Debugger oder etwas Ähnliches bauen
will, ist es daher meist sicher, I2C nur als Ausgang vorzusehen.

Hergen
 
Rafael Deliano <Rafael_Deliano@t-online.de> wrote:
--+-- 5V
|
R1
|
in --+------ EEPROM
A
K
out --+

koennte es sein, dass die diode falschherum eingezeichnet ist?
A = Anode , K = Kathode.
out=5V : Diode sperrt ; in = mittels R1 5V
out=0V : Diode leitet ; in = 0,4V

Wenn man das Signal für out in Software invertiert könnte man
auch BS107 Fet verwenden, dann hätte man sauberen Pegel 0V.

ok, ich haette genauer hinschauen sollen. das mit dem pullup erklaert
natuerlich die richtige funktion. Ich hatte beim kurzen Blick den Pullup
nicht beruecksichtigt.

sorry,

achim
 
Hergen Lehmann <hlehmann.expires.311203@snafu.de> wrote:

Bausteine, die der Spezifikation für I2C entsprechen. Nicht alle. Es
muss auch nicht im jeweiligen Datenblatt erwähnt werden (sollte aber).
Es steht ganz einfach in der I2C-Spec drin, dass ein langsamer Baustein
den Takt auf diese Weise bremsen kann, wenn er ihm zu schnell ist.

Ja. Es gibt aber nur sehr, sehr wenige Bausteine die dies wirklich tun
(praktisch kenne ich gar keinen). Insbesondere die genannten EEPROMs
bremsen nicht den Takt herunter, sondern verzögern lediglich den
ACK-Impuls, wenn sie etwas Bedenkzeit brauchen.
Den ACK-Impuls verzögern. Aha. Wie bitte machen diese Bausteine das,
ohne den zugehörigen Takt-Impuls per Stretching zu verlängern?

ACK einfach später zu liefern würde vom I2C-Master als nicht gesetztes
ACK und damit als Fehler aufgefasst, und würde eventuell sogar in das
nächste zu übertragende Byte hinein stören.


Kannst Du das bitte erklären?



Grüße,

Günther
 
"Günther Dietrich" <guenther_dietrich@despammed.com> wrote:

Den ACK-Impuls verzögern. Aha. Wie bitte machen diese Bausteine das,
ohne den zugehörigen Takt-Impuls per Stretching zu verlängern?
Sorry, war unklar ausgedrückt.
Sie tun es, indem sie während des internen Schreibzyklus zunächst gar
keinen Ack-Impuls mehr liefern. Der Master muß periodisch erneut
anfragen, bis der Baustein wieder antwortet. Siehe Datenblatt der
24Cxx-Reihe.

In jedem Fall wird SCL von diesen Bausteinen nicht angefasst.

Hergen
 
Hergen Lehmann <hlehmann.expires.311203@snafu.de> wrote:

In jedem Fall wird SCL von diesen Bausteinen nicht angefasst.
Ich muss gestehen ich habe bisher auch nie einen Baustein in den
Fingern gehabt der SCL befingert hat. Vielleicht kann ja mal einer ein
Beispiel nennen?

Olaf


--
D.i.e.s.S. (K.)
 
Olaf Kaluza <olaf@criseis.ruhr.de> wrote:

Hallo Olaf!

Hergen Lehmann <hlehmann.expires.311203@snafu.de> wrote:

In jedem Fall wird SCL von diesen Bausteinen nicht angefasst.

Ich muss gestehen ich habe bisher auch nie einen Baustein in den
Fingern gehabt der SCL befingert hat. Vielleicht kann ja mal einer ein
Beispiel nennen?
Es gibt Bausteine von Micronas, die so verfahren. Der MAS3507 ist so ein
Kandidat wenn ich mich nicht sehr täusche.
Olaf

Viele Grüße,

Christoph
 
Christoph Brinkhaus wrote:

Ich muss gestehen ich habe bisher auch nie einen Baustein in den
Fingern gehabt der SCL befingert hat. Vielleicht kann ja mal einer ein
Beispiel nennen?

Es gibt Bausteine von Micronas, die so verfahren. Der MAS3507 ist so ein
Kandidat wenn ich mich nicht sehr täusche.
Stimmt. Wenn der grad keine Zeit hat, um sich um I2C zu kümmern, zieht er
SCL auf LOW, um den Master zum Warten zu zwingen.

Sebastian
 

Welcome to EDABoard.com

Sponsor

Back
Top