Hallo allerseits,
ich habe vor, meinen uC über Bluetooth mit einem PC bzw. Handy etc.
kommunizieren zu lassen. Verwenden wollte ich dabei das SPP (Serial Port
Profil), da es ja sowohl uC-, als auch PC-seitig recht leicht zu
implementieren scheint.
Übertragen sollen Steueranweißungen bzw. kurze Strings!
Um die Kommunikation nicht allzu wild aussehen zu lassen wollte ich ein
genormmtes Protokoll verwenden.
Kennt ihr da ein sinnvolles für diese Aufgabe? Dachte da evtl an CCP!
Danke & Viele Grüße,
Lugge
Lugge schrieb:> Kennt ihr da ein sinnvolles für diese Aufgabe? Dachte da evtl an CCP!
CAN Calibration Protocol? Compression Control Protocol? Ein Link zur
Spezifikation von wasauchimmer du hier meinst wäre evtl. sinnvoll.
CAN Calibration Protocol meinte ich, sorry für die Unklarheiten :)
Wobei das fast schon Overkill wäre. Ein Groß des Protokolls ist ja für
eine einfach serielle Verbindung unnötig da ja die Eigenheiten des
CAN-Buses wegfallen.
Wie wurden denn "früher" serielle Daten ausgetauscht? Oder könnte
vielleicht ein altes Druckerprotokoll sinnvoll sein?
Lugge schrieb:> Wobei das fast schon Overkill wäre. Ein Groß des Protokolls ist ja für>> eine einfach serielle Verbindung unnötig da ja die Eigenheiten des>> CAN-Buses wegfallen.
Welche wären das denn, Deiner Meinung nach?
Ich weiß nicht, was Du übertragen willst, aber CCP ist für die zyklisch
wiederholte Übertragung von ein und den selben Messwerten aus
Steuergeräten (meinetwegen auch µCs) definiert worden. Außerdem ist die
Überragung über CAN unidirektional.
Bei UART würde man den Vorteil der Bidirektionalität verschenken, wenn
man CCP versuchen würde, umzusetzen.
Die Organisation mit CRO und DTO liegt daran, dass man 8 Datenbyte
übersteigende zyklisch wiederkehrende Messanforderungen organisieren
muß. Dieses Problem könnte auch bei der seriellen Übertragung auftreten,
weil die Bandbreite begrenzt ist.
Beim CAN hat man dann Transportprotokolle wie ISO-TP 1.6 oder 2.0
umgesetzt, um so etwas wie eine virtuelle bidirektional funktionierende
Datenverbindung aufzubauen.
Willst Du Dir das wirklich antun?
Schicke doch Deine Daten einfach über den Äther und sortiere auf dem PC,
wie es Dir gerade einfällt. Irgendeinen Standard zu implementieren wäre
überzogen.
cskulkw schrieb:> Welche wären das denn, Deiner Meinung nach?
Eben die zyklische Übertragung zB.
Wahrscheinlich werd ich doch was eigenes mir Ausdenken müssen, aber
sowas wirkt für mich immer so "zusammengeschustert". Es haben sich schon
schlauere Leute als ich Gedanken über die Probleme der Datenübertragung
gemacht, deswegen wollte ich eigentlich ein vorhandenes,
funktionierendes Protokoll nachbauen...
Grüße, Lugge
Naja, so standardmäßig würd ich Binärpakete definieren (a la "Bytes 0/1
sind Paketlänge, Byte 2 ist command code, rest sind Daten, o.ä.), oder
aber du machst ein ASCII-basiertes Protokoll mit Kommandos a la
"INIT\r\n", "SET X=5\r\n", "CONNECT\r\n", "ACK\r\n", ...
Du kannst auch was FTP/HTTP-Header-artiges nachahmen wenn du etwas
nehmen willst das schon existiert, da gibts RFCs die das dokumentieren.
Ist aber eher unüblich/Overkill.
So, endlich wieder Zeit gefunden...
Ja, hab mir mittlerweile ziemlich viele angschaut, auch SNAP und SLIP,
also eher "einfachere".
Trotzdem halte ich deren Implementierung für meine Zwecke als zu
aufwendig.
Es wird wohl auf was eigenes hinauslaufen, denke da an einen Frame der
sich ziemlich an PPP orientiert, evtl noch mit Rahmen-ID.
Wenn noch Jemandem was einfallen sollte, ich bin immer noch offen für
alles :)
Danke & viele Grüße,
Lugge
Achja, ich habe vor, das BTM-222 zu verwenden.
Kann mir jemand, der damit eine erfolgreiche yC - PC - Kommunikation
zustande gebracht hat, evtl einen Bluetooth-Dongle empfehlen?
Wollte jetz ned extra nen neuen Fred aufmachen!
Danke & Viele Grüße,
Lugge
