Costruiamo un visualizzatore per 4 sonde EGT??

[Fabius72]

Nel frattempo (col caricamento dei caratteri speciali non sono in grado di andare avanti), ho visto che con analogWrite si può far funzionare un ingresso analogico come uscita digitale. Ne parlavamo un po' di post fa.
Ho fatto alcune prove e l'uscita che ha un range 0-255 se l'imposto da 127 in giù l'uscita è a livello logico bassa, mentre da 128 in su è alta.
es: analogWrite(A5, 128); e su A5 avrò 5v

Per curiosità, ho quindi provato a vedere cosa succedeva se si spostassero dalle digitali alle analogiche (dichiarate essere uscite con pinMode (A5, OUTPUT);) i collegamenti dei 4 segnali del display.
Cacchio, funziona! Mi stupiscono sempre di più la versatilità e le potenzialità di questo oggettino!!!

Ho voluto fare questa prova, perchè mi piacerebbe avere a disposizione il bus I2C che funziona con 2 di quelle 4 porte digitali che erano connesse al display.
In questo modo piloto il display con 2 porte digitali e le altre 2 analogiche:
LiquidCrystal lcd(12,11,A5,A4,3,2);
(11,12 e 13 saranno destinati invece alle comunicazioni ISP col modulo SD e con i 4 max che leggono le EGT)

I2C:
porta digitale 4 = SDA
porta digitale 5 = SCL

Voglio intanto sfruttarlo per metterci un RTC e poter finalmente loggare e visualizzare sul display anche giorno e ora.
Poi se riuscissi anche a metterci un GPS, avrei modo di calcolare il consumo istantaneo in km/l leggendo gli RPM e i 4 PW, ora che conosco con precisione i dead time.

Enri, quale RTC avete usato per la V4?


Ho inoltre avuto uno scambio di mail con Wesley Clark ed è stato così gentile e disponibile da modificare quella parte del suo codice per adattarlo alla MS2!

Questo, come esempio per leggere gli RPM. Ora ragioniamo! Una cosa semplice così, intendevo io...
Me l'ha mandato stanotte, ora lo provo!!

//code begins

byte inByte = 0;
int rpm = 0;
Serial.write("A"); // calling data from megasquirt. Array of 153 bytes to be received
if (Serial.available() > 0)
{
while(index < 154) // array is from 0 - 153
{
inByte = Serial.read(); //reading in one byte of data
inData[index] = (inByte); // storing data into the array
if(index == 6){ //checking to see where in the array the code is and setting a value based on the byte

rpm = inByte; // setting the rpm value to the 7th byte (since it's the 6th index)
}
index++; // moving to the next byte
}
inData[index] = '\0'; // Null terminate the strinG
}

delay(100);
}

[masterx81]

la v4 usa un chip microchip perchè la microchip offre i samples... Ma puoi usare i classici ds1337

[vitoos]

Potresti usare anche un ds1624 per loggare la temperatura esterna, funziona via i2c e quindi non perdi nessun pin

[Fabius72]

Temperatura esterna sarebbe anche utile, così potrei confrontarla col MAT (o IAT che dir si voglia) e vedere quanta differenza c'è nelle varie condizioni, ma il problema è che non saprei dove mettere il sensore nella moto... che non sia influenzato dal calore del sole che d'estate ci batte, o dal calore che sale dal motore.
Visto il costo irrisorio, penso che adatterò questo

http://www.robot-italy.com/it/grove-rtc.html

visto che devo ordinare su quel sito anche i convertitori di livello logico 3.3-5V sia per i 4 max per le egt, sia per il modulo SD che mi è già arrivato (le SD lavorano a 3,3v mentre i segnali in uscita da arduino sono a 5v)

Detto questo, ho studiato e testato il codice che mi ha mandato Clark e non può funzionare, visto che gli RPM derivano dalla somma di 2 valori a 8bit, ma con quel codice ne vengono presi solo 8 alla volta (un numero solo dalla stringa seriale).
Dovrei quindi fare due letture sequenziali, ma come si sommano 2 valori a 8 bit per averne uno solo a 16 per potergli attribuire il nome RPM??


EDIT: Penso d'aver trovato quel che fa al caso mio:

Serial.readBytes(buffer, length)

buffer: the buffer to store the bytes in (char[] or byte[])
length : the number of bytes to read (int)

[PierGSi]

L'ottava riga è quella destinata all'uso come cursore, ma a noi questo non importa, per cui si può illuminare anche quel pixel?

Anzichè cosi

//LOCAZIONE numero 1

lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(0); //nulla


così:

//LOCAZIONE numero 1

lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(16); //una tacca
lcd_write(16); //una tacca

Dico bene?

Credo di si

Poi, cercando di rendere comprensibile il codice al compilatore di arduino, ho bisogno di "tradurre" questi:

- LCD_RS (EDIT: è del display ed è connesso al pin 12 di arduino e va dichiarato)
- PORTA
- LCD_STROBE
- lcd_write
- lcd_putch

(Il codice si ritrova in fondo alla pagina 4 di questo thread)

Grazie

#define LCD_STROBE (LCD_EN = 1,LCD_EN=0);


STROBE alza-abbassa il pin EN per caricare quel che hai messo sul bus...lcd_write carica il byte nel display, con il pin RS basso (dato).
lcd_putch carica il byte nel display con il pin RS alto (carattere da scrivere).

PORTA è la PORT 'A,' PORTA=0x02 significa mettere 0x02 sul bus del display, ovviamente perche' il mio è connesso alla PORTA...

Se leggi il datasheet del controller HD44780 è tutto spiegato per filo e per segno.

Detto questo, ho studiato e testato il codice che mi ha mandato Clark e non può funzionare, visto che gli RPM derivano dalla somma di 2 valori a 8bit, ma con quel codice ne vengono presi solo 8 alla volta (un numero solo dalla stringa seriale).
Dovrei quindi fare due letture sequenziali, ma come si sommano 2 valori a 8 bit per averne uno solo a 16 per potergli attribuire il nome RPM??

volatile unsigned int risultato16bit;
volatile unsigned char 8bitmenosignificativi=0xFA;
volatile unsigned char 8bitpiusignificativi=0x10;



risultato16bit=8bitmenosignificativi;
risultato16bit=risultato16bit+(8bitpiusignificativi<<8);

//risultato16bit sara' uguale a 0x10FA

Sempre se ho ben capito...

Certo che quelle librerie già pronte sono belle perche' in poco tempo si riesce ad ottenere un qualcosa di funzionante, ma non è che siano granche' didattiche...

[masterx81]

Certo che quelle librerie già pronte sono belle perche' in poco tempo si riesce ad ottenere un qualcosa di funzionante, ma non è che siano granche' didattiche...

Straquoto...
Pero' ti butta in tempo 0 nel mondo dei micro...

[Fabius72]

Straquoto entrambi

Una settimana fa non ne sapevo proprio nulla e ora ci sono dentro di brutto, però il C non lo conosco e sto impazzendo.
Tra l'altro il compilatore non mi aiuta affatto.
Spesso dice cose assurde che non c'entrano con la risoluzione del problema, ma soprattutto non dice in quale punto del codice ha trovato qualcosa che non va! E io non ne so abbastanza da capirlo da solo...

Il compilatore che usavo in TurboPascal un quarto di secolo fa, mostrava chiaramente il punto incriminato e dava spiegazioni corrette per la risoluzione del problema!

Per favore, avete qualche testo da consigliarmi?
Io ho comprato "Programmazione in C" della Apogeo, ma viene usato un linguaggio un po' troppo ostico, e più che voler aiutare il principiante, sembra che abbiano preferito sfoggiare le loro conoscenze divine...

[PierGSi]

Il compilatore che usavo in TurboPascal un quarto di secolo fa, mostrava chiaramente il punto incriminato e dava spiegazioni corrette per la risoluzione del problema!

Tutti i compilatori dovrebbero tipo di errore e riga, mi pare strano...

Per favore, avete qualche testo da consigliarmi?
Io ho comprato "Programmazione in C" della Apogeo, ma viene usato un linguaggio un po' troppo ostico, e più che voler aiutare il principiante, sembra che abbiano preferito sfoggiare le loro conoscenze divine...

cerca TrickyC con google, e' disponibile sia in pdf che in html online.

[Fabius72]

Tutti i compilatori dovrebbero tipo di errore e riga, mi pare strano...

Il numero di riga c'è, ma raramente coincide con la posizione dove si trova l'errore.
Mi capita anche che venga segnalata una riga nel bel mezzo di 5 righe "nascoste"
/*
...
...
...
... (l'errore è qua!)
...
*/

Sembra quasi che il compilatore salti le righe di commento e quindi i numeri di riga (del compilatore e della parte dove si scrive il codice) si sfalsano.

Un altro esempio, mi veniva segnalato un errore in void loop(), mentre andava tolta e messa "fuori" una riga dal void setup().
Ma sicuramente qua il problema è mio, che scrivo male il codice e non ho confidenza con i messaggi di errore del compilatore.

cerca TrickyC con google, e' disponibile sia in pdf che in html online.

Trovato e scaricato.
Mille grazie!


Ho provato il tuo modo di mettere in un byte da 16bit due byte da 8bit, ma continuo ad avere numeri strani.

Ho provato quest'altro modo:
byte PrimoByte = 0;
byte SecondoByte = 0;
unsigned int SEC = 0; // secondi (i primi due byte)

PrimoByte = mySerial.read();
SecondoByte = mySerial.read();
SEC = word(PrimoByte, SecondoByte);

Stesso risultato.
Comincio a pensare che la stringa che mi arriva dalla MS non sia del "formato" che cerco di leggere.
Mi spiego:
Dal miniterminal di tunerstudio, inviando i comandi S e Q mi arrivano dati in formato ASCII, mentre se voglio vedere la stringa che arriva col comando A, devo commutare la visualizzazione su "decimal", altrimenti vedo solo caratteri insignificanti.
Invece su HyperTerminal in win non riesco ad avere la stringa in decimal, ma solo a caratteri ASCII

Pomeriggio torno sul caricamento dei caratteri nel display e provo a capire bene quel che mi hai spiegato.

[Fabius72]

Risolto il problema del compilatore.
In linux avevo installato la versione dell'IDE che è nei repository, ma ho scoperto essercene una più aggiornata, che è la 1.0.5 e l'ho installata.
Non solo i numeri di riga adesso corrispondono, ma i messaggi di errore hanno più senso di prima e addirittura viene evidenziata con una barra arancione la riga incriminata.
Ora ci siamo

Tornando a noi...

Pier, ho risolto i problemi che avevo col codice che hai postato, solo che i caratteri visualizzati erano così (non ne ho capito il motivo) :

DSC_1129.JPG

Allora ho cercato un po' in rete e ho trovato l'apposito comando:
createChar()

http://arduino.cc/en/Reference/LiquidCrystalCreateChar

con cui ho caricato un nuovo set di caratteri per avere 4 barre che vanno in senso negativo e 4 in senso positivo. In totale 8, il massimo ammissibile (locazioni 0-7).
Il carattere vuoto sarà " ", mentre visualizzo il pieno (Block) tramite il suo codice che è B11111111;

con lcd.write(Block);

DSC_1131.JPG

Poi sono andato avanti col codice (grazie al grande Pier che mi ha fornito un'ottima base su cui lavorare), anche se per tentativi, visto che la sintassi mi sta facendo impazzire hehehe.
La barra in alto la muovo con un potenziometro.
Nella seconda riga c'è "lo zero" in centro al display e corrisponderà alla temperatura del cilindro n.2 a cui faranno riferimento le visualizzazioni degli altri 3 cilindri.
Terza e quarta riga saranno i cilindri 3 e 4, ma adesso le rispettive porte analogiche leggono una resistenza il 3 e 5v il 4.
Intanto che aspetto che mi arrivi il materiale per montare i 4 max, il modulo SD e l'RTC...



Da capire se far corrispondere 5°C/tacca come nel video, così si ottengono variazioni di +-250° rispetto al cilindro 2 di riferimento, oppure è meglio avere più dettaglio con 1°C/tacca con cui si ottengono +-50° di escursione.
Qual è meglio?