Druckbare Version
Schön, dass ihr heir so schöne Fortschritte macht!
So wie ich das jetzt verstanden habe, warte ich mit dem Testen noch bis du deine neue Version draußen hast? Scheinst ja bei dir noch einige Änderungen zu haben.
Aber auch von mir schonmal ein Kompliment ;) Ohne guten Debugger würde ich mich an sowas nicht rantrauen ;)
@Fabian
ja warte besser bis morgen Nachmittag. Aber so viel wird sich dann erst mal nicht mehr ändern.
Zum Thema debuggen... da sag'ste was... ich hab noch gelernt Fehler zu suchen indem man mit nem Schraubendreher auf nen Bauteil kloppt... :) Aber nen 2.ter USB Adapter wär schon klasse damit ich nicht mehr ständig umstecken muss. Sonst arbeite ich mit dem gcc... bis ich mich in eine IDE eingefunden hab... puh... aber da freue ich mich schon auf die M128 Unit. :)
LG Rolf
Ja, da klappt das tatsächlich ganz gut. Zumindest wenn du die UART Schnittstelle nicht debuggen willst... das ist nämlich nicht so ganz einfach ;-)
*breitgrins....
So.. der Fehler mit hängen bleiben lang tatsächlich an E_INT1.
Kurze Beschreibung dazu: Ich habe eine pcf8583 Uhr am i2c hängen dessen INT Leitung am E_INT1 der Base liegt. Dies ist ansich ein harmloser ADC-Port. Ich möchte deren Alarmfunktion später mal nutzen.
Die Uhr gibt wenn das Register 0 mit 0 beschrieben ist, pro Sek ein Impuls aus. Ich hatte dem Baustein das die Tage abgewöhnt aber irgend ein rumflitzendes Byte auf dem i2c bus hat es zurück gesetzt. Die Base juckt das nicht weiter, für sie ist das nur ein normaler Port an dem jemand klopft. Die Leitung ist aber auch über den XBUS an den INT1 der M32 geführt was ein echter Interrupt ist - und ich nicht bedacht hatte. Dem zu Folge löste die M32 pro Sek ein irq aus wo der Master drauf läuft. Die INT Leitung hat eine höhere Priorität als TWI - daher wurde die TWI immer wieder unterbrochen was zu Timingproblemen und letztlich zum Abbruch des Datenflusses führte.
Für euch interssant ist eigentlich die Info, das wenn man den E_INT1 z.B. als Ausgang nutzt - warum auch immer - ihr damit die M32 quasi ständig in eine ISR schickt. Ich finde das sogar sehr gut durchdacht vom Entwickler... nur darf man das halt nicht vergessen wenns um die Leitung geht. Die E_INT1 ist als Steuerleitung Tabu wenn man eine M32 oder vermutlich auch M128 nutzt. Eigentlich logisch aber man denkt eben nicht immer dran.
Nun zum TWI. Ich hab euch meine aktuellen Files zum Projekt bzw. Dirks modifiziertes Testprogramm zusammen mit der TWI in ein Zip gepackt. Damit können jetzt auch mehr Leute mal versuchen wie es klappt. Achtet bitte auf Pfade und Abhänigkeiten im makefile und kommentiert die defines zum lcd und das lcd.h aus wenn ihr kein i2c lcd mit pcf Baustein habt. Benötigt zum testen mit Dirks Programm werden die Base, eine M32 sowie ein M32Display.
I2CTWI_isBusy() (bit_is_set(TWI_statusReg,STR_isr))
#define I2CTWI_needAction() (bit_is_set(TWI_statusReg,STR_needAction) && bit_is_clear(TWI_statusReg,STR_isr))
#define I2CTWI_waitAction() (bitset(TWI_statusReg,STR_needAction))
#define I2CTWI_doneAction() (bitclr(TWI_statusReg,STR_needAction))
#define I2CTWI_NACKonAction() bitset(TWI_statusReg,STR_NACKonAction)
#define I2CTWI_ACKonAction() bitclr(TWI_statusReg,STR_NACKonAction);bitclr(TWI_ statusReg,STR_needAction)
Das hier sind Befehle, die für die Ablaufsteuerung relevant sind. Sie fragen oder setzen alle Flags ab die die ISR steuert.
I2CTWI_isBusy() ist gesetzt wenn die ISR ein Datagram überträgt. Egal ob als Master oder Slave, vom Start bis zum Stop.
Achtung, die Befehle
I2CTWI_requestRegisterFromDevice
und
I2CTWI_readRegisters
bestehen je aus 2 Einzelbefehlen in denen die ISR zwischendurch "Frei" meldet was zur Ausführung nachfolgend wartender TWI Befehle führen kann. Dafür muss ich noch eine Lösung stricken. Alle anderen TWI-Befehle sind Einzelbefehle, da sollte das Problem nicht auftauchen.
I2CTWI_needAction() prüft ob die Slave Register beschrieben wurden was mit einem gesetzten Bit angezeigt wird. Wenn ja, sollte der Slave als Zeichen das er die Daten verarbeitet hat immer I2CTWI_doneAction() ausführen was das Bit zurück setzt. Der Master hat dazwischen keine Schreibmöglichkeit und wird geblockt (was der natürlich auch über I2CTWI_isBusy() merken kann). Will man den Master ohne vorherige Schreiboperation zwingen zu warten (was eigentlich nur für mich zum testen relevant ist) nutzt man I2CTWI_waitAction() was das schreiben der Register simuliert. Soll der Master immer schreiben können (Verhalten wie bisher, führt zum überschreiben von Registern) nutzt man I2CTWI_ACKonAction(), mit I2CTWI_NACKonAction() blockt der Slave wieder das überschreiben.
Das Blocken geschiet durch senden von NACK wäred der Master ein Datenbyte auf ein bereits beschriebenes Registerset schreiben will, was wiederum mit einen neuen Anlauf der Übertragung mündet bis er erfolgreich war. Quasi eine Endlosschleife. Das Beschreiben des Adressbytes müsste aber noch gehen so lange der Master keine Daten mitsendet. Zur Not könnte der Master also auch noch darüber dem Slave was mitteilen. Morsen sozusagen... Vielleicht eine Möglichkeit für weitere Master zu signalisieren, wenn sie Daten haben und der Slave gefälligst die Register frei zu geben hat.... aber das ist dann schon leicht abgedreht und scheitert noch an fehlender Busarbitierung :). Derzeit ist der Bus belegt wenn der Slave nackt und ein 2.ter Master müsste den ersten von der Leitung schubsen um reden zu dürfen, wobei sich der erste vermutlich dann gehörig verschluckt. Bildlich gesprochen...
I2CTWI_waitAction() werde ich vermutlich wieder entfernen da es für euch kaum Sinn macht. I2CTWI_(N)ACKonAction() wird bleiben.
Die Variablen
I2CTWI_genCallCMD
I2CTWI_dataWasRead
I2CTWI_dataReadFromReg
I2CTWI_readBusy
I2CTWI_writeBusy
sind obsolet, I2CTWI_genCallCMD tut es eh nicht weil gencalls derzeit garnicht gehen, die anderen 4 Vars machen quasi das gleiche wie I2CTWI_isBusy() und I2CTWI_needAction() mit der Ausnahme das sie nun auch zu gebrauchen sind und den Ablauf am TWI beeinflussen.
Konfiguriert wir die Anwendung mit twi_target.h, sie ist selbsterklärend, jedes Projekt hat sein eigenes File. Es gelten die üblichen Vorgaben für TWI.
Flags wie DEBUG, XDEBUG können kommentiert wreden (//) dabei bedeutet:
TWISLAVE=Slave & Master
TWIMASTER=Master
TWILOW=(Slave & Master | Master) & TWILOW
Ich glaube, es geht nichts kaputt wenn man TWISLAVE und TWIMASTER setzt aber es ist doppelt gemoppelt. TWILOW sind Bascom ähnliche Funktionen die - wenn genutzt - das Handling auf dem TWI erlauben ohne das die ISR dazwischen funkt. Dazu müssen die Funktionen ein paar Dinge berücksichtigen, insbesondere das Ausschalten des TWI Interrupts und das Einschalten wenn man fertig ist. Gedacht ist das zum debuggen eigener Devices/Hardware, man kann sich natürlich auch kompexe Funktionen daraus basteln die mit der ISR koexistieren. Damit ist jedoch kaum Slave Betrieb möglich oder man müsste wie blöde TWI-Register pollen, daher nur einfache Masterfunktion.
Im Base Programm sitzt noch ein vagabundierender extINT Befehl, der kann/muss raus... und einige Kommentare wo ich am basteln war.. kann auch raus.
Ich bin mir noch nicht sicher wie die TWI auf Busarbitation reagiert, grundsätzlich können und dürfen am Bus mehrere Master laufen. Evtl. stürtzt aber die aktuelle TWI ab bzw. baut Mist. Aber es geht nichts kaputt.
Wer möchte, kann also Dirks Programm so umbauen das auf beiden Prozessoren Master und Slave laufen und die sich gegenseitig Daten zuwerfen und abfragen.... schlimmstenfalls bleiben die Programme nur nach einigen Bytes hängen. Nur hätte ich den Source dann bitte gern am Montag da ich dann auch die Arbitation in Angriff nehmen kann. :) Sonst muss ich mir das erst selbst schreiben.
Das sind mal grob alle wichtigen Infos zusammen gepackt.
Sonst schaut auch mal in die .h und .c files ... die beissen nicht...
Der compilerlauf mit gcc klappt hier, wenn was nicht klappt, bitte zuerst in der twi_target prüfen. Dirks Programm testet alle 4 Teilfunktionen der TWI, also MR/MT/SR/ST und sollte damit auch in eigenen Projeken funktionieren. Alles weitere findet sich auch im Thread hier.
Ich hab am WE keine Zeit und werde mich erst Montag wieder intensiv darum kümmern, ihr habt also die Möglichkeit damit zu spielen bevor ich wieder alles auf den Kopf stell. :) Es werden noch weitere Veränderungen und Betatests kommen, insbesondere Fabian sollte mit der Lösung und Remotrol aber schon arbeiten können. Sonst fragt einfach hier, ich werde sicher mal reinschauen am WE.
LG Rolf
Cool, dann habe ich ja was zu tun. =)
Das ist mit dem E_INT1 ist ja genau für den Interrupt gedacht, der RP6 muss ja quasi Interupts an die M32 schicken können.
Aber wenn man das vergisst, kann das natürlich ganz schön verwirrend sein. =)
Ich hatte da aber auch schon Probleme mit, zwar nicht bei der M32 sondern bei der M128... Da ist ein Interuptpin hinüber... Zum Glück kann man das da ja auf einen anderen umstecken.
@Rolf:
Doch, ich schon. Meine ersten ASM-Versuche waren mit dem 6502, da habe ich auch noch an "Treibern" (z.B. Druckerspooler, ich glaube für den 6510) gearbeitet, dann aber in ASM nur noch bis zum 8086 mithalten können.Zitat:
... ich komme eigentlich von 68000er CPUs (asm) die heute kaum einer noch kennt...
Naja, da gab es z.B. von mir schon über die Jahre Libs und Verbesserungen vorhandener Libs.Zitat:
... 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.
Kurze unvollständige Liste: M32-Lib-Version 1.3beta, M32-EEPROM-Zugriff, M32/Base/M128-Clock-Lib und DCF-Lib, M32/Base-Servo-Lib, M32/M128-TRX433-Lib, M32/Base-Uart_2-Lib
Ja, wenn du die in die Finger kriegst, geht es hier wohl erst richtig ab. \:D/Zitat:
... aber da freue ich mich schon auf die M128 Unit.
Ja, das ist so und gilt auch für die M128: Dort ist E_INT1 der Base (und INT0 (PD2) der M32) mit INT5 (PE5) verbunden, also auch mit einem interruptfähigen Eingang.Zitat:
Die E_INT1 ist als Steuerleitung Tabu wenn man eine M32 oder vermutlich auch M128 nutzt.
Gruß Dirk
@Rolf:
So, ich habe jetzt die neue Version getestet und die Bytes herumsausen lassen.
Ergebnis: Es gibt keine Probleme.
Ich habe dann im Base-Programm noch die task_RP6System() aufgenommen, um eine realistische Umgebung zu haben.
Ergebnis: Keine Probleme.
Dann habe ich noch im M32-Programm die task_RP6M32System() aufgenommen, die es aber nur in meiner Version 1.3beta der RP6ControlLib gibt.
Ergebnis: Auch keine Probleme.
Fragen eines kleinen Testers:
1. Die Funktionen I2CTWI_needAction() und I2CTWI_doneAction() umschließen ja den ganzen Komplex der I2C-Kommunikation. Im Grunde will ja der Nutzer des I2C-Busses ja nur Bytes senden oder empfangen, genau wie bei der Uart-Lib. Ihm ist es wohl eher egal, ob TWI eine "action" braucht oder ob die zuende ist. Daher meine (vorsichtige) Frage, ob man das auf der Befehlsebene wirklich braucht? Müßte nicht der Treiber selbst entscheiden, ob er eine action (bzw. Busaktivitäten) durchführen muss oder wann er damit fertig ist? Wie gesagt: Vielleicht verstehe ich auch nicht die Intention. Eigentlich brauche ich auf der Befehlsebene nur Schreib-/Lesebefehle und evtl. ein oder 2 Flags, ob der Bus wieder frei ist. Sonst will ich als Nutzer eigentlich nicht unbedingt wissen, was sich im Busprotokoll tut.
2.Oh,- da bräuchte ich von dir Anregungen, wie das zu initialisieren wäre ... Dann mache ich da gern was draus ...Zitat:
Wer möchte, kann also Dirks Programm so umbauen das auf beiden Prozessoren Master und Slave laufen und die sich gegenseitig Daten zuwerfen und abfragen...
Gruß Dirk
6502 ? nettes Teil... auch einer der mit ner Brotkiste angefangen hat? :) Mein erster war ein ZX81 :) Hach ja die alten Zeiten ... :)
Aber zur TWI. Ich war unzufrieden, das der IRQ mir die Daten auf dem i2c zerbröselte - auf Grund der Sache mit der Uhr - und hab eine Lösung gefunden. Einfach aber effektiv. Die ISR wird zukünftig (steuerbar über twi_target.h) im Eingang ein cli(); ausführen und im Ausgang ein sei(); , das verhindert nach nun 24h lang laufenden Dauertests absolut zuverlässig die Unterbrechung und Abbruch trotz sekündlichen Uhrenticks. Wird in der nächsten Release drin sein.
Dann freut es mich erst mal sehr, das Du reproduzierbar stabile Funktion berichten kannst. Zu Deiner Frage, nun wenn Du dich nicht um das "Protokoll" kümmern willst, kannst Du mit I2CTWI_ACKonAction() kurz nach der Initialisierung das so einstellen, das der Master nicht behindert wird.
I2CTWI_init()
I2CTWI_ACKonAction();
...
Programmlauf
...
Wenn aber dein Programm auf der Base sowas wie ein Handshake braucht, (Fabians Remotrol braucht das z.B. zwingend) oder verhindert werden muss das der Master Daten überschreibt (weil Befehlssequenzen übertragen werden, kommst Du um eine Verarbeitung der Daten/Befehle und letztlich auch einem Handshake.. nicht rum. Da bietet sich die default Einstellung bzw. I2CTWI_NACKonAction(); und dann endsprechendes bearbeiten mit I2CTWI_needAction() und I2CTWI_doneAction() an.
Es kommt also ein wenig auf deine Anforderungen an das Programm an, es gibt keine ja/nein Antwort dazu. Man kann überlegen, die Defaulteinstellung auf I2CTWI_ACKonAction zu setzen was dem alten Verhalten entspricht, ohne ein Handshake ist allerdings eine gesicherte Datenübertragung nicht möglich. Vergleich es mit den RTS/CTS Leitungen und dem Software Protokoll XON/XOFF, es würde auch keiner eine stabile UART ohne die Leitungen betreiben können und wenn doch, so muss zumindest das Softwareprotokoll XON/XOFF vorhanden sein. I2C hat kein RTS/CTS bzw. XON/XOFF, also braucht es da was anderes, die ACK/NACK Signale sind quasi eine Mischumg aus beidem und ohne die klappt so gut wie nix wirklich sicher auf dem Bus - der alte Treiber welcher alles ACKte, ist bester Beleg dazu. Natürlich muss man sich als Programm... nein.. man muss nicht, man kann... sich drum kümmern... und sicher stellen das die Daten korrekt verarbeitet werden. Aber es gibt auch Anwendungen wo das nicht so wichtig ist. Das entscheidest letztlich Du als Programmierer bzw. die Aufgabenstellung.
Man kann grundsätzlich das Ganze in ein Task packen und mit einem
If I2CTWI_needAction() task_do_i2c();
erledigen, wo dann halt in task_do_i2c alles verarbeitet wird. Incl. einem I2CTWI_doneAction(); am Taskende. Die Libs und Examples liefern dazu reichlich Beispiele. Das hatte ich in deinem Programm auch schon im Kommentar irgendwo angemerkt. Ich werde dazu am Montag ein kleines Beispiel bauen, denke aber das ihr da jetzt schon mit klar kommt.
Eigentlich reicht für das genannte Programm also:
while (true)
{
die_üblichen_System_Tasks();
If I2CTWI_needAction() task_do_i2c(); //Receiver bedienen (Daten kopieren wie im Slavebeispiel)
Master_task();//Selber aktiv werden, so wie in dem Masterbeispiel
}
Das ist echt nicht kompliziert, Du hast bereits alles geschrieben da was wir da brauchen...
LG Rolf
PS: Ich hab noch was für Dich Dirk, extra eben noch geknipst :) Du wirst sie erkennen, für die anderen: Eine 6502 CPU von MOS aus dem Jahr 1983 aus meiner Grabbelkiste. Hier noch bissel Text dazu. http://de.wikipedia.org/wiki/MOS_Technology_6502
Die 6509 war ein direkter Verwandter und wurde im CBM610 z.B. verbaut. http://www.zock.com/8-Bit/D_CBM610.HTML Ich hatte auch mal einen. Und nicht zu vergessen die allseits berühmte 6510 CPU aus dem C64 und die 6508 aus dem NES :) Eine Z80 CPU aus der Generation hab ich auch noch, und hüte sie wie Dagobert Duck sein ersten Taler :)
EDIT: Ich hab über die Handshake Geschichte nachgedacht und stelle fest, das es da noch einiges zu verbessern gibt. Z.B. kann der Masterzugriff bisher nicht beeinflussen was bei einem NACK passiert, bzw. ist einem hängendem Slave quasi ausgeliefert. Das ist unschön und wird demnächst behoben. Beide Seiten werden also steuern können, ob und wie sie mit NACKS umgehen. Dazu wird die ISR ein weiters Flag bekommen, das mit 1 oder 2 Funktionen/Macros steuerbar ist.
@Rolf:
Hier 'mal meine Testprogramme, die (erwartungsgemäß) nicht funktionieren. Das "erwartungsgemäß" hat damit zu tun, dass ich nicht wirklich verstanden hatte (SORRY!), wie auf beiden Systemen Master- und Slavefunktionen zu initialisieren sind.
Ich bin sicher, du kannst da rasch weiter helfen.
Meine Idee war, in einer Richtung einen Aufwärtszähler laufen zu lassen, in die andere Richtung einen Abwärtszähler. Abwechselnd würden dann beide Systeme den Master machen. Auf dem LCD der M32 wäre die eine Zeile für die (eigene) Masterfunktion, die andere für die Gegenrichtung, für die Base würden die Textausgaben über Uart mit "M-" für die eine und "S-" für die andere Richtung ausgegeben. Vielleicht habe ich mir das Ganze auch zu naiv so vorgestellt.
In der twi_target.h habe ich beide Systeme als TWISLAVE definiert (richtig?).
Als TWI-Adresse für die M32 nehme ich 12 dezimal (NICHT hex!). An der Base habe ich kein I2C-LCD.
Testprogramm 3 (RP6Control M32):
Code:/*
* ****************************************************************************
* RP6 ROBOT SYSTEM - RP6 CONTROL M32 EXAMPLES
* ****************************************************************************
* Example: I2C Master/Slave - I2C Send/Receive Test 3
* Author(s): Dirk
* ****************************************************************************
* Description:
*
* This Example sends/receives data via I2C.
*
*
* ############################################################################
* The Robot does NOT move in this example! You can simply put it on a table
* next to your PC and you should connect it to the PC via the USB Interface!
* ############################################################################
* ****************************************************************************
*/
/*****************************************************************************/
// Includes:
#include "twi_target.h" // Include the new I2C-Bus Library
#include "RP6ControlLib.h" // The RP6 Control Library.
// Always needs
to be included!
/*****************************************************************************/
// Defines:
// The Slave Address of the RP6Base on the I2C Bus can be specified here:
#define RP6BASE_I2C_SLAVE_ADR 10
#define CMD_SHOW_DATA 99 // Command to display the data
#define TEXT_OUTPUT // Show text
/*****************************************************************************/
// I2C Event handlers:
/**
* This function gets called automatically if there was an I2C Error like
* the slave sent a "not acknowledge" (NACK, error codes e.g. 0x20 or 0x30).
* The most common mistakes are:
* - using the wrong address for the slave
* - slave not active or not connected to the I2C-Bus
* - too fast requests for a slower slave
* Be sure to check this if you get I2C errors!
*/
void I2C_transmissionError(uint8_t errorState)
{
writeString_P("\nI2C ERROR --> TWI STATE IS: 0x");
writeInteger(errorState, HEX);
writeChar('\n');
}
/*****************************************************************************/
// Variables:
uint8_t buffer[4];
uint16_t error_cnt = 0;
uint8_t controlbyte;
uint8_t highbyte = 0;
uint8_t lowbyte = 0;
/*****************************************************************************/
// Functions:
void task_Slave(void)
{
static uint16_t cnt;
if I2CTWI_needAction() {
controlbyte = I2CTWI_writeRegisters[0]; // Read
control byte
I2CTWI_writeRegisters[0] = 0;
// and reset it (!!!)
lowbyte = I2CTWI_writeRegisters[1];
// Read lowbyte
highbyte = I2CTWI_writeRegisters[2]; // Read
highbyte
I2CTWI_readableRegisters[0] = controlbyte; // copy
controlbyte
I2CTWI_readableRegisters[1] = lowbyte; // copy
lowbyte
I2CTWI_readableRegisters[2] = highbyte; // copy
highbyte
cnt = ((highbyte << 8) | lowbyte);
// Restore 16-bit value
#ifdef TEXT_OUTPUT
setCursorPosLCD(1, 0);
writeStringLCD_P("S-Rcved ");
// What was received?
writeIntegerLCD(cnt, DEC);
writeStringLCD_P(" ");
#endif
if (!cnt) error_cnt = 0;
// Reset error counter
else error_cnt++;
// Error counter + 1
if (cnt != error_cnt) {
setCursorPosLCD(1, 0);
writeStringLCD_P("S-ERROR!");
error_cnt = cnt;
}
else {
setCursorPosLCD(1, 0);
writeStringLCD_P(" ");
}
controlbyte = 0;
I2CTWI_doneAction();
}
}
void task_Master(void)
{
static uint16_t cnt = 32768;
if (!I2CTWI_isBusy()) {
cnt--;
// TEST: COUNTER!!!
if (cnt > 32767) cnt = 32767;
buffer[0] = 0;
buffer[1] = CMD_SHOW_DATA;
buffer[2] = cnt;
buffer[3] = (cnt >> 8);
I2CTWI_transmitBytes(RP6BASE_I2C_SLAVE_ADR, buffer, 4);
buffer[0] = 0;
// reset buffer
buffer[1] = 0;
buffer[2] = 0;
buffer[3] = 0;
I2CTWI_readRegisters(RP6BASE_I2C_SLAVE_ADR, 0, buffer, 4);
if (cnt == ((buffer[2] << 8) | buffer[1])) {
#ifdef TEXT_OUTPUT
setCursorPosLCD(0, 0);
writeStringLCD_P("M-Moved "); // What
was sent?
writeIntegerLCD(cnt, DEC);
writeStringLCD_P(" ");
#endif
}
else {
setCursorPosLCD(0, 0);
writeStringLCD_P("M-ERROR! "); // What
was sent?
}
// if (cnt==3) while(true);
// countertrap
}
}
/*****************************************************************************/
// Main - The program starts here:
int main(void)
{
initRP6Control();
initLCD();
// I2CTWI_init(100); // Initialize the TWI Module for Master
operation
// with 100kHz SCL
Frequency
// Register the event handlers:
I2CTWI_setTransmissionErrorHandler(I2C_transmissionError);
setLEDs(0b1111);
mSleep(500);
setLEDs(0b0000);
while(true)
{
task_Slave();
task_Master();
if (RP6LIB_VERSION == 15) {
// Only for
task_RP6M32System();
// Lib V1.3beta!!!
}
else mSleep(5);
// Other Libs: 5ms
}
return 0;
}
/******************************************************************************
* Additional info
* ****************************************************************************
* Changelog:
* - v. 1.0 (initial release) 27.02.2011 by Dirk
*
* ****************************************************************************
*/
/*****************************************************************************/
Testprogramm 3 (RP6Base):
Vielleicht kannst du ja daraus was machen. Ich brauche auf jeden Fall noch ein paar Anregungen.Code:/*
* ****************************************************************************
* RP6 ROBOT SYSTEM - ROBOT BASE TESTS
* ****************************************************************************
* Example: I2C MaSTER/Slave - I2C Send/Receive Test 3
* Author(s): Dirk
* ****************************************************************************
* Description:
*
* This Example sends/receives data via I2C.
*
*
* ############################################################################
* The Robot does NOT move in this example! You can simply put it on a table
* next to your PC and you should connect it to the PC via the USB Interface!
* ############################################################################
* ****************************************************************************
*/
/*****************************************************************************/
// Includes:
#include "twi_target.h" // Include the new I2C-Bus Library
//#include "PCF8583.h"
//#include "RP6RobotBaseLib.h" // The RP6 Robot Base Library.
// Always needs
to be included!
/*****************************************************************************/
// Defines:
// The Slave Address of the Control M32 on the I2C Bus can be specified here:
#define RP6CONTROL_I2C_SLAVE_ADR 12
#define CMD_SHOW_DATA 99 // Command to display the data
#define TEXT_OUTPUT // Show text
/*****************************************************************************/
// Variables:
uint8_t buffer[4];
uint16_t error_cnt = 0;
uint8_t controlbyte;
uint8_t highbyte = 0;
uint8_t lowbyte = 0;
/*****************************************************************************/
// Functions:
void task_Slave(void)
{
static uint16_t cnt;
if I2CTWI_needAction() {
controlbyte = I2CTWI_writeRegisters[0]; // Read
control byte
I2CTWI_writeRegisters[0] = 0;
// and reset it (!!!)
lowbyte = I2CTWI_writeRegisters[1];
// Read lowbyte
highbyte = I2CTWI_writeRegisters[2]; // Read
highbyte
I2CTWI_readableRegisters[0] = controlbyte; // copy
controlbyte
I2CTWI_readableRegisters[1] = lowbyte; // copy
lowbyte
I2CTWI_readableRegisters[2] = highbyte; // copy
highbyte
cnt = ((highbyte << 8) | lowbyte);
// Restore 16-bit value
#ifdef TEXT_OUTPUT
writeString_P("S-Received: ");
// and show it
writeInteger(cnt, DEC);
writeChar('\n');
#endif
if (!cnt) error_cnt = 0;
// Reset error counter
else error_cnt--;
// Error counter - 1
if (cnt != error_cnt) {
writeString_P("S-ERROR!\n");
error_cnt = cnt;
}
controlbyte = 0;
I2CTWI_doneAction();
}
}
void task_Master(void)
{
static uint16_t cnt = 0;
if (!I2CTWI_isBusy()) {
cnt++;
// TEST: COUNTER!!!
if (cnt > 32767) cnt = 0;
buffer[0] = 0;
buffer[1] = CMD_SHOW_DATA;
buffer[2] = cnt;
buffer[3] = (cnt >> 8);
I2CTWI_transmitBytes(RP6CONTROL_I2C_SLAVE_ADR, buffer, 4);
buffer[0] = 0;
// reset buffer
buffer[1] = 0;
buffer[2] = 0;
buffer[3] = 0;
I2CTWI_readRegisters(RP6CONTROL_I2C_SLAVE_ADR, 0, buffer, 4);
if (cnt == ((buffer[2] << 8) | buffer[1])) {
#ifdef TEXT_OUTPUT
writeString_P("M-Moved: ");
writeInteger(cnt, DEC);
writeChar('\n');
#endif
}
else {
writeString_P("M-ERROR!\n");
}
// if (cnt==3) while(true);
// countertrap
}
}
/*****************************************************************************/
// Main function - The program starts here:
int main(void)
{
extIntOFF();
initRobotBase();
// initLCD();
setLEDs(0b111111);
mSleep(500);
setLEDs(0b000000);
// I2CTWI_init(RP6BASE_I2C_SLAVE_ADR);
// clearI2CLCD();
// setCursorPosLCD(0,0);
// writeStringLCD("I2C Init "); writeIntegerLCD(1,DEC);
//---------------------------------------
/*
writeString("START ----------------------------------\n");
uint8_t results[15];
I2CTWI_transmitByte(PCF8583_ADDR_WRITE, 0);
I2CTWI_readBytes(PCF8583_ADDR_READ, results, 7);
*/
//---------------------------------------
//while (true);
while (true)
{
task_Slave();
task_Master();
task_RP6System();
}
return 0;
}
/******************************************************************************
* Additional info
* ****************************************************************************
* Changelog:
* - v. 1.0 (initial release) 27.02.2011 by Dirk
*
* ****************************************************************************
*/
/*****************************************************************************/
Gruß Dirk
P.S.: Oh, ja, ich habe auch noch eine 6502 und eine 6510 liegen. Ich gehe mal in den Keller,- suchen ...
Hallo Dirk, ich schau gleich rein, hab jetzt wieder Zeit. Ja so in etwa dachte ich mir das. Mal genauer hinsehen wo es da klemmt...
Aber vorweg...
Initialisiert werden hier beide Seiten im Programm mit I2CTWI_initSlave(wert_egal); zumindest in der Version die du jetzt noch hast. Die Werte für Speed und Adresse müssten aus dem jeweiligen twi_target.h kommen, je 100khz und base dez.10, m32 dez.12. für die EIGENE Adresse, den jeweils anderen 10->12 und 12->10 muss man im Programm als Ziel in den Funktionen mitgeben. Das reicht eigentlich. Ach ja.. in beiden twi_targets muss natürlich TWISLAVE aktiv sein weil beide Seiten Registersets bereit stellen sollen. Und die beiden Tandems dürfen sich natürlich nicht gegenseitig in die Register schreiben oder sonst wie ins Gehege kommen.. also z.B. einen Master/Slave Verbund auf der Base in die Register 0(1) bis 3(4) packen wie bisher, den anderen neuen Master/Slave Verbund mit Slave auf der M32 in die Register z.b. ab 8(9)... (die Klammern jedes mal für den Master weil der ja erst ab reg, 1 liest.)
Eigentlich kann man auf beiden Seiten die regs 0-3 nutzen aber damit man sich nicht verhaspelt würd ich das erst mal logisch in 2 Bereiche trennen, später wenns klappt und verstanden ist müsste man es auch runter setzen können. <- Die Aussage is glaube ich Quark, es is recht eindeutig was wo hin geht.. sorry..
In folgenden Versionen wird es kein differenziertes Master/Slave Init mehr geben, und ist nur aus Kompatibilität (wie gepostet) noch vorhanden, wird aber von meinem .h File auf eine gemeinsame Init Funktion per Macro umgebogen.
Damit sollten erst mal die Unklarheiten beseitigt sein, warum das Programm klemmt, da schau ich nun und Poste es wohl als Edit.
EDIT:
Ja zum Init sagte ich schon, in beiden:
// die Funktion holt sich die Addresse aus twi_target.h
I2CTWI_initSlave(42); // parameter egal
Aber da klemmt noch mehr... erst mal gucken ob die Einzeln gehen... also in der Base
// task_Master();
und im M32
// task_Slave();
das ist ja die alte laufende Konstellation...
Der extIntOFF(); Befehl ist auch noch in der Base.. wir sprachen drüber wie ungeschickt es wäre den, E_INT1 als Ausgang zu steuern :) Hatte ich extra noch gesagt das der raus muss :) Aber auch das ist noch nicht der Fehler...
LG Rolf
Habt ihr schon mal davon gehört, das die Pullups duchbrennen???
Ich hab seid stunden Probleme mit dem i2c und such mir hier nen Wolf, nachdem ich mein Oszi angeschlossen hab sah ich etwas seltsame Pegel, darauf hin hab ich R32 und R33 durchgemessen und siehe da.. R32 ist hochohmig, bei R33 finde ich 4,62 KOhm. Von den Pins SDA und SCL sollte ich laut Schaltplan einen Widerstand von 4k7 gegen Vdd messen können... sowie zwischen den Widerstandsanschlüssen gegen vdd 0 Ohm und andere Seite zu scl/sda auch 0 Ohm... alles so wie es sein soll.. aber der R32 ist und bleibt futsch...eine kalte Lötstelle schließe ich optisch aus.
Ich bin etwas ... naja ... platt !
Das Problem tritt erst seid dem 24h i2c-Dauertest auf, ich habe in der Zeit nichts am RP6 gemacht. Ich hoffe der Prozessor hat nichts abbekommen, den Widerstand kann ich ersetzen...
LG Rolf
Hallo,
das ist höchst seltsam. überlasten/durchbrennen kann so ein 4K7 Widerstand in der Schaltung eigentlich nicht - selbst dann nicht wenn man den dauerhaft direkt an den Akku klemmen würde.
Das einzige was ich mir vorstellen könnte, wäre ein Materialfehler im Widerstand, beim Lötprozess dann weiter gestresst und dann irgendwann gebrochen.
Sind aber zum Glück alles sehr große 0805er Bauteile, daher problemlos auszutauschen.
Wenns doch Probleme geben sollte kannst Du mich gerne per Mail kontaktieren.
MfG,
SlyD
Also ich kann euch beruhigen, die komischen Flanken lagen an dem PCF Uhrenmodul was ich vor einiger Zeit eingebaut hatte. Ich habe eben mit etwas mehr System und Sorgfalt (und Schlaf, ich war gestern Nacht zu k.o.) alles noch mal durchgemessen und den R32 vorsichtshalber ersetzt, und das verlötete Uhrenmodul abgetrennt, es ist alles wieder so wie es sein soll. Der R32 kann eigentlich nicht durchgebrannt sein wie SlyD schon sagte, dem stimme ich auch voll zu, der R hatte aber wohl trotzdem nen Schlag weg. Kann passieren. Das Uhrenmodul ist aber definitiv nicht in Ordnung obwohl ich da zig mal die Zeit mit auslesen konnte. Ich werde nun ohne das Uhrenmoul weiter testen und bedanke mich vor allem für SlyDs Angebot zu helfen. Da nun alles wieder ok ist, kann ich auch mit dem Treiber weiter machen. Jetzt hab ich nur dummer Weise kein unabhänigen Slave mehr, den ich auslesen kann. Mal sehen... vielleicht kann ich den pcf8574 am i2c Display verwenden..., der tut es.
LG Rolf
EDIT:
@All
@ Dirk, deine Programme die Masterfunktion nutzen... müssen natürlich auch task_I2CTWI(); aufrufen. Sonst bleibt der Transport hängen... aber ich bin schon wieder so viel am umstellen, wartet lieber auf die nächste Beta.
Ok, hätte ich merken können.Zitat:
Dirk, deine Programme die Masterfunktion nutzen... müssen natürlich auch task_I2CTWI(); aufrufen. Sonst bleibt der Transport hängen... aber ich bin schon wieder so viel am umstellen, wartet lieber auf die nächste Beta.
Das mit deinem Pullup an SDA ist ja echt merkwürdig! Naja, hast du ja gut gelöst!
Also: Ich warte geduldig auf die nächste Version ... :Ostern :Weihnacht
Gruß Dirk
Ich hab mir scheinbar doch was am SDA Pin der CPU zerstört.
Hier eine kurze Diganoseanleitung, alles natürlich OHNE angebaute Teile am I2C Bus mit dem Oszi und einem Multimeter geprüft!
SDA verhält sich so als wenn kein Pullup (R32) da wäre, der ist aber gewechselt und mehrfach getetet. Darauf hin habe ich die Ports SCL und SDA als Ausgang geschaltet und volle Rechteckflanken gemessen, schaute also gut aus. Als Ausgang ist das ok. Hier der Code dazu.
Dann SDA und SCL als Eingang geschaltet und den Prozessor die Werte ansagen lassen.Code:while (true) {
DDRC |= (SCL | SDA);
PORTC |= SCL;
PORTC |= SDA;
mSleep(100);
PORTC &= ~SCL;
PORTC &= ~SDA;
mSleep(100);
}
Ergebnis war, das beide Pins zunächst logisch 1 hatten, der SDA aber manchmal auf 0 kippte. Mit einer Brücke konnte ich beide Pins gegen GND auf 0 ziehen, was ok ist, SCL sprang danach sofort auf 1. SDA kippelte zwischen 0 und 1. Gemessen habe ich am SDA dabei 1,4v statt der erwarteten 4v wie am SCL. Das erklärt das kippeln, ein Verhalten wie bei fehlendem R32 nur das dann 0,7 statt 1,4v zu messen sind.Code:PORTC &= ~SCL;
PORTC &= ~SDA;
DDRC &= ~SDA;
DDRC &= ~SCL;
while (true) {
writeString_P("SCL / SDA -> ");
writeInteger(PINC & SCL , BIN);writeString_P(" / ");
writeInteger(PINC & SDA , BIN);writeChar('\n');
mSleep(500);
}
Also noch mal R32 ausgebaut, gemessen, anderen besorgt, eingebaut... immer das gleiche. SlyD gab mir dann den Tip, mal einen Diodentest zu machen.
Der Diodentest zeigt eine Auffälligkeit.Zitat:
Was misst Du mit dem Multimeter im Diodentest (gegen GND und VDD bei beiden I2C Pins in allen Kombinationen also Rot/Schwarzes Kabel auch tauschen)? Das sollte bei beiden Pins identisch sein. (0,7V 0,6V 1,6V 1,7V sowas in der Richtung je nachdem wie mans polt)
Mit - am SDA/SCL gegen gnd gemessen 0,5v, gegen vdd 1,5v
Mit + am SCL gegen gnd gemessen 1,7v, gegen vdd 0,6v
Mit + am SDA gegen gnd gemessen 1,2-1,0v, gegen vdd 0,4-0,3v und schwankt ein wenig
Meine Folgerung daraus ist, das der Port SDA als Eingang in der CPU einen Schaden hat. Ich glaube nicht an einen Fehler durch den Dauertest oder beschädigung durch Software, vermutlich eher statische Entladung oder der defekten Slave. Es wäre aber auch denkbar das der Slave dabei mit zu Bruch ging (was bedeuten kann, das die M32 auch im Eimer ist). Werde ich gleich noch per Diodentest durchmessen.
Da ich mir nicht zutraue, die CPU selbst zu wechseln, werde ich den RP6 wohl zur reparatur einschicken müssen und mit dem TWI Treiber länger pausieren.
Ich hänge meine letzte aktuelle TWI-Version noch an, sie müsste so ziemlich laufen, testen kann ich sie leider nicht mehr. Wichtigste Änderung ist die Umstellung aller Masterfunktionen auf asyncronen Betrieb da es immer wieder zu Problemen kam, wenn man syncrone und asyncrone Funktionen mischte. Man kann die Befehle aber quasi syncronisieren wenn man nach dem TWI-Befehl sofort task_I2CTWI aufruft, ein folgender TWI-Befehl würde das auch tuen. Es ist also nur für den ersten/letzten in einer Kette von Befehlen sowie bei I2CTWI_requestRegisterFromDevice und I2CTWI_readRegisters relevant, welche aus Mehrfachinstruktionen für die TWI bestehen - sowie für die Fehlerprüfung die auch dort abgewickelt wird. Anders ausgedrückt, es wird immer erst ein Befehl ausgeführt wenn ein weiterer abgeschickt wird oder mit task_I2CTWI nachgeholfen wird. Das ist in zeitkritischen Situationen wie Abfragen eiens SRF zu bedenken. Es erlaubt aber die einstufige Entkoppelung einer TWI Aktion wenn man selbst zeitkritische Dinge zu erledigen hat, die nichts mit dem TWI zu tun haben. Jede Medaille hat eben 2 Seiten. Die Idee dafür stammt übrigends aus SlyDs TWI Version wo es dann manchmal (für den User zuweilen schlecht nachvollziehbar) zu verzögerten TWI-Reaktionen kam, ich habe das nun auf alle Funktionen umgesetzt, damit das Verhalten eindeutig ist.
Wer oft syncrone Funktionen braucht, kann sich mit einem Macro Set ala #define SyncTWIBEFEHL TWIBEFEHL;task_I2CTWI(); für jeden Befehl ähnlich der LCD-Macros in twi_target.h oder einige Macros in RP6I2CTWI.h das Ausführen direkt hinten dran klatschen. Allerdings spart das (noch) nicht den Aufruf von task_I2CTWI(); in der Idle-Loop ein. Ich hatte vor, das später per twi_target.h einstellbar zu machen ob generell sync oder async gearbeitet werden soll.
LG Rolf
Das ist ja echt Pech!Zitat:
Ich hab mir scheinbar doch was am SDA Pin der CPU zerstört.
Aber:
Am I2C-Bus sind die Pins der Teilnehmer direkt miteinander verbunden und über einen Pullup an VDD. Hat man also 3 Teilnehmer am Bus, sind schon 3 Portpins direkt verbunden. Sind dann z.B. 2 davon gleichzeitig AUSGÄNGE (sollte nicht passieren!) und davon einer logisch high und einer low, dann kann das auch das Ende eines Portpins sein. Da braucht es nicht einmal EMV Einflüsse.
Schutz:
Wäre in der Entwicklungsphase eines I2C-Treibers nur mit Reihenwiderständen (z.B. 220 Ohm) an jedem Portpin möglich. Das erlaubt dann aber zunächst keine hohen Taktfrequenzen.
Gruß Dirk
Hier ist aber ein Beitrag von mir verschwunden... ^^
Naja egal.
Ich habe nach einiger Sucherei was gefunden, was im Zusammenhang mit dem Hinweis von Dirk und den Ports auf den Grund der Beschädigung meines Boards und der Schwierigkeiten im MM-Betrieb hinweisen könnte. Ich war zwar der Meinung das Atmel das gefixt hat...
http://www.robotroom.com/Atmel-AVR-T...r-Problem.html
Dort wird beschrieben, das die TWI Hardware bei einem Stop den Bus nicht überwacht und fälschlich für frei halten kann - was zu den besagten Zuständen wie von Dirk beschrieben führen kann. Ich hatte in meinem fehlenden Beitrag argumentiert, warum das nicht passieren darf/kann aber scheinbar haben die CPUs da evtl. eine Macke. Dort wird auch ein Workarround beschrieben, den ich dann testen werde. Ich habe noch einen anderen Verdacht, und zwar das man nach einem Stop dem TWI erst wieder sagen muss das er auf dem Bus lauschen soll. Ähnlich wie bei der Slaveinitialisierung. Dafür habe ich aber bisher nicht 1 Zeile Code im Netz oder in Dokus gefunden, das muss ich erst ausmessen. Es wäre aber quasi logisch zumal ein Stop auch kein irq auslöst - also prädestiniert ist für ein Folgebefehl.
LG Rolf
Eigentlich kann das nur passieren wenn Du einen Port aktiv auf 1 setzt. I2C ist ja Open Drain.Zitat:
mit dem Hinweis von Dirk und den Ports auf den Grund der Beschädigung meines Boards
Nur weil der Master mal nicht am Bus lauscht schaltet der nicht einfach so auf aktiv high. Der darf den Pin nur zwischen aktiv low und high Z wechseln den Rest übernimmt der externe Pullup.
Mehrere Ausgänge gleichzeitig machen so kein Problem - wenn alle nur aktiv auf GND ziehen können.
@SlyD
Hm.. hm... auch wahr. Ok, da auf den Schaden zu schließen funktioniert nicht. Sehe ich ein.
Für das i2c Protokoll ist es jedoch von Bedeutung wenn der Master den Bus nicht verfolgt und nach einem Stop "wild" ein Start bzw Daten sendet. Im "schlimmsten" Fall müsste er arbitieren und/oder ein Buserror kriegen...davon hatte ich beides reichlich beim testen. Das kann ich damit evtl. (hoffentlich) reduzieren. Ich werde mich hüten, die Leitungen aktiv zu steuern ... mir ist schon nicht wohl bei der Umsetzung wie in dem Bugreport die Leitungen abzufragen. Geht zwar aber irgendwas werden sich die Entwickler bei Atmel dabei gedacht haben... die Frage ist nur was. Da bin ich mit dem (N)ACK nach STOP wohl näher dran.... hoff ich.
Andere Frage, wie kriege ich zuverlässig raus, ob noch weitere Devices was abbekommen haben? Reicht es, die Diodenstrecken von SDA und SCL zu messen? Mein M32 Modul und das i2c LCD device sehen nach dieser Messung gesund aus aber ich will mir mein Board nicht gleich wieder zerlegen weil ich was nicht beachtet hab.
EDIT: Mir ist grade aufgefallen, das ich bei einer meiner letzten Umräumaktionen im code eine wichtige Abfrage verschusselt habe.
Und zwar fehlt in task_I2CTWI um das ganze Switch Konstrukt die Zeile:
if bit_is_clear(TWI_statusReg,STR_isr) {
und unten dann }
Ohne die Abfrage überrennen sich natürlich die Befehle wieder... was zu Allem führt.. nur nicht zu einer geordneten Datenübertragung. Sorry. Wirklich lauffähig ist der Code aber auch dann noch nicht. Ich wieder einige Problemstellen gefunden.
Es hat sich auch sonst wieder einiges getan im Source. Es gibt jetzt einen speziellen 400KHz Mode für den 100KHz Bus, eine Fehlerbehandlung mit Zähler und Retry, ein Timeout bei Fehlern, syncrone/asyncrone Ausführung ... ich hoffe mein Board ist schon unterwegs da ich so vieles nicht wirklich testen kann. Hab zwischenzeitlich WinAVR ausprobiert aber der SIM ist nicht besonders geeignet um ISRs zu debuggen, sonst aber ganz nett.
EDIT: Ein netter Mensch hier aus dem Forum ist bereit mir sein RP6 zu verkaufen, demnächst hab ich also 2 Stück... und kann besser vergleichen. Mal sehen was zuerst eintrifft. Das Ersatzboard oder der Zukauf. Und dann gehts endlich weiter...
EDIT: Da mein Board noch nicht hier ist, suche ich diverse Schaltungen und Knowhow zum Thema AVR und I2C. Nun ist mir aufgefallen, das manche die Pullups bis 470 Ohm - also auf 10% dessen runter setzen was aktuell im RP6 anliegt - allerdings dann mit einer LED im Zweig gegen VDD. Namentlich z.b. die ATmega8 ASM Treiber im www.mikrocontroller.net für Master/Slave Betrieb mit Schaltplan. Dies bedeuet natürlich ordentlich Laststrom in der Ausgangsstufe des AVR, zieht die Leitung aber bei high weiter nach VDD. Sie baumelt ja bei mir normal derzeit so um 2 V, mit der LED zum testen nun bei 3V -3,5V im Highzustand.
Ich hab mal ein Filmchen davon gemacht.
http://home.arcor.de/rolf.diesing/daten/P1100529.MP4 (fliegt die Tage wieder raus... )
Die CPU befindet sich zu dieser Zeit GARANTIERT in einer While (true) Schleife, es finden keine Datenbewegungen statt und wenn die CPU SDA auf low schaltet also aktiv Daten schiebt, leuchtet die LED erwartungsgemäß kräftig. Die gelbe 5mm LED flackert hier schwach obwohl der AVR nichts auf den Ports macht. Mein Oszi zeigt ebenfalls oben die grade laufende SCL Leitung bei 5v und unten die flackernde SDA Leitung (Oszi im Dual chopper Mode, 1V/cm 20ms/cm). Und das Ganze mit 470 Ohm Pullup an der LED. Mit der Schaltung kriege ich übrigends fast zuverlässig Daten auf ein I2C LCD mit PCF8574 geschrieben da ich nun halbwechs definierte Logikpegel habe. Die Störungen/Flackern tritt jedoch auch bei der Datenübertragung auf und einlesen kann der Port damit immer noch nicht richtig. Ohne die LED und nur mit R32 flackert der SDA Port sonst irgendwo bei 1,2V und 2,2V ... ich hätte aber ehrlich gesagt nicht mal damit gerechnet, das es mit der LED klappt, denn da muss ja irgendwo in der CPU ein angeschlagener Transistor sein und der kriegt nun locker 10mA ab.
EDIT: So... mein 2ter RP6 steht auf dem Tisch, heute war der Paketbote da, es kann weiter gehen. Das Ersatzboard aus Holland ist leider noch nicht da. Die M32 ist auch wieder angeflanscht und die Hardware ist damit jetzt erst mal wieder soweit ok das ich Base und Master zugleich testen kann. Erste Messungen an SDA/SCL ergeben erwartete Werte und ordentliche Pegel. Ich werde zusehen, das ich Dirks letztes Programm ans laufen bekomme und bald eine neue beta rausbringe. Ich habe durch den 2.ten Bot nun auch 2 USB-Adapter. Man kann zwar 2 Robotloader starten aber wenn man Verbindung zum ersten USB Adapter aufbaut, verweigert der Loader beim 2. dann mit Hinweis das die Schnittstelle "in use" sei. Base und M32 gleichzeitig debugen geht also immer noch nicht aber ich brauche zumindest nicht mehr umzustecken. Wäre schön wenn man den Loader (ich hab 1.5h) da noch anpassen kann.
EDIT: Mein Ersatzboard von AREXX ist da :) Das ist die Gute Nachricht... die schlechte - man hat bei AREXX das Board in einen wattierten Umschlag gepackt und die Post hatte nix besseres zu tun als da massenweise Stempel mit "Priority mail" draufzukloppen.... 8-9 Stück... beidseitig.... und das ganze für eine Strecke von unglaublichen 231 Km und min. 1 Woche unterwegs... Ich muss leider erst testen ob das Board das überlebt hat ... mit grade biegen von Teilen isses da leider nicht mehr getan. Der Schalter, der sich schon durch die Briefhülle gedrückt hatte ist jedenfalls hin... aber da kann ich den aus dem alten Bord umlöten. Oh man... nur Ärger!
EDIT: Das I2C treibt mich noch in den Wahnsinn...
Sooo... wieder mal neues vom TWI.
Folgendes... der Treiber ist BETA und noch nicht fertig. Ich kann ihn noch nicht zur allgemeinen Nutzung frei geben. Er funktioniert aber schon mal soweit, das man es sehen kann und ich denke, zum betatesten langts auch schon mal.
Basis zum testen ist weiterhin Dirks Programm, was ich leicht modifiziert habe. Beide Programme (Base/M32) sind beigefügt, incl. der dazugehörenden TWI_TARGET.H
Es sind einige Optionen hinzu gekommen in twi_target, ansich sind sie aber dort jeweils kurz erklärt.
Was passiert da jetzt genau?
Nun auf beiden CPUs läuft jeweils ein masterfähiger Slave. Die beiden werfen sich Daten zu, die sie umkopieren so das die wieder abgeholt werden können. Die Ergebnisse werden vom Master verglichen und wenn Fehler auftauchen, werden diese erkannt und ausgegeben.
Starten tuen die jeweiligem Mastertasks z.Z. nur auf verlangen, das heisst beim drücken der Bumpertasten bzw. Key 1 auf der M32. Das habe ich deshalb gemacht, weil die sich z.Z. noch gegenseitig überrennen würden, wenn aber nur je einer sendet, klappts. Kann man einfach testen indem man auf beiden Boards die Taster drückt. Ziel wird sein, das beide auch dauerhaft senden können. Dafür ist das System jedoch noch nicht robust genug. Daher auch Beta. Derzeit dürften es die beiden Funktionen I2CTWI_request* nicht tuen.... also nicht wundern. Auch ein Grund für Beta.
Es gibt neben dem normalen Debug nun ein Debug für eine State Engine, diese überwacht ob ein kompletter Transport erfolgte (incl. Stop) sowie eine allgemeine Ausgabe für Bufferüberläufe.
Es gibt da noch ein paar ungereimtheiten im Timing, ich hoffe aber das beseitigen zu können. U.a. gehen ab und zu Daten verloren bzw. ist der Slave der Meinung, das Daten reinkamen obwohl die Register noch nicht beschrieben wurden. Je mehr Befehle in der ISR ausgeführt werden - und sich damit das Clocksignal streckt - um so seltener werden die Fehler. Es macht dabei z.B. einen Unterschied ob man die Stateengine einschaltet oder nicht. Das sind vielleicht 20 Maschinenbefehle mehr als sonst... also keine wirklich langen Zyklen. Mir ist aber nicht klar warum das so ist. Es gehen aber bis auf dieses kleine Problem keine Daten flöten, der Master macht bis zu 10 neue Anläufe mit je 5ms Pause dazwischen (alles einstellbar), der Slave nackt wenn er Busy ist und so kommen normal auch alle Daten zielsicher an.
Viel Spass beim testen
LG Rolf
EDIT: Einen längeren Test über mehrmalig je 1-2 Std. überstanden mein reparierter RP6 und der 2.te damit auch schon. Also keine Sorge. Übrigends sind seid der Reparatur komischer Weise ALLE Buserrors weg.
Edit: Weitere Änderung, ich hatte nicht bedacht, das bei Dirty Regs der Host (Slave) zwar ein weiteres Schreiben mit I2CTWI_doneAction(); frei geben muss, der Client (Master) aber die Regs bisher auslesen kann wärend der Slave sie ändert bzw. bearbeitet - was vor allem auf der schnelleren M32 zu Fehlern führt. Daher muss man die case TWI_STX_DATA_ACK gegen Folgende austauschen. Dies verhindert dann ein Auslesen wenn der Client noch nicht so weit ist - auch wenn kein Registerpointer geschrieben wird.
Dieser Fix ist für eine Anwendung wie in dem RP6-Slave weniger wichtig, in Dirks Programm jedoch, wo sich beide CPU's mit Daten bewerfen und requesten spielt es eine gewichtige Rolle.Code:case TWI_STX_DATA_ACK: // 0xB8 TW_ST_DATA_ACK Data byte in TWDR has been transmitted; ACK has been received
if (TWI_statusReg.needAction && TWI_statusReg.NACKonAction) { //if Registers dirty, now send nacks
#ifdef DEBUG
logmyaction(TWI_STATUS,"/ STX_(ADR|DATA)_ACK NACK (Slave busy)");
#endif
TWI_statusReg.SendNACK=1; //dead end, master must retry, I2CTWI_doneAction/TWINIT will reset this
} else {
if (current_register < I2CTWI_SLAVE_READ_REGISTERS) {
TWDR = I2CTWI_readableRegisters[current_register++];
TWI_statusReg.SendACK=1;
#ifdef DEBUG
logmyaction(TWDR,"<- STX_DATA_ACK -> ACK (data)");
#endif
} else {
#ifdef DEBUG_MISC
writeString_P("Register read boundary violation\n");
TWI_statusReg.SendNACK=1;
#else
TWDR = 0;
TWI_statusReg.SendACK=1; // THIS should not happen... count your Regs please...
#endif
}
}
break;
Damit macht nun auch ein weiterer Befehl in der RP6I2CTWI.h Sinn.
#define I2CTWI_doAction() TWI_statusReg.needAction=1
was quasi den Slave jederzeit in die Lage versetzt, dem Master anzuzeigen das er grade keine Daten kriegt, was man aber durch
I2CTWI_doneAction(); auch wieder freigeben sollte. Dabei sind die Retrys und der Timer in twi_target.h zu berücksichtigen.
Der Slave sollte also nur max so lange die Regs blockieren wie sich aus den beiden Zahlen Millisekunden + Reserve ergeben.
Leider liefern die asyncronen Funktionen ja kein echten Errorcode zurück, sonst könnte man das besser abfangen.
Kleine Änderung für TWI_MRX_ADR_NACK, bisher wurde hier ein Error initiiert, dies sollte durch ein Restart ersetzt werden. Zum einen entscheidet der Retrycode ob und was ein Error ist, zum anderen ist ein NACK auf Grund von "Device Bussy" ja kein Grund, den ganzen Transport abzuwürgen. Die case TWI_MRX_ADR_NACK wird daher ersetzt mit:
Das System verhält sich damit bei einem NACK im Master Receive (MRX) Mode genau so wie im Master Send (MTX) Mode und versucht es erneut bis die Retry Defaults aus twi_target.h erreicht sind.Code:case TWI_MRX_ADR_NACK: // 0x48 TW_MR_SLA_NACK SLA+R has been transmitted and NACK received
#ifdef DEBUG
logmyaction(TWDR,"<- MRX_DATA_NACK RESTART (busy)");
#endif
TWI_STATUS_state = TWI_STATUS;
TWI_statusReg.SendStop=1;
TWI_old_operation = I2CTWI_NEED_RESTART;
break;
EDIT:
Ich habe ein weiters Problem gefixt, der Slave war zu früh der Meinung, das der Transport fertig ist wesshalb teilweise Daten nur halb ankamen bzw. zu früh verarbeitet wurden. Die Änderungen im Code sind zu verstreut als das ich sie hier posten kann, es wird also demnächst wieder eine Beta geben. Ich suche z.Z. aber noch ein Fehler, der dann zu Stande kommt wenn beide CPUs quasi zeitgleich senden. Das ist ein Laufzeitproblem und hat wohl noch nichts mit Arbitierung zu tun.
Es gibt mal wieder eine neue Beta.
Einige Fehler sind gegenüber der vorherigen Version behoben. Achtung, die TWI Einstellungen stehen z.Z. auf debug. Die Version läuft recht stabil und macht nur Probleme wenn beide Seiten gleichzeitig senden, da bleibt der Slave code dann wohl irgendwie hängen ohne das es zur arbitation käme.
In dem Code stecken mehrere "Verriegelungen" damit z.B. der Master nicht das Senden anfängt so lange der Slavecode noch empfängt. Ich hab das nun schon drei mal umgeschrieben aber da ich mich an viele Vorgaben des alten Treibers halte, gelingt es mir bisher nicht, gewisse Probleme wasserdicht zu lösen.
Die Version ist also wie die vorherigen eine Beta bzw. "Zwischenstand".
Um den Master zu aktivieren muss man hier T1 auf der M32 oder die Bumper auf der Base auslösen, ansonsten befinden sich die Boards im slave mode.
LG Rolf
EDIT: Für Leute die mal testen wollen ohne das Projekt zu bauen leg ich mal noch die hex-Files bei. Wie gesagt... Debug aktiv -> viel Textausgabe auf Console... Benötigt werden die Base, eine M32 und ein Display an der M32
Und, wie sieht es so aus? Hast du nochmal nach den Problemen beim wechselseitigen Senden geforscht?
Wolltest du nicht auch eine Version für die M128 machen? :)
Nein... ja.. geforscht schon.. aber es nicht wasserdicht gelöst. Ich habe auch den Eindruck das viel zu wenig Interesse besteht als das ich da allein Tage über Tage an Zeit reinhänge. Auf die letzte Testversion gabs auch kein Feedback... also was solls.
Für die M128 könnte man das als Maschinencodemodul evtl. auch machen, die Software hat ja nur eine mässig implementierte Master-I2C mit polling...bedingt durch das Interpreter-C. Da hab ich aber noch keine weiteren Forschungen unternommen.
LG
Hi Rolf,
ich hatte bislang leider leider noch keine Zeit das genauer unter die Lupe zu nehmen,
aber mal dazu:
> da ich mich an viele Vorgaben des alten Treibers halte,
> gelingt es mir bisher nicht, gewisse Probleme wasserdicht zu lösen.
Wenn Dir die API nicht gefällt, änder das ruhig ab. Die ganze RP6lib ist gerade deshalb Opensource damit man bei Bedarf was dran ändern kann wenn es nicht passt (in großen Opensource Projekten (z.B. im Linux Kernel) ändert sich auch dauernd irgendwo irgendwas an den APIs das ist völlig normal)
Die geringe Resonanz dürfte auch daher kommen, das für die meisten standard Anwendungen die bisherige Lib stabil genug ist.
(also die möglichen Fehlerfälle nicht weiter auffallen)
MfG,
SlyD
Das sehe ich genauso. Da ich von I2C nicht viel Ahnung habe warte ich als "Abstauber" auf eine bessere Version von euch :)Zitat:
Die geringe Resonanz dürfte auch daher kommen, das für die meisten standard Anwendungen die bisherige Lib stabil genug ist.