RS232 mit Java ansprechen - Seite 2

Seite 2 von 4 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/rs232_mit_java_ansprechen_219398/page_2 - zur Vollversion wechseln!

djonny schrieb am 24.11.2010 um 11:12

Jetzt bin ich mal komplett verwirrt lol

Ok also das Gerät erwartet soviel ich weiß einen Hex String, dieser Hex String kann variabel groß sein.

Das Gerät nimmt das Telegramm und guckt was im 2. Byte steht dort steht dann zB 01 = Zieladresse 1 oder 0A = Zieladress 10

somit vermute ich dass das Gerät einen Hex String erwartet und nicht eine Folge von verschieden großen Bytes

Mr. Zet schrieb am 24.11.2010 um 11:42

Äh, ein Byte ist immer gleich groß
Ein "variabel großer Hex String" ist nichts anderes als eine Folge von Bytes

@ DKCH, nein, tut es nicht, wenn du einen String "02" hast, dann liefert dir getBytes() 0x30, 0x32; was er braucht ist aber 0x0, 0x2

Anders formuliert: Er braucht nicht den ASCII Code vom Zeichen "0" sondern das Zeichen mit ASCII Code 0!

djonny schrieb am 24.11.2010 um 11:56

ok mit dem byte immer gleich groß hast recht ;-)

allerdings wenn ich mich jetzt nicht irre hat eine 2er Hex Gruppe nur 1 Byte und nicht 2 Byte?

also 255 = FF = 1111 1111 = 1 Byte?

edit://
Ist in in .net einfacher zu realisieren? ich hab kein Problem wenn ich eine andere Sprache einsetze es soll nur den sinn und zweck erfüllen

Mr. Zet schrieb am 24.11.2010 um 12:01

Ja das stimmt natürlich.

Aber dein Gerät (Ich nehm an das ist was älteres?) wird für Adressen, etc. ja sicherlich ganze Bytes nehmen und nicht half bytes, oder?

um nochmal sicher zu gehen:
Du schreibst, dass du "0201010203040506" übertragen willst
heißt das, dass du
0x02
0x01
0x01
0x02
etc.
übertragen willst oder brauchst du
0x00
0x02
0x00
0x01
0x00
0x01
0x00
0x02
etc.
?

@ .net und einfacher: du brauchst einfach keine 3rd party Addons/Packages/whatever für die serielle Schnittstelle, weil die .net die Klassen dafür einfach "out of the box" zur Verfügung stellt, aber die Problematik verschiedener Zeichencodierungen hast du dort genauso....

Hast du eigentlich genau vorgegebene Codes die zu übertragen sind, oder eher Nachrichten der Form
{STX}{Zieladresse}{Senderadresse}{Befehlnummer}{variabler Inhalt}{cheksum}{ETX}
?

Weil dann würd ich mir eine Methode basteln, der du nur den Inhalt und die Adressen übergibst (oder was du halt alles variabel brauchst) und die dir die Nachricht als ASCII String zusammenbaut und sendet.

DKCH schrieb am 24.11.2010 um 12:02

Zitat von Mr. Zet
Äh, ein Byte ist immer gleich groß
Ein "variabel großer Hex String" ist nichts anderes als eine Folge von Bytes

@ DKCH, nein, tut es nicht, wenn du einen String "02" hast, dann liefert dir getBytes() 0x30, 0x32; was er braucht ist aber 0x0, 0x2

Anders formuliert: Er braucht nicht den ASCII Code vom Zeichen "0" sondern das Zeichen mit ASCII Code 0!

naja, normalerweise liefert chr ja den ascii-code zu einem character, und wenn du mit input[i] (also zB '0') reingehst, kommst ja auch wieder 0x30 raus, oder?

aber gut, am stream gibts ja eh write(int) auch... im zweifel also mit einer maximal grauslichen schleife à la

Code:

for (int i=0; i<string.length();i++) {
			stream.write(Integer.valueOf(""+string.charAt(i)));
		}

drüber

djonny schrieb am 24.11.2010 um 12:07

Zitat von Mr. Zet
Ja das stimmt natürlich.

Aber dein Gerät (Ich nehm an das ist was älteres?) wird für Adressen, etc. ja sicherlich ganze Bytes nehmen und nicht half bytes, oder?

Das Gerät ist eigentlich was neues und arbeitet im Normalfall mit SPSen zusammen.

Ich kann einstellen ob die Adresse 1 Byte oder 2 Byte lang ist und an welcher stelle die Adresse steht

also mir sind alle anderen Daten egal bis auf die Daten im 2. Byte dort müssen Hex zahlen rauskommen

Mr. Zet schrieb am 24.11.2010 um 12:19

Uh, da gehts ab... Ich hab meinen obigen Post editiert während ihr da wieder gepostet habt!

Zitat von DKCH
naja, normalerweise liefert chr ja den ascii-code zu einem character, und wenn du mit input[i] (also zB '0') reingehst, kommst ja auch wieder 0x30 raus, oder?

Äh nein, aber darum hab ich ja auch geschrieben ich verwechsel sicher Java und vb.net sachen

In VB liefert "Chr(x)" den Character mit ASCII Code x
Wenn du den ASCII Code von "0" willst, brauchst du Asc("0")

Aber das bringt ihm ja nichts, weil er nicht den ASCII Code von "0" braucht, sondern damit ein Byte 0x00 übertragen wird, braucht er das ASCII Zeichen mit Code 0 also "NUL".

Daher war meine Idee, dass er den String umwandelt in (nicht lesbare) ASCII Zeichen und diesen umgebauten String dann raus schreibt-

also:
nachricht = convertToByteCode("0201010203040506")
outputStream.write(nachricht.getBytes());

Ists jetzt verständlicher, was ich meine?

djonny schrieb am 24.11.2010 um 12:35

Zitat von Mr. Zet
Hast du eigentlich genau vorgegebene Codes die zu übertragen sind, oder eher Nachrichten der Form
{STX}{Zieladresse}{Senderadresse}{Befehlnummer}{variabler Inhalt}{cheksum}{ETX}
?

Genau das ganze ist ein UniProtocoll das ich im Master Master, Master Slave mode fahren kann.

Allerdings brauch ich das ganze zum testen und es soll sich bei jeder Ausgabe die Zieladresse ändern.

Zitat von Mr. Zet
Du schreibst, dass du "0201010203040506" übertragen willst
heißt das, dass du
0x02
0x01
0x01
0x02
etc.

Wo jetzt in dem Fall
0x01 die Zieladresse ist

bei "020A010203040506"
0x02
0x0A = Zieladress
0x01
etc.

also wenn ich das jetzt richtig verstanden habe.

Müsste ich eine möglichkeit suchen wie ich in Java einen String in einen ByteCode convertieren kann und diesen dann über den Outputstream ausgeben?

DKCH schrieb am 24.11.2010 um 13:10

Zitat von Mr. Zet
Äh nein, aber darum hab ich ja auch geschrieben ich verwechsel sicher Java und vb.net sachen

In VB liefert "Chr(x)" den Character mit ASCII Code x
Wenn du den ASCII Code von "0" willst, brauchst du Asc("0")

ah, ok, dann versteh ichs

Byte.fromString(x, 16) liefert dir ein byte für einen hex-string
also "02" -> 2
"0A" -> 10
"01" -> 1
usw. die kannst du dir in ein byte[] zusammenstopfen und dann mit write rausschreiben

djonny schrieb am 25.11.2010 um 10:34

So bin gestern nicht mehr dazugekommen das zu testen

hab das heute testen wollen irgendwie nimmt er mir das fromString nicht an...

es wird andauernd unterwellt und ich bekomm diesen fehler
cannot find symbol
symbol: method fromString(java.lang.String,int)
location: class java.lang.Byte

leider finde ich in google nichts brauchbares

murcielago schrieb am 25.11.2010 um 10:42

Byte.valueOf is die richtige.

DKCH schrieb am 25.11.2010 um 10:42

sorry, valueOf heissts natürlich (http://download.oracle.com/javase/1...te.html#valueOf(java.lang.String) - wie komm ich auf fromString?! sakra, das alter...

meepmeep schrieb am 25.11.2010 um 10:51

Byte hat auch einen Konstruktor für String.
Byte b = new Byte("F");

wenn er dir die "cannot find symbol" meldung bringt, will er dir damit sagen dass das objekt eine solche methode nicht hat. kA welche IDE du verwendest (wahrscheinlich eclipse?!), aber es wäre ratsam dich mit der code completion vertraut zu machen.

djonny schrieb am 25.11.2010 um 11:52

Danke das funktioniert

jetzt habe ich nur noch ein Problem, da ich noch recht neu in der Materie bin

ich hab mir jetzt das Byte so ausgeben lassen:

Byte testausgabe = Byte.valueOf(teststring, 16);
sendeSerialPort(testausgabe);

das klappt auch wunderbar nur wie kann ich das Byte jetzt erweitern bei einem String würd ich ja einfach Byte testausgabe = "02"+Byte.valueOf(teststring, 16)+"dummydata";

machen aber wie geht das bei einem Byte?

edit:// Ich verwende Netbeans und bin gerade erst dabei Java zu lernen, haben vorher in der Schule C++ gemacht aber allerdings nur sowas wie schleifen und if/else, switch/case bzw. Anwendungen die niemand braucht wie gib x beliebig Sterne aus...

pinkey schrieb am 25.11.2010 um 12:18

schleife das solang den string in byte umwandelt u. schickt bis der string aus is