Go Down

Topic: Topic permanente di programmazione newbie (Read 36740 times) previous topic - next topic

Michele Menniti


Non è che lo ignora, semplicemente esci dal ciclo do..while quando arriva un carattere giusto (corretto) poi però va a leggere un'altra volta dalla seriale (sbagliato): in questo modo memorizzi il carattere successivo. Hai provato col codice che ti ho messo nel 2° post?

Intanto vado a dormire, dopo 2 notti insonni causa influenza non ce la faccio più  :smiley-roll-blue:

certo che ho provato: se scrivo DF non dà segni di vita, se scrivo XX invece va avanti, ecco perché credo che invece lavori all'opposto. buonanotte, ne riparliamo domattina, non ti preoccupare, vado a riposare anch'io tra qualche minuto.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

BrainBooster

#331
Apr 06, 2012, 06:17 am Last Edit: Apr 06, 2012, 07:30 am by BrainBooster Reason: 1
allora prova così: ti crei un indice (i) e serbuffer diventa un array con i caratteri ricevuti
Code: [Select]

if (Serial.available() > 0) {  //ci sono dei caratteri sulla seriale
 r=Serial.read();
 if ((r>=48 && r<=57) || (r>=65 && r<=70) || (r>=97 && r<=102)) { //se sono interessanti
   serbuffer[i]=r;    //li mettiamo nell'array
i++; //e passiamo a riempire il posto successivo
 }
else{  //altrimenti
Serial.print("carattere non valido");  // se non sono caratteri interessanti lo notifichiamo con un messaggio (rimuovibile)
}
 }


il controllo lo farai sull'ultimo carattere di serbuffer che se diverso da zero= (buffer pieno di caratteri validi) e usabili.
cancellerai serbuffer dopo l'uso per prepararlo a ricevere nuovi dati.

Michele Menniti

Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Michele Menniti

Solo ora mi rendo conto che se invece del Terminal di Win qualcuno usasse il serial monitor sarebbe un problema, in quanto questo ha un buffer in cui si può scrivere il fuse e poi dare invio e a questo punto sarebbe problematico gestirlo. Ma la cosa più importante è che il progetto integrale prevede la tastiera esadecimale, quindi il problema poi si risolve da solo. :)

Ora chiudo lo sketch per il terminal ed inizio a lavorare alla versione per LCD 4x20, quindi il Topic sarà ancora molto attivo.....
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Michele Menniti

#334
Apr 07, 2012, 03:29 pm Last Edit: Apr 08, 2012, 11:04 am by Michele Menniti Reason: 1
Finito! seguendo i saggi consigli del buon Leo, maestro d'arte programmatoria XD, ho realizzato un semplice protocollo di comunicazione seriale tra due micro. In pratica uno è quello che gestisce tutta la programmazione HV e l'altro invece controlla il keypad esadecimale ed il display LCD, sono collegati col classico scambio tx1/rx2 e rx1/tx2; molto semplicemente ho usato 5 caratteri "speciali" per controllare il clear e il posizionamento del cursore, caratteri che nel firmware del master antepongo alle stringhe di testo inviate con Serial.print.... Qualche esempio:
1 - sul master inserisco il comando Serial.print("$menu principale"); - l'altro micro effettua un clear del display($) e poi fa apparire sulla prima riga la scritta "menu principale";

2 - sul master inserisco il comando Serial.print("$%scrittura"); - l'altro micro effettua un clear del display($), poi si posiziona sulla terza riga (%) e su questa scrive "scrittura";

Semplice e comodissimo! Ad onor del vero Leo mi aveva suggerito una cosa "un po'" più professionale, con tanto di inizio e fine trasmissione, ma era fuori dalla mia portata, mi è bastato aggiungere invece alla fine del mio mini-protocollo un controllo che bloccasse la maggior parte dei caratteri strani e ho risolto.

In tutto ciò un colpo di coda della Legge di Murphy: il tx del micro del display disturbava (tanto per cambiare) la programmazione HV, in quanto sul master purtroppo sono usate anche le linee seriali; ho risolto disaccoppiandolo con una R in serie al segnale e tutto è andato bene. Ora devo solo implementare la gestione dei lock_bit, ma prima devo scrivere la seconda puntata..... :D
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

leo72


Finito! seguendo i saggi consigli del buon Leo, maestro d'arte programmatoria XD, ho realizzato un semplice protocollo di comunicazione seriale tra due micro.

Troppo buono  :smiley-sweat:

Code: [Select]
Ad onor del vero Leo mi aveva suggerito una cosa "un po'" più professionale, con tanto di inizio e fine trasmissione
Beh, vista la semplicità della comunicazione, forse era sovraccarico del codice che a te non serviva  ;)

Michele Menniti

#336
Apr 08, 2012, 11:08 am Last Edit: Apr 08, 2012, 07:19 pm by Michele Menniti Reason: 1


Finito! seguendo i saggi consigli del buon Leo, maestro d'arte programmatoria XD, ho realizzato un semplice protocollo di comunicazione seriale tra due micro.

Troppo buono  :smiley-sweat:

no, senza il tuo suggerimento starei ancora impazzendo , invece me la sono cavata sfruttando una giornata di influenza trascorsa forzatamente a casa :)
Quote

Quote
Ad onor del vero Leo mi aveva suggerito una cosa "un po'" più professionale, con tanto di inizio e fine trasmissione

Beh, vista la semplicità della comunicazione, forse era sovraccarico del codice che a te non serviva  ;)

Vero, in realtà, avendo creato una copia del firmware specifica per tastiera ed lcd, non ho particolari incognite oltre a qualche disturbo seriale. Comunque ho scoperto che tra tutti i micro ATMEl i 2313 sono dei ces.. ehm, i più delicati, perdono la signature che è una bellezza; ora che ho quasi messo in ordine devo riprendere la versione di BB che mi permette di programmarli comunque; alla prima occasione ci butto un firmware e li pianto su un PCB, non ne compro mai più! Invece nessun problema con i 4313
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Michele Menniti

E' arrivato il momento di implementare la gestione dei Lockbits nel firmware del Programmatore HV; inizio dalla versione HVSP. In realtà non ho un problema legato alla procedura di programmazione lettura e scrittura, perché il meccanismo è simile a quello di fuse, signature e chip erase che già funzionano senza problemi.
Spiego la questione Lock bits (rif. pag.151 Reference tiny25/45/85): si tratta di un BYTE in cui si devono considerare solo i due bits meno significativi (0 e 1), mentre gli altri sono "non programmabili). Sono possibili tre coppie di valori:
11 mode 1 : chip "libero" da blocchi
10 mode 2 : chip con blocco in scrittura della flash e della EEPROM anche in modalità HV
00 mode 3 : chip con blocco in scrittura e verifica della flash e della EEPROM anche in modalità HV

Per modificare il valore iniziale 11 in 10 o 00 devo ricorrere ad una serie di 5 byte, forniti al micro tramite apposita sequenza di comandi (qui mostro le definizioni):
#define HVSP_LOCKB_WRITE_DATA      B00100000  // Comando di scrittura LOCK BITS
#define HVSP_LOCKB_WRITE_INSTR1    B01001100  // Istruzione 1
#define HVSP_LOCKB_WRITE_INSTR2    B00101100  // Istruzione 2
#define HVSP_LOCKB_WRITE_INSTR3    B01100100  // Istruzione 3
#define HVSP_LOCKB_WRITE_INSTR4    B01101100  // Istruzione 4
Insieme alla seconda istruzione devo inviare il BYTE del LB:
#define HVSP_LOCKB_WRITE_VALUE     B00000000
Variando le ultime due cifre a destra in: 11, 10, 00

La lettura invece richiede solo 4 byte.

Finora ho provato ad inviare direttamente il BYTE in formato B000000xx (come da Reference tabella 20-16 pag.164) e ottengo questi dati:
11 = FF; 10 = FE; 00 = FC
Mi sembravano sballati ma in realtà se pensiamo che i bits  non programmabili siano = 1 (invece di 0) allora abbiamo:
FF = B11111111; FE = B11111110; FC = B11111100.

Domanda: è corretta questa interpretazione? Se la risposta è "sì" sta funzionando tutto, poi passiamo all'ulteriore chiarimento.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

leo72

Sì, è corretto perché nei fuse un bit ad 1 significa "NON impostato" mentre un bit a 0 significa "impostato".
Quindi 0b11111111 è il valore corretto per un byte che ha tutti i lock bit NON impostati mentre 0b11111100 è per i lock bit attivi alla massima protezione.

Credo dipenda dal fatto che si usino le celle di memoria in modalità "raw", cioè "grezza". Se ci pensi ha una sua logica dato che una EEPROM o una FLASH non programmata (o appena erasata) ha tutti i suoi byte a $FF, quindi una cancellazione pone i singoli bit ad 1. Non so il motivo elettrico, forse porre in conduzione l'elemento della cella richiede un lavoro inferiore.

Testato

#339
Apr 15, 2012, 10:56 pm Last Edit: Apr 15, 2012, 10:59 pm by Testato Reason: 1
e' corretto
perche' nella verifica dei bit non programmabili il risultato sara' NonAttivo, che nel mondo dei fuse si identifica con 1 e non con 0
questo significa che sono invertti anche i risultati, cioe' FF significhera' 11 tutto protetto ??
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

Michele Menniti

Ottimo! Nel frattempo ho verificato (risp implicita a Testato) che funzionano; se setto uno quasiasi dei due bit a 0 non riesco più a programmare i fuses, è un'altra delle caratteristiche dei lock bits; per poter riprogrammare devo fare prima un chip erase che mi resetta i lock bits su FF. Ho già implementato la sezione di programmazione personalizzata (ora, a richiesta, gli dò io FE o FC, FF è inutile in quanto o lo è già o non si può scrivere).

Secondo quesito: non capisco in cosa consiste il write o write/verify locked, riguardo flash e EEPROM; cioè settando 00 io blocco tutto e mi è chiaro che il chip erase cancella tutto e resetta i LB; però anche in condizione 00 io riesco tranquillamente in ISP a programmare il micro "bloccato", e contemporaneamente resetto i LB. Ma allora a che cavolo serve questo LB?

Terzo quesito: il comando
Code: [Select]
read_lockbits=read_HVSP_command(0x00, HVSP_LOCKB_READ_INSTR3); legge il valore dei LB, con Serial.print(read_lockbits, HEX) riesco a vedere FF, FE, FC; non riesco però a "leggere" il contenuto ai fini di associargli una descrizione. Cioè se faccio
Code: [Select]
switch (read_lockbits,HEX) {
    case 'FF':
     Serial.print("Free");
     break;
    case 'FE':
     Serial.print("Write Lock");
     break;
    case 'FC':
     Serial.print("Write & Verify Lock");
     break;
  }   
non funziona, non mi riconosce mai il contenuto, infatti il comando Serial.print(read_lockbits) mi restituisce blank, però il valore c'è.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

leo72


Ottimo! Nel frattempo ho verificato (risp implicita a Testato) che funzionano; se setto uno quasiasi dei due bit a 0 non riesco più a programmare i fuses, è un'altra delle caratteristiche dei lock bits; per poter riprogrammare devo fare prima un chip erase che mi resetta i lock bits su FF. Ho già implementato la sezione di programmazione personalizzata (ora, a richiesta, gli dò io FE o FC, FF è inutile in quanto o lo è già o non si può scrivere).

Sì, va bene. Se ti ricordi quel documento di AvrFreaks che segnalai, i lock bit possono essere impostati solo unidirezionalmente verso un aumento della protezione, non puoi ritornare indietro. Quindi dal livello zero al massimo va bene, viceversa no.

Quote

Secondo quesito: non capisco in cosa consiste il write o write/verify locked, riguardo flash e EEPROM; cioè settando 00 io blocco tutto e mi è chiaro che il chip erase cancella tutto e resetta i LB; però anche in condizione 00 io riesco tranquillamente in ISP a programmare il micro "bloccato", e contemporaneamente resetto i LB. Ma allora a che cavolo serve questo LB?

Livello minimo: libero accesso alle memorie sia in lettura che scrittura
Livello intermedio: non puoi più scrivere sulle memorie ma puoi leggerle
Livello massimo: non puoi né scrivere né leggere

I lock bit servono non solo per evitare sovrascritture della memoria ma anche per proteggere il firmware ed evitare che qualcuno faccia il dump della memoria "rubandoti" il firmware.

Quote

Terzo quesito: il comando
Code: [Select]
read_lockbits=read_HVSP_command(0x00, HVSP_LOCKB_READ_INSTR3); legge il valore dei LB, con Serial.print(read_lockbits, HEX) riesco a vedere FF, FE, FC; non riesco però a "leggere" il contenuto ai fini di associargli una descrizione. Cioè se faccio
Code: [Select]
switch (read_lockbits,HEX) {
    case 'FF':
     Serial.print("Free");
     break;
    case 'FE':
     Serial.print("Write Lock");
     break;
    case 'FC':
     Serial.print("Write & Verify Lock");
     break;
  }   
non funziona, non mi riconosce mai il contenuto, infatti il comando Serial.print(read_lockbits) mi restituisce blank, però il valore c'è.

Ma perché non usi una maschera a bit per estrarre il valore dei lock bit?
Fai un (VALORE_LOCK && 0b00000011). Come risultato hai appunto la condizione dei 2 lock bit.

Michele Menniti

Chiarimenti:
Non ricordo il documento e francamente non ho provato a passare da FE a FC, da fare. :)

La domanda sul funzionamento dei LB era retorica, infatti lo vedi dal codice che avevo postato in basso che so bene qual è la loro funzione; la domanda finale era: a che serve la protezione se poi posso sovrascrivere via ISP? Io capisco che non riuscirò a leggere (a proposito, qualcosa per testare la lettura?), e capisco che chip_erase resetta tutto, ma perché mi fa scrivere tranquillamente con la write protect settata? :smiley-roll-sweat:

Quote

Ma perché non usi una maschera a bit per estrarre il valore dei lock bit?
Fai un (VALORE_LOCK && 0b00000011). Come risultato hai appunto la condizione dei 2 lock bit.

Un esempio? Non ho capito niente. :smiley-sad-blue:

Intanto ho completato la procedura di implementazione, ora leggo e scrivo i LB in HVSP, HVPP e HVP13; mi manca solo il controllo, che risolvo appunto appena capisco questo tuo suggerimento.  :D
Ho già creato le due versioni PC e LCD (qui sudori a vasche per farci entrare tutto, ma è ok).

L'ultimo passaggio che volevo fare è fornire il vLCD di Astro come interfaccia PC, ma non ricordo più a che punto era; in realtà su PC però vorrei usare una simulazione 6x40, che mi permette di non stravolgere il firmware PC; fattibile? :smiley-mr-green:
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

leo72


Chiarimenti:
Non ricordo il documento e francamente non ho provato a passare da FE a FC, da fare. :)

http://www.avrfreaks.net/index.php?func=viewItem&item_id=301&module=Freaks%20Tools

Quote

La domanda sul funzionamento dei LB era retorica,

Ponevi 3 quesiti, ho risposto a tutti altrimenti dici sempre che non ti ascoltiamo  :P

Quote

infatti lo vedi dal codice che avevo postato in basso che so bene qual è la loro funzione; la domanda finale era: a che serve la protezione se poi posso sovrascrivere via ISP? Io capisco che non riuscirò a leggere (a proposito, qualcosa per testare la lettura?), e capisco che chip_erase resetta tutto, ma perché mi fa scrivere tranquillamente con la write protect settata? :smiley-roll-sweat:

Uhm... o non spedisci il valore corretto, per cui in realtà non proteggi la memoria oppure i lock bit non funzionano  :smiley-sweat:
Che chip stai cercando di proteggere?

Quote

Quote

Ma perché non usi una maschera a bit per estrarre il valore dei lock bit?
Fai un (VALORE_LOCK && 0b00000011). Come risultato hai appunto la condizione dei 2 lock bit.

Un esempio? Non ho capito niente. :smiley-sad-blue:

Si tratta dell'AND binario.
1 AND 1 = 1
0 AND 1 = 0
1 AND 0 = 0
0 AND 0 = 0
In pratica, hai 1 se e soltanto se entrambi i bit sono ad 1.
Una "maschera" AND serve appunto ad avere come risultato 1 solo quando un bit della maschera settato ad 1 incontra un bit del valore da testare anch'esso ad 1.
Quindi, visto che il byte che regola i fuse tiene conto solo dei primi 2 bit,
facendo
BYTE_FUSE && 0b00000011
ottieni i soli primi 2 bit, senza fregartene del contenuto del resto del byte, che può avere qualunque valore tanto il risultato dell'AND tra i suoi bit e la maschera sarà sempre 0.


Michele Menniti

Se il ragionamento di ieri è giusto sono giusti anche i LB; la prova è che se setto i LB su FE o FC non riesco più a programmare i Fuse, devo per forza fare un chip erase. Ho provato con tiny84, sia FC che FE mi permettono di riprogrammarlo via ISP, anche se mi viene ora un onesto dubbio: ieri quando cambiavo i fuse la procedura veniva eseguita correttamente, ma poi alla verifica vedevo i valori inalterati, mentre ieri al tiny mandavo sempre lo stesso sletck, non vorrei che facesse finta di ricevere i dati, le linee ISP lavoravano come sempre e l'IDE mi ha dato il done, quindi mi sono fidato di ciò. Stasera approfondisco con un 328 ed un 4313, per avere l'intero arco chiaro.

Sul tuo suggerimento purtroppo non capisco come posso risolvere, scusa ma: se "stampo" a video il contenuto della variabile in forma HEX vedo i valori FF, FE, FC, in qualsiasi altra forma mi da spazio vuoto, io vorrei riuscire a leggere questa variabile e confrontarla fisicamente con uno dei possibili valori per attribuire anche la descrizione dello status. Tu dici che se faccio qualcosa come:
if LOCKB && 0b00000011 = 0b00000011 ; Serial.print("Free");
funziona? ma se è così non posso direttamente fare:
if BYTE(LOCKB) = 0b00000011 ; Serial.print("Free");
?

Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Go Up