in der Industie ist es so das alles als String übertragen wird.(Soweit ich das weiß)
Gento
Hi,
bei einem Projekt von mir möchte ich Daten über ein BUS auf einen anderen Prozessor schicken und wieder zurück.
habe somit min. 2 Geräte die kommunizieren.
das Gute, es funktioniert auch schon mit entsprechenden Testroutinen in beiden Geräten (einer sendet, der andere Wertet aus und reagiert)
meine Frage:
in welcher Form sollten die Zeichen über die Schnittstellen geschickt werden? ich meine: HEX DEZ oder gar das Zeichen (wie z.B. ein "T") als Klartext (String)
was ist den so "der Standard" bei euch bzw. in der Industie?
und:
hat es irgendwelche Nachteile wenn man es in einer bestimmten Codierung schickt? --> wie z.B. das man dann beim Empfänger wieder umwandlen muss oder so???
zur INFO:
als Empfang und Auswertung benutze ich SELECT CASE und springe dann in die entprechnenden Antworten
in der Industie ist es so das alles als String übertragen wird.(Soweit ich das weiß)
Gento
ist halt am einfachsten zu programmieren. Wenn du nur einfach Zahlen überträgst, dann wird das sicher am schnellsten/sparsamsten sein
So mache ich es auch.
Ala...
Empfangen: 231
Wird interpretiert als: Selbstzerstörung
![]()
verstehe ich jetzt nicht ganz warum das einfacher ist...
ich schreibe z.b.
und wenn man z.B. schreibt:Code:If Ischarwaiting() <> 0 Then zeichen = Chr(udr) 'hier deklariere ich den "Empfangstyp" Select Case zeichen Case "Z" Cls Lcd "Antwort a" Lowerline Lcd zeichen Wait 2 Case "Y" Cls Lcd "Antwort b" Lowerline Lcd zeichen Wait 2 Case Else Cls Lcd "Antwort c" Lowerline Lcd zeichen Wait 2 End Select
" zeichen = udr " anstelle von " zeichen = chr(udr) "
dann ist das doch genauso viel Aufwand, denke ich...
das Zeichen ist dann halt kein String sondern ein Byte!
und somit wird der Empfang dann als Dezimalzahl dargestellt.
nur was benutzt man so, bzw. was ist sinnvoller? oder ist das meiner Kreativität überlassen wie ich das besser deuten kann...
vor allem wie macht ihr das?
Wenn die kleinen keinen Text in Werte umrechnen müssen hilft das Rechenleistung zu sparen.
Schau mal Hier vorbei:
http://www.marvins-lab.roboterbastle...tml/rncom.html
Dort ist schon einiges zum Thema Kommunikation zusammengetragen. Kann sein, dass auch für Dich was Hilfreiches dabei ist.
Falls Dir dort was an Information fehlt sag ruhig bescheid, das hilft mir die Dokumentation zu verbessern.
Netter Gruß
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
@Zapo
Die Frage ist "was" du machen willst.
Wenn du in der Mehrheit nur feste Komandos übertragen und dort Zeit sparen willst dann kann die Form "Startzeichen,Befehl,Parameter,Stoppzeichen" Sinvoll sein.
Der Text wird dann über einen Speziellen Befehl erledigt und kostet mehr Zeit.
Andersrum wenn es mehr Text als Befehle gibt dann eben alles Per Textbefehle die du dann etwas umständlicher entschlüsseln mußt aber der Text geht dafür einfacher.
Du must dir erstmal klar werden was du machen möchtest und dir anhand des Ergebnisses ein eigenes Protokoll zusammenstellen.
Danach fragen was andere so machen hilft sicher bei der Technik und bietet Ideen aber nichts ist so effektiv wie die eigene Lösung weil sie meist genau auf den Fall zugeschnitten ist.
Edit:
Meine Gott was für Tippfehler![]()
Gruß
Ratber
@Ratber
alles klar, das war verständlich... meine Nachricht die ich sende bestehe aus:
STX,Adresse(Ziffern),Nachricht(Buchstaben),ETX
dann denke wenn alles in HEX übertragen wird wäre das für mich am sinnvollsten....
Achso, ich dachte du willst lange Strings senden und vergleichen.Zitat von Zapo.
Jap, so wierds wohl beinahe egal sein, was du machst, wobei ich immernoch zu KONSTANTEN mit geschickten NAMEN tendieren würde
#DEFINE DO_SELFDESTROY 213
Das ist am perfomantesten(wird der Compiler wohl hinbekommen)
Solange du sicherstellen kannst das die Steuerzeichen "niemals" im Text/Datenbereich vorkommen oder du Steuerbefehle im Text/Datenbereich von der Befehlserkennung ausblendest ist das kein Problem.Zitat von Zapo.
Gruß
Ratber
ja eigentlich schon, wird durch ein Protokoll sichergestellt...
Lesezeichen