Topic permanente di programmazione newbie

[astrobeed]

EDIT: ma mi viene un dubbio e devo fare una controverifica...

Nel frattempo guardati pure la soluzione che ti ho scritto qualche post sopra per il controllo della signature.

[menniti]

Scusami Astro, ho visto il lunghissimo post di risposta che il povero Leo si è massacrato a scrivere e non havevo proprio visto il tuo post, dove peraltro mi chiarivi già la questione funzione/void; la soluzione che mi prospetti è semplice ed efficace, la metto subito in atto.
Però non posso basarmi immediatamente sul controllo 1E, perché devi considerare che io "non so" a priori che micro ho messo e quindi la modalità che uso potrebbe non essere compatibile.
Intanto ho avuto conferma del sospetto che avevo, devo proprio iniziare a leggere con la modalità HVSP, in tal modo ho:
1E se il micro è HVSP compatibile
FF se non lo è ma se comunque c'è un micro
00 se non c'è alcun micro e ho premuto per errore
quindi la tua routine la eseguo solo quando riesco ad ottenere un 1E, fra poco devo andare all'UNI, per oggi mi sa che ho finito, però mi pare di essere sulla buona strada.... Grazie a tutti! XD

[astrobeed]

quindi la tua routine la eseguo solo quando riesco ad ottenere un 1E, fra poco devo andare all'UNI, per oggi mi sa che ho finito, però mi pare di essere sulla buona strada.... Grazie a tutti! XD

Ovviamente la mia routine di controllo la esegui solo dopo aver ottenuto una signature valida.
Attenzione al fatto che 0x1e per il momento è vero che ti indica un micro AVR di Atmel, ma non è detto che in futuro rimane sempre solo questo valore, per come è organizzata la signature è possibile specificare solo 255 diversi modelli di micro più le loro varianti come quantità di memoria.

[menniti]

quindi la tua routine la eseguo solo quando riesco ad ottenere un 1E, fra poco devo andare all'UNI, per oggi mi sa che ho finito, però mi pare di essere sulla buona strada.... Grazie a tutti! XD

Ovviamente la mia routine di controllo la esegui solo dopo aver ottenuto una signature valida.
Attenzione al fatto che 0x1e per il momento è vero che ti indica un micro AVR di Atmel, ma non è detto che in futuro rimane sempre solo questo valore, per come è organizzata la signature è possibile specificare solo 255 diversi modelli di micro più le loro varianti come quantità di memoria.

Sì, ci riflettevo su, d'altra parte che posso farci? posso mettere una define all'inizio del firmware col valore 1E, per semplificare la variazione, ma per aumentare il numero devono almeno raddoppiare i byte, posso tentare di "anticipare" la possibile applicazione di due byte con un define ATMEL 0xFF1E e trasformare ogni primo byte in un doppio byte, ma dici che vale la pena? però considera che io rilascio il firmware libero, e se ciò dovesse accadere sarei il primo ad apportare le dovute correzioni e ridarlo alla Rivista e comunque ognuno potrebbe fare la correzione.
Comunque accetto suggerimenti, ovviamente, della tua esperienza mi fido ciecamente.
Intanto la routine di check della signature ora è perfetta, mi dice perfino se il micro non è nello zoccolo o se è danneggiato (ho un atmega8 morto che avevo conservato per usi futuri.... )

[astrobeed]

Sì, ci riflettevo su, d'altra parte che posso farci? posso mettere una define all'inizio del firmware col valore 1E, per semplificare la variazione, ma per aumentare il numero devono almeno raddoppiare i byte, posso tentare di "anticipare" la possibile applicazione di due byte con un define ATMEL 0xFF1E e

Ma no, semplicemente in futuro avranno come primo byte non solo 0x1e, ma un secondo valore che potrebbe essere 0x1f, questa non è una convenzione mondiale di tutti i produttori, è solo uno standard usato da Atmel, tutti gli altri fanno come gli pare.
Per esempio Microchip usa solo due byte per il device ID, l'equivalente della signature di Atmel, i vari bit indicano sia il modello esatto del micro che la revisione hardware, quest'ultima informazione, molto importante, è totalmente assente nella signature di Atmel.

[brainbooster]

@Menniti oltre alle possibilità che elencavi prima, hai pensato alla eventualità di mettere i micro al contrario?
in teoria dovrebbe rientrare nel caso "nessun micro" ma siamo sicuri che per qualche strana ragione non si legga qualcosa (di sicuramente errato) comunque?

[menniti]

Sì, ci riflettevo su, d'altra parte che posso farci? posso mettere una define all'inizio del firmware col valore 1E, per semplificare la variazione, ma per aumentare il numero devono almeno raddoppiare i byte, posso tentare di "anticipare" la possibile applicazione di due byte con un define ATMEL 0xFF1E e

Ma no, semplicemente in futuro avranno come primo byte non solo 0x1e, ma un secondo valore che potrebbe essere 0x1f, questa non è una convenzione mondiale di tutti i produttori, è solo uno standard usato da Atmel, tutti gli altri fanno come gli pare.
Per esempio Microchip usa solo due byte per il device ID, l'equivalente della signature di Atmel, i vari bit indicano sia il modello esatto del micro che la revisione hardware, quest'ultima informazione, molto importante, è totalmente assente nella signature di Atmel.

Pensavo fosse uno standard per tutti i micro, a questo punto lascio com'è, non avendo idea di cosa possa diventare, quando sarà se ne parlerà....

@Menniti oltre alle possibilità che elencavi prima, hai pensato alla eventualità di mettere i micro al contrario?
in teoria dovrebbe rientrare nel caso "nessun micro" ma siamo sicuri che per qualche strana ragione non si legga qualcosa (di sicuramente errato) comunque?

BB, ti rispondo con una prova da fare: prepara uno schema per un tiny85 e poi mettilo al contrario, ma PRIMA guardati le piedinature ok? Non scherziamo, ci manca solo che devo calcolarmi come prevedere il chip a rovescia (il tiny85 scoppierebbe) o magari quello che lascia i primi o gli ultimi due pin fuori dallo zoccolo
La logica che ho usato è chiara e lampante, sono previsti i casi 00 (chip assente), FF (modo di programmazione sbagliato), 1E (chip e modo corretti), qualsiasi altro valore verrà dato come chip spacciato, cosa possibile se lo metti al contario o con i pin sfasati. Non lo scriverei nell'articolo come possibilità nemmeno sotto tortura, al principiante puoi dire che deve far corrispondere la tacca del chip col pin 1 serigrafato accanto allo zoccolo, non puoi trattarlo come un deficiente

[brainbooster]

chiaro... come solo un (bravo) insegnante puo essere

[menniti]

chiaro... come solo un (bravo) insegnante puo essere

Beh, grazie, ma anche tu come "studente" non sei niente male XD

Giovani, sono rientrato (è una specie di minaccia ), ho già litigato col code di Astro che lui giustamente aveva definito buttato al volo e non esente da errori; ora vediamo se facciamo pace da soli o se deve intervenire il suo papà  a tra poco.......

[menniti]

Un problemino per la tabella dati: ho diversi elenchi con le signature ma nemmeno uno con i fusebit di default, non è che posso mettermi col FuseCalc a tirarli fuori tutti, sai che sbatts, per non dire che non è detto che combaci la mia idea con quella di Atmel, specialmente per i tipi poco noti.

Queste dovrebbe essere una ricerca per BB, il LINKBUSTER

[brainbooster]

hai qualcosa per leggere un'enciclopedia di avr in xml ? se si mandami un mp

[astrobeed]

Giovani, sono rientrato (è una specie di minaccia ), ho già litigato col code di Astro che lui giustamente aveva definito buttato al volo e non esente da errori; ora vediamo se facciamo pace da soli o se deve intervenire il suo papà  a tra poco.......

Infatti ci stava qualche errore di battitura, un unsigned char al posto di un unsigned int e due coppie di parentesi mancanti, ti allego uno sketch completo funzionante  (provato) che illustra il senso generale della cosa:

Code: [Select]




char Stringa[20] [20] = { {"ATmega328p"},
                          {"ATMEGA644"},
                          {"ATMEGA2560"}
                        };
                       
byte signature [20] [3] = { {0x1E,0x1C,0x1D},
                            {0x1E,0x1C,0x1E},
                            {0x1E,0x1C,0x1F}
                          }; 

byte fuses [20] [4] = { {0xff,0xff,0xff,0xff},
                        {0xff,0xff,0xff,0xff},
                        {0xff,0xff,0xff,0xff}
                       }; 
char modello[20];

void setup()
{
  Serial.begin(9600);
}

void loop()
{
unsigned char indice;
char modello[20],i;

delay(500);
indice = Controllo_signature(0x1c,0x1e);
if (indice < 20)
  {
   
     Serial.print("Trovato : ");
     for(i=0;i<20;i++) modello[i] =  Stringa[indice] [i];
     Serial.println (modello);
  } 
else Serial.print("Nessun micro trovato");

}

/* funzione controllo signature invocata dopo il controllo del primo byte,
    la invochi fornendo gli altri due byte della signature, ti ritorna il valore
   dell'indice se viene trovata corrispondenza oppure 0xff in caso di errore.

*/

unsigned char Controllo_signature(unsigned char byte2, unsigned char byte3)
{
char i;
unsigned int temp1, temp2;

temp1 = (unsigned int)(byte2 << 8) + byte3;

for (i=0;i<20;i++)
{
  temp2 = (unsigned int) (signature[i] [1] <<8) + signature[i] [2];
  if (temp1 == temp2) return i; // esce dalla funzione con il valore dell'indice
}

return 0xff; // corrispondenza non trovata.
}


[menniti]

hai qualcosa per leggere un'enciclopedia di avr in xml ? se si mandami un mp

se è questo mi sa che proprio tu mi avevi mandato il link, ma così è illeggibile, ci vuole un programma specifico?


@ Astro: sei un gioiello impagabile ora provo....

[brainbooster]

... quello è un riassuntino a confronto

[astrobeed]

non è che posso mettermi col FuseCalc a tirarli fuori tutti, sai che sbatts, per non dire che non è detto che combaci la mia idea con quella di Atmel, specialmente per i tipi poco noti.

Con fusecalc ci metti un attimo, selezioni il modello che ti interessa e automaticamente hai i valori di defaults, al limite clicca sul tasto "defaults" per sicurezza, copia e incolla e in 10 minuti hai i fuse di almeno 30 modelli diversi, anche senza controllare il catalogo Atmel sono già di più di quelli che puoi inserire sugli zoccoli del programmatore HV vista la limitata scelta di AVR in case pdip.