Hallo Zusammen! Ich möchte per Uart eine 2 Byte Zahl von einem MSP430F2616 an den Rechner schicken. Bei einem bestehendem Gerät funktioniert dies bereits, jedoch mit einem TMS 370. Bei einem (meinem) neuen Gerät funktionert dies nur mit einer Hex- bzw. 1 Byte Zahl. Und das duzgehörige Programm kann aber nur mit dem alten Format was anfangen. Jetzt die Frage: Ich weis nicht weiter, da ich nicht verstehe worin der Unterschied zwischen den Beiden Formaten besteht. Das RS232 Terminal zeigt mir einerseits in ASCII die 2 BYTE Zahl des alten Formats an und zum anderen nur(ASCII) Punkte des neuen Formats. Wie kann ich die Configuaration der alten Schnittstelle eines TMS370 anhand des Datenstrings herausbekommen mfg Thomas
Wenn du einen 16 Bit Wert sendest sendest du erst das High Byte dann das Low Byte.
Hab Dein Problem nicht ganz verstanden, aber es hört sich so an, als ob
Dein altes Ding die Zahl als ASCII-String verschickt.
Im diesem Fall würde die Zahl 8Bit-Zahl 0x10 als zwei getrennte
8Bit-ASCII-Codes ('1' = 0x31 und '0' = 0x30) gesendet. Dies hat den
Vorteil, daß man im Terminalprogramm "Klartext" sieht.
Wenn Dein neues Ding hingegen die 8Bit-Zahl 0x10 als ASCII-Code 0x10
versendet, kommt am Terminalprogramm ein "Linefeed" an.
Siehe
http://de.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange
Thomas schrieb: > Jetzt die Frage: > Ich weis nicht weiter, da ich nicht verstehe worin der Unterschied > zwischen den Beiden Formaten besteht. Das RS232 Terminal zeigt mir > einerseits in ASCII die 2 BYTE Zahl des alten Formats an und zum anderen > nur(ASCII) Punkte des neuen Formats. ergänzend: Benutz als Terminal HTerm. Das kann dir die übertragenen Bytes in ihrer Hexadezimalen Form UND die Interpretation dieser Bytes als ASCII Zeichen gleichzeitig anzeigen. Dann solltest du den Unterschied sofort sehen.
@Karl Heinz Buchegger also der Unterschied ist das beim alten Ding die Hexzahlen irgendwie einen Code ergebender dann (für mich zufällig) eine Ascii Zahl ergibt. ------------------------------------------------------------------------ -- wenn ich nun die HEX Zahlen nach Ascii Zahlen nach Dosmo von hand codiere dann krieg ich das auch hin. Das wäre also genau die Lösung: mit Steuerzeichen eine String Kette erstellen. Wenn ich nun eine Sterzeichentabelle hernehme und mir das angesprochene Linefeed raussuche, dann ist das in diesem Falle ein 0x0a, und das kommt auch alle 4 Byte + 1Byte "Carriage Return" (0x0d) vor. also muss ich meinem Uart beibringen das er nicht nur den Buffer sendet sondern die Steuerzeichen beachtet. Das ist natürlich eine Ganz andere Situation halt nicht das was mir zu dem Projekt erzählt wurde. ich bedanke Mich!!! mfg Thomas
Thomas schrieb: > also muss ich meinem Uart beibringen das er nicht nur den Buffer sendet > sondern die Steuerzeichen beachtet. Dem UART sicher nicht!
Thomas schrieb: > halt nicht das was mir zu dem Projekt erzählt wurde. Um ehrlich zu sein bin ich mir nicht sicher ob du verstanden hast, was das Problem ist. Das ein mal wird offenbar so gesendet int i = 20; uart_write_byte( i >> 8 ); // das HighByte uart_write_byte( i & 0x0F ); // das LowByte und das andere mal so int i = 20; char buffer[10]; sprintf( buffer, "%d\n", i ); uart_write_string( buffer ); Das eine mal eben direkt die Bytes in ihrer binären Repräsentierung und das andere mal indem zuerst ein Text erzeugt wird und dann dieser Text gesendet wird. > also muss ich meinem Uart beibringen das er nicht nur den Buffer > sendet sondern die Steuerzeichen beachtet. typischerweise geht das den UART selber überhaupt nichts an. In letzter Konsequenz kriegt der ein paar Bytes, die er über die Leitung rausbläst (bzw. umgekehrt reinkommende Bytes in einem Buffer ablegt). Was diese Bytes dann bedeuten interessiert die UART einen feuchten Kehrricht. Es ist einzig und alleine dein Programm, welches darüber entscheidet, was mit diesen Bytes zu tun ist.
Thomas schrieb: > Das ist natürlich eine Ganz andere Situation > > halt nicht das was mir zu dem Projekt erzählt wurde. Idealerweise gibt es so etwas wie eine Protokollspezifikation, wo genau solche Sachen drinnstehen. PS: Mein Fehler: 0x10 ist natürlich nicht Linefeed, sondern 0x0A - Doof!
Also nochmal wiederholen.
klar der Uart kann in meinem fall nur 1 Byte auf einemal übertragen und
der Syntax muss ausserhalb des Uart geklärt werden.
ich muss meiner Uart_sende_Funktion beibringen das sie anstatt einer
Zahl
z = 3735
sechs Zeichen Sendet warscheinlich so:
Uart_string_buffer_2_byte_zahl_z[6] =
{
0x33;
0x37;
0x33;
0x35;
0x0d;
0x0a;
}
Oder meinst du das wenn ich einen String mit vier zeichen erzeuge und
mit Sprintf formatiere/umlade das dann die Steuerzeichen schon drin
sind? Hab solche Sachen noch nie so machen müssen...
mfg Thomas
Wenn du hinten ein \n dranmachst für newline macht er das auch.
google mal printf
printf("%d \n",i);
printf kostet aber viel speicher im AVR.
Machs lieber selber.
Deine UART-Sendefunktion sollte einfach nur 1:1 einen Puffer senden. Was Du in diesen Puffer hinschreibst, muß das richtige Format haben, aber das sollte an der Stelle berücksichtig werden, wo in den Puffer geschrieben wird, und nicht in der UART-Sendefunktion. Es könnte gut sein, daß Du doch mal etwas anderes als ASCII-codierte Zahlen senden willst, neech?
Thomas schrieb: > Also nochmal wiederholen. > > klar der Uart kann in meinem fall nur 1 Byte auf einemal übertragen und > der Syntax muss ausserhalb des Uart geklärt werden. > > ich muss meiner Uart_sende_Funktion beibringen das sie anstatt einer > Zahl > z = 3735 > sechs Zeichen Sendet warscheinlich so: > > Uart_string_buffer_2_byte_zahl_z[6] = > { > 0x33; > 0x37; > 0x33; > 0x35; > 0x0d; > 0x0a; > } > > Oder meinst du das wenn ich einen String mit vier zeichen erzeuge und > mit Sprintf formatiere/umlade das dann die Steuerzeichen schon drin > sind? Hab solche Sachen noch nie so machen müssen... Jetzt wundert mich deine Aussage, dass du so arm wärst, weil dir das niemand gesagt hat, nicht mehr. void uart_print_int( int z ) { char buffer[20]; sprintf( buffer, "%04d\r\n", (int)z ); uart_print_string( buffer ); } (oder wie dann eben die bisherige Funktion heißt, die einen int verschickt). fertig ist die Umstellung unter der Voraussetzung das der Empfänger das auch wirklich so haben will. Wenn du keine Protokollspezifikation hast, dann musst du dir im HTerm schon genau ansehen, was da über die Leitung flutscht. Das eine mal hast du nur einen \n, hier hast du plötzlich beides 0x0d und 0x0a. Einmal sind es 4 Bytes + 1 zur Endekennung. Dann sind es wieder 6 Bytes. Erhebt sich auch noch die Frage: müssen es immer 4 Bytes sein? was ist mit führenden 0-en? Müssen die gesendet werden oder nicht?
Karl Heinz Buchegger schrieb: > sprintf( buffer, "%04d\r\n", (int)z ); Ich bin mir nicht so sicher, ob er wirklich eine 16Bit-Zahl senden will. Vielleicht meinte er mit "eine 2 Byte Zahl" auch nur ein Byte, weil es in Hex-Darstellung zwei Nibble hat...
Dosmo schrieb: > Karl Heinz Buchegger schrieb: >> sprintf( buffer, "%04d\r\n", (int)z ); > > Ich bin mir nicht so sicher, ob er wirklich eine 16Bit-Zahl senden will. > Vielleicht meinte er mit "eine 2 Byte Zahl" auch nur ein Byte, weil es > in Hex-Darstellung zwei Nibble hat... Ganz ehrlich: Am einfachsten wäre es, wenn er einfach mal Screen Dumps von beiden Übertragungsvarianten im HTerm posten würde. Dann würden wir uns das selber aus dem Hex-Protokoll raussuchen. Zusammen mit den Angaben, was da eigentlich gesendet wird und welche Zahlenwerte das sein sollten, hat man sowas relativ schnell rausgefunden (solange nichts verschlüsselt ist).
Angehängte Dateien:
-
INPUT_HEX.jpg
190 KB -
INPUT_STRING__1.jpg
150 KB -
INPUT_STRING__2.jpg
150 KB
so es sind 28mal 2BYTE und 2mal 4BYTE ZAHLEN ja eigenglich ist es ein String. Ergo brauch ich entweder eine Codierung mit variabler Codelänge oder halt zwei Codierungen. Ich muss das aber selber tun da es bei mir kein printf gibt. mfg thomas
So hat nun geklappt Zeichen können wie vom alten Gerät eingelesen werden. mfg Thomas und ein Dankeschön für die Tipps und ich Wünsch ein schönes Wochenende
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.