mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega an SMBus eines Motherboards anschließen


Autor: berlibaer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin dabei eine Art Lüftersteuerung für meinen Rechner zu bauen.
Zur Erfassung von Temperaturen und Lüfterdrehzahlen verwende ich ICs von 
maxim (max1668, max6651, max6657). Die Werte werden von einem ATmega16 
über TWI ausgelesen und auf zwei LCDs (hd44780-kompatibel) angezeigt. So 
weit läuft auch alles. ich würde die Werte aber gerne auch parallel mit 
dem Rechner auswerten / aufzeichnen. Die ICs allein kann man einfach an 
den SMBus hängen und mit einer Software namens Motherboardmonitor (MBM) 
auslesen. Funktioniert auch (die Chips werden jedenfalls erkannt). Wenn 
ich nun aber das ganze Teil mit ATmega an den SMBus hänge, dann ist der 
Bus blockiert. Weder MBM zeigt dann etwas an (auch die Werte der 
rechnereigenen Sensoren sind dann alle 0), noch die Werte auf den LCDs 
werden aktualisiert.
Kann mir jemand sagen, was ich beachten muss, wenn ich einen ATmega in 
den SMBus eines Motherboardes einbinde!? Geht das überhaupt?
Ich habe bereits auf gut Glück die PullUp-Widerstände im ATmega 
deaktiviert, aber das hat nichts gebracht. Einen Adresskonflikt dürfte 
es auch nicht geben.

MfG, Enrico

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mögliche Ursachen (die mir so auf die Schnelle einfallen):

- I²C-Adressen doppelt vergeben

- Busarbitrierung (für Multimaster) auf dem AVR nicht richtig
  implementiert

Autor: Klaus R. (klaus2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...in den maxim datenblättern sieht man evtl was zum sm-bus, dem 
protokoll, den hw-treibern? ohne dieses wissen ist das alles recht vage 
- ich meine, man schließt ja auch nicht pd0 & pd1 an ein cat7 und 
erwartet IPv6 kompatibilität :)

Klaus.

Autor: berlibaer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die schnellen Antowrten.

Seltsamer Weise geht es nun doch... ohne eine bewußte Änderung. Die 
Methode hat allerdings so ihre Macken. Nichts dramatisches und relativ 
einfach zu beheben, aber irgendwie stümperhaft g
Ich werde den Datenaustausch über die serielle Schnittstelle laufen 
lassen und zur Auswertung ein kleines Proggi schreiben. Damit kann ich 
das ganze Teil dann auch konfigurieren, ohne jedesmal ein neues Programm 
auf den ATmega spielen zu müssen.
Ich liebe Herausforderungen...

MfG, Enrico

Autor: berlibaer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kennt vll jemand sowas wie den max232 mit TWI-Interface!?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>kennt vll jemand sowas wie den max232 mit TWI-Interface!?

Ja, ein uC mit TWI Interface + UART der dann an max232 geht.

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt auch TWI UARTs, dann kann man sich den µC sparen.

Autor: berlibaer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok... hatte gehofft so etwas gibt es in einem stück.

andere frage:
in dem avr-tutorial unter uart sind nur die txd und rxd pins vom 
com-port belegt. reicht ds wirklich aus, oder brauche ich auch die 
ganzen anderen signale?
wenn die beiden leitungen reichen, dann brauch ich den umweg über's twi 
nicht zu machen, hab nämlich nur noch 2 ports frei.

noch eine andere frage:
noch genialer wäre es das ganze über usb zu machen. gibt es außer dem 
ft232 noch einen ic, der als uart-usb-bridge fungieren kann. der ft232 
ist mir etwas zu kompliziert und ob wie es bei dem mit den 
hand-shake-leitungen des uart aussieht (gleiche frage stellung wie bei 
der anderen frage).

mfg.

Autor: berlibaer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habe mir gerade mal das datenblatt vom ft232 r-typ angesehen, nachdem 
ich hier in einem anderen thread gelesen habe, der soll einfacher zu 
handhaben sein. der ist eigentlich recht pflegeleicht und braucht laut 
einem beispiel nur höchstens 4 pins für's uart: txd, rxd, cts und rts. 
kann ich die letzteren beiden auch weglassen?

Autor: butrus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"...txd, rxd, cts und rts. kann ich die letzteren beiden auch weglassen?"

Man kann. Wenn man die aber benutzt, dann kann man sicher sein, dass man 
kein  einziges byte verliert...

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> höchstens 4 pins für's uart: txd, rxd, cts und rts. kann ich die
> letzteren beiden auch weglassen?

Klar. Du kannst den Handshake entweder softwaremäßig machen oder von
vorne herein dafür sorgen, dass immer nur so viele Daten übertragen
werden, dass der Empfangspuffer auf keiner Seite überläuft. Ich selbst
benutze den hardwarehandshake so gut wie nie.

Autor: berlibaer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!

ich habe mich allerdings entschieden das spi zu benutzen. zum 
programmieren sind dessen pins sowieso auf einen stecker gezogen. sie 
waren nur eigentlich im normalen betrieb auch noch mit status-leds 
beschaltet. die hab ich jetzt verlegt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.