Druckbare Version
Die zeitliche Auflösung der Aufnahmen erlaubt leider keine Beurteilung dessen, was dort tatsächlich an Daten ausgetauscht wurde. Eigentlich bräuchte man zu Vergleichszwecken einmal die Kommunikation (im Detail) mit der RP6-Lib und mit der Fleury-Bibliothek.
Außerdem stocherst du noch immer im Nebel rum. Es wäre keine große Kunst, sich genau anzusehen was der Code von Fleury im vergleich zur RP6-Lib anders macht.
mfG
Markus
Hallo,
ja, das gebe ich zu, die zeitliche Auflösung ist mies, war aber eben nur einfacher abzufotografieren. :D Leider kann ich das Oszilloskop nur momentan noch nicht an den PC anschließen, ich muss also abfotografieren...
Ich habe das ganze jetzt mit einem ATmega8 und der Library von Fleury getestet, dort funktioniert das nahezu perfekt - nahezu. Bei der Adresse 0x00 funktioniert (mit dem Mega8!) alles perfekt, komplett wie im Datenblatt, die Werte ändern sich, wenn man z.B. mit der Hand über dem Sensor ist. Bei 0x5A sieht das aber schon anders aus - anscheinend wird richtig initialisiert, aber das, was da zurückkommt, ist die Adresse, also 0x5A (im Bild vorsichtshalber erstmal als ,,???" gekennzeichnet)...
In Sachen RP6 kann ich da allerdings nichts draus deuten - ich bekomme immer noch 0 zurück, obwohl das sehr ähnlich aussieht, bis auf die Sendepause nach dem Repeated Start...
Naja, hier jetzt vernünftige Fotos. Ich hoffe, dass da jetzt alles passt, ich habe auch etwas kommentiert, wo ich vermute, was was bedeutet.
Die Adresse ist bei einem Foto 0x5A und bei einem anderen Foto 0x55, das liegt daran, dass ich es immerhin zusätzlich mit einem Mega8 geschafft habe, die Adresse des Sensors zu ändern (natürlich mit einem anderen Code, Adresse muss aber so oder so früher oder später geändert werden).
Bitte schaut Euch die Fotos nochmal an, auch wenn wir damit weiterhin im Nebel stochern - wer weiß...
Bild 1 = ATmega8, Adresse 0x00
Bild 2 = ATmega8, Adresse 0x5A
Bild 3 = RP6, Adresse 0x00
Bild 4 = RP6, Adresse 0x55
A = Ack
RS = Repeated Start
W = Write
R = Read
Vielen Dank und
Viele Grüße
teamohnename
Anhang 21615Anhang 21616Anhang 21617Anhang 21618
Hallo,
so damit kann man schonmal was anfangen.
Das liegt wohl daran das beim Code der RP6Lib da schlicht kein Repeated Start gesendet wird.
Da wird gestoppt und neu gestartet.
Setzt vorraus, dass das Register zwischengespeichert wird - macht der Sensor aber wohl nicht und
braucht das alles in einer Transaktion.
Kann man natürlich ändern.
Ist bei der RP6Lib alles in der Interrupt Routine und task_I2CTWI - also komplexer als die Fleury Lib damit noch anderes nebenher laufen kann.
Muss ich mir bei Gelegenheit mal anschauen aber eigentlich habe ich da grad keine Zeit für daher wäre es gut wenn ihr euch das selbst anschaut.
Hinweise:
-->im TWCR Register das TWSTA Bit 1 setzen für Start. TWSTO --> Stop.
Rest steht im ATMEGA Datenblatt.
In der ISR müsste man halt nen Sonderfall einführen (also nen Flag setzen das ein Repeated start benötigt wird und das dann eben
machen anstatt stop senden - für die normalen RP6 Slaves sollte es weiter so laufen wie es aktuell ist)
Glaube im Zustand TWI_MTX_DATA_ACK - da bei // Send Stop after last Byte das Stop wegmachen also 0 << TWSTO...
Die eigentliche Anfrage der Datenbytes wird dann in task_I2CTWI gestartet (daher auch die Pause - das passiert halt irgendwann
wenn die Hauptschleife da wieder vorbeikommt der Controller also Zeit hat sich drum zu kümmern ;) ).
Im Prinzip müsste es für einen ersten Test schon reichen das TWSTO in Zeile 381 auf 0 zu setzen .
Alles ohne Gewähr kann auch sein das man noch was anderes ändern muss.
Ist viele Jahre her das ich den Code geschrieben habe und mir das Datenblatt dazu
durchgelesen hab. Zeit zum testen hab ich nicht.
...
Zeile 381: ...(rep<<TWSTO)...
rep darf nur 0 oder 1 sein - 1 für normal - 0 für repeated start.
Machste dann ne neue Funktion oben hin wie eine von den anderen und setzt das da eben auf 1 - in allen anderen auf 0.
Sorry aber das ist nur Quick&Dirty - hab zuviel anderes zu tun zur Zeit um mich da genauer mit zu befassen und das zu testen hoffe die Tipps helfen euch schon um es selbst zu lösen.
MfG,
SlyD
Hi SlyD,
danke für Deine Antwort.
Habe ich es richtig verstanden, dass ich theoretisch nur die ISR bearbeiten muss und direkt unter ,,case TWI_MTX_DATA_ACK" abfragen muss, ob ich einen Repeated start brauche oder ein stop?
Wie findet der Roboter denn heraus, ob der Sensor einen repeated start benötigt? Was kommt also in die if-Abfrage? Das ist mir noch nicht ganz klar, das finde ich auch niergends im Datenblatt. Der Roboter müsste ja dazu in die Zukunft sehen?! :)
Danke nochmal und
Viele Grüße
teamohnename
EDIT: Oder hat das was mit den Codes in Figure 87 oder 89 des ATmega32 Datenblattes zu tun? Dann hätte sich für mich auch die Frage mit ,,in-die-Zukunft-sehen" geklärt (der Master erkennt das dann am vorherigen Verhalten des Slaves?!). :D
Die Werte aus diesem Diagramm stehen ja in TWSR. Einzig logisch wäre meiner meiner Meinung nach nur Figure 87, da der Master zu dem Zeitpunkt noch im Sendemodus ist und erst einen Repeated Start senden muss, bevor er neu anfragt und in den Receivermodus geht. Laut dem Datenblatt sendet der Slave (MLX90614) nachdem die Schreibeadresse und 0x07 gesendet wurde ein Ack. Der Code, der dann in TWSR stehen würde, wäre dann theoretisch 0x28. Dann müsste man unter ,,case TWI_MTX_ADR_ACK" rep=1 schreiben. Wo müsste dann aber rep = 0 stehen, also ein Stop eingeleitet werden?
;) nein ich meinte DU legst fest ob Dein Slave das braucht oder nicht!Zitat:
Der Roboter müsste ja dazu in die Zukunft sehen?!
Im Programmcode.
Ne ist invertiert.Zitat:
aber rep = 0 stehen, also ein Stop eingeleitet werden?
Nenn die variable no_rep dann isses logischer ;)
no_rep muss in ALLEN transmit / read funktionen oben auf 1 gesetzt werden.
Dann kopier Dir die eine die Du für den Sensor brauchst und änder die um, setzt es da auf 0 und setzt es in task_I2CTWI wieder auf 1.
MfG,
SlyD
Hi,
sorry, aber entweder ich bin zu blöd dafür oder es ist falsch...
Was meinst Du mit transmit/read Funktionen? Die I2C Read etc. aus der Library oder meine selbst geschriebenen, die die einzelnen Sensoren abfragen? Ersteres wäre ja sinnlos...
Es ändert sich am Oszilloskop nur etwas, wenn ich direkt in der ISR TWSTO komplett ändere, dass generell kein STop mehr gemacht wird, dann gibt es aber auch wieder einen Error.
Habe ich es denn wenigstens richtig verstanden, dass ich in die task_i2c() no_rep auf 1 setzen soll, vor jede eigene Funktion auch no_rep auf 1 setze und dieses dann in der Routine zum Abfragen des Sensors auf 0 setze, dass das also dann so aussieht:
Vielen Dank undCode://no_rep wird in der ISR vor TWSTO eingetragen, in task_i2c() am Anfang auf 1 gesetzt und in dieser einen Funktion auf 0 gesetzt
void getIR(void)
{
no_rep_start = 0;
I2CTWI_transmitByte(0x00,0x07);
I2CTWI_readBytes(0x00, sensorBuf, 3);
}
Viele Grüße
teamohnename
In den I2CTWI_transmit Funktionen in der Lib - direkt bevor TWCR gesetzt wird - muss das auf 1 gesetzt werden.
In den anderen Funktionen könnte man es auch setzten - geht aber glaub ich auch ohne.
no_rep sollte übrigens ein uint_8t sein.
In der task_I2CTWI sollte dann in der if(TWI_operation)
no_rep auf 1 gesetzt werden....
Im einfachsten fall einfach immer ohne unterscheidung welcher Zustand.
readRegisters kannst Du dann übrigens nicht dafür verwenden - das müsste auch noch passend modifiziert werden mit zusätzlichem Zustand in der task_I2CTWI... aber egal. Probier erstmal das.
I2CTWI_transmitByteREPEATED_START(0x00,0x07); <<<---- Deine Eigene Funktion
I2CTWI_readBytes(0x00, sensorBuf, 3);
müsste dann aber klappen.
MfG,
SlyD
Hallo,
no_rep_start wird jetzt in allen i2c Transmit Funktionen über der TWCR Zuweisung auf 1 gesetzt, außer in einer Funktion I2CTWI_transmitByteREPEATED_START(0x00,0x07);), dort wird es über TWCR auf 0 gesetzt. Auf 1 gesetzt wird es in der task_I2CTWI in if(TWI_operation).
Diese Variable wird dann nur in Zeile 381 der I2CMaster Libs TWSTO zugewiesen:
Sonst niergends!Code:case TWI_MTX_DATA_ACK: // Data byte has been transmitted and ACK received
if (TWI_bufPos < TWI_msgSize) {
TWDR = I2CTWI_buf[TWI_bufPos++];
TWCR = (1<<TWEN)| // TWI Interface enabled
(1<<TWIE)|(1<<TWINT)| // Enable TWI Interupt and clear the flag to send byte
(0<<TWEA)|(0<<TWSTA)|(0<<TWSTO)| //
(0<<TWWC); //
} else { // Send STOP after last byte
TWI_statusReg.lastTransOK = 1; // Set status bits to completed successfully.
TWCR = (1<<TWEN)| // TWI Interface enabled
(0<<TWIE)|(1<<TWINT)| // Disable TWI Interrupt and clear the flag
(0<<TWEA)|(0<<TWSTA)|(no_rep_start<<TWSTO)| // Initiate a STOP/REP_START condition.
(0<<TWWC); //
}
break;
Das Resultat ist der TWI Error 0x30.
Wenn ich in meiner neuen, angepassten Funktion:
Das no_rep_start auf 1 setze, ist alles wie vorher...Code:void I2CTWI_transmitByte_RepeatedStart(uint8_t targetAdr, uint8_t data)
{
while(I2CTWI_isBusy() || TWI_operation != I2CTWI_NO_OPERATION) task_I2CTWI();
I2CTWI_delay();
TWI_msgSize = 2;
I2CTWI_buf[0] = targetAdr;
I2CTWI_buf[1] = data;
TWI_statusReg.all = 0;
no_rep_start = 0;
TWCR = (1<<TWEN)|(1<<TWIE)|(1<<TWINT)|(0<<TWEA)|(1<<TWSTA)|(0<<TWSTO);
}
Muss eventuell noch irgendwas (ein TWSTO) mit no_rep_start gesetzt oder ergänzt werden?
Danke und
Viele Grüße
teamohnename
Hallo,
die Bedeutung der Fehlercodes steht übrigens in der Header Datei.
In diesem Fall kam ein NACK nach nem Datentransfer zurück.
> Auf 1 gesetzt wird es in der task_I2CTWI in if(TWI_operation).
wo genau? Muss ganz oben gemacht werden nicht unter den Fallunterscheidungen.
(also wieder bevor TWCR gesetzt wird)
> Muss eventuell noch irgendwas (ein TWSTO) mit no_rep_start gesetzt oder ergänzt werden
Schon möglich. Wie gesagt - ich hab keine Zeit das zu testen das oben gesagte war alles
frei aus dem Kopf ohne nochmal ins Datenblatt zu schauen.
MfG,
SlyD
Hi,
wenn es ganz oben in task_I2CTWI steht, ist auch wieder alles wie vorher, also ohne Repeated Start...
Was könnte denn noch geändert werden müssen? Wenn Du keine Zeit hast, ist das auch erstmal nicht so schlimm... Wir werden dann wohl noch etwas experimentieren müssen... Aber wenn Dir noch etwas einfällt; nur her damit! ;)
Vielen, vielen Dank für Deine Hilfe bis jetzt und
Viele Grüße
teamohnename
Hier übrigens nochmal ein Bild vom Scope, wie es war, als das Nack kam:
Anhang 21622