I2C mit mega8515

Hi

hierich
fingerheb
http://www.lugbz.org/documents/smart-questions_de.html

Matthias

hallo,

hast du irgentwelche doku dazu bekommen ?

Das Kameramodul heißt COmedia 3088, ist mit i2c-bus zu programmieren und
ich möchte dazu einen ATmega8515 verwenden!

alles was in im Datenblatt der CAM zu finden war:

* Programmierung über I2C-Bus
* CAM-Adresse
* Registeradressen
* Registerbeschreibung

kein Zeitverlauf, kein GarNix

sonst hätt ich hier keine Frage gepostet!

also nochmal die Frage:
wie kann ich das am elegantesten Lösen (SPI, UART, ...)??

mfg Florian

PS: nix für ungut :-)

Tja, dass sieht erstmal nach falscher Prozessorwahl aus.

I2C heisst bei Atmel TWI und der 8515 ist einer der wenigen
Prozessoren, der das eben nicht kann (es sei denn, man "strickt" es
selbst).

Aber selbst wenn Du jetzt weisst, wie Du Daten an die Kamera senden
kannst, weisst Du immer noch nicht, welche Daten Du ihr senden musst,
damit sie tut, was Du willst. Und Trial-und-Error ist sehr
frustrierend.

Also, ohne Datenblatt, vergiss es. Oder frag Deinen Händler.

Sebastian

@Sebastian: Er hat doch Registeradressen + Beschreibung. Das sollte
reichen.
@ubootfanat:
Timing gibts bei I2C (TWI) so gut wie nicht. Es ist ein synchroner,
bidirektionaler serieller Bus. Synchron heißt: Es gibt ein Taktsignal.
Ich würde Dir folgendes empfehlen: Besorg Dir bei Reichelt einen
PCF8574, das ist ein 8-Bit I/O-Port mit I2C-Ansteuerung. Mit dem kannst
Du gefahrlos herumexperimentieren, bis Deine I2C-Routinen funktionieren,
wäre nicht so berauschend, wenn Du wild in Deiner Kamera irgendwelche
Register veränderst. Eine Alternative wäre auch der PCF8584, das ist
ein I2C-Controller, den Du am Atmel anschließen könntest.
I2C ist aber nicht so tragisch, das kann man auch per Software machen.
Tipp: Entsprechende Infos aus dem Netz saugen (schau Dich mal beim
Erfinder des I2C, Philips, um). Man kann übrigens den Bus sehr weit
verlangsamen - sogar so weit, daß man per LEDs die Übertragung sehen
kann. Das hilft bei der Fehlersuche ebenfalls.
Wichtig ist, daß Du Dir erst einmal das Protokoll (mit Start, Stop und
Acknowledge-Bits) verinnerlichst.

hab mir mehrere Controllerprogramme gesaugt und den Zeitverlauf
rekonstruiert --> so ziemlich das gleiche als das, was mein Prog
fabriziert!

das einzige, wo keines der Programme gleich ist, ist das ACK-Bit!
manche schreiben gar keinen CLK auf den Bus und warten einfach so,
andere schreiben CLK und empfangen und wieder andere schreiben CLK und
setzen SDA = 0!

hab mir schon ein Datasheet von Philips bez. I2C-Bus besorgt, aber mit
dem ACK komm ich nicht zurecht! könnt ihr mir da helfen

mfg florian

PS: die Controllerwahl hab nicht ich getroffen

Das ACK ist ein Low nach dem übertragenen Byte. Das Low wird vom Slave
gebildet. Der Master schaut in den 9. Takt nach, ob der Bus Low ist.
Wenn das letzte Byte z. B. vom Master gelesen wurde, wird kein ACK (vom
Master) verlangt, sondern danach wird eine Stop-Condition gesendet und
der Bus ruht. Bei vom Master gesendeten Daten wird immer mit dem ACK
gesendet, das heißt nach jedem übertragenen Byte (Master -> Slave) wird
im 9. Takt ein Low auf der SDA-Leitung erwartet. Und da I2C oder TWI
einem Standard entsprechen, sollte das bei allen Devices so sein.
Michael