Visualizzazione dei risultati da 1 a 4 su 4
  1. #1
    Utente di HTML.it
    Registrato dal
    May 2006
    Messaggi
    378

    [JAVA] lettura e scrittura su seriale

    Ciao a tutti vi chiedo aiuto per leggere da seriale.

    Ho recuperato la lista delle porte COM presenti nel pc ed effettuato la connessione alla porta che mi interessa....

    Avvio un thread in lettura sulla seriale che legge da un InputStream: questo è il codice

    Codice PHP:
    public void run(){
            
    String lettura "";
            
    byte[] readBuffer = new byte[50];
            
    System.out.println("AVVIO THREAD RICEZIONE: OK");
            while(
    esegui){
                try{
                    while (
    inputStream.available() > 0) {
                        
    int numBytes inputStream.read(readBuffer);
                        
    System.out.println("LETTI: " numBytes " " readBuffer.toString());
                        } 
                    }
                catch(
    Exception err){
                    
    System.out.println("ERRORE LETTURA SERIALE");
                    }
                }
            } 
    Il problema è che quando converto in stringa mi ritorna qualcosa del tipo: "[B@8813f2"

    sto sbagliando la conversione !?!??!


    p.s. il programma mi occupa la CPU al 100%, da cosa può dipendere ?? avvio il thread in questo modo:



    Codice PHP:
    // avvio thread lettura                        
                            
    readingThread = new ReadingThread(inputStream);
                            
    Thread thread = new Thread(readingThread);
                            
    thread.start(); 
    grazie...

  2. #2
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284

    Re: [JAVA] lettura e scrittura su seriale

    Originariamente inviato da bmw
    Il problema è che quando converto in stringa mi ritorna qualcosa del tipo: "[B@8813f2"

    sto sbagliando la conversione !?!??!
    Sì. Perché hai invocato toString() su un array. Gli array non ridefiniscono toString() ... rimane e viene usata la implementazione in Object, che fornisce quella stringa in quel formato (non potendo fare altro di più specifico).

    Se da un array di byte vuoi ottenere un String, non devi usare toString() ma usare uno dei costruttori di String che riceve un byte[]. Ma sopratutto devi tenere presente che quando si converte un String in sequenza di byte (o viceversa) bisogna anche tenere presente la questione del "charset". In quella tua sequenza di byte i caratteri con quale charset sono codificati? ASCII? UTF-8? ISO-8859-1? O uno dei vari "codepage"?

    Insomma, vedi i costruttori di String.

    Originariamente inviato da bmw
    p.s. il programma mi occupa la CPU al 100%, da cosa può dipendere ??
    La mia deduzione è che sia dovuto al ciclo in cui testi il risultato di available(). Questo metodo fornisce una "stima" di quanti byte si possono leggere senza che si blocchi per attendere i dati. In pratica quanti byte sono disponibili per poter essere letti subito, immediatamente.

    Visto che le seriali sono lente, il available() probabilmente ritorna spesso 0 e quindi il tuo codice è in continuo "loop" per attendere dati (= consuma CPU).

    No. Non usare available(), usa direttamente read(), che "sospende" il thread in attesa di dati se necessario (e non lo tiene occupato in loop inutili!).

    Ma c'è ancora un'altra cosa da notare. Tu hai un buffer fisso di 50 byte. Ok. Tu passi alla read() questo buffer ma la read() NON è detto che riempia sempre tutto il buffer. Morale della favola: devi sempre tenere in considerazione il valore di ritorno di read() perché esso ti dice quanti byte sono davvero quelli "utili" nel buffer.

    Ripeto che non so quale charset viene usato per codificare i caratteri che ricevi ma se il charset fosse uno di quelli multibyte sarebbe pure sbagliato prendere blocchetti di lunghezza arbitraria/sconosciuta (non sai quanti byte ritorna read()) e convertire ognuno in String. Perché rischi di spezzare una sequenza di più byte che codifica 1 singolo carattere. Se il charset è single-byte, andrebbe bene.

    Concludo dicendo che dovresti considerare di più di queste questioni.
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  3. #3
    Utente di HTML.it
    Registrato dal
    May 2006
    Messaggi
    378
    Ciao, grazie per l'aiuto, stasera provo a sistemare il codice...

    ..ti chiedo un altra cosa, è possibile utilizzare una DataInputStream al posto di un InputStream ??


    grazie ancora...


    p.s. come faccio a sapere la codifica ?? sto utilizzando i comandi AT su di un telefono cellulare...

  4. #4
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Originariamente inviato da bmw
    ti chiedo un altra cosa, è possibile utilizzare una DataInputStream al posto di un InputStream ??
    Certo, incapsuli il tuo InputStream dentro un DataInputStream. Però bisognerebbe vedere a cosa ti serve e oltretutto se davvero ti serve!
    L'obiettivo principale di DataInputStream è quello di permettere la lettura e la ricomposizione dai byte in modo facile di dati "primitivi" int, long, double, ecc.... tipicamente generati dalla controparte DataOutputStream.

    Originariamente inviato da bmw
    p.s. come faccio a sapere la codifica ?? sto utilizzando i comandi AT su di un telefono cellulare...
    Allora:
    a) Non credo proprio che ti serva DataInputStream e
    b) Credo che sia ASCII o al massimo uno dei charset single-byte (ISO-qualcosa) .... non me ne intendo dei comandi AT, purtroppo.
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.