Hallo zusammen,
ich lese ein UART Register wie folgt aus :
unsigned char Data = 0;
Data = RDR0;
TDR0 = Data; //zum testen was er zurück gibt
if (Data == 0x41)
{
i=1
}
.
.
.
.
Habe nun folgendes Probelm :
Sende ich in ASCII jetzt ein A was in Hex der 41 entspricht bekomme ich
dieses Signal über mein TDR0 auch zurück geliefert. Sprich die
Kummunikation funktioniert soweit.
Das eigentliceh Problem ist jetzt das er nicht in die IF-Schleife
springt.
Habe ich da einen Fehler in meinem Code ?
Gruß Fuchs
Vermutlich ja, aber vermutlich in dem Teil den du nicht gepostet hast ;) Bitte auch kopieren und nicht abtippen (wie hier, da fehlt nämlich ein Semikolon), sonst findet man Tippfehler nicht.
M. F. schrieb: > Sende ich in ASCII jetzt ein A was in Hex der 41 entspricht bekomme ich > dieses Signal über mein TDR0 auch zurück geliefert. ist das nicht nur eine Interpretation von deinem Empfänger am TDR0 das 'A' == 0x41 ist? Die Abfrage sollte doch besser if (Data == 'A') sein
Joachim B. schrieb: > ist das nicht nur eine Interpretation von deinem Empfänger am TDR0 das > 'A' == 0x41 ist? Die American Standard Code for Information Interchange hat sich darüber schon Gedanken gemacht und es standadisiert. Und ich kenne keinen Controller, der sich nicht an ASCII hält. Dementsprechend sollte das 'A' immer und überall 0x41 sein. Zum Fehler: Ist sichergestellt, dass zur Zeit der Abfrage im RDR0 überhaupt etwas drin steht? Ohne Kontext-Programm ist der Fehler so nicht zu finden.
Sebastian R. schrieb: > Die American Standard Code for Information Interchange hat sich darüber > schon Gedanken gemacht und es standadisiert. normalerweise ja, beim TO offensichtlich nicht und verlassen wir ASCII sollte man char NICHT mit Zahlen vergleichen, aber auch unabhängig von ASCII. char ist char und Zahl ist Zahl! Du kannst dem TO gerne andere Lösungen vorschlagen.
Joachim B. schrieb: > Sebastian R. schrieb: >> Die American Standard Code for Information Interchange hat sich darüber >> schon Gedanken gemacht und es standadisiert. > > normalerweise ja, beim TO offensichtlich nicht und verlassen wir ASCII > sollte man char NICHT mit Zahlen vergleichen, aber auch unabhängig von > ASCII. > char ist char und Zahl ist Zahl! Ne, ist Quatsch. Das ist reine Konvention und einen char mit 0x41 zu vergleichen ist völlig korrekt, wenngleich 'A' etwas klarer lesbar wäre. Es gibt auch kein mir bekanntes Encoding, bei dem 'A' nicht genau dasselbe Literal wäre wie 0x41.
__interrupt void IRQ_UART_0_Rx( void )
{
unsigned char i_ucData = 0;
unsigned char i_ucStatus = 0;
unsigned char ucWW;
unsigned char ucXX;
unsigned char ucI;
i_ucStatus = (SSR0 & 0xE0);
i_ucData = RDR0;
TDR0 = i_ucData;
if (i_ucData == 0x41)
{
MOTOR.uc_Aktiv = kk_Motor_Nr_B_1;
ucWW = 0;
ucWW = TASTE_S2_GetVal();
STATUS_LED.ucFL_S2 = 1;
i_ucData=0;
LED_S2_ClrVal();
}
}
Der Ausschnitt sollte reichen oder ?
M. F. schrieb: > Das eigentliceh Problem ist jetzt das er nicht in die IF-Schleife > springt. Wie stellst du das fest? > Habe ich da einen Fehler in meinem Code ? Kannst du da nicht einfach mal mit dem Debugger ansehen, was tatsächlich im i_ucData steht? > IF-Schleife http://www.if-schleife.de/ M. F. schrieb: ucWW = 0; i_ucData=0; Was soll das bewirken?
M. F. schrieb: > Das eigentliceh Problem ist jetzt das er nicht in die IF-Schleife > springt. das liegt ganz einfach daran, dass es sowas wie eine IF-Schleife nicht gibt.
Joachim B. schrieb: > char ist char und Zahl ist Zahl! Und in C ist "unsigned char" (char) gleich "uint8_t" (Zahl). Davon abgesehen: Was ist eigentlich eine if-Schleife? Eine Schleife sehe ich da nämlich nicht. Meine Testvariante für "UART-Kommunikation funktioniert" ist übrigens ein Echo, bei dem ich +1 auf den Wert addiere oder so, d.h. wenn ich 'A' tippe kommt 'B' zurück und so weiter. Damit schließe ich aus, dass mein Sender versehentlich seinen eigenen Wert zurückliest. Sei es durch "local echo" oder eine Kreuzung von Tx und Rx. Bringt ja nichts, wenn ich nur glaube, dass die Kommunikation funktioniert.
M. F. schrieb: (...) > if (i_ucData == 0x41) > { > MOTOR.uc_Aktiv = kk_Motor_Nr_B_1; > ucWW = 0; > ucWW = TASTE_S2_GetVal(); > STATUS_LED.ucFL_S2 = 1; > i_ucData=0; > LED_S2_ClrVal(); > > } (...) Sind die globalen Variablen, die Du in der ISR manipulierst, als volatile deklariert? Grüßle Volker
Volker B. schrieb: > M. F. schrieb: > (...) >> if (i_ucData == 0x41) >> { >> MOTOR.uc_Aktiv = kk_Motor_Nr_B_1; >> ucWW = 0; >> ucWW = TASTE_S2_GetVal(); >> STATUS_LED.ucFL_S2 = 1; >> i_ucData=0; >> LED_S2_ClrVal(); >> >> } > (...) > > Sind die globalen Variablen, die Du in der ISR manipulierst, als > volatile deklariert? > > Grüßle > Volker Lasse ich die IF-Anweiseng weg, wird der Code abgearbeitet. Da liegt definitiv nicht der Fehler. Gruß
S. R. schrieb: > Meine Testvariante für "UART-Kommunikation funktioniert" ist übrigens > ein Echo, bei dem ich +1 auf den Wert addiere oder so, d.h. wenn ich 'A' > tippe kommt 'B' zurück und so weiter. > > Damit schließe ich aus, dass mein Sender versehentlich seinen eigenen > Wert zurückliest. Sei es durch "local echo" oder eine Kreuzung von Tx > und Rx. Bringt ja nichts, wenn ich nur glaube, dass die Kommunikation > funktioniert. Danke dafür, habe gerade mal +1 auf mein TX addier und bekomme direkt nur noch Murks zurück. Habe anscheind doch noch ein Problem mit dem richtigen lesen des Registers.
M. F. schrieb: > Danke dafür, habe gerade mal +1 auf mein TX addier und bekomme direkt > nur noch Murks zurück. Das sieht nach Baudratenfehler aus.
M. F. schrieb: > Habe anscheind doch noch ein Problem mit dem richtigen lesen des > Registers. Sende doch mal ein paar definierte Buchstaben (also nicht das, was du bekommst) über die serielle Schnitte und schau, was beim Terminal ankommt. Besonders aussagekräftig und hilfreich sind da die binären Werte 0x01, 0x02, 0x04... 0x80 und 0x55 sowie 0xAA. Denn wenn du nur das sendest, was du bekommst, dann können das u.U. sogar 2 Zeichen hintereinander sein. Peter D. schrieb: > Das sieht nach Baudratenfehler aus. Und/oder ein Parametrierungsfehler 7/8/9 Bits. Aber ein Oszilloskop bringt da erste Gewissheit. Und ohne Oszilloskop möchte ich keine serielle Schnittstelle (SIO, SPI, I2C, ...) debuggen.
Peter D. schrieb: > M. F. schrieb: >> Danke dafür, habe gerade mal +1 auf mein TX addier und bekomme direkt >> nur noch Murks zurück. > > Das sieht nach Baudratenfehler aus. Hatte einen Tippfehler in der Baudrate... Jetzt funktioniert es. Danke für die ganzen schnellen Antworten. Gruß
Sven B. schrieb: > einen char mit 0x41 zu > vergleichen ist völlig korrekt, wenngleich 'A' etwas klarer lesbar wäre. danke Das Problem habe ich immer in der Arduino IDE Im Quelltext steht ° für °C aber die IDE macht 2 char daraus anderer Zeichensatz, auch wenn ich Compiler Ergebnisse als Kommentar einfüge "für Variablen stehen 666 Bytes zur Verfügung" kommt nach dme 'f' für "für" nur noch Datenmüll, z.B. für das '°' // im LCD Font ist ~ das ÃÃâ€à ‚ ÃƒÂ¢Ã¢â€šÂ¬Ã¢â€žÂ¢ÃƒÆ’ĮšÃ‚¢ÃƒÂ¢Ã¢â‚¬Å¡Ã‚ ¬Ã…¡ÃƆ™Ãƒâ€ Ã¢â‚¬â„¢ÃƒÆ’¢â ¡Ãƒâ€šÃ‚¬Ãƒâ€¦Ã‚¡ÃƒÆ’ââ‚à ‚¬Ã…¡Ãƒâ€šÃ‚°C" bei "für" sieht das so aus 438 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes. Auch andere Editoren machen manchmal "merkwürdiges"
M. F. schrieb: > Hatte einen Tippfehler in der Baudrate... > Jetzt funktioniert es. Schreibs mal in Deinen Eröffnungspost und im Topic [gelöst], damit nicht immer mehr antworten.
Peter D. schrieb: > M. F. schrieb: >> Hatte einen Tippfehler in der Baudrate... >> Jetzt funktioniert es. > > Schreibs mal in Deinen Eröffnungspost und im Topic [gelöst], damit nicht > immer mehr antworten. Geht nicht mehr. "Der Beitrag kann nicht bearbeitet werden. Eigene Beiträge können bis maximal 60 Minuten nach dem Absenden bearbeitet werden, und nur wenn noch keine Antworten eingetroffen sind."
Sven B. schrieb: > Es gibt auch kein mir bekanntes Encoding, bei dem 'A' nicht genau > dasselbe Literal wäre wie 0x41. Dann kennst Du halt kaum welche. Bei EBCDIC wäre das 'A' z.B. 0xC1, ansonsten gibt es das 'A' z.B. auch noch als 0x01, 0x03, 0x11 oder 0x31.
guest schrieb: > Sven B. schrieb: >> Es gibt auch kein mir bekanntes Encoding, bei dem 'A' nicht genau >> dasselbe Literal wäre wie 0x41. > > Dann kennst Du halt kaum welche. > Bei EBCDIC wäre das 'A' z.B. 0xC1, ansonsten gibt es das 'A' z.B. auch > noch als 0x01, 0x03, 0x11 oder 0x31. Na gut, point taken. Sagen wir, keines was dein C-Compiler als Source-Encoding verwendet. ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.