Gleich vorab: Ich weiß wirklich nicht ob ich im richtigen Forumsbereich bin, also bitte nich böse sein! Ich bin derzeit in einer Fachschule für Elektroniker. Wir müssen bis zur nächsten Klasse ein Projekt fertigstellen/Präsentieren. Ich habe hier also meine Hardware(ATMEGA128) und meine PC-Software. Kommuniziert wird über RS232 mittels eines FT232RL, nun stehe ich vor dem Problem das das ganze Zeitkritisch ist und ich nicht weiß wie(also in welchem Format) ich die Befehle bzw. Werte senden/empfangen soll. Ich sende und empfange bidirektional Zahlen(von -300 bis 300), Werte(0 bis 100) und Befehle(zum Bsp. "OUTPUT.1.ON" oder "GET.FIRMWARE") Welches Format(ASCII, HEX, BIN) wäre am besten und am schnellsten um die Daten zu senden/empfangen? Vielen Dank für die Hilfe! Mfg Georg
Georg Wolfsteiner schrieb: > Ich habe hier also meine Hardware(ATMEGA128) und meine PC-Software. > Kommuniziert wird über RS232 mittels eines FT232RL, nun stehe ich vor > dem Problem das das ganze Zeitkritisch ist Wie zeitkritisch? > und ich nicht weiß wie(also > in welchem Format) ich die Befehle bzw. Werte senden/empfangen soll. So das du es programmieren kannst. ASCII hat den Vorteil du kannst die Übertragung sofort mitlesen. Auch ASCII wird als HEX bzw binär übertragen es ist alles eine Interpretationsfrage. http://en.wikipedia.org/wiki/ASCII Georg Wolfsteiner schrieb: > Ich sende und empfange bidirektional Zahlen(von -300 bis 300), Werte(0 > bis 100) und Befehle(zum Bsp. "OUTPUT.1.ON" oder "GET.FIRMWARE") Zahlen müssen dann in ASCII gewandelt und dann wieder zurückgewandelt werden. ASCII O U T P U T . 1 . O N HEX 4F 55 54 50 55 54 2e 31 2e 4F 4e So würde die Übertragung in ASCII aussehen
Hallo chris!
Zeitkritisch in dem Sinne da die Daten bestenfalls so gut wie ohne
zeitverzögerung übertragen werden sollten da zum bsp. die Zahlen/Werte
vom PC so schnell wie möglich vom μC ausgwertet und auf einem LCD
angezeigt werden sollen.
>ASCII hat den Vorteil du kannst >die Übertragung sofort mitlesen
Das ist eben das Problem, es soll "Codiert" also eine art
Verschlüsselung haben, das ist eine Vorgabe von meinem Fachlehrer..
(genauso wie die Programmierung in BASCOM und VB.NET, leider)
Sonst hätte ich ASCII genommen und fertig.
Hab ich vergessen zu erwähnen, sry.
Georg Wolfsteiner schrieb: > Hallo chris! > > Zeitkritisch in dem Sinne da die Daten bestenfalls so gut wie ohne > zeitverzögerung übertragen werden sollten da zum bsp. die Zahlen/Werte > vom PC so schnell wie möglich vom μC ausgwertet und auf einem LCD > angezeigt werden sollen. Mal wieder die typische Anforderung... so schnell wie möglich. Wie schnell ist denn das genau in SI Einheiten ausgedrückt? Und die viel wichtigere Frage, kannst du mehr als sagen wir mal 20 Werte pro Sekunde unterscheiden? Bzw ist es Unterhaupt förderlich wenn sich die Werte so schnell ändern? Irgendwann hast du nämlich überall 8en drin stehen ;-) > Das ist eben das Problem, es soll "Codiert" also eine art > Verschlüsselung haben, das ist eine Vorgabe von meinem Fachlehrer.. Also musst du dir einen Frameaufbau überlegen. Hat auch den Vorteil das du evtl weniger Zeichen benötigst. Die typischen Fragen bei so etwas sind z.B: Was für Werte möchte ich übertragen? Was für Datentypen verwende ich für die einzelnen Werte? Wie soll der Frame aussehen? Daten auf Anforderung durch den Master oder sendet der Slave automatisch? Gibt es mehrere Slaves? Dann wird das automatische senden schwieriger...Stichwort Synchronisation. Checksumme? Verschlüsselung? > (genauso wie die Programmierung in BASCOM und VB.NET, leider) > Sonst hätte ich ASCII genommen und fertig. > Hab ich vergessen zu erwähnen, sry. Macht keinen Unterschied.
Entschuldigt die späte Antwort, mein Router hats nicht mehr gemacht. >Wie > schnell ist denn das genau in SI Einheiten ausgedrückt? Also wenn ich jetzt mal großzügig bin: 100ms pro Wert, 12 - 15 Werte insgesamt > Und die viel wichtigere Frage, kannst du mehr als sagen wir mal 20 Werte > pro Sekunde unterscheiden? Ist, denke ich, möglich mit 16MHz am μC und 54600baud, falls mich meine Rechenkünste nicht im Stich gelassen haben :-D Wegen dem Frameaufbau, hast du vielleicht eine Dokumentation, Beschreibung oder Definition wie sowas aufgebaut wird? (Ich möchte keine fertige Lösung, nur einen kleinen Leitfaden oder so eine Art Nachschlagwerk) Mfg Georg
> Und die viel wichtigere Frage, kannst du mehr als sagen wir mal 20 Werte > pro Sekunde unterscheiden? > > Ist, denke ich, möglich mit 16MHz am μC und 54600baud, falls mich meine > Rechenkünste nicht im Stich gelassen haben :-D Ich meinte am LCD ;-) Das menschliche Auge ist dich reichlich träge. Aber wenn du sowieso nur 10 Frames pro Sekunde willst, sollte das mehr als machbar sein. > Wegen dem Frameaufbau, hast du vielleicht eine Dokumentation, > Beschreibung oder Definition wie sowas aufgebaut wird? Eine Bestimmte? No. Es gibt einfach zu viele Protokolle. Du hast nicht darauf geantwortet wieviele Teilnehmer es gibt. Auch hast du nicht geschrieben ob die Daten auf Anfrage durch einen(?) Master kommen sollen oder ob der (eine?) Slave einfach nur dumm senden kann! Im einfachsten Fall ballert nämlich der eine Server nur seine Daten raus. Typische Arten um einen neuen Frame zu kennzeichnen sind z.B. Timeouts oder gewisse Start/Endpattern. Eine weitere Möglichkeit ist das es ein endloser Stream ist. Der Client weiß aber z.B. das ein Frame von mir aus 12 Zeichen lang ist und danach noch eine CRC16 kommt. Also sucht er sich am Anfang einen Frame indem er über die ersten 12 empfangenen Zeichen die CRC16 berechnet. Stimmt die mit der empfangenen CRC überein, hat er einen Frame gefunden. Stimmt sie nicht überein, verwirft er ein Zeichen und berechnet wieder die CRC. Dies wiederholt er so lange bis die CRCs übereinstimmen und somit ein gültiger Frame gefunden wurde. Das ist die etwas aufwendigere Variante, hat aber den Vorteil das keine unnötigen Zeichen gesendet werden müssen oder man Zeit durch die Timeout verschwendet. Des weiteren können die Rohdaten ohne Zeitwerte direkt abgespeichert werden und zu einem späteren Zeitpunkt ausgewertet werden.
Georg Wolfsteiner schrieb: > Wegen dem Frameaufbau, hast du vielleicht eine Dokumentation, > Beschreibung oder Definition wie sowas aufgebaut wird? > (Ich möchte keine fertige Lösung, nur einen kleinen Leitfaden oder so > eine Art Nachschlagwerk) Also, ich hab das mal so gemacht und es hat sehr gut funktioniert: | 0x5A | za | xx | yy | zz | DataBlock 0..255 | CS | 0xAA | 0x5A = FrameStart za = ZielAdresse xx = Länge (nur für Datablock), 0 = keine Daten vorhanden yy = Command (0..127) - (Falls bit7 gesetzt ist, handelt es sich um Antwort auf vorheriges Command) zz = SenderAdresse ... CS = Checksum ( Auf Byt0 bis ChkSum-1) 0xAA = FrameEnd In der ISR wird empfangenes Byte geprüft, wenn == 0x5A, wird FrameFlag gesetzt, FramePointer und CS auf Null gesetzt. Wenn FrameFlag gesetzt ist, wird zweites Byte auf eigene Adresse geprüft (deswegen kommt die ZielAdresse als zweites Byte - spart unnötiges checken der Bytes). Wenn ZielAdresse == eigene Adresse wird weitergemacht, ansonsten FrameFlag = 0, FramePointer wurde erst gar nicht erhöht. Checksum = CS XOR empfangenes Byte. Das läuft schnell und zuverlässig. P.S. 0xAA als FrameEnd habe ich genommen, weil man mit SoftUart damit die tatsächliche Baudrate sehr gut bestimmen und anpassen kann - nach dem Empfang von ChkSum Hardware UART abschalten, 5 mal die Null empfangen, 4 mal die Eins, Zeiten zusammenzählen, mit 5 bzw. 4 teilen und man hat die tatsächliche Baudrate und kann evtl. UBRR korigieren.
Protokoll mit kleinst möglichem overhead und ohne längenbegrenzung: [ 0xFF | DataBlock 0..254 | CS ] 0xFF = FrameStart DataBlock = wird vor dem Senden von base 256 nach base 255 umgerechnet, kann kein 0xFF enthalten, schwierig zu berechnen. Wird bei empfang von base 255 nach base 256 zurückgerechnet. CS = checksumme // ( abrunden ) Overhead = 1 + sizeof(CS) + n / 255 + 1 n = länge von DataBlock Es ist komplizierter als es aussieht.
Hallo Leute! Also erstmal vielen, vielen Dank für die Hilfe! Ihr habt meine Erwartungen echt übertroffen! @Norbert: Die EBCDIC Methode ist sehr interresant, die werde ich auf jedem Fall mit meinem Fachlehrer besprechen! @Frank: Teilnehmer gibt es nur einen, also ein µC und ein PC Die meißten Daten vom Master(PC) werden in bestimmten Zeitabständen immer gesendet, andere werden nur gesendet wenn Sie benötigt werden (eben die Kommandos wie OUTPUT.1.ON) Der Slave sendet nur eine handvoll Werte, die meisten nach Abfrage vom Master. @Marc: >Also, ich hab das mal so gemacht und es hat sehr gut funktioniert. > | 0x5A | za | xx | yy | zz | DataBlock 0..255 | CS | 0xAA | Das sieht ebenfalls sehr vielversprechend aus! Also, ich werde jetzt mal alle Möglichkeiten mit meinem Fachlehrer besprechen, mal sehn was der dazu sagt! Also nochmal Danke für die Hilfe und schöne Ostern wünsch ich euch! Mfg Georg
Norbert M. schrieb: > Nimm doch einfach EBCDIC, alles Andere ist sowiso Kinderkram. Was ist denn beim EBCDIC anders als beim ASCII, außer dass die Zeichen-Code Zuordnung anders ist?
Wolfgang schrieb: > Norbert M. schrieb: >> Nimm doch einfach EBCDIC, alles Andere ist sowiso Kinderkram. > Was ist denn beim EBCDIC anders als beim ASCII, außer dass die > Zeichen-Code Zuordnung anders ist? Es kommt von IBM, dem größten Hersteller internationaler Geschäfts- maschinen. Und was für AS/400 und zEntrumpreis gut und teuer ist, das wird dann doch wohl auch für den Atmel-Chip von Georg recht und billig sein. Daher auch die Anmerkung, dass "alles Andere" Kinderkram sei. Sorry, der Hinweis auf EBCDIC war eher ironisch gemeint, da schon die Ausgangsfrage, ob denn nun ASCII, Binär oder Hexadezimal "besser" sei, zumindest mir gegenüber ziemlich witzlos erscheint. Und ja, EBCDIC rlz rly, imo. YMMV.
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.