Zitat Zitat von Dirk
@Rolf:
Du bleibst ja energisch am Ball. Komplement! =D>
Naja ich will das es funktioniert... ich kauf mir keine Zusatzboards wenn die am TWI nur so vor sich hin stottern... alles Eigennutz

Zitat Zitat von Dirk
Kurze Frage als Beta-Tester:
Warum wird der M32 Master mit I2CTWI_initSlave(12) initialisiert?
Muss ich ihn in der twi_target.h auch als Slave (#define TWISLAVE) definieren, weil als Master das I2CTWI_initSlave(12) zum Fehler führt?
Nein.. ja.. das auch.. aber es hat andere Gründe. Technisch gesehen gibts zwischen der Master und Slave Init ganze 3 Unterschiede. Der Master kann ohne eigene Adresse leben funktioniert aber auch mit dieser, der Slave ohne Geschwindigkeitsangabe und funktioniert mit dieser und letztlich macht der Master im Init ein NACK und der Slave ein ACK.
Dazu braucht es keine 2 separaten Funktionen, es reicht wenn diese Daten da sind, zur Not eben Defaultwerte. Daher habe ich in der aktuellen Codefassung nicht mal mehr ein Unterschied sondern gleich alles in eine Funktion gesetzt.
Code:
void I2CTWI_init(uint8_t dummy)
{
	UNUSED(dummy); // reserved, set up speed and OWN address in twi_target.h

	TWI_operation = I2CTWI_NO_OPERATION; //Setup defaults
	bitset(TWI_statusReg,STR_lastTransOK);
	bitclr(TWI_statusReg,STR_needAction); // we start clean
 	bitclr(TWI_statusReg,STR_isr); // don't talk if isr is busy
	bitset(TWI_statusReg,STR_NACKonAction);//we NACK, Master must wait to rewrite dirty Regs
	cli();
#ifdef TWISLAVE
	TWAR = TWIADDR;                  // Set own TWI slave address.
#endif
	TWDR = 0xFF;                     // Default content = SDA released.
	TWSR = 0x00;                    // DO NOT USE PRESCALER! Otherwise you need to mask the
	TWBR = I2CTWI_SPEED(TWISPEED);		// default Speed @ KHz in master mode, 100 and 400 are well known
#ifdef TWISLAVE
	TWACK();
#else
	TWNACK();
#endif
	sei();
}
So schaut die Init in der kommenden Version aus...

Wer möchte, kann sich dann ein:
#define I2CTWI_initMaster I2CTWI_init
und
#define I2CTWI_initSlave I2CTWI_init
in die twi_target setzen und man muss nicht mal groß was an alten Programmen umschreiben. Ich glaube das setz ich sogar so ins .h File.
Weitere Krücken wären ebenfalls denkbar. Zu irgendwas muss so'n Compiler ja taugen...
#define I2CTWI_delay nop // microwaiting
der is auch schön

Noch mal zum Verständnis, es gibt keinen wirklichen Unterschied zwischen Master und Slave AUSSER das der Slave Code enthält, den der Master allein so nicht braucht und der Master Code enthält, den der Slave allein so nicht braucht. Das würde immer zu einer Codegröße von Master+Slave führen und man müsste sich um Code kümmern den man vielleicht nie nutzt. Das versuche ich mit der twi_target.h etwas einzugrenzen wenn man z.B. den Slave nicht braucht weil man nur ein RP6 ohne Zusatz und vielleicht ein SRF-Sensor hat. Mit der Lib wird man aber auch von 2 CPUs gemeinsam auf Targets wie i2c-LCDs zugreifen können und da müssen dann beide Programmteile zusammen wirken wenn die Prozessoren noch untereinander quatschen sollen. Ich betone "zusammen" ... also nicht Master oder Slave. Der alleinige Mastermode ist quasi nur eine reine Ersparnis um ein paar codebytes + etwas ram für Register aber oft sinnvoll wenn man eben kein Slave braucht. Es ist aber nicht als sich "gegenseitig ausschließender Modus" zu verstehen... Hier in der Lib ist vorgesehen: Slave+Master und Master sowie eine Lowlevel Master Geschichte die aber davon eigentlich unbetroffen und z.Z. noch unveröffentlicht ist.

Das ist das Gleiche wie bei der Multimastergeschichte.... jede ATMEL-cpu mit I2C Bus hat eine eingebaute Busarbitierung und daher sind sie alle MM-Fähig. Allerdings muss die Software die Situation erkennen - tut sie es nicht, ist sie eben nicht MM-fähig... die Hardware.. ist es aber, und die sorgt z.B. auch dafür wenn sich die Software nicht kümmert, das es auf dem Bus eigentlich nicht zu Schäden/Datenverlust kommt - im Gegensatz zu selbstgeschriebenen Softwarelösungen an irgendwelchen Portpins. Wenn man aber jegliches Handshake abschaltet, ist klar das Daten verloren gehen. Es käme auch keiner auf die Idee ein UART mit wilden Baudraten zu betreiben bzw. da weiss jeder das sowas in die Buxe geht. Wir nutzen mit dem alten Treiber quasi nur max. 30% dessen was möglich wäre - und selbst das nur wackelig. Das ist der Punkt. Was ich hier mache hat absolut nix mit "Magic" zu tun... das TWI in der MEGA32 ist mit 400KHz stabil vorgesehen, es gibt nichts was daran hindert das auch zu nutzen... ausser suboptimale Software. Das versuch ich mit meinen bescheidenen Mitteln zu beheben. Wirklich ärgerlich ist nur, das selbst die Codebeispiele von ATMEL selbst unvollständig sind. Scheinbar will man bei ATMEL die Lust aufs unbekannte wecken indem man nur ja nicht konkret wird. Und die TWI-State Engine von ATMEL wird bei Philips/NPX nun mal nicht genauer beschrieben... Das Problem ist nicht i2c, das Problem ist TWI. (Oder ich hab noch nicht die richtigen Stellen im Mega32-Datenblatt gefunden... will ich nicht ausschließen.) Sorry für's ausschweifen

Der Grund warum man in der twi_target einstellen soll was man möchte, ist schlicht und einfach das ich daran erkennen kann welcher Code Teil nicht gebraucht wird - und der wird dann entfernt. Entfernt wurde dabei eben auch der überflüssige Initaufruf für den Master da ja in der target Slave angegeben war. Also bei mir.. bei euch war es noch TWIMASTER was natürlich zu fehlendem Code führt. Sorry dafür. Hätte ich besser kommunizieren sollen.

Zitat Zitat von Dirk
Kurze Anregung als "normaler User":

Du bist ja da an einem dynamischen Prozeß dran, d.h. versuchst, in mehreren Schritten möglichst gute Lösungen zu finden. Dabei verändert sich auch die "Makrosprache" und der Funktionsumfang, der dem RP6 zur Nutzung des I2C-Bus mitgegeben wurde.
Wenn die entstehende Lib (ich bin da guter Hoffnung!) problemlos für alle zu nutzen sein soll, gibt es bei der Entwicklung eines neuen TWI-"Treibers" aus meiner Sicht auf der Makroebene nur 3 Möglichkeiten:
1. Man nutzt NUR die vorgegebenen Befehle und Makros, so dass vorhandene Programme mit der neuen Version kompiliert werden können.
2. Man ergänzt alle vorgegebenen Befehle und Makros durch neue Funktionen und Makros. Damit ist ebenfalls Abwärtskompatibilität möglich, es können dann aber neue Funktionalitäten zusätzlich genutzt werden.
3. Man verzichtet auf Kompatibilität und beschreibt einen neuen "Befehlssatz" für die TWI-Funktion.
Absolut richtig.
Weg 1 funktioniert nicht.
Weg 2 ist der goldene Mittelweg aber leider nicht immer möglich.
Weg 3 hört sich theoretisch gut an aber auch ich koche nur mit Wasser und habe nicht vor das Rad neu zu erfinden.

Zitat Zitat von Dirk
Mir persönlich liegt die Option 2. am Herzen, weil ich faul bin, und meine Programme nicht ändern möchte. Trotzdem würde ich gern von "Fortschritten" durch eine neue Lib profitieren (egoistisch wie ich bin ...).
Das sehe ich zu 100% wie Du. Siehe oben die defines. Letztlich wird es eine Mischung aus allen 3 Wegen wobei ich Weg 2 anvisiere. Es ist auch immer eine Frage der Abwägung von Aufwand und Nutzen. Ich sitze zwar jeden Tag lange hier dran aber es mus eben auch zum Prozessor und zum Rest der Libs passen.
Ich versuche jedenfalls die Änderungen klein zu halten und ändere nur da wo es wirklich Sinn macht oder Notwendig ist. Grundsätzliche Änderungen wären nur möglich wenn man die ganze RP6 Lib auf den Kopf stellt und dazu braucht man a. mehrere Leute um das in einem zeitlich sinnvollen Rahmen zu schaffen und es besteht b. glaube ich kaum eine echte Notwendigkeit da es nur ein (schönes!) Spielzeug und Experimentierplattform ist. Wenn auch eine sehr Interssante. Aber so lange mir die ESA kein Gehalt zahlt, tue ich auch nicht so als sei das hier ein Marsrover...

Zitat Zitat von Dirk
Also: Bitte nicht als Kritik, sondern nur als Anregung verstehen.
Ich teste weiter ...
Das ist schön.
Nein ich verstehe das nicht als Kritik, nur meine Zeiten als Codewarrior sind schon etwas länger her und ich hab den RP6 erst seid 3 Wochen. AVR-Prozesoren sind mir auch fremd, ich komme eigentlich von 68000er CPUs (asm) die heute kaum einer noch kennt... und Linux von da her ists ne gewaltige Umstellung. Aber keine Sorge, ich werd euch keinen Linux Kernel schreiben auch wenns mich in den Fingern juckt Ich versuche euch an den Veränderungen Teil haben zu lassen und zu begründen und ihr habt natürlich die Möglichkeit darauf zu reagieren. Eine richtige Docu dazu fehlt ja auch noch aber das meiste ist im Programm zu erkennen.

Vielleicht erklärt das auch die RTOS Frage von mir an anderer Stelle des Forums etwas besser. Ich bin es gewohnt, in den Source zu schauen und nehme nicht alles als gegeben hin. (Was ich auch nicht als Kritik verstanden haben möchte) Na jedenfalls hab ich Hoffnung das es noch was wird mit dem TWI hier Es geht ja jetzt schon mehr als mit dem alten Treiber ohne das es riesengroß wird.
Ich bin übrigends dabei einen weiteren Fehler einzukreisen, welcher sich hier in meinem Hardwareaufbau eingeschlichen hat - der evtl. auch die Buserrors BEI MIR verursacht. Wäre möglich das ihr weniger bis keine habt... Hängt evtl. mit der Nutzung von E_INT1 zusammen. Der Lötkolben ist schon warm.... Ansonsten läuft die Lib schon ganz gut hab ich das Gefühl.

PS: mich wundert schon etwas, das sich noch niemand rangetraut hat um dem RP6 bzw. die Libs zu verbessern, schließlich sagt SlyD selbst das nicht alles optimal ist. Die TWI ist da nur ein, aber bestimmt nicht das einzige Beispiel. Und ich hab jetzt nicht den Eindruck, das sich SlyD guten Ideen und Umsetzungen gegenüber sperren würde. Ich rege mich jedenfalls mehr über ein störanfälliges TWI auf, als über laute Zahnräder ...

LG Rolf