Ich nutze die Onboard RS232-Schnittstelle meines MSP430FG4618 Board für
Debugausgaben Richtung PC.
Klappt soweit auch gut. Allerdings habe ich als erstes Zeichen oft
(nicht immer) Datenmüll:
yHallo oder ähnliches.
Die Initialisierung erfolgt so:
1
// Configure UCA0 for RS232
2
3
P2SEL|=0x30;// // P2.4 + P2.5 = USCI_A0 RXD/TXD
4
UCA0CTL1|=UCSSEL_2;// SMCLK
5
UCA0BR0=0x09;// 1MHz 115200
6
UCA0BR1=0x00;// 1MHz 115200
7
UCA0MCTL=0x02;// Modulation
8
UCA0TXBUF=0;
9
UCA0CTL1&=~UCSWRST;// Start UART
Geschrieben wird so:
1
voiduart_putstring(char*str){
2
while(*str!=0)uart_putchar(*str++);
3
}
4
5
voiduart_putchar(charc){
6
while(!(IFG2&UCA0TXIFG));
7
UCA0TXBUF=c;
8
}
Muß ich vorher vlt. den Puffer irgendwie noch löschen?
Bei den ATmegas konnte ich immer sowas machen:
while(!(UCSRA&(1<<UDRE)));// Wait until buffer is ready to be filled
6
UDR=c;// Fill buffer with content
7
return0;
8
}
und konnte dann immer transparent mittels printf auf die RS232
Schnittstelle schreiben. Das scheint aber bei dem MSP430 (Compiler)
nicht zu gehen?
Muß ich dort anders vorgehen? Wenn ja, wie?
Danke!
Das erste Zeichen kann daher kommen, dass die Pegeländerung beim
Einschalten der Spannungsversorgung als Zeichen interpretiert wird (UART
Txd ist im Leerlauf high). Das sollte also nicht passieren, wenn man nur
Reset auslöst, die Spannung aber eingeschaltet bleibt.
Beim mspgcc kann es sein, dass das genauso wie beim avr-gcc funktioniert
mit den Streams. Das hab ich noch nicht probiert. Was auf jeden Fall
geht, ist dass man printf einfach verwendet, dann gibt es eine Warnung,
dass man ein putc implementieren muss. Das macht man dann einfach. Das
habe ich so schon verwendet, nur den Quellcode gerade nicht hier.
Wie das mit anderen Compilern geht, weiß ich nicht. Ich hab (bis auf ein
kleines Projekt) immer den mspgcc verwendet, der ist dem avr-gcc sehr
ähnlich, deswegen ging das von Anfang an recht gut.
Grüße,
Peter
Peter Diener schrieb:> Das erste Zeichen kann daher kommen, dass die Pegeländerung beim> Einschalten der Spannungsversorgung als Zeichen interpretiert wird (UART> Txd ist im Leerlauf high). Das sollte also nicht passieren, wenn man nur> Reset auslöst, die Spannung aber eingeschaltet bleibt.>> Beim mspgcc kann es sein, dass das genauso wie beim avr-gcc funktioniert> mit den Streams. Das hab ich noch nicht probiert. Was auf jeden Fall> geht, ist dass man printf einfach verwendet, dann gibt es eine Warnung,> dass man ein putc implementieren muss. Das macht man dann einfach. Das> habe ich so schon verwendet, nur den Quellcode gerade nicht hier.>> Wie das mit anderen Compilern geht, weiß ich nicht. Ich hab (bis auf ein> kleines Projekt) immer den mspgcc verwendet, der ist dem avr-gcc sehr> ähnlich, deswegen ging das von Anfang an recht gut.>> Grüße,>> Peter
Hallo Peter,
bzgl. "Reset und Spannung": Heißt das ich kann es gar nicht verhindern,
dass da ein Zeichen Müll kommt, oder meinst Du mit "Reset" dieses Flag
an dem UART Bausteil des MSP430, dass ich ändern könnte?
Compiler: Also ich verwende das TI CCS. Kan ich da einfach den mspgcc
auch verwenden? Ich verstehe das so, dass sowohl im CCS als auch im IAR
native Compiler der Hersteller enthalten sind und die verhalten sich
wohl alle ein kleines bisschen anders?
Danke!
Markus
Kommt das Fehlzeichen denn wenn du die Schaltung einschaltest, oder erst
später wenn das erste mal was übertragen wird?
Wenn es bei Reset passiert solltest du das mit entsprechender Schaltung
und Software verhindern können.
Beim anlegen der Spannung hingegen lässt es sich nicht so leicht
verhindern. Kommt dann darauf an wie deine Schaltung aufgebaut ist.
Es kommt wenn ich das erste Mal was via uart_putstring() konkret
ausgebe. Das Evalboard des µC hat dann natürlich schon Strom. Zuvor
erfolgt dann ja noch die Initialisierung des UART Bausteins (siehe
oben). Ich hab auch schon mal explizit das TX Register vor dem
Aktivieren des UART gelöscht, aber das hat nichts verändert.
Es ist mir ja nur aufgefallen, weil ich das bei einem Atmel STK 500 z.B.
noch nie beobachtet habe.
Kann bei UART manchmal auch einfach daran liegen, dass beide Teilnehmer
noch nicht synchronisiert sind und erstmal korrekt ein Start-Bit erkannt
werden muss.
Ist bei Verbindung über Draht zwar nicht oft der Fall, aber nur mal als
Beispiel: Bei HART wird ja auch der UART zum Senden verwendet - hier
wird aber das digitale Signal analog auf eine Leitung aufmoduliert.
Auf jeden Fall kannst du hier ohne Synchrnonisation erstmal alles
vergessen - da kann man beispielsweise nicht direkt mit dem eigentlichen
Datenstrom loslegen, sondern sendet zuvor einige 0xFF - da dies nur aus
Einsen besteht, wird ein Start-Bit spätenstens nach dem zweiten Byte
definitiv erkannt und beide Teilnehmer sind synchronisiert...aber nur
als Beispiel halt.
>Zuvor erfolgt dann ja noch die Initialisierung des UART Bausteins
Wenn es genau bei der Initialisierung auftaucht, würde ich den P2SEL
Teil mal an das Ende der Initialisierung verschieben.
>Kann bei UART manchmal auch einfach daran liegen, dass beide Teilnehmer>noch nicht synchronisiert sind...
Kann ich irgendwie nicht glauben. Der UART ist ja vollkommen in Hardware
aufgebaut. Was soll sich da synchronisieren? Sobalt eine High-Low Flanke
kommt legt er los...
Jörg S. schrieb:>>Zuvor erfolgt dann ja noch die Initialisierung des UART Bausteins> Wenn es genau bei der Initialisierung auftaucht, würde ich den P2SEL> Teil mal an das Ende der Initialisierung verschieben.>
Verhalten hat sich leider nicht verändert
Öhm, nein, es geschieht beim allerersten Mal wenn ich etwas mittels
uart_putstring() ausgebe, also wirklich in den UART schreibe, wie es
aussieht. Ich habe aber, wie Du vorgeschlagen hast, das P2SEL mal nach
den ganzen UART-Initialisierungsanweisungen geschrieben, das hat aber
auch nichts geändert.
Ich weißt es nicht 100%, da ich es nicht selbst definiert habe, aber
wenn ich mir die Kommentare zu dem Codeschnippsel ansehe, dass ich zum
Initialisieren des i2c Busses aus den TI Examples genommen habe würde
ich sagen die normalen ca. 100 kHz (siehe UCB0BR0 = 0x0b Anweisung)
Hmm.. ich sehe gerade, dass ich mich bei dem letzten Post vertan habe...
der gehört da ja gar nicht rein ;-)
Habe nun noch das TX Flag gelöscht, ist aber unverändert so.
Und, ich habe mich leider gleich nochmal vertan, das "falsche" Zeichen
kommt nicht erst beim uart_putstring()-Aufruf sondern doch schon
tatsächlich bei der Initialisierung, sobald ich den UART loslaufen lasse
mit UCB0CTL1 &= ~UCSWRST.
Wie lange dauert es eigentlich, vom Einschalten bis zum Initialisieren
des UART? Kann es sein, dass der Oszillator da noch nicht stabil läuft?
Das ungewollte Zeichen kommt also auch, wenn man danach garnichts
sendet? Also nur durch das Initialisieren?
Peter Diener schrieb:> Warum schreibst du eine Null in den Sendepuffer, bevor der UART> eingeschaltet wird?>> UCA0TXBUF = 0;
Das hatte ich testweise rein, um den Buffer zu leeren. Wobei mir
inzwischen auch klar ist, dass "leeren!=0"
Peter Diener schrieb:> Wie lange dauert es eigentlich, vom Einschalten bis zum Initialisieren> des UART? Kann es sein, dass der Oszillator da noch nicht stabil läuft?>
Keien Ahnung, wie lange das dauert. Beim Programmanfang sind aber noch
Warteschleifen, bis der Quarz sich sauber eingeschwungen hat (TI Std.
Sample Code)
> Das ungewollte Zeichen kommt also auch, wenn man danach garnichts> sendet? Also nur durch das Initialisieren?
Ja, offenbar.
Kannst du die Wartezeit zwischen Einschalten und UART-Initialisierung
viel größer machen, so etwa 5 Sekunden und dann prüfen, wann das Zeichen
kommt?
Als nächstes wäre es interessant, ob es wirklich gesendet wird, oder nur
vom Umkonfigurieren des Ports kommt. Dazu würde ich testweise gleich
beim Einschalten, also noch vor der Wartezeit, den Txd Pin manuell auf
Ausgang und high konfigurieren, das ist der Leerlaufzustand vom UART. So
dürfte sich beim Einschalten des UART der Pegel nicht mehr ändern.
Wenn der Fehler dann direkt beim Start kommt und nicht erst bei der
UART-Initialisierung, ist es einfach durch den Pegelwechsel beim
Einschalten bedingt.
Wenn es dagegen immer noch erst bei der UART-Initialisierung kommt,
passiert da etwas seltsames.
Grüße,
Peter
OK, probiere ich aus. Gibt es denn beim MSP430 auch sowas wie
_delay_ms() wie bei den ATmegas? Habe das jetzt immer mit einer banalen
for-Schleife gelöst...
Hallo,
durch ein explizities Low-Setzen der beiden UART-Pins (TX hätte
vermutlich gereicht), ist das gewünschte Ziel erreicht und es erscheint
kein "Müll" mehr beim Konfigurieren des UARTs:
Also wie folgt:
1
P2OUT&=~((1<<4)|(1<<5));// Clear P2.4 and P2.5
2
3
UCA0CTL1|=UCSSEL_2;// SMCLK
4
UCA0BR0=0x09;// 1MHz 115200
5
UCA0BR1=0x00;// 1MHz 115200
6
UCA0MCTL=0x02;// Modulation
7
UCA0CTL1&=~UCSWRST;// Start UART
8
P2SEL|=0x30;
9
10
uart_putstring("Let's go...");
Das P2OUT ist ausschlaggebend. Wartezeiten sind nicht notwendig.
Vielen Dank and Peter und Jörg für Ihre Hilfe bei der Klärung dieses
Problems.
Nein, das war es doch noch nicht 100%...
Zwar erreiche ich damit, dass es auch mal vorkommt, dass kein
Sonderzeichen als erstes Zeichen erscheint, ABER das scheint vom Zufall
abzuhängen.
Ich habe gerade alle Varianten durchpermutiert: Nur RX, nur TX, beide
Pins, TXBUF auf 0 gesetzt, Flag gelöscht oder nicht und tatsächlich
kommt bei der Version oben ziemlich häufig kein Zeichen beim
Konfigurieren des Pins, aber manchmal eben doch.
Es scheint auch nicht von der Wartezeit abhängig zu sein, da ich auch
unterschiedlich lange gewartet habe, bevor ich die entsprechenden
Aktionen ausgeführt habe (via Singlestep im Debugger allerdings!). Das
es also am Quarz oder so liegt, glaube ich jedenfalls nicht, der müsste
ja auch einschwingen, wenn die CPU gestoppt ist, oder?
Add: Auch "echte" Warteschleifen vor dem Ausführen der Kommandos ändern
daran nichts...
Add2: Und auch Stromversorgung über JTAG-FET oder Batterie führt zum
gleichen Ergebnis...
Lassen wir's gut sein, oder?
Hi
Im Datenblatt deines MSPs steht:
The required USART initialization/reconfiguration process is:
1) Set SWRST (BIS.B #SWRST,&UxCTL)
....
Irgendwie vermisse ich diesen Schritt bei dir.
MfG Spess
Na ja, der Code ist 1:1 aus dem TI Beispiel
msp430xG46x_uscia0_uart_115k.c
übernommen...
Hab's aber gerne ausprobiert, gleiches Ergebnis...
Aktueller Code:
bzgl. des erneuten Zuweisens von UCSWRST im 3. Befehl, habe ich gelesen
(Buch: "MSP430 Microcontroller Basics"), dass das so notwendig ist, weil
der UART ansonsten wohl auch losläuft, wenn man nur UCSSEL_2 setzt.
Man sollte den Tx-Pin ja auch HIGH setzen und nicht low. Das wäre der
richtige Leerlaufpegel vom UART. Außerdem auf Ausgang schalten.
Aber nur für Txd, wenn das P2.4 ist, dann
P2OUT |= (1<<4);
P2DIR |= (1<<4);
Grüße,
Peter
Peter Diener schrieb:> Man sollte den Tx-Pin ja auch HIGH setzen und nicht low. Das wäre der> richtige Leerlaufpegel vom UART. Außerdem auf Ausgang schalten.>> Aber nur für Txd, wenn das P2.4 ist, dann>> P2OUT |= (1<<4);> P2DIR |= (1<<4);>> Grüße,>> Peter
Verhalten hat sich nicht verändert...
Hallo Marcus ,
schon mal mit einer sehr niedrigen Baudrate probiert ?
sendest du daten an das "HyperTerminal "? zum daten anschauen
dann das "hyper Terminal" erst öffnen wenn der Controller bereit ist .
so ein Problem hat ich auch mal (Msp430F149) und Assembler .
aber wie ich das gelöst hatte ???
mfg Erik
Hallo Erik,
hmm.. nein, ich möchte ja vielmehr eine möglichst hohe Baudrate, da die
Debugmeldungen ja ggf. sehr schnell kommen.
Ich benutze nicht Hyperterminal sondern Putty im COM mode, da es mir
alles bietet, was ich brauche.
Es ist ja auch keine Riesensache, es wundert mich nur, dass "es"
passiert, und ich hätte gerne gewußt warum, bzw. ich wollte mir sicher
sein, dass ich nicht irgendwas falsch gemacht habe.
Was ich halt seltsam finde, ist dass wir hier ja wirklich kleine
Wundermaschinen vor uns haben, die man haarklein konfigurieren kann,
aber es scheint nicht möglich zu sein, eine ganz saubere Ausgabe zu
bekommen?
Allerdings: an einem Atmel STK 500 hatte ich sowas noch nie, und das
setzen wir auch ziemlich intensiv bei uns ein. MSP430 ist für mich noch
Neuland.
Grüße,
Markus
Markus D. schrieb:> aber es scheint nicht möglich zu sein, eine ganz saubere Ausgabe zu> bekommen?
Doch, das ist möglich.
Hast du ein Speicheroszi zur Hand? Dann schau dir mal den TX-Pin in den
verschiedenen Zuständen an.
Ja, ich habe ein Oszi da. Was genau meinst Du mit "in den verschiedenen
Zuständen" bzw. was soll ich da sehen? Ich werde vermutlich den Pegel
von 0 auf 3 Volt wechseln sehen oder erwartest Du etwas anderes?
>P2DIR |= ((1<<4)|(1<<5));
Du solltest P2.5 nicht auf Ausgang setzten, das gibt einen Kurzschluss
zwischen dem Prozessor und dem Pegelwandler.
Jörg S. meint vermutlich, dass du am Oszi genau anschaust, welche
Zeichen gesendet werden und wie der Unsinn zustande kommt, bzw. was in
dieser Zeit genau passiert.
Grüße,
Peter
Hallo,
in diesem Zusammenhang mal noch eine Frage, die ich schon in einem
anderen Thread auch gestellt hatte, aber noch keine Antwort bekommen
habe.
Kurzfassung: Wo bekomme ich GND für das Oszi-Probe her?
Ich nutze das MSP430FG4618/2013 Evaluation Board. Dort sind (fast alle)
Pins der MCs auf Pins herausgeführt. Es sind JTAG Buchsen dran und auch
ein paar Jumper wo man zwischen JTAG-Powered, Batterie und External
umschalten kann. ("External" wären dann zwei Zuleitungen die man auch
direkt auf zwei Steckleisten führen müsste, das nutze ich aber nicht,
schon allein weil ich kein passendes Netzteil habe).
Es gibt keine ausgewiesenen Pins wo man VCC oder GND abgreifen kann, wie
es bei anderen Evalboards häufig der Fall ist, um Add-on Komponenten zu
versorgen.
Ich speise das Board über den JTAG-FET via USB.
Wo würde ich denn in dieser Konstellation die GND Klemme des Probes
befestigen?
Wäre das möglich einfach einen Pin explizit auf low zu schalten und das
dann als GND zu verwenden? Oder ist das technisch gesehen nochmal was
anderes als GND? Und/Oder ist das für diese Tests egal?
Danke!
Wie scheon gesagt wurde gibt es zu den Boards ja eigentlich immer die
Schaltpläne. Ansonsten ist auf dem JTAG Stecker garantiert irgendwo
Masse. Am RS232 Stecker gibt es auch Masse. Sieht man ja i.d.R. auch an
Verbindungen zur GND-Plane.
Hmm. ja, gut, aber am JTAG Stecker steckt ja eben auch dieser.
Euren Antworten entnehme ich aber, dass es eben nicht geht, einfach
einen Pin auf Low zu schalten?
>Hmm. ja, gut, aber am JTAG Stecker steckt ja eben auch dieser.
Kein Lötkolben und ein Stück Draht da?
>Euren Antworten entnehme ich aber, dass es eben nicht geht, einfach>einen Pin auf Low zu schalten?
Geht schon, nur keine schöne Lösung. Masse direkt ist besser.
Na ja, eigentlich möchte ich es vermeiden, bei so einem (für mich)
teuren Board irgendwas rumzulöten...
Das Ganze stellt sich aber auch nicht nur wegen der Masse problematisch
dar: Der RX/TX Ausgang wird vom Chip aus direkt auf den RS232 Stecker
geführt (ggf. noch durch einen MAX232 o.ä.). Ich habe hier aber also
auch keinen Angreifpunkt für die eigentliche Mess-Spitze, denn an der
RS232 Buchse steckt ja auch wieder das RS232 Kabel...
Vielleicht noch mal zum Sinn des Ganzen: Erwartet ihr, dass vor der
Initialisierung der Wert am Pin nicht sauber 0 oder 3.3V ist, sondern
irgendwas dazwischen oder erwartet ihr irgendwelche Spitzen beim Wechsel
zu sehen oder was genau versprecht Ihr Euch in diesem Fall davon, das am
Oszi mitzulesen?
>Erwartet ihr, dass vor der Initialisierung der Wert am Pin nicht sauber 0>oder 3.3V ist, sondern irgendwas dazwischen oder erwartet ihr>irgendwelche Spitzen beim Wechsel zu sehen
Genau das ist die Frage. Wann liegt was am Pin an...
>Na ja, eigentlich möchte ich es vermeiden, bei so einem (für mich)>teuren Board irgendwas rumzulöten...
Was soll passieren? Du willst doch nur ein einzelnes Kabel an eine
einzelne dicke fette Lötstelle anlöten. Das bekommst du (wenn du keine 2
linke Hände hast) absolut sauber ran und wieder ab.
>ggf. noch durch einen MAX232 o.ä.). Ich habe hier aber also auch keinen>Angreifpunkt für die eigentliche Mess-Spitze,
Doch, am RS232/MAX232 Baustein und am RS232 Stecker (Lötpunkte vom
Stecker). Vielleicht gibt es auch Durchkontaktierungen wo das Signal
rüber läuft, da kommt man mit der Messpitze dann auch an das Signal
dran.
Löten und messen ist das A&O bei der Entwicklung :)
Laut Schaltplan auf der letzten Seite des
MSP430FG4618/F2013 Experimenter’s Board Users Guide
http://focus.ti.com/lit/ug/slau213a/slau213a.pdf
ist die RS232 Schnittstelle über Optokoppler vom Rest des Boards
elektrisch isoliert. GND vom Board und Signal von Schnittstelle oder
umgekehrt funktioniert also nicht.
GND kann man z.B. an Pin 9 des MSP430F2013 Programmieranschlusses JTAG2
abgreifen und das serielle Ausgangssignal UCA0TXD an Pin 5 von Anschluss
H4.
Also: Ich habe die von Stefan vorgeschlagenen Pins benutzt und mein
Programm im Debugger Schritt für Schritt ablaufen lassen. Allerdings war
auch ohne Singlestep das Signalverhalten klar erkennbar:
Sobald das Programm bei der ersten Anweisung initial "breaked", geht der
Pegel auf saubere 0V zurück. In dem Moment wo die Anweisung "P2DIR |=
(1<<4);" ausführt springt das Signal von 0 auf 3V und bleibt dort
stabil, bis die ersten Ausgaben über uart_putstring() erscheinen. Dort
wechselt das Signal dann entsprechend der Codierung mehrmals von Low auf
High. Das "Müllzeichen" erscheint allerdings bereits in dem Moment, wo
der Pegel auf High springt, also bei der P2DIR-Anweisung.
Ich habe mit 100µs/div und 9k Samples mit meinem Picoscope 2204
gesampled und auf 1V, steigende Flanke getriggert. Der Flankenanstieg
ist praktisch vertikal.
Sieht für mich als Laie also alles prima aus.
Andere Frage: Könnte es denn vielleicht auch an der seriellen
Schnittstelle am PC liegen?? Ich habe mir dort extra eine 2xSeriell
PCI-Schnittstellenkarte vom Pollin eingebaut, da ich mit dem USB2Seriell
Adapter (auch Pollin) oft BSODs bekam...
>Andere Frage: Könnte es denn vielleicht auch an der seriellen>Schnittstelle am PC liegen?? Ich habe mir dort extra eine 2xSeriell>PCI-Schnittstellenkarte vom Pollin eingebaut, da ich mit dem USB2Seriell>Adapter (auch Pollin) oft BSODs bekam...
Daran wird es dann wohl liegen, denn die Tatsache, dass die Schaltung in
irgendeinem Moment am Txd von den 0 V (die man logischerweise hat, wenn
es ausgeschaltet ist) auf die 3,3 V (die der Leerlaufpegel vom uart
sind) wechselt, lässt sich nicht vermeiden.
Es sollte dann die Aufgabe vom Übertragungsprotokoll sein, auf so eine
Störung nicht zu reagieren.
Grüße,
Peter
>Daran wird es dann wohl liegen, denn die Tatsache, dass die Schaltung in>irgendeinem Moment am Txd von den 0 V (die man logischerweise hat, wenn>es ausgeschaltet ist) auf die 3,3 V (die der Leerlaufpegel vom uart>sind) wechselt, lässt sich nicht vermeiden.
Ich würde einfach einen Pull-Up dran bauen, dann hat man es vermieden :)
Peter Diener schrieb:>>Andere Frage: Könnte es denn vielleicht auch an der seriellen>>Schnittstelle am PC liegen?? Ich habe mir dort extra eine 2xSeriell>>PCI-Schnittstellenkarte vom Pollin eingebaut, da ich mit dem USB2Seriell>>Adapter (auch Pollin) oft BSODs bekam...>> Daran wird es dann wohl liegen, denn die Tatsache, dass die Schaltung in> irgendeinem Moment am Txd von den 0 V (die man logischerweise hat, wenn> es ausgeschaltet ist) auf die 3,3 V (die der Leerlaufpegel vom uart> sind) wechselt, lässt sich nicht vermeiden.>> Es sollte dann die Aufgabe vom Übertragungsprotokoll sein, auf so eine> Störung nicht zu reagieren.>> Grüße,>> Peter
Aber das muss sich doch irgendwie eingrenzen lassen? "Muss an der
seriellen Schnittstelle liegen" ist doch etwas zu pauschal?
Liegt es denn dann vielleicht an den konkreten Verbindungsparametern
8N1, keine Flußkontrolle? Würde man durch Aktivierung der Flußkontroller
sowas verhindern können?
Jörg S. schrieb:>>Daran wird es dann wohl liegen, denn die Tatsache, dass die Schaltung in>>irgendeinem Moment am Txd von den 0 V (die man logischerweise hat, wenn>>es ausgeschaltet ist) auf die 3,3 V (die der Leerlaufpegel vom uart>>sind) wechselt, lässt sich nicht vermeiden.> Ich würde einfach einen Pull-Up dran bauen, dann hat man es vermieden :)
Ist das eine ernstgemeinte Antwort gewesen? Vermutlich nicht, oder?
Meiner Meinung nach stellt ein einfacher Pegelwechsel von low nach high
keinen gültigen UART-Frame dar. Die Karte müsste einen Frame-Error
ausgeben, aber nicht irgendein Zeichen, das nicht gesendet worden ist.
Das ist offenbar einfach schlecht implementiert und alle Karten von mir
haben dieses Verhalten auch nicht, demnach gehe ich davon aus, dass man
das durchaus konstruktiv in der Schnittstellenkarte verhindern kann.
Trotzdem ist es ein Fehler der Karte und liegt nicht an den
Einstellungen.
Möglicherweise erkennt die Karte einen Frame-Fehler richtig, wenn die
Paritätsprüfung eingeschaltet wird. Sicher ist das aber nicht, denn den
Fehler müsste sie auch ohne diese Prüfung erkennen.
@Jörg S.
Was soll denn ein Pullup gegen eine ausgeschaltete Versorgung nützen?
Der Pegel ist in diesem Fall trotzdem low und beim Einschalten gibt es
trotzdem den Übergang von low nach high.
Grüße,
Peter
hallo Markus,
hast du schon mal die zeile
P2OUT |= ((1<<4)|(1<<5));
P2DIR |= ((1<<4)|(1<<5));
hinten drangestellt bei der initialisierung ?
bzw P2Out ganz weggelassen ? ist brauch mann die Zeile überhaupt ?
ich kann leider kein C
bei einen alten Projekt von mir (Msp430F149)sieht in Assembler so aus
;SetupUART0
mov.b #CHAR,&UCTL0 ; 8-bit characters
mov.b #SSEL0,&UTCTL0 ; UCLK = ACLK
mov.b #00Dh,&UBR00 ; 32k/2400 - 13.65
mov.b #000h,&UBR10 ; 32k 2400
mov.b #06Bh,&UMCTL0 ; 32k 2400 modulation
bis.b #UTXE0+URXE0,&ME1 ; Enable USART0 TXD/RXD
bis.b #URXIE0,&IE1 ; Enable USART0 RX
interrupt
;SetupP3
bis.b #030h,&P3SEL ; P3.4,5 = USART0 TXD/RXD
bis.b #010h,&P3DIR ; P3.4 = output direction
Ich hoffe das hilft weiter
mfg Erik
Erik schrieb:> hallo Markus,>> hast du schon mal die zeile> P2OUT |= ((1<<4)|(1<<5));> P2DIR |= ((1<<4)|(1<<5));> hinten drangestellt bei der initialisierung ?> bzw P2Out ganz weggelassen ? ist brauch mann die Zeile überhaupt ?>>
Hallo Erik,
ja, ich glaube ich hatte inzwischen schon alle Varianten durch ;-)
(siehe Anfang des Threads). Habe inzwischen auch nur den 4er alleine
versucht.
Wenn das Problem tatsächlich an der Empfängerseite liegt, wird man auf
MSP Seite ja nichts ändern können. Zumal würde ja auch bei einer völlig
korrekten Initialisierung irgendwann dieser Pegelwechsel von 0 auf VCC
beim UART passieren, und dann würde ja wieder das Müllzeichen
ausgegeben...
Ich probier's aber einfach mal weiter, bzw. schaue auch mal ob man vlt.
auf Empfängerseite irgendwas konfigurieren kann.
Peter Diener schrieb:> @Jörg S.> Was soll denn ein Pullup gegen eine ausgeschaltete Versorgung nützen?> Der Pegel ist in diesem Fall trotzdem low und beim Einschalten gibt es> trotzdem den Übergang von low nach high.
Gegen den Pegelwechsel beim Einschalten hilft ein Pullup natürlich
nichts, wenn die Versorgungsspannung dauerhaft anliegt und nur ein Reset
ausgeführt wird aber schon. Wenn das Programm wiederholt per Debugger
gestartet wird sollte mit Pullup nur beim ersetn Programmstart ein
störendes Zeichen auftreten können.
Thread beobachten
Seitenaufteilung abschalten