Java ME Baudrate

[Sannchen]

Hallo Leute!

Ich schreibe ein Programm für ein Digitalfunkgerät, welches mit einer Baudrate von 9600 Baud arbeitet. Später möchte ich an dessen serielle Schnittstelle ein anderes Gerät hängen, dieses braucht aber 115200 Baud. Wie kann ich das realisieren?
Kann ich in dem Programm die Baudraten für das jeweilige Gerät "umstellen"? ???:L

Danke!
Sannchen

 

[AquaBall]

Die Baud-Rate wird wohl nur ein Parameter an der Schnittstelle sein.
Die Probleme von Buffer-Over/Under-Flow musst du ohnedies handeln.

Aber wenn du weißt, wie du die Schnitstelle ansprichst, dann weißt du auch wie die Buffer verwaltet werden (und damit ist dir die Baud-Rate egal.) .

 

[jf]

Ja, im Java MIDlet ist die Baudrate nur ein Parameter. Wenn du die Baudrate des Gerätes selber umstellen möchtest, dann wird es wohl ein AT-Kommando dafür geben.

Wenn du hierbei immer noch Probleme hast, dann zeige mal ein paar Zeilen Code, wo es hängt...

 

[Sannchen]

Ich hab die Baudrate an dem Gerät auf 9600 Baud geändert. Jetzt haben beide die gleiche Baudrate.

@Aquaball: Was meinst du mit dem Buffer-Over/Underflow? Kannst du das bitte etwas näher erklären?

Ich habe mittlerweile ein anderes Problem.
Ich möchte über ein Javaprogramm, welches auf einem Funkgerät läuft, AT-Befehle an ein Bluetoothmodul übergeben (seriell).
Ich habe das Programm auf dem Funkgerät seriell an den PC geschlossen und die Ausgaben der AT-Befehle auf dem HTerm sieht richtig aus. Allerdings scheint sich das Bluetoothmodul nicht angesprochen zu fühlen.
Hat jemand damit Erfahrungen??

 

[jf]

Verstehe ich es richtig: du möchtest per AT-Kommando das Bluetooth-Modul deines Funkgerätes aktivieren?

Wenn ja, dann musst du im MIDlet genau die gleichen AT-Kommandos anwenden, wie im HyperTerminal auch (AT-Kommandos händisch eingeben).
Teste das Bluetooth-Modul erst einmal nur so - das sollte schneller gehen, als für jede Code-Änderung das die neue jar aufzuspielen.

rein interessenshalber: Was für ein Modul steckt in deinem EADS-Funkgerät?

 

[Sannchen]

Hey jf,

nicht ganz richtig.
Ich hab auf der einen Seite ein Digitalfunkgerät. Auf der anderen Seite habe ich ein Bluetoothmodul in einem Evaluationskit (BlueMod+P25/G2 von Firma Stollmann).
Diese beiden Geräte verbinde ich seriell. Über diese serielle Verbindung möchte ich aus einem Programm (welches auf dem Funkgerät läuft) AT-Befehle an das Bluetoothmodul geben.

Dem Bluetoothmodul AT-Befehle über den PC geben (per Terminal) funktioniert.
Das Javaprogramm auf dem Funkgerät an den PC angeschlossen (seriell) gibt mir im Terminal auch die AT-Befehle richtig aus.
Nur die Kommunikation zwischen Funkgerät und Bluetoothmodul (seriell) funktioniert nicht. Also ich bekomme vom Bluetoothmodul keine Antwort.

 

[jf]

Wenn ich ein Modem an den Rechner anschließe, dann ist es oftmals so, dass die erste Eingabe nicht klappt, da sich im Puffer scheinbar noch Zeichen befinden (z. B. werden durch den Start von Windows irgendwelche Signale am RS232 ausgegeben, welche dann evtl. als Zeichen im Puffer landen).
Sende vor den AT-Kommandos zur Sicherheit ein Newline. Prüfe außerdem, welche HyperTerminal-Einstellung gewählt ist ([Enter] == "\r\n" || [Enter] == "\n" || [Enter] == "\r") und vergleiche diese mit deinem Source. Es kann nur an so etwas "kleinem" liegen, meine ich.
Bei manchen AT-Kommandos muss ich bei meinen HyperTerminal-Einstellungen für manche Tasten zwei Anschläge machen (z. B. ^^) - dies muss evtl. in deinem Code ebenfalls berücksichtigt werden.

 

[Sannchen]

Das ist ein klasse Tipp! Danke!
Werde ich auf jedenfall berücksichtigen bzw. gleich in meinen Code einarbeiten.

Vermutlich liegt der Fehler aber noch an der seriellen Schnittstelle. Da das Bluetoothmodul eine DCE Schnittstelle hat. Das Funkgerät vermutlich aber auch, das muss ich noch herausbekommen.
Wenn es so ist, kann ich das über ein Cross-over-Kabel lösen.

Trotzdem kurze Verständnisfrage:
Das Bluetoothmodul braucht die Einstellung Flusskontrolle: Hardware. Heißt das also CTS und RTS on??

Danke!!

 

[jf]

Das ist ein klasse Tipp! Danke!
Werde ich auf jedenfall berücksichtigen bzw. gleich in meinen Code einarbeiten.

Ja, schau mal ab es hilft. In unserer Anwendung wird das AT-Kommando ständig wiederholt, weshalb so etwas nicht nötigt ist. - Wenn du aber eine starre AT-Sequenz sendest, wo die nächsten AT-Kommandos auch noch vom verherigen abhängen, dann könnte dies durchaus hilfreich sein. - zumindest in den Situationen, wo hin- und hergestöpselt, sowie Modem und Rechner neu gestartet wird. (unser Modem sendet z. B. eine Startmeldung - macht dies dein Funkgerät auch, so würde diese natürlich im Puffer vom Bluetooth-Modul landen)

Vermutlich liegt der Fehler aber noch an der seriellen Schnittstelle. Da das Bluetoothmodul eine DCE Schnittstelle hat. Das Funkgerät vermutlich aber auch, das muss ich noch herausbekommen.
Wenn es so ist, kann ich das über ein Cross-over-Kabel lösen.

Ich bin weniger der Hardware-Guru, weshalb ich in dieser Stelle auch immer erst nachschlagen muss:
bei RS232 heißt ein Cross-over-Kabel Nullmodem-Kabel. Es wird zum Verbinden von zwei Rechnern benötigt. Für Rechner und Modem braucht man das serielle Standard-Kabel. Demzufolge wäre es nur logisch, wenn für Modem zu Modem (gleiche Belegung bei den Buchsen) ebenfalls ein Nullmodem-Kabel nötig ist - du dürftest also Recht haben.

Trotzdem kurze Verständnisfrage:
Das Bluetoothmodul braucht die Einstellung Flusskontrolle: Hardware. Heißt das also CTS und RTS on??

Wie gesagt, ich bin nicht so der Hardware-Guru. Ich kann da leider nicht weiterhelfen. Sorry.

 

[Sannchen]

Hey jf,
danke für deine Antwort.
Mittlerweile habe ich ein Nullmodemkabel zwischen beide Geräte gehangen und nun können sie kommunizieren. Bin ich erstmal sehr froh darüber.:applaus:
Allerdings reagiert mein Bluetoothgerät immer noch nicht auf die gesendeten AT-Befehle, da muss ich noch etwas dran arbeiten. ???:L
Und ich habe ein Problem mit der while-Schleife für den Inputstream. Da er zwar die ankommenden Daten einliest aber die While-Schleife nie verlässt.

public void run()
            {
                try
                {
                    openConnections(); // in dieser Methode wird auch der Inputstream geöffnet
                    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
          }

Hättest du noch einen Vorschlag für eine andere Abbruchbedingung?

Danke!

 

[jf]

Ja, ich hatte auch schon das Problem, dass das Ende des Streams nie erreicht wird und somit ein

while ((n = is.read()) != -1)

nicht abbricht. Du musst die Kommunikation zeilenweise angehen: lese alle Zeichen aus dem Stream in einen StringBuilder, bis ein Zeilenumbruch kommt - dann werte die Zeile aus und setze die Kommunikation entsprechend fort.
Dafür muss das Bluetoothmodul zwingend ein Abschlusszeichen schicken (z. B. LF oder CR).