Hallo ich versuche gerade einen I2c bus aufzubauen hab auch schon ewig
lang gesucht und hab keine konkreten beispiele gefunden die mir
weiterhelfen bei meinem projekt das problem ist das ich die kompletten
befehle des msp430 für den i2c bus nicht kenne. Ich versuche gerade
einen fm75 komplimentärtyp lm75 auszulesen und den wert zum einschalten
verschiedener ports zu verwenden kann mir jemand helfen?? wäre über jede
hilfe dankbar.
Bobby schrieb:> das ich die kompletten> befehle des msp430 für den i2c bus nicht kenne.DerMSP430 hat keine Befehle "für den i2c bus". Je nach Variante wird
unterschiedliche Hardware verwendet, die I2C zur Verfügung stellt.
Welche in Deinem Falle zum Tragen kommt, kannst Du dem /User's Manual/
entnehmen, das zu DeinemMSP430-Derivat passt.
Das ist die USCI_B, und die wird in http://www.ti.com/litv/pdf/slau144e
ab Seite 17-1 (521) beschrieben.
TI stellt recht ausführliche Codebeispiele zur Verfügung, die auch für
Deinen 'F2132 beschreiben, wie die I2C-Schnittstelle anzusteuern ist.
http://www.ti.com/litv/zip/slac163c
Da sind die Dateien
msp430x21x2_uscib0_i2c_02.c
und
msp430x21x2_uscib0_i2c_03.c
besonders von Interesse.
All diese Informationen sind mit weniger als 5 Minuten Recherche von
genau EINER Webseite abrufbar gewesen:
http://focus.ti.com/docs/prod/folders/print/msp430f2132.html
Ich habe diese Beispiele bereits gefunden komme aber nicht richtig mit
den kommentaren klar und da ich blutiger anfänger bin komm ich auch
damit nicht richtig weiter z.b in dem programm
verstehe ich diesen teil nicht:
while (1)
{
__bis_SR_register(CPUOFF + GIE); // CPU off, interrupts
enabled
UCB0CTL1 &= ~UCTR; // I2C RX
UCB0CTL1 |= UCTXSTT; // I2C start condition
while (UCB0CTL1 & UCTXSTT); // Loop until I2C STT is
sent
UCB0CTL1 |= UCTR + UCTXSTT; // I2C TX, start condition
__bis_SR_register(CPUOFF + GIE); // CPU off, interrupts
enabled
while (UCB0CTL1 & UCTXSTT); // Loop until I2C STT is
sent
UCB0CTL1 |= UCTXSTP; // I2C stop condition after
1st TX
}
}
#pragma vector = TIMER0_A0_VECTOR
__interrupt void TA0_ISR(void)
{
__bic_SR_register_on_exit(CPUOFF); // Exit LPM0
}
// USCI_B0 Data ISR
#pragma vector = USCIAB0TX_VECTOR
__interrupt void USCIAB0TX_ISR(void)
{
UCB0TXBUF = (UCB0RXBUF << 4) | 0x0f; // Move RX data to TX
__bic_SR_register_on_exit(CPUOFF); // Exit LPM0
wo wird hier das byte geschickt und wo wird das empfangene gespeichert??
}
Noch eine frage benötige ich eigentlich bei siesem Typ einen I2c Bus
treiber oder kann ich einen kleinen i2c bus direkt an den ports con
uscib0 anschliessen welcher vorteil wird durch eine i2c treiber
erbracht.
So hab jetzt mal ein code example aufgesplittet und paar fragen
eingebaut wäre sehr schön wenn jemand mir jetzt mal diese fragen
beantworten könnte hier das programm:
//Originalprogramm MSP430x21x2_uscib0_i2c_01.c
// wo werden hier die daten gesendet und wo empfangen wo wird das
register ausgewählt in das geschrieben wird
1
#include"msp430x21x2.h"
2
3
4
unsignedintRxByteCtr;
5
unsignedintRxWord;
6
7
8
voidmain(void)
9
{
10
WDTCTL=WDTPW+WDTHOLD;
11
P1DIR|=0x01;
12
P3SEL|=0x06;
13
UCB0CTL1|=UCSWRST;// für was den software reset
14
UCB0CTL0=UCMST+UCMODE_3+UCSYNC;// synchronous mode= SCL anpassung auf die richtige geschwindigkeit??
15
UCB0CTL1=UCSSEL_2+UCSWRST;//
16
UCB0BR0=12;// ~100kHz SCL geschwindigkeit 100 KHZ
17
UCB0BR1=0;
18
UCB0I2CSA=0x20;// ersetze ich durch meine Slave Adresse
19
UCB0CTL1&=~UCSWRST;
20
IE2|=UCB0RXIE;// interrupt für empfangene daten?
21
TA0CCTL0=CCIE;//was bedeutet dieser Kommentar "TACCR0 interrupt enabled"
__bis_SR_register(CPUOFF+GIE);// Enter LPM0, enable interrupts
46
// Remain in LPM0 until TACCR0
47
// interrupt occurs
48
TA0CCTL0&=~CCIE;// TACCR0 interrupt disabled
49
}
50
}
51
#pragma vector = TIMER0_A0_VECTOR
52
__interruptvoidTA0_ISR(void)
53
{
54
__bic_SR_register_on_exit(CPUOFF);// was ist "Exit LPM0"
55
}
56
57
// The USCIAB0TX_ISR is structured such that it can be used to receive any
58
// 2+ number of bytes by pre-loading RxByteCtr with the byte count.
59
#pragma vector = USCIAB0TX_VECTOR
60
__interruptvoidUSCIAB0TX_ISR(void)
61
62
/verstehediesenteilleidernicht
63
64
{
65
RxByteCtr--;// Decrement RX byte counter
66
67
if(RxByteCtr)
68
{
69
RxWord=(unsignedint)UCB0RXBUF<<8;// Get received byte
70
if(RxByteCtr==1)// Only one byte left?
71
UCB0CTL1|=UCTXSTP;// Generate I2C stop condition
72
}
73
else
74
{
75
RxWord|=UCB0RXBUF;// Get final received byte,
76
// Combine MSB and LSB
77
__bic_SR_register_on_exit(CPUOFF);// Exit LPM0
78
}
79
}
/was bedeutet diese letzte teil wird hier der wert in den puffer
geschrieben und gezählt wie viel bytes empfangen wurden??
[Edit: Bitte in Zukunft Code-Zitate in [ c ] und [ / c ] einschließen,
sonst wird das durch die Zeilenumbrüche eine unlesbare Zumutung.
-rufus]
Bobby schrieb:> // für was den software> reset
Man konfiguriert das USCI-Modul nur, während es sich im Reset befindet,
sonst kann es unerwünschte Ergebnisse geben.
Also: RESET -> KONFIGURIEREN/ÄNDERN -> RESET-BIT WEG
Bobby schrieb:> synchronous mode
Heisst, du arbeitest mit CLK und Daten, also synchron.
Bobby schrieb:> interrupt für empfangene> daten?
Du schaltest die Möglichkeit frei, dass das Kommunikationsmodul beim
fertig-empfangenen Zeichen einen Interrupt auslösen kann.
Bobby schrieb:> was bedeutet dieser> Kommentar "TACCR0 interrupt enabled"
Du hast die Interruptfreigabe für den Timer gesetzt. Mit dem Capture
Compare Interrupt Enable sagst, du, dass bei einem Überlauf, oder einem
Vergleich ein Interrupt kommen kann.
@Herold danke für deine antworten aber weisst du wo ich jetzt die
eigentlichen date4n schicke und wo sie versendet werden der erste teil
des programms wäre mir jetzt soweit mal klar danke
@jörg s brauche ich nun einen i2c treiber oder funktioniert das auch
ohne??
Normalerweise macht man das ohne externen I2C Treiber. Der kommt nur zum
Zug wenn Du über längere Distanzen oder mehrere Boards hinweg
kommunizieren willst.
Bobby schrieb:> brauche ich nun einen i2c treiber oder funktioniert das auch> ohne??
Was soll ein "i2c treiber" sein?
Man kann Bausteine, die das I2C-Protokoll nutzen, direkt mit dem I2C-Bus
verbinden, man muss nur bei der Wahl der Pullup-Widerstände am Bus und
der Betriebsspannung aller am Bus angeschlossenen Teilnehmer aufpassen.
Bei unterschiedlichen Betriebsspannungen kann es zu unterschiedlichen
Schaltschwellen für High- und Low-Pegel kommen, diese lassen sich mit
einem I2C-Repeater wie dem PCA9517 aber anpassen.
Der Widerstand muss so gewählt sein das der maximal erlaubte Strom nicht
überschritten wird.
I.d.R. sind bei I2C Widerstände im Bereich 2,7k..4,7k Ohm günstig. Wenn
du eine langsame Kommunikation hast (~100kHz) spielt das aber eh keine
große Rolle, da wird 10k Ohm auch noch gehen.
okay super hab 10kohm drin köntest du mir vllt noch meine fragen oben
beantworten verstehst du dieses programm?? wie das i2c bus Protokoll
selber funktioniert ist mir schon klar aber ich würde halt jetzt gerne
verstehen wie ich meine bytes versenden kann und wie ich empfangene
bytes speichern kann?
@herold kansst du mir vllt auch den rest kurz erläutern mich würde nur
kurz intressieren wo ich die bytes die ich schreiben möchte eintragen
muss und wo ich die bytes die ich empfange speichere bitte um hilfe
>weisst du wo ich jetzt die eigentlichen date4n schicke und wo sie>versendet werden
Gesendet wird da nur die Adresse, keine Daten. Empfangen werden 2 Byte.
An den Stellen wo es um UCB0RXBUF geht wird der Empfangsbuffer gelesen.
Aber ich muss ja meinem fm75 schreiben das ich aus dem Temperatur
register lesen möchte muss man das bei dem im beispiel verwendetten
tmp100 nicht?
ich möchte ja dem fm75 schreiben das ich aus seinem teperaturregister
lesen möchte oder in sein config register schreiben möchte wie mache ich
das??
Guten Morgen hab da mal noch ne Frage "__bis_SR_register(CPUOFF + GIE);"
was Bedeutet eigentlich dieser Teil hier. _bis_SR_register was bedeutet
den das? das ist ja kein word und kein Befehl oder?
und warum beantwortet mir nicht mal jemand die frage wie ich daten
versende weis das den niemand kann mir nicht jemand einen kleinen
übersichtliches code example reisntellen mit senden und empfangen von
daten i2c bus mit guten kommentaren langsam bin ich echt am verzweifeln
jemand muss doch schon so was gemacht haben
Bobby schrieb:> Sorry kenn mich echt noch nicht so gut aus was ist das?? bin halt noch> anfänger
Gerade deshalb wäre es schon wichtig, Du würdest Dich mit der
Dokumentation -sowohl dem User Guide des MSP, als auch der Dokumentation
der Entwicklungsumgebung- vertraut machen. Ausserdem wurde ja auch schon
auf die Code-Beispiele von TI aufmerksam gemacht.
So schlecht, wie oft behauptet, ist die Doku nämlich nicht!
ich habe den kompletten abschnitt über i2c im user guide gelesen und
darin wird nicht genau auf den ablauf eines programms eingegangen und
das programm das oben steht ist eines der code examples von ti wenn du
mal genau hinkuckst ich häng mich wirklich rein und versuch alles um das
hinzukriegen ich behaupte nicht das die doku schlecht ist ich denke nur
das wenn man noch nicht so viel ahnung hat probleme mit den vielen
fachbegriffen usw hat. Es wär toll wenn mal jemand konkret auf meine
fragen eingeht und nicht einfach nur schreibt kuck dir die und das an
das habe ich nun schon tausendmal gemacht nur ich finde immer wieder die
gleichen sachen die ich nicht verstehe und hätte einfach mal gerne das
mir jemand die fragen von oben so beantwortet das auch ein blutiger
anfänger sie versteht
[Edit:
Das mit dem Einklammern des Quelltextes hast Du ja fast schon
hinbekommen. Du musst nur die Leerzeichen zwischen den Klammern und
anderen Zeichen weglassen, dann sieht's so aus wie oben.
Ich habe das mit Leerzeichen geschrieben, weil Du sonst die Klammern
gar nicht zu Gesicht bekommen hättest.
Geheime Raketenwissenschaft ist das übrigens nicht, das steht oberhalb
des Texteingabefensters als erster Punkt unter "Formatierung".
-rufus]
ja das habe ich mir bereits angeschaut aber ich weis auch nicht entweder
ich bin einfach zum programmieren ungeeignet oder mir steht jemand auf
dem Schlauch ich versteh leider dieses Programm auch nicht wie ich es
auf mein Bedürfnisse umschreiben muss Jörg
Bobby schrieb:> Aber ich muss ja meinem fm75 schreiben das ich aus dem Temperatur> register lesen möchte muss man das bei dem im beispiel verwendetten> tmp100 nicht?
Wenn man beim TMP100 nie ein Register angibt, wird immer das
Temperaturregister gelesen.
> ich möchte ja dem fm75 schreiben das ich aus seinem teperaturregister> lesen möchte oder in sein config register schreiben möchte wie mache ich> das??
So wie ich das sehe verhält sich der FM75 identisch zum TMP100 was das
betrifft. Es ist also auch dort nicht zwingend notwendig das Config
Register zu schreiben. Das Temperaturregister kann man auch so sofort
lesen.
>#define FM75_CMD_INPUT 0x90 //Adresse FM75 mit Write Bit>#define FM75_CMD_OUTPUT 0x91 //Adresse FM75 mit read Bit
Das ist schon mal falsch. Das RW Bit wird vom MSP erzeugt. Die Adresse
wird ohne RW Bit von MSP erwartet.
> do (i--);> while (i != 0);
???
Ich würde wenn sagen:
while (i != 0)i--;
>UCB0I2CSA = 0x20; // Slave Adresse MSP 100000
Slave Adresse? In Das Register gehört die Adresse vom FM75
> UCB0CTL1 |= UCTXSTT; // Start Condition senden> UCB0CTL1 |= FM75_CMD_INPUT; // Schreibe auf FM75> UCB0CTL1 |= 0x0; // Befehl aus dem Temperaturregister Lesen> UCB0CTL1 |= UCTXSTT; // Repeat Start Condition> UCB0CTL1 |= FM75_CMD_OUTPUT; // Lese aus FM75
Absolut falsch!
Bobby schrieb:> ja das habe ich mir bereits angeschaut aber ich weis auch nicht entweder> ich bin einfach zum programmieren ungeeignet oder mir steht jemand auf> dem Schlauch ich versteh leider dieses Programm auch nicht wie ich es> auf mein Bedürfnisse umschreiben muss Jörg
Das schöne ist das du eigentlich nichts umprogrammieren musst, weil
alles schon fertig ist!
So ungefähr könnte es mit meinem Code aussehen:
okay das war ja sehr nieder schmetternd den fehler mit while (i !=
0)i--; habe ich behoben und bei der adresse des fm75 adresse ohne lese
oder schreib bit eintragen oder??
und wie mach ich das absolut falsche wieder richtig??
Hab jetzt mal an deinem Programm rumgeschrieben und versucht es zu
verstehen ich verstehe es ein bischen hab mal das umgeschribene
angehängt ich hoffe das stimmt so hab die funktionen return False und
True rausgeschmiesen da diese nicht im programm waren und ich weis nicht
wie sie geschrieben sind wo ist dann der wert den ich empfangen habe
kann ich den wie mit dem zuvor programmierten vergleicher wieder
vergleichen??
>ja und das wäre dan schon alles?? nur sieser absatz die header datei von>dir brauch ich dann ja auch oder??
Ein bisschen was musst du auch noch tun, ja...
>hab die funktionen return False und True rausgeschmiesen da diese nicht>im programm waren
Das sind defines:
#define TRUE 1
#define FALSE 0
>wo ist dann der wert den ich empfangen habe kann ich den wie mit dem>zuvor programmierten vergleicher wieder vergleichen??
Der steht in der "data[]" Variable.
>habe ich behoben und bei der adresse des fm75 adresse ohne lese>oder schreib bit eintragen oder??
Was bedeutet dieser Satz?
Könntest du allgemein vielleicht mal Punkte hinter Satzenden setzen?
Dann wird das alles leserlicher was du schreibst.
>und was machen diese defines??
Die Machen den Code verständlicher weil man nicht mehr 0 sondern einfach
FALSE schreiben kann.
>hast du dir mal mein programm oben angeschaut??
Ja. Der Compiler wird sich beschweren weil du den Funktionen die return
Werte geklaut hast. Ebenso wird es ihm nicht gefallen das die
Funktionsaufrufe ganz unten einfach so da steht. Du brauchst eine
Hauptscheleife wo du die Funktionen aufrufst.
und was passiert dann bei diesem return befehl wohin verweist der dann
und wenn ich oben FALSE und TRUE definiere müsste das dann ja
funktionieren und mein programm auch
Ja, das hast Du jetzt sehr schön zum Ausdruck gebracht.
Warum soll sich jemand Mühe machen, Dir zu helfen, wenn Du Dir noch
nicht mal Mühe machst, verständliche Fragen zu stellen?
So hab mich mal eingelesen und die antwort auch gleich gefunden return
gibt einen wert an das betriebssystem zurück um im zu zeigen ob eine
funktion richtig ausgeführt wurde. Stimmts? Und jetzt kann man wenn ein
Fehler auftritt über FALSE das versenden von Daten mit dem Stopbit
Stoppen,oder?
Und noch ne Kurze Frage du Hast das eigentliche Programm nicht in I2C.c
geschrieben oder??
Du rufst die Funktionen von I2C.c in einer andern c.Datei auf?
Könnte man diese Funktionen nicht in I2C.h schreiben und muss man dan in
dem Main.c Programm auch I2C.c include aufrufen.
Bobby schrieb:> So hab mich mal eingelesen und die antwort auch gleich gefunden return> gibt einen wert an das betriebssystem zurück um im zu zeigen ob eine> funktion richtig ausgeführt wurde. Stimmts?
Nein. return gibt einen Wert an den Aufrufer der mit return
beendeten Funktion zurück. Welche Bedeutung der Wert hat ist von der
Funktion abhängig und mitnichten prinzipiell ein Fehlercode.
Du solltest ganz dringend ein Grundlagenbuch über die Programmierung
in C lesen.
Standardempfehlung: Brian Kernighan & Dennis Ritchie, "Programmieren in
C", 2. Auflage, Hanser-Verlag.
Ja, ein Buch und kein Tutorial oder irgendwelche anderen Anleitungen aus
dem Internet.
> Und jetzt kann man wenn ein> Fehler auftritt über FALSE das versenden von Daten mit dem Stopbit> Stoppen,oder?
Das Stopbit der seriellen Schnittstelle wird von der Hardware
automatisch erzeugt und hat nichts damit zu tun, das Senden von Daten
anzuhalten.
So hab mich jetzt mal noch weiter eingelesen und das programm von jörg
noch ein wenig umgeschrieben und überarbeitet, aber das Programm läuft
immer noch nicht richtig.
Kann mal jemand nochmal über dieses Programm drüber Schauen und mir
erklären was ich ändern muss?
Bobby schrieb:> aber das Programm läuft immer noch nicht richtig.
Und was heisst das genau?
Anwortet der Sensor mit ACK auf die Adresse?
Klappt das schreiben des Registers?
Klappt das abholen der Daten?
Sind SCL und SDA nach der Übertragung wieder beide auf high?
Tut sich an den I2C Pins überhaupt was?
Wie kann ich Testen ob der Sensor mit Ack antwortet.
Also bei Data Steht immer ein wert der ist aber immer derselbe egal wie
ich die Temperatur verändere.
Ich habe mal mit dem Osziloskop versucht den I2C bus zu messen aber ich
messe keinen Clock und messe auch auf SDA nichts.
Der Clock müsste ja ständig da sein und denn müsste ich doch messen
können oder?
Bobby schrieb:> Wie kann ich Testen ob der Sensor mit Ack antwortet.
Schau nach ob i2c_write_byte() ein FALSE zurück gibt.
> Also bei Data Steht immer ein wert der ist aber immer derselbe egal wie> ich die Temperatur verändere.
Du liest ja auch nur ein einziges mal die Temperatur. Eine Veränderung
kannst du nur sehen wenn du die Temperatur öfters ausliest.
> Der Clock müsste ja ständig da sein und denn müsste ich doch messen> können oder?
Mit deinem Code nicht, nein. Wie bereits geschrieben liest du nur ein
einziges mal die Temperatur. Danach macht der MSP nichts mehr ausser
warten.
>Was soll ich mit dem Programm unten anfangen??
Ausprobieren
>und wie mache ich das das er immer wieder misst?
Das macht mein Programm.
Versuch einfach mal selbstständig herauszufinden wie das Programm
funktioniert. Sollte auch für Änfänger schaffbar sein. Muss man sich nur
etwas Zeit nehmen...
Hab dein main einfach mal durch mein main erstezt funktioniert aber
immer noch nicht hast übrigens ne klammer vergessen
[
}
}
// Warten
for (i = 0; i < 5000; i++);
}
]
Also der SCL ist ständig high und SDA ständig low es wird immer noch
städig der gleiche wert eingelesen! und die led leuchtet dauerhaft
obwohl ich in der Werkstatt bestimmt nicht mehr als 33 grad habe. ich
weiss nicht wie ich überprüfen soll ob die datensendung funktioniert da
ich auf dem Osziloskop keine veränderungen von SCL und SDA sehe. war das
Korekt das ich die 2 main schleifen ausgetauscht hab und wie ich die
klammer gesetzt habe könnte es noch ein problem mit dem programm geben
oder hab ich hardware probleme?
Du hast Verständnisprobleme. Hast Du denn sichergestellt, daß Dein
Programm die Abfrage des I2C-Busses mehrfach ausführt? Anscheinend
nicht, sonst könntest Du das mit dem Oszilloskop auch sehen.
@rufus doch das müsste sichergestellt sein jörg meinte ab jetzt wird
immer wieder neu gemessen mit seinem programm das er mir etwas weiter
oben eingestellt hat.
An was könnten diese verständigungsprobleme noch liegen?
>Also der SCL ist ständig high und SDA ständig low
Ganz schlecht.
>und die led leuchtet dauerhaft obwohl ich in der Werkstatt bestimmt nicht>mehr als 33 grad habe.
Die LED wird bei meinem Programm auch dafür benutzt anzuzeigen ob die
Abfrage des Sensors geklappt hat. Hast du dir den Code evt. doch nicht
noch mal angesehen?
>ich weiss nicht wie ich überprüfen soll ob die datensendung funktioniert
Die I2C Funktionen sind extra so programmiert das sie ein FALSE zurück
geben wenn was nicht geklappt hat.
Bobby schrieb:> Kann es an den Pull up widerständen liegen hab 10 KOHM bei 3,3 Volt> busspannung drin sind diese vllt zu gross?
Glaub ich nicht. Dein Bus sollte mit so 20kHz laufen. Das ist
Schnarchlangsam. Da sollte es mit 10k keine Probleme geben.
@ jörg hab mir das programm wohl nochmmal angeschaut
if (data[0] < 0xBD0) // >33C?
P1OUT &= ~0x01; // No, P1.0 = 0
else
P1OUT |= 0x01; // Yes, P1.0 = 1
Hier wird ja die led gesteuert und hier wird doch verglichen ob data[0]
gröser als BD0 ist und dann wird die led ein oder ausgeschaltet liege
ich da etwa Falsch??
hier noch das programm und der Schaltplan im Anhang
Spendier Dir 'ne zweite Leuchtdiode, mit der Du unterscheiden kannst, ob
die I2C-Routinen einen Fehler ausgeben oder ob Deine Temperatur stimmt.
Derzeit verwendest Du ein und dieselbe LED für beides, das ist bei der
Diagnose eher ... unpraktisch.
Im folgenden wird davon ausgegangen, daß sowohl an P1.0 als auch an P1.1
eine LED angeschlossen ist, die bei High-Pegel leuchtet.
1
P1OUT|=0x02;// Fehler-LED an
2
3
if(i2c_write_byte(0x48,0x00))
4
{
5
if(i2c_read_bytes(0x48,2,&data[0]))
6
{
7
if(data[0]<0xBD0)// >33C?
8
P1OUT&=~0x01;// Temperatur-LED aus
9
else
10
P1OUT|=0x01;// Temperatur-LED an
11
12
P1OUT&=0x02;// Fehler-LED aus
13
}
14
}
Vor dem Ansteuern des I2C-Busses wird die Fehler-LED eingeschaltet, sie
wird erst dann ausgeschaltet, wenn ohne Fehler vom I2C gelesen werden
kann.
Und das geschieht bei jedem Durchlauf, die LED sollte also bei korrektem
Betrieb nur sehr kurz aufblitzen.
Dein "Schaltplan" übrigens hat keinen Gebrauchswert. Einerseits ist es
ziemlich nutzlos, im Schaltplan das IC-Gehäuse abzupinseln,
üblicherweise verwendet man Symbole, die die logische Struktur des
Bauteils wiedergeben, andererseits ist es besonders nutzlos, nur
Pinnummern, aber keine Signalnamen an den IC-Anschlüssen anzugeben.
Daß außerdem Kreuzungen und Verbindungspunkte von Leitungen deutlich
unterscheidbar sein müssen, hast Du immerhin ein paarmal schon
hinbekommen.
Hinzu kommt, daß Dein Schaltplan unvollständig ist - wo z.B. ist die
LED?
Ja entschuldigung hab den gerade erst kurz in oaint gezeichnet damit er
schnell fertig wird hab ihn eigentlich nur auf papier und da ist er
korrekt gezeichnet keine sorge =) werd ich ausprobieren.
@rufus hab jetzt mal dein Programm ausprobiert also die daten werden
über den I2c bus gesendet und Empfangen das funktioniert jetzt (konnte
ich mit dem Osziloskop messen und das Programm lief beim senden und
empfangen korrekt durch).
Aber der vergleicher scheint nicht richtig zu funktionieren. Oder das
einlesen von daten den data ist immer 0x200 auch wenn ich die temperatur
verändere.
Wenn du kommunikation soweit funktioniert kann ich ja kein
Hardwareproblem mit dem FM75 haben das dieser möglicherweise defekt
ist??
kann mir jemand sagen ob dieser teil des programms korrekt ist?? hab ich
die richtige variable zum vergleichen "data[0]"?
if (i2c_read_bytes(0x48, 2, &data[0]))
{
if (data[0] < 0xBD0) // >33C?
>Oder das einlesen von daten den data ist immer 0x200 auch wenn ich die>temperatur verändere.
Wie denn "oder"? Sind die Daten immer 0x200 oder nicht?
Du weisst das du Breakpoints setzen kannst?
Du weisst das du dir im Debugger die Variablen ansehen kannst?
Entweder der vergleicher ist falsch programmiert oder das einlesen von
daten funktioniert nicht richtig.Data ist immer 0x200. ja ich weiss das
ich breakpoints setzen kann und habe auch im debugger gesehen das der
wert immer 0x200 ist. Woran könnte das liegen.
Wie soll ein Fehler beim vergleichen dazu führen das sich der Wert der
Variable nicht ändert?
Versuch doch mal andere Register zu lesen.
z.B. Tos:
if (i2c_write_byte(0x48, 0x03))
{
if (i2c_read_bytes(0x48, 2, &data[0]))
{
Sollte 0x5000 ergeben.
Oder bei Register 0x02 sollte 0x4B00 raus kommen.
Bobby schrieb:> und ich weiss nicht ob der wert im ASCII Code angezeigt wird eigentlich> ja nicht.
Wie du weisst es nicht? Was ist denn im Compiler für die Anzeige
eingestellt?
>Kann es sein das die Taktfrequenz des I2c Buses zu gering ist?
Nein, sowas gibt es nicht.
Ich weiss mnicht mehr weiter kann mir den niemand helfen woran könnte es
liegen. Der wert von data ist jetzt nur noch , ein einfaches , oder ein
. mann erkennt es nicht genau ich weiss nicht mehr was ich tun soll ist
mein fm75 defekt? habe dir richtigen pull ups drin den kondensator am
eingang des FM75 und die kommunikation ansich funktioniert ja ich weiß
wirklich nicht mehr weiter hab jetzt bald alles überprüft.
>Ich weiss mnicht mehr weiter kann mir den niemand helfen
Hab ich doch schon geschrieben: Register schreiben (Z.B. Over Limit) und
wieder auslesen.
Ansonsten würde ich empfehlen erst mal mit was einfachem weiter zu
machen (z.B. LED blinken lassen, Knight-Rider Licht o.ä. programmieren
um Erfahrung zu sammeln).
Oder zumindest erst mal einen PCF8574 oder PCA9554 zum üben.
Kennst du das schon?: http://www.mathar.com/msp430.html>Der wert von data ist jetzt nur noch , ein einfaches , oder ein>. mann erkennt es nicht genau
Dann schalt halt einfach wieder zurück auf Hex.
>ist mein fm75 defekt?
Glaub ich nicht.
>habe dir richtigen pull ups drin
Wenn du dir nicht sicher bist, mach einfach mal andere rein oder schau
dir die Signale am Oszi an.
Zeichne noch mal einen gescheiten Schaltplan und poste ihn hier.
Bobby schrieb:> Ich schreie nich
Das ist glatt gelogen.
Wenn Du die Watch-Funktion Deiner Entwicklungsumgebung verwendest, dann
musst Du Dir die Dokumentation Deiner Entwicklungsumgebung ansehen, um
herauszufinden, wie man das Format von Werten in der Watchfunktion
verändert.
Vermutlich wählt die Watchfunktion standardmäßig die Darstellung als
einzelne Zeichen, weil Deine Variable als "char" deklariert ist.
Probiere es doch mal mit uint8_t oder, da es sich ja um einen
16-Bit-Wert handelt, gleich mit einem uint16_t.
Rufus t. Firefly schrieb:> Wenn Du die Watch-Funktion Deiner Entwicklungsumgebung verwendest, dann> musst Du Dir die Dokumentation Deiner Entwicklungsumgebung ansehen, um> herauszufinden, wie man das Format von Werten in der Watchfunktion> verändert.>> Vermutlich wählt die Watchfunktion standardmäßig die Darstellung als> einzelne Zeichen, weil Deine Variable als "char" deklariert ist.
Code sieht nach IAR aus -> im Watch Window einfach Rechtsklick und
Format auswählen
> Probiere es doch mal mit uint8_t oder, da es sich ja um einen> 16-Bit-Wert handelt, gleich mit einem uint16_t.
Das wird den TE eher noch mehr verwirren, da es diese Datentypen im IAR
standardmäßig nicht gibt (zumindest nicht bei einem C-Projekt).
> Das wird den TE eher noch mehr verwirren, da es diese Datentypen im IAR> standardmäßig nicht gibt (zumindest nicht bei einem C-Projekt).
Da hast Du natürlich recht.
Bei den Verständnisproblemen, die Bobby anscheinend hat (ich würde so
weit gehen und hier eine recht ausgeprägte Lernresistenz
diagnostizieren), ist so etwas natürlich fatal.
Eigentlich wäre das mit
#include <stdint.h>
lösbar.
Und eigentlich sollte "Bobby" schon seit einigen Tagen die beiden vom
LM75 empfangenen Bytes (die er in seinem Array data ablegt) zu einem
16-Bit-Wert zusammenfassen und als 16-Bit-Wert betrachten.
Aber wenn ihn solche Banalitäten wie die Werteinterpretation im Debugger
so komplett durcheinanderbringen, und er Leute anschreit, die mit so
einer Engelsgeduld wie Jörg versuchen, ihm etwas beizubringen, dann ist
das vermutlich ein zu weit gestecktes Ziel.
Stefan schrieb:> Leider, leider nicht !!! ;-)
Was genau magst Du damit meinen? Daß das "Bobby" nicht hilft, oder daß
das bei IAR nicht funktionieren soll? Ersteres würde ich fast schon
blind unterschreiben (obwohl man ja die Hoffnung nicht aufgeben soll),
aber letzteres bestreite ich.
Rufus t. Firefly schrieb:> Was genau magst Du damit meinen? Daß das "Bobby" nicht hilft, oder daß> das bei IAR nicht funktionieren soll? Ersteres würde ich fast schon> blind unterschreiben (obwohl man ja die Hoffnung nicht aufgeben soll),> aber letzteres bestreite ich.
Ich meine zunächst mal letzteres. Mit CLIB Library Einstellung ergibt
sich ein Fehler (s. Anhang).
Dieser läßt sich entweder dadurch beheben, dass man in den Optionen
mindestens "normal DLIB" wählt...
... oder man "wie wild" diverse h-Files kopiert (nein, nur stdint.h
reicht auch hier nicht ;-)) Was dann allerding wieder Deinen ersten
Punkt aktuell werden lässt...
... wo soll ich unterschreiben...?
Wie wärs wenn der ganze Thread gelöscht wird. Weil langsam nervt es mich
das ihr mich dumm anmacht, und alles so interpretiert wie ihr wollt zum
bsp. das gross schreiben gleich schreien ist, das ich nicht lernfähig
bin usw. daher möchte nein ich verlange das dieser ganze Thread gelöscht
wird. Denn hier ging es mehr darum vom Moderator für dumm verkauft zu
werden, als von ihm geholfen zu bekommen. Der einzigste der mir wirklich
geholfen hat war Jörg danke nochmal Jörg.
Und übrigens ich Programmiere nicht mit IAR sondern mit TI CodeComposer
Studio 4.0.
>bsp. das gross schreiben gleich schreien ist
Ist es aber.
Ich weiss jetzt nicht um was bei dir jetzt genau geht. Wenn das ein
privat Projekt ist um was zu basteln und dich längere Zeit damit zu
beschäftigen, würde ich dir wie gesagt empfehlen erst mal mit einem
PCF8574 anzufangen. Das ist ein I2C I/O Baustein an den du z.B. LEDs
hängen kannst. D.h. wenn das schreiben der Register klappt, siehst du
sofort das Ergebnis an den LEDs. Für das Lernen im Umgang mit dem I2C
Bus wäre sowas besser als der Temp. Sensor.
Ja hab ich mir auch schon bestellt und werde ich auch tun aber ich
möchte einfach das dieser Thread gelöscht wird da ich in diesem Forum
nicht weiterhin schreiben möchte.
Bobby schrieb:> Ja hab ich mir auch schon bestellt und werde ich auch tun aber ich> möchte einfach das dieser Thread gelöscht wird da ich in diesem Forum> nicht weiterhin schreiben möchte.
Ob du hier weiter schreiben willst oder nicht, ist rein deine Sache.
Deshalb löschen wir aber noch lange keine Threads, denn die Welt
besteht ja schließlich nicht nur aus dir.
Stefan schrieb:> Das wird den TE eher noch mehr verwirren, da es diese Datentypen im IAR> standardmäßig nicht gibt (zumindest nicht bei einem C-Projekt).
Blödsinn. IAR unterstützt recht umfangreich C99, auch die stdint-Typen.
Pothead schrieb:> Stefan schrieb:>> Das wird den TE eher noch mehr verwirren, da es diese Datentypen im IAR>> standardmäßig nicht gibt (zumindest nicht bei einem C-Projekt).>> Blödsinn. IAR unterstützt recht umfangreich C99, auch die stdint-Typen.
Bevor Du hier mit großen Worten um Dich schmeisst, hättest Du besser mal
meine Beiträge zu diesem Sachverhalt genauer durchgelesen!
stdint wird in der CLIB eben nicht unterstützt, in der DLIB aber sehr
wohl!
Stefan schrieb:> stdint wird in der CLIB eben nicht unterstützt, in der DLIB aber sehr> wohl!
Ja, und?
Warum sollte man die DLIB denn nicht in einem C-Projekt benutzen
können? Sie heißt ja nun nicht gerade deshalb so, weil man sie nur
für die Programmiersprache D benutzen könne...
Ich verstehe ohnehin nicht, warum sich noch jemand die altertümliche
CLIB freiwillig antun wöllte (von Altprojekten natürlich mal
abgesehen).
Jörg Wunsch schrieb:> Warum sollte man die DLIB denn nicht in einem C-Projekt benutzen> können?
Wo genau habe ich geschrieben, dass man das nicht kann?
Wer will, der kann natürlich, bloß müssen tut man nicht!
> Ich verstehe ohnehin nicht, warum sich noch jemand die altertümliche> CLIB freiwillig antun wöllte (von Altprojekten natürlich mal> abgesehen).
Ich verstehe nicht, warum man für spezielle Bedürfnisse gleich Full DLIB
einbinden sollte, wenn man gewissen Overhead und C++ Schnickschnack gar
nicht braucht. Alles eine Frage der Anwendung!
Stefan schrieb:>> Warum sollte man die DLIB denn nicht in einem C-Projekt benutzen>> können?> Wo genau habe ich geschrieben, dass man das nicht kann?
Du hast im Beitrag "Re: Mit MSP430F2132 den Hardware I2c Bus aufbauen um Temperatursensor anzusteuern"
zumindest suggeriert, dass das in einem C-Projekt so wäre.
> Ich verstehe nicht, warum man für spezielle Bedürfnisse gleich Full DLIB> einbinden sollte, wenn man gewissen Overhead und C++ Schnickschnack gar> nicht braucht. Alles eine Frage der Anwendung!
Du hast, glaub' ich, nicht begriffen, wie eine Bibliothek funktioniert.
Die erzeugt erstmal gar keinen Overhead per se, und hat auch nichts
mit C++ zu tun -- höchstens insofern, dass man ein C++-Projekt halt
mit der (technisch völlig veralteten) CLIB gar nicht erst anfangen
kann.
Kann sein, dass die DLIB einen aufwändigeren startup-Code besitzt,
der dir etwas mehr "Grundrauschen" rein durch die Auswahl von DLIB
statt CLIB verursacht (ich habe gerade keine funktionierende IAR-
Installation mehr zur Hand, um das zu verifizieren), aber das dürfte
dann in der Gesamtgröße eines jeden realen Projekts keine Rolle mehr
spielen. Ansonsten werden aus jeder Bibliothek nur die Funktionen
genommen, die man auch tatsächlich benutzt, und rein durch das
Einbinden eines <stdint.h> gibt es einfach nur ein paar neue
Datentypen (die letztlich nur Aliase auf existierende Typen sind),
davon entsteht kein Byte mehr an Code.
Übrigens gibt es auch noch irgendwelche DLIB-Varianten jenseits
von "Full DLIB", bei denen meiner Erinnerung nach sparsamere
Implementierungen einzelner Funktionen zum Tragen kommen, wie
beispielsweise eine Nichtberücksichtigung von wide character types.
Trotzdem hat man damit noch die anderen Annehmlichkeiten der DLIB,
insbesondere die gute Kompatibilität zum C99-Standard.
Jörg Wunsch schrieb:> Übrigens gibt es auch noch irgendwelche DLIB-Varianten jenseits> von "Full DLIB", bei denen meiner Erinnerung nach sparsamere> Implementierungen einzelner Funktionen zum Tragen kommen,...
Damit gibst Du doch selbst zu, dass es zu Overhead kommen kann, den man
unter Umständen eben nicht braucht oder nicht haben will/darf!
> Trotzdem hat man damit noch die anderen Annehmlichkeiten der DLIB,> insbesondere die gute Kompatibilität zum C99-Standard.
Solange ich Compiler-spezifische Intrinsics und Extensions in meinem
Code einsetze (einsetzen muss), mache ich mir ehrlich gesagt um die
ANSI-/ISO- und was-weiß-ich-Kompatibilität keinen großen Kopf!
Aber das soll's jetzt gewesen sein, da meine ursprünglichen Postings
einen ganz anderen Hintergrund hatten...
Stefan schrieb:> Solange ich Compiler-spezifische Intrinsics und Extensions in meinem> Code einsetze (einsetzen muss), mache ich mir ehrlich gesagt um die> ANSI-/ISO- und was-weiß-ich-Kompatibilität keinen großen Kopf!
Das sehe ich halt anders. "So inkompatibel wie nötig" lautet da die
Devise, und die Compilerabhängigkeiten kann man dann erfolgreich
in einem einzigen Headerfile verstecken.
Dinge wie <stdint.h> sind dabei einfach mal eine große Hilfe, da sie
einem bestimmte Abstraktionen bereits abnehmen, die man sich sonst
extra schaffen müsste.
Stefan schrieb:> Bevor Du hier mit großen Worten um Dich schmeisst, hättest Du besser mal> meine Beiträge zu diesem Sachverhalt genauer durchgelesen!>> stdint wird in der CLIB eben nicht unterstützt, in der DLIB aber sehr> wohl!
Huijui, warum denn so agressiv?
Stefan schrieb:> Wo genau habe ich geschrieben, dass man das nicht kann?> Wer will, der kann natürlich, bloß müssen tut man nicht!
Man kann natürlich auch um den heißen Brei herumlamentieren und sich so
alle Ausreden offen halten, oder? Dann will ich mal zitieren:
Stefan schrieb:> Das wird den TE eher noch mehr verwirren, da es diese Datentypen im IAR> standardmäßig nicht gibt (zumindest nicht bei einem C-Projekt).
Das ist schlichtweg falsch. Legt man ein neues C-Projekt (nicht C++) an,
so ist standardmäßig die DLIB ausgewählt. Siehe Anhang.