leggere e visualizzare temperature pc

[dr_jekyll]

Beh ti capisco. Ma personalmente sono abbastanza pigro ed invece di reinventare la ruota preferisco appoggiarmi su un linguaggio pieno di librerie, si trova di tutto. Poi power shell su un sistema gnu/linux.... insomma 


Lo Zen di Python, di Tim Peters

Bello è meglio che brutto.
Esplicito è meglio che implicito.
Semplice è meglio che complesso.
Complesso è meglio che complicato.
Lineare è meglio che nidificato.
Sparso è meglio che denso.
La leggibilità conta.
I casi speciali non sono abbastanza speciali per infrangere le regole.
Anche se la praticità batte la purezza.
Gli errori non dovrebbero mai passare sotto silenzio.
A meno che non vengano esplicitamente messi a tacere.
In caso di ambiguità, rifiuta la tentazione di indovinare.
Ci dovrebbe essere un modo ovvio -- e preferibilmente uno solo -- di fare le cose.
Anche se questo modo potrebbe non essere ovvio da subito, a meno che non siate olandesi.
Ora è meglio che mai.
Sebbene mai sia spesso meglio che *proprio adesso*.
Se l'implementazione è difficile da spiegare, l'idea è pessima.
Se l'implementazione è facile da spiegare, l'idea può essere buona.
I namespace sono una grandiosa idea, usiamoli il più possibile!

[krypton18]

Beh ti capisco. Ma personalmente sono abbastanza pigro ed invece di reinventare la ruota preferisco appoggiarmi su un linguaggio pieno di librerie, si trova di tutto.

Beh non è proprio reinventare la ruota. Se si utilizzano librerie esterne fatte da altri e comandi di shell si ha comunque riutilizzo di codice e a parte il richiamo degli stessi, cosa che bisognerebbe fare anche in python visto che negli esempi ho letto che su piattaforma Windows ci si deve appoggiare alla solita libreria esterna di openhardwaremonitor, non ci si inventa granché.
La mia puntalizzazione riguarda quest'applicazione specifica, ma in generale è vero che python dispone sicuramente di molte più librerie se confrontato a powershell.

[Beppos]

La scimmia di passare a python mi era già passata per la testa (soprattutto per windows).
Per ora il dilemma è questo: dato il seguente codice

Code: [Select]

#!/bin/bash
while :  ; do
    cpuTemp=`sensors | grep '^Physical'| cut -f2 -d"+" | cut -f1 -d"."`
    gpuTemp=`nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader`
    echo ${cpuTemp} >/dev/ttyUSB0
    echo ${gpuTemp} >/dev/ttyUSB0
    sleep 1s
done

leggo ed invio due numeri da due cifre l'uno (fisicamente non posso scendere sotto i 20 gradi medi della temperatura ambiente e a 100 la cpu va in stallo). Qualcuno sarebbe così gentile da scrivere uno strech per arduino uno che legga i due numeri e li salvi in due variabili? Il resto dell'implementazione la posso fare anche da solo, ma per la comunicazione seriale sono negato. 

[krypton18]

La scimmia di passare a python mi era già passata per la testa (soprattutto per windows).
Per ora il dilemma è questo: dato il seguente codice

Code: [Select]

#!/bin/bash
while :  ; do
    cpuTemp=`sensors | grep '^Physical'| cut -f2 -d"+" | cut -f1 -d"."`
    gpuTemp=`nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader`
    echo ${cpuTemp} >/dev/ttyUSB0
    echo ${gpuTemp} >/dev/ttyUSB0
    sleep 1s
done

leggo ed invio due numeri da due cifre l'uno (fisicamente non posso scendere sotto i 20 gradi medi della temperatura ambiente e a 100 la cpu va in stallo).

Occhio che nello script manca la definizione della velocità di trasmissione:
 stty -F /dev/ttyUSB0 speed 9600 cs8 -cstopb -parenb raw

Qualcuno sarebbe così gentile da scrivere uno strech per arduino uno che legga i due numeri e li salvi in due variabili? Il resto dell'implementazione la posso fare anche da solo, ma per la comunicazione seriale sono negato.

Non è questione di essere negati a fare qualcosa ma di provare a farla di testa propria, ci sono n-mila esempi sparsi sulla rete su come impostare una comunicazione seriale con Arduino e basta veramente poco per adattarli. Se poi ci sono problemi, perché il programma funziona parzialmente, siamo qui per aiutarti e darti delle dritte. In qualche mio precedente post delle ultime settimane, ho già trattato l'argomento della seriale. Prova a darci un'occhiata.

[Beppos]

Occhio che nello script manca la definizione della velocità di trasmissione:
 stty -F /dev/ttyUSB0 speed 9600 cs8 -cstopb -parenb rawNon è questione di essere negati a fare qualcosa ma di provare a farla di testa propria, ci sono n-mila esempi sparsi sulla rete su come impostare una comunicazione seriale con Arduino e basta veramente poco per adattarli. Se poi ci sono problemi, perché il programma funziona parzialmente, siamo qui per aiutarti e darti delle dritte. In qualche mio precedente post delle ultime settimane, ho già trattato l'argomento della seriale. Prova a darci un'occhiata.

Devo dichiarare la velocità una volta sola corretto? Quindi la metterei come prima riga prima del ciclo while.
Facendo questo ho la certezza che i dati vengano inviati in modo corretto? In questo modo so, che se non leggo i dati il problema è sicuramente nello strech.
precisamente come vengono interpretati i byte inviati da seriale? voglio dire: ipotizziamo di inviare "30", questo è considerato un numero (intero) oppure una stringa?
magari potreste darmi qualche link a del materiale che spieghi bene l'argomento?

grazie per la pazienza e l'aiuto che mi state offrendo 

[krypton18]

Devo dichiarare la velocità una volta sola corretto? Quindi la metterei come prima riga prima del ciclo while.

Sì confermo. Per fare un paragone, è come se dovessi scrivere quell'istruzione nella funzione setup di Arduino.

Facendo questo ho la certezza che i dati vengano inviati in modo corretto? In questo modo so, che se non leggo i dati il problema è sicuramente nello strech.

Sì, la teoria dice questo se le impostazioni di comunicazione sono identiche per entrambe le parti. Tieni presente però che errori di trasmissione possono avvenire comunque, difatti le opzioni "controllo di parità" e "controlli XON/XOFF", abilitabili nell'ambito di quell'istruzione che stiamo discutendo, sono state introdotte apposta come sistemi per rilevarli. Le cause possono essere disparate: cavo scadente (poco rame, contatti ossidati, falsi contatti), porte USB mezze guaste, rumore elettrico generato da una delle due parti che si propaga sul mezzo trasmissivo, interferenze elettromagnetiche esterne e chissà quante altre possibili "sfighe".
C'è una vasta letteratura sui controlli degli errori di comunicazione. Per non complicarci la vita per ora non abiliterei nessun controllo.

magari potreste darmi qualche link a del materiale che spieghi bene l'argomento?

Il primo link da leggere è la reference di Arduino: https://www.arduino.cc/reference/en/language/functions/communication/serial/
Leggiti questo link per interpretare le opzioni del comando stty:
https://www.esrl.noaa.gov/gmd/dv/hats/cats/stations/qnxman/stty.html

precisamente come vengono interpretati i byte inviati da seriale? voglio dire: ipotizziamo di inviare "30", questo è considerato un numero (intero) oppure una stringa?

Dipende dalla funzione di Arduino che usi per decodificarli; il caso più comune è quello di interpretarli come caratteri codificati in codice ASCII. Altrimenti, utilizzando l'appropriata funzione, si possono interpretare come byte, quindi una sorta di valore intero a cui sei tu che attribuisci un particolare significato.
Se dovessi farlo io un programma simile approfondirei l'uso delle due seguenti funzioni:
Serial.readBytesUntil()
Serial.readStringUntil()
Esse consentono al ricevitore, Arduino, di sapere tramite un carattere terminatore, di solito si usa il carriage return (\r), quando la trasmissione del dato corrente è conclusa e quindi si riesce a stabilire una sincronia fra le due parti coinvolte.
Oppure c'è anche questa funzione che legge direttamente un intero la Serial.parseInt(), ma alla sincronizzazione devi pensarci tu.

[zoomx]

Lo Zen di Python, di Tim Peters

Bello è meglio che brutto.
Esplicito è meglio che implicito.
Semplice è meglio che complesso.
....... ......... ..........

XKCD!

[dr_jekyll]

XKCD!

A modo loro, rientrerà nel "complesso è meglio che complicato"

[zoomx]

Sicuramente!