Torna indietro   Hardware Upgrade Forum > Software > Programmazione

NZXT H9 Flow RGB+, Kraken Elite 420 e F140X: abbiamo provato il tris d'assi di NZXT
NZXT H9 Flow RGB+, Kraken Elite 420 e F140X: abbiamo provato il tris d'assi di NZXT
Nelle ultime settimane abbiamo provato tre delle proposte top di gamma di NZXT nelle categorie case, dissipatori e ventole. Rispettivamente, parliamo dell'H9 Flow RGB+, Kraken Elite 420 e F140X. Si tratta, chiaramente, di prodotti di fascia alta che si rivolgono agli utenti DIY che desiderano il massimo per la propria build. Tuttavia, mentre i primi due dispositivi mantengono questa direzione, le ventole purtroppo hanno mostrato qualche tallone d'Achille di troppo
ASUS ROG Swift OLED PG34WCDN recensione: il primo QD-OLED RGB da 360 Hz
ASUS ROG Swift OLED PG34WCDN recensione: il primo QD-OLED RGB da 360 Hz
ASUS ROG Swift OLED PG34WCDN è il primo monitor gaming con pannello QD-OLED Gen 5 a layout RGB Stripe Pixel e 360 Hz su 34 pollici: lo abbiamo misurato con sonde colorimetriche e NVIDIA LDAT. Ecco tutti i dati
Recensione Nothing Phone (4a) Pro: finalmente in alluminio, ma dal design sempre unico
Recensione Nothing Phone (4a) Pro: finalmente in alluminio, ma dal design sempre unico
Nothing Phone (4a) Pro cambia pelle: l'alluminio unibody sostituisce la trasparenza integrale, portando una solidità inedita. Sotto il cofano troviamo uno Snapdragon 7 Gen 4 che spinge forte, mentre il display è quasi da top dig amma. Con un teleobiettivo 3.5x e la Glyph Matrix evoluta, è la prova di maturità di Carl Pei. C'è qualche compromesso, ma a 499EUR la sostanza hardware e la sua unicità lo rendono un buon "flagship killer" in salsa 2026
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 22-10-2012, 20:22   #1
stefanoxjx
Senior Member
 
L'Avatar di stefanoxjx
 
Iscritto dal: Jul 2002
Città: Padova
Messaggi: 4245
[C]Dove sto sbagliando?

Ciao a tutti, dopo qualche anno di inattività, sto sviluppando un programma in C, però mi sono arenato in un punto e non riesco a capire dove sto sbagliando

Praticamente, devo leggere da un dispositivo seriale dei dati, ogni pacchetto inizia con 0x7e e finisce con 0x7e ed è lungo 11 byte HEADER compresi.
Il secondo byte del pacchetto (0xfe, 0xfd) definisce il tipo di dato ricevuto.
Questo è il programma:
Codice:
void	ParseAnalog(void);
void	ParseHUB(void);

#define HEADER	'\x7e'
#define ANALOG	'\xfe'
#define	HUB	    '\xfd'
//#define	HUB	'\x5e'
#define PACKETSIZE  11

int  port;
unsigned	int 	packet[PACKETSIZE+1];

int main(void)
{
    int 	i=0;
    unsigned char buf[2];

    port=ComOpen();

    while(1)
    {
        buf[0]=0;
        if(read(port,buf, 1) > 0)
        {
//            printf("%d\n",i);
 
            if(i==10 && buf[0]==HEADER && packet[0]==HEADER)
            {

                if((int)packet[1]==(int)ANALOG)
                    printf("ParseAnalog\n");
                    //ParseAnalog();
                //printf("i=10\n");
                //if(packet[1]==ANALOG)
                    //ParseAnalog();
                //if(packet[1]==HUB)
                    //ParseHUB();
            }

            if(buf[0]==HEADER && i < PACKETSIZE) i=0;

            packet[i++]=buf[0];

            if(i >= PACKETSIZE) i=0;
        }
    }
}

void ParseAnalog(void)
{
    printf("Parte analogica\n");
}

void ParseHUB(void)
{
    printf ("**************** DATI HUB ***************\n");
}
Il problema sta nella parte in grassetto.
Praticamente, l'istruzione dopo if((int)packet[1]==(int)ANALOG) non viene mai eseguito nonostante packet[1] sia uguale ad ANALOG (0xfe).
Stessa cosa dicasi per le altre righe commentate che al momento sono così perchè sto cercando di capire il problema.
In cosa sto sbagliando?
Pensavo fosse un problema di casting, ma come potete vedere ho forzato le variabili ad INT e quindi anche il casting non può essere.

Grazie.
Ciao.
stefanoxjx è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2012, 21:00   #2
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Perchè (int)packet[1]?? Si tratta di 8 bit, quindi il cast va fatto con char.
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2012, 21:06   #3
stefanoxjx
Senior Member
 
L'Avatar di stefanoxjx
 
Iscritto dal: Jul 2002
Città: Padova
Messaggi: 4245
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Perchè (int)packet[1]?? Si tratta di 8 bit, quindi il cast va fatto con char.
Forse ricordo male, ma "(int)packet[1]" non dovrebbe convertire char in int?
Sono circa 10 anni che non programmo, quindi un po' qualcosa l'ho perso
Tra le altre cose, nel frattempo ho scoperto il mio problema.
Era "#define ANALOG '\xfe'" che una volta printato ho visto che ritornava -2.
Probabilmente sempre per lo stesso problema del quale a questo punto ho probabilmente un po' di confusione.
stefanoxjx è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2012, 21:15   #4
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da stefanoxjx Guarda i messaggi
Forse ricordo male, ma "(int)packet[1]" non dovrebbe convertire char in int?
Si.

Quote:
Originariamente inviato da stefanoxjx Guarda i messaggi
Era "#define ANALOG '\xfe'" che una volta printato ho visto che ritornava -2.
Probabilmente sempre per lo stesso problema del quale a questo punto ho probabilmente un po' di confusione.
Un problema di segni. Quindi (unsigned int) risolve.
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 22-10-2012, 22:44   #5
stefanoxjx
Senior Member
 
L'Avatar di stefanoxjx
 
Iscritto dal: Jul 2002
Città: Padova
Messaggi: 4245
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Si.

Un problema di segni. Quindi (unsigned int) risolve.
Negativo, (unsigned int) restituisce 4294967294, mentre (unsigned char) risolve
Grazie dell'aiuto
stefanoxjx è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2012, 07:27   #6
WarDuck
Senior Member
 
L'Avatar di WarDuck
 
Iscritto dal: May 2001
Messaggi: 12966
La cosa migliore che puoi fare quando hai un buffer il cui contenuto è più o meno fissato è definirti una struttura che descrive il buffer (quantomeno la parte fissa), e poi fare un unico cast con quello:

Codice:
struct my_buff
{
   int a;
   int b;
   char c;
   int len;
   char data[1]; // segnaposto per i dati
};

int main(void)
{
    // retreive buffer

    struct my_buff* packet = (struct my_buff*) buffer;

    // packet->a;
    // packet->b;
    // packet->c;

}
WarDuck è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2012, 08:53   #7
stefanoxjx
Senior Member
 
L'Avatar di stefanoxjx
 
Iscritto dal: Jul 2002
Città: Padova
Messaggi: 4245
Quote:
Originariamente inviato da WarDuck Guarda i messaggi
La cosa migliore che puoi fare quando hai un buffer il cui contenuto è più o meno fissato è definirti una struttura che descrive il buffer (quantomeno la parte fissa), e poi fare un unico cast con quello:

Codice:
struct my_buff
{
   int a;
   int b;
   char c;
   int len;
   char data[1]; // segnaposto per i dati
};

int main(void)
{
    // retreive buffer

    struct my_buff* packet = (struct my_buff*) buffer;

    // packet->a;
    // packet->b;
    // packet->c;

}
Grazie, questa è una buona dritta.
Devo però ripassarmi le struct perchè mi ero completamente dimenticato della loro esistenza
stefanoxjx è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2012, 08:55   #8
enaud
Senior Member
 
L'Avatar di enaud
 
Iscritto dal: Sep 2003
Messaggi: 847
ad occhio, non ho letto le risposte, prova ad usare unsigned char invece di int.
__________________
"VIVERE ARDENDO E NON SENTIRE IL MALE"
enaud è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2012, 09:05   #9
stefanoxjx
Senior Member
 
L'Avatar di stefanoxjx
 
Iscritto dal: Jul 2002
Città: Padova
Messaggi: 4245
Quote:
Originariamente inviato da enaud Guarda i messaggi
ad occhio, non ho letto le risposte, prova ad usare unsigned char invece di int.
Si si, hai azzeccato la risposta.
Se leggi quanto scritto prima vedrai che confermo che unsigned char risolve
stefanoxjx è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2012, 09:27   #10
marco.r
Senior Member
 
Iscritto dal: Dec 2005
Città: Istanbul
Messaggi: 1817
Quote:
Originariamente inviato da WarDuck Guarda i messaggi
La cosa migliore che puoi fare quando hai un buffer il cui contenuto è più o meno fissato è definirti una struttura che descrive il buffer (quantomeno la parte fissa), e poi fare un unico cast con quello:

Codice:
struct my_buff
{
   int a;
   int b;
   char c;
   int len;
   char data[1]; // segnaposto per i dati
};

int main(void)
{
    // retreive buffer

    struct my_buff* packet = (struct my_buff*) buffer;

    // packet->a;
    // packet->b;
    // packet->c;

}
Occhio che cosi' il codice diventa non portabile e, soprattutto, non funziona se viene scritto in una architettura e letto in un'altra.
Questo perche' a priori non sai che allineamento viene usato e quindi la dimensione di my_buff.
Senza contare che manco sizeof(int) e' definita.
Serializzare e deserializzare direttamente delle strutture non e' una buona pratica, a meno che non si tratti di una cosa interna al programma (e.g. parti diverse di un sistema operativo che comunicano tra di loro).
In ogni caso anche un array di int e' sbagliato (per il discorso di sizeof(int) detto piu' sopra).
Meglio usare un array di unsigned char, nella struttura dati usare possibilmente delle dimensioni esplicite (int32_t ad esempio) ed infine verficare il byte ordering dei numeri letti, usando ntohl e compagnia (eventualmente "invertendo" l'ordine prima, se on the wire non sono in network order).
__________________
One of the conclusions that we reached was that the "object" need not be a primitive notion in a programming language; one can build objects and their behaviour from little more than assignable value cells and good old lambda expressions. —Guy Steele
marco.r è offline   Rispondi citando il messaggio o parte di esso
Old 23-10-2012, 18:51   #11
WarDuck
Senior Member
 
L'Avatar di WarDuck
 
Iscritto dal: May 2001
Messaggi: 12966
Quote:
Originariamente inviato da marco.r Guarda i messaggi
Occhio che cosi' il codice diventa non portabile e, soprattutto, non funziona se viene scritto in una architettura e letto in un'altra.
Questo perche' a priori non sai che allineamento viene usato e quindi la dimensione di my_buff.
L'allineamento può essere indicato con le direttive del compilatore, comunque se non erro ci dovrebbero essere una serie di regole comuni al linguaggio C o comunque legate alla specifica implementazione del compilatore.

Certo se lavori ad un progetto cross-platform bisogna valutare questi aspetti, ma IMHO risulta enormemente più comodo lavorare in quel modo, chiaramente con la dovuta accortezza.

Anche perché una volta preparata la struttura ad esempio di un protocollo (se è a campi fissi), hai automaticamente accesso a tutti i campi.

Quote:
Originariamente inviato da marco.r Guarda i messaggi
Senza contare che manco sizeof(int) e' definita.
Serializzare e deserializzare direttamente delle strutture non e' una buona pratica, a meno che non si tratti di una cosa interna al programma (e.g. parti diverse di un sistema operativo che comunicano tra di loro).
In ogni caso anche un array di int e' sbagliato (per il discorso di sizeof(int) detto piu' sopra).
Meglio usare un array di unsigned char, nella struttura dati usare possibilmente delle dimensioni esplicite (int32_t ad esempio) ed infine verficare il byte ordering dei numeri letti, usando ntohl e compagnia (eventualmente "invertendo" l'ordine prima, se on the wire non sono in network order).
Il mio era un esempio per fargli vedere la potenzialità della tecnica, è sicuramente consigliabile usare i tipi definiti in stdint.h.

Riguardo al byte ordering bisogna vedere se questo può essere un problema o meno, a seconda dei casi.
WarDuck è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


NZXT H9 Flow RGB+, Kraken Elite 420 e F140X: abbiamo provato il tris d'assi di NZXT NZXT H9 Flow RGB+, Kraken Elite 420 e F140X: abb...
ASUS ROG Swift OLED PG34WCDN recensione: il primo QD-OLED RGB da 360 Hz ASUS ROG Swift OLED PG34WCDN recensione: il prim...
Recensione Nothing Phone (4a) Pro: finalmente in alluminio, ma dal design sempre unico Recensione Nothing Phone (4a) Pro: finalmente in...
WoW: Midnight, Blizzard mette il primo, storico mattone per l'housing e molto altro WoW: Midnight, Blizzard mette il primo, storico ...
Ecovacs Goat O1200 LiDAR Pro: la prova del robot tagliaerba con tagliabordi integrato Ecovacs Goat O1200 LiDAR Pro: la prova del robot...
EK Waterblock si arrende agli aumenti, i...
Geekbench si aggiorna: tutti i test con ...
Per la prima volta un computer quantisti...
Telecamere Reolink 4K su Amazon: Wi-Fi 6...
Anthropic vuole farsi i chip da sola? Co...
Il fondatore di Framework: il personal c...
JBL Live Flex 3 a 129€ su Amazon: ANC ad...
Come un uomo ha costruito un'azienda da ...
Multe fino a 400 euro anche se hai pagat...
Tapo lancia una valanga di offerte su Am...
Little Snitch su Linux: finalmente dispo...
John Deere accetta un accordo da 99 mili...
Gli astronauti di Artemis II osservano i...
OpenAI lancia ChatGPT Pro da 100 dollari...
Allarme rosso: CPU-Z e HWMonitor, segnal...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 18:58.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v