Register richtig lesen

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?

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"

ah alles geklärt:

M. F. schrieb:
> Hatte einen Tippfehler in der Baudrate...

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."

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. ;)