wie kann ich das am elegantesten lösen? ich hab mir eine kleine DigiCAM gekauft, welche über einen I2C-Bus programmierbar ist! hab daraufhin ein bisschen herumprobiert aber keinerlei Erfolge verzeichnet! aja, ich programmier in Assembler! kann mir da jemand helfen? mfg ubootfanat
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.