Input beim MCP23017

[Klebwax]

Mag sein, dass manche Library die Unterscheidung zwischen Adresse und Control Byte nachvollzieht

Dann würde sie sich daran orientieren, was im geschriebenen Standard und eigentlich auch in allen Datenblättern der Bausteine steht. Es gäb dann natürlich auch nicht mehr soviele Threads in den Foren "Kann meinen I2C Slave nicht ansprechen" oder

Er hört allerdings auf die Adresse 0x40 anstatt auf 0x20..gibt es hier Bauart Unterschiede

(letztere Betrachtungsweise finde ich irreführend, wiel ich bei 0x'irgendwas' eben an 8-Bit-Einheiten denke.)

Warum grad 8 und nicht 16, 32 oder 64? Es gibt auch genügend kleinere Werte, Prescaler Register z.B. die dann auch noch auf ungraden Bitadressen liegen. I2C mit Adresse und R/W Bit ist ja noch harmlos, schau dir mal andere Protokolle an. Da werden die Bytes (meist Oktets genannt) munter mit unterschiedlich großen Werten gefüllt. Und wenn 8 mal nicht reichen, 16 aber zu viel sind werden die Reste in einem Byte gesammelt (Nunchuk). Wenn man damit arbeiten will, muß man sich das natürlich immer passend zusammensetzen.

MfG Klebwax

[HaWe]

@modtronic:
zum Einen darfst du nicht vergessen: i2c-Funktionen sind keine Funktionen der Sprache C oder C++, das gibt es dort nicht. Deshalb gibt es keinen Standard dafür.
Es sind mehr oder weniger komplexe Implementierungen in Form von verschiedensten API libs, die die Basis-Funktionen (reine file Operationen) mit Wrappern "angenehmer" machen.
Aber auch File-I/O ist eigentlich kein C-Standard, sondern wieder in optionalen Libs definiert, wie zB. stdio.h .
Gerade AVRs haben aber gar nicht das "übliche" stdio.h, sondern was ganz anderes, z.B. lib.c und ähnliches, was es aber für GCC C auf Linux nicht in dieser Form gibt.
Also ist dein Problem kein C Problem, sondern ein ganz spezielles AVR-Library-Problem; wie es mit GCC samt Linux Libs geht, habe ich ja oben erklärt, da sind die Libs halt einfach besser verständlich oder praktischer anwendbar.
Noch einfacher als Basis-File-I/O gehen komplexere Libs wie wiringPi, die dort ebenfalls gern verwendet werden.
Aber auch für AVRs gibt es so etwas für C/C++, z.B. von Arduino, deswegen wird Arduino so gern genommen (hier ist es die Wire-Class).
Nützt dir ntl nichts, wenn es so etwas für deine Plattform nicht gibt, dann musst du es selber bauen.

Oder zu Arduino überwechseln.

Zu deinem Problem:
Bevor du an 2 Fronten mit 2 MCPs kämpfst, musst du erstmal jeden einzeln beherrschen.
Es klingt ja, als ob du den 1. schon mal auslesen kannst.
Jetzt versuche deinen 2. MCP mit anderer Adresse von einem extra Programm aus einzeln anzusprechen, zum Schreiben.
Versuche z.B. einzelne LEDs einzeln mit Software-Befehlen an und auszuschalten (ohne externe Taster, z.B. einfach als Lauflicht in einer for() Schleife).
Kannst du das?
Mit "meinen" GCC Linux API Libs klappt das, also muss es auch mit "deinen" funktionieren, nur eben mit anderer Syntax (die ich aber nicht kenne).
Wenn du das dann kannst, versuche den Input vom ersten (z.B. per 16 einzelne Taster) 1:1 auf den 2. zu übertragen (Anzeige dort über 16 einzelne LEDs).

Hier siehst du so ein Beispiel für GCC mit Linux und wiringPi, nur um das Prinzip deutlich zu machen:
http://wiringpi.com/extensions/i2c-mcp23008-mcp23017/