Datum:
Hallo Leute, ich habe ein Bluetoothmodul (BlueMod+P25/G2 von Stollmann) und möchte das über ein Java(ME) Midlet, seriell gekoppelt mit einem Funkgerät, mit den dafür bereitgestellten AT-Befehlen ansprechen. Allerdings scheine ich die Übergabe der AT-Befehle oder ein paar Vorbedingungen nicht richtig machen. Habt ihr Erfahrung, ob es möglich ist über ein Java Programm AT-Befehle an das Bluetoothmodul zu übergeben?
private void sendeAT_i()
{
try
{
os = cc.openOutputStream();
os.write(65); // A
os.write(84); // T
os.write(32); // Leerzeichen
os.write(105); // i
os.write(13); // Enter
os.write(10); // Linefeed
os.flush();
}
catch(IOException io)
{
textBox.setString("Fehler beim Senden der Daten: " + io.getMessage());
}
}
private void open()
{
try
{
cc= (CommConnection)Connector.open("comm:COM0");
if(cc != null)
{
is = cc.openInputStream();
sendeAT_i();
int n = 0;
StringBuffer sb = new StringBuffer();
while ((n = is.read()) != -1)
{
sb.append((char) n);
String result=sb.toString();
textBox.setString("InputStream:" + result);
}
os.close();
cc.close();
is.close();
}
}
catch(IOException io)
{
textBox.setString("Fehler " + io);
}
finally
{
if (cc != null)
{
try
{
cc.close();
os.close();
is.close();
}
catch(IOException e)
{
textBox.setString("Fail: " + e.getMessage());
}
}
}
|
Danke!!
Datum:
Hallo Sannchen, ja es ist möglich, und du hast noch immer deine Probleme mit der inkonsistenten Nutzung der Streams. Beitrag "JavaME Input Stream"
Datum:
Hey, irgendwie wusste ich, dass du der Erste bist, der antwortet :) Ja ich weiß, richtig gut ist das Programm noch nicht, aber es läuft erstmal so wie ich es will (fast). Mir ist es erstmal wichtig, dass das Bluetoothmodul angesprochen wird und reagiert. Nur leider reagiert es nicht.
Datum:
Naja das ist eben der unterschied zwischen "Funktioniert" und "Funktioniert (fast)". Hast du den schon mal versucht das Modul mit hterm oder ähnlichem anzusprechen? Außerdem verschluckst du möglicherweise immer noch Fehlermeldungen/Exceptions Su Si schrieb: > os.write(65); // A > os.write(84); // T > os.write(32); // Leerzeichen > os.write(105); // i > os.write(13); // Enter > os.write(10); // Linefeed Wieso jetzt hier als "Zahlen"? Das verwirrt doch nur, du hattest das doch schon mal als String gesendet oder? Wenn das noch was werden soll musst du auf jedenfall strukturierter vorgehen, wie und wo wird z.B. sende aufgerufen etc... du blockierst dir da nämlich den aktuellen Thread, das kann ins Auge gehen...
Datum:
Ja, hatte das Bluetoothmodul schon mehrfach über hterm oder tera term angesprochen und das funktioniert tadellos. Ich weiß ja, was ich auf bestimmte AT-Befehel vom Bluetoothmodul für Antworten bekomme. Nur diese bekomme ich über das Javaprogramm nicht, von daher weiß ich auch nicht, ob die Kommunikation zwischen den beiden überhaupt funktioniert. Baudrate und sowas sind bei beiden gleich. Wie gesagt, das Javaprogramm funktioniert zwischen Funkgerät und PC/Terminal so wie es soll. So das ich eigentlich nirgends eine Exception erwarten würde. Ja ich hatte erst die Befehle als Strings übergeben. Aber das Bluetoothmodul erwartet ASCII Zeichen und antwortet auch in diesen (habe nachgelesen). Deswegen übergebe ich jetzt Zahlen/ASCII. Ich will den InputStream noch in eine Methode auslagern. Welchen Thread blockier ich mir denn?
Datum:
Su Si schrieb: > Deswegen übergebe ich jetzt Zahlen/ASCII das ist im endeffekt aber alles dasselbe, so ist es nur maximal unleserlich. Versuch doch einfach mal die selbe Sequenz mit dem Programm zu senden und nutze als Empfänger Teraterm dann sieht man doch was ankommt und was sich unterscheidet.
Datum:
Du meinst wenn ich "AT-Befehl\n\r".getBytes(); mache, werden die letztendlich auch als ASCII Zeichen übergeben? Muss ich dann dem Programm noch irgendwie sagen, dass er das umwandeln soll? Läubi .. schrieb: > Versuch doch einfach mal die selbe Sequenz mit dem Programm zu senden > und nutze als Empfänger Teraterm dann sieht man doch was ankommt und was > sich unterscheidet Versteh ich nicht. Bitte mal genauer erklären, wie und was?
Datum:
Su Si schrieb: > Muss ich dann dem Programm noch irgendwie sagen, > dass er das umwandeln soll? Mittels getBytes("US-ASCII"); gehst du auf Nummer sicher, ist aber nur bei Sonderzeichen relevant. Su Si schrieb: > Versteh ich nicht. Bitte mal genauer erklären, wie und was? PC1 mit Java Programm-->Comport-->KABEL->Comport PC 2 mit hterm
Datum:
Okay, dann werde ich in Zukunft die Methode nutzen. Da die Zahlen echt umständlich sind. Ganz ehrlich, ich verstehe deinen Aufbau immer noch nicht. Denn das Javaprogramm läuft nur so richtig auf dem Funkgerät. In NetBeans der Emulator kann das nicht richtig nachbilden, da es dort keine Funkgeräte gibt.
Datum:
Du sollst das auch erstmal ohne Funkmodul sondern über die "normale" RS232 erst mal gegenchecken.
Datum:
Ich habe jetzt einen PC seriell mit einem anderen PC gekoppelt. Auf PC1 starte ich das Midlet (.jad). Es kommt nur die Frage, ob eine serielle Verbindung eingegangen werden soll, ich klicke auf ja und dann passiert nichts mehr. Ich hab nur noch Fragezeichen im Kopf!
Datum:
Hey Läubi, mittlerweile funktioniert mein Input Stream. Allerdings verlässt er die while-Schleife nicht mehr. Ich habe schon sämtliche Abbrechbedingungen versucht. Vielleicht fällt dir/euch noch eine ein?
public void run()
{
try
{
openConnections();
form.append("\n Sende AT-Befehle");
form.append("\n Sende AT**BINQ=2");
os.write("\n\r AT**BINQ=2 \n\r".getBytes("US-ASCII"));
os.flush();
int n = 0;
StringBuffer sb = new StringBuffer();
while ((n = is.read()) != -1)
{
sb.append((char) n);
String result = sb.toString();
form.append("\n InputStream:" + result);
}
}
// es folgt catch Block
}
|
Er gibt nacheinander die Zeichen die ankommen, aus und dann bleibt er in der Schleife hängen. Bin für jeden Tipp dankbar! Sannchen
Datum:
Su Si schrieb: > Allerdings verlässt er die > while-Schleife nicht mehr Hab ich doch schon oben geschrieben, der Stream wird nie beendet, da ein Serieller Port kein "EOF" oder dergleichen kennt. Üblicherweise weiß man aber, dass z.B. nach einem Zeilenumbruch o.ä. zumindest ein Datensatz vollständig da ist, kann diesen verarbeiten und dann weiter vorgehen.