Hallo,
ich bin relativ neu im Bereich des MSP430. Beim aktuellen Projekt eines
USB-Tracers hänge ich gerade bei der Instandsetzung der I2C Übertragung.
Ich verwende für den Master den MSP430F5310 und für den Empfang den
MSP430F6638. Die empfangenen Daten speichere ich in einem Ringbuffer.
Nur leider sind die empfangenen Daten ziemlcih durcheinander. SIe kommen
einfach nicht in der richtigen Reihenfolge an. Verbaut habe ich 5,1kOhm
Pull-ups. Das witzige ist auch, wenn ich Breakpoints setze sowohl in der
INterrupt Routine des Senders als auch beim Empfänger, und immer wieder
auf Play drücke, kommen die Daten in der richtigen Reihenfolge an.
Woran kann das liegen?
Es handelt sich hier um den Beispielcode von TI:
EMpfänger:
Das wichtigste zeigst du nicht: addElement ()
Was man auf die Schnelle sieht:
TXData wird auf 21h und nicht 31h gesetzt.
TXByteCtr darf nicht in der Mainloop immer wieder gesetzt werden.
MMh ja, das sind ja zwei sachen, die eigentlich nicht so zu
fehlübertragungen führen sollten, oder? Das komische ist ja wenn ich
schritt für schritt debugge wird alles richtig übertragen. Habe nen Takt
von 100kHz. Sollte ja auch nicht so das Problem sein.
Der Ringbuffer funktioniert bei SPI problemlos, daher dachte ich, wäre
er nicht so wichtig. Hier ist er aber noch mal:
1
#include"circularBuffer.h"
2
#include<stdbool.h>
3
TYPEBuffer[BUFFER_SIZE+1];// It needs 1 extra byte to difference full and empty
4
unsignedcharnext=0;
5
unsignedcharfirst=0;
6
7
boolisFull(){
8
if(getNumberOfElements()==BUFFER_SIZE){
9
next=first;
10
returnfalse;
11
}else{
12
returnfalse;
13
}
14
}
15
16
boolisEmpty(){
17
if(next==first){
18
returntrue;
19
}else{
20
returnfalse;
21
}
22
}
23
24
TYPEgetElement(){
25
TYPEtheElement=0;
26
if(!isEmpty()){
27
theElement=Buffer[first];
28
if(first!=BUFFER_SIZE){
29
first++;
30
}else{
31
first=0;
32
}
33
}
34
35
returntheElement;// Return 0 always if it is empty, must be checked before
Hallo,
ich hab mir den ganzen thread nicht angeschaut aber mir ist aufgefallen,
dass Deine Funktion "isFull()" immer false zurückliefert. Vielleicht
hilft das weiter.
Die ganze Puffer Verwaltung ist für die Tonne. Schreib deine Daten in
ein großes lineares array und über prüfe die Kommunikation. Wenn das
läuft, kümmere dich um den Puffer.
Florian Hinrichs schrieb:> Nur leider sind die empfangenen Daten ziemlcih durcheinander.> Verbaut habe ich 5,1kOhm Pull-ups.
Durcheinander, aber richtig oder sind sie falsch?
Zur Hardware (auch wenn der Fehler eher in der SW vermutet wird):
5k1 ist in Ordnung, wenn deine I2C-Leitungen kurz sind, wenn du nicht zu
schnell unterwegs bist (100kbit/s), wenn nur ein Slave dran hängt und
wenn es ein 5V-Interface ist.
Ich persönlich tendiere bei I2C eher zu 2k-Pullups oder, wenn mehrere
der o.g. Parameter zutreffen, auch zu noch kleineren Werten.
Danke erstmal für eure schnellen Antworten.
zu HildeK: ja Leitungen sind kurz (20 cm), 100kb/s Übertragung und es
hängt nur ein Slave dran. Gemessene BEtriebsspannung liegt bei 2,88 V.
Werde morgen dann auch mal zu kleineren Pull-ups greifen.
zu nur mal so: uhhh, ok. Aus welchem Grund ist er für die Tonne?
Grundlegende Fehler drin? Konzept total falsch. Bei SPI hat der
wunderbar funktioniert.
VErsuche es gleich erstmal mit nem linearen Array. MAl schauen was
rauskommt
ein Beispiel:
Florian Hinrichs schrieb:> bool isFull(){> if (getNumberOfElements() == BUFFER_SIZE){> next = first;> return false;> }else{> return false;> }> }
Die beiden false Zweige hatten wir ja schon. Aber was passiert bei true?
next = nil ist die Bedingung für Buffer Empty. Ist das wirklich gewollt?
Florian Hinrichs schrieb:> bool isEmpty(){> if ( next == first ){> return true;
Probier es erst mit einem linearen array.
Es ist einfach nur total komisch. Ich habe jetzt nur ein ganz normales
lineares Array.
1
voidaddElement(chardata)
2
{
3
Buffer[n]=data;
4
n++;
5
}
Aber trotzdem sind die Einträge wild durcheinander. Ich übertrage immer
von 0 bis 9. herauskommen tut dann aber: 0,4,1,8,5,2,9...
Wenn ich im Sendercode debugge und wirklich schritt für schritt
weitergehe kommt alles richtig an. Ich verstehe es einfach nicht.
Das verrückte ist jetzt auch noch, dass das Array jedes Mal in der
selben chaotischen Reihenfolge beschrieben wird. Also jedes Mal, wenn
ich neu builde.
Florian Hinrichs schrieb:> das Array jedes Mal in der> selben chaotischen Reihenfolge beschrieben wird
Dann ist es doch nicht chaotisch.
Florian Hinrichs schrieb:> void addElement(char data)> {> Buffer[n] = data;> n++;> }
Was passiert bei Überlauf?
Florian Hinrichs schrieb:> unsigned char TXByteCtr;
Wie wäre es mit volatile? Und warum beschreibst du die Variable ohne
Synchronisation mit der ISR? Passt die Zuweisung nicht in die ISR nach
der Stop Condition?
Da es im Einzelschritt läuft, hast du kein Hardware Problem! Also
vergiss die Pull Upps und sortiere deinen Sender: Während die USCI die
Daten raus taktet, zählt die main loop fröhlich TXData hoch.