Newsgroup: it.hobby.elettronica.digitale
Titolo: lettura EEPROM PIC

Ciao,
ho una look-up-table di 32 byte memorizzata nella eeprom interna di un 
PIC. Ogni tanto (come stima diciamo 50 letture ravvicinate ogni 5 
minuti) devo leggere alcuni valori in essa contenuti. Premetto che so 
che l'accesso a dati in RAM è piú veloce di quelli in ROM.
Vi chiedo se la lettura di dati contenuti nella EEPROM possa a lungo 
andare danneggiare la memoria stessa. Ad esempio, anche se altissimo, in 
scrittura c'è un limite garantito dalla casa. La lettura però dovrebbe 
essere non distruttiva, è cosí ?
Lo chiedo perchè vorrei risparmiare spazio in RAM, evitando cioè di 
trasferire la LUT in un array durante l'esecuzione del programma.
Grazie,
Marco / iw2nzm

 essere non distruttiva, è cosí ?
La lettura della EEPROM non comporta alcun tipo di degrado, solo la scittura 
ha un numero limitato di operazioni, circa 1.000.000 di volte.
Però visto che la tua LUT è piccola perchè non la metti direttamente nella 
flash memory come si fa di solito per tutti i parametri fissi del programma, 
tipo scritte per display lcd, costanti etc. ?
Bye 

 tipo scritte per display lcd, costanti etc. ?
ho lavorato diverso tempo con gli Atmel (sempre in C) adesso per lavoro 
mi sono trovato a sviluppare semplici applicazioni per i PIC. Beh, non 
so se sbaglio qualcosa io... in ditta usano il CCS come compilatore:
Esempio:
spazio occupato dal codice su EEPROM a un certo punto dello sviluppo
30%
aggiungo (con a e b float):
a = 0.217 * b - 61.111;
e l'occupazione sale al 58%
dulcis in fundo, uso una sprintf per convertire in stringa e sale quasi 
al 90%....
quindi cercavo di liberare piú ROM possbile per avere un po' di spazio 
in piú (ecco il perchè della LUT nella EEPROM). Ma di qui a qualche ora 
avrei postato proprio questo problema.
Mi pare assurdo un codice cosí inefficiente! Proprio pochi mesi fa ho 
fatto una cosa simile su un Atmel (sempre in C) ma ricordo che 
l'incremento della dimensione del codice era moooolto piú contenuto!
Immagino dipenda dal compilatore ma il CCS non mi sembra proprio 
l'ultimo arrivato....
Marco / iw2nzm

 al 90%....
Utilizzi float e sprintf su un PIC??? E' un suicidio... di quale PIC parli?

 di quale PIC parli?
16F688
ciao!
Marco / iw2nzm

 
<cut>
sprintf e' una delle funzioni piu' pesanti in assoluto della libreria c 
standard.
Essendo una funzione di libreria C standard non credo che l'Atmel faccia 
eccezione a meno che non l'abbiano castrata in qualche maniera.
Comunque l'utilizzo di una simile funzione, specialmente in 
microcontrollori piccoli, e' sempre (se possibile) da evitare.
Ciao
Giuseppe

l'ultimo arrivato....
Non dipende dal compilatore, dipende da chi lo usa e per fare cosa.

 Usare il C con i PIC sarebbe da vietare per legge.
Non sarei cosi' estremista. Anzi non bisogna vietare
il 'C' ci sono compilatori che ottimizzano molto bene
ma effetivamente bandirei l'uso di qualsiasi stdlib!!
Se devi stamparti qualcosa meglio due o tre funzioncine
ad hoc.
Cuai

 decine, unità ecc visto che il compilatore non collabora... hi hi
Come ti hanno gia' detto, printf e parenti mangiano memoria
perche' praticamente printf e' un interprete della striinga di
controllo che puo' acettare tutti i tipi in tutti i formati possibili,
anche quelli che a te non interessano in quel momento.
In genere pero' ci sono anche delle altre funzioni meno generiche,
per esempio ci dovrebbe essere una funzione specifica che
converte un float in ascii e sicuramente occupa molta meno
memoria di printf, forse si chiama ftoa() o qualcosa di simile.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

ad hoc.
Ditto.

 Non dipende dal compilatore, dipende da chi lo usa e per fare cosa.
riferendomi anche all'altro post, io l'asm lo conosco abbastanza, forse 
non cosí tanto da riuscire a scrivere un'applicazione completa e 
complessa interamente in assembler. Preferisco però avere tempi di 
sviluppo molto piú brevi e maggiore flessibilità nelle modifiche a 
prezzo di un codice meno efficiente. Non devo scrivere firmware che 
vanno in produzione... devo solo montare (e collaudare) prototipi nel 
piú breve tempo possibile. E comunque - ripeto - sono diversi anni che 
uso uC anche strapazzandoli con float e stringhe varie :) ma forse ho 
usato compilatori dedicati che tagliavano eventuali funzioni standard 
non usate nel codice compilato.
ciao,
Marco / iw2nzm

non usate nel codice compilato.
Mi sembra MOOLTO strano che un compilatore per PIC butti dentro
roba che non c'entra.. .sarebbe troppo una cazzata... il fatto è che 
pur di rimanere il più possibile "C compliant" devono mettere dentro
anche robe pensate per sistemi più grossi (in fondo il C è stato 
inventato per scrivere Unix... e mi sembra che con tutta 
l'arretratezza dei sistemi di allora non andava su un povero pic.)
Comunque tirando le somme: usare il C sul pic NON è come usare
il C sul PC : ci sono delle sorprese in agguato ! :-)

 il C sul PC : ci sono delle sorprese in agguato ! :-)
ok, mi hai messo curiosità. Appenna ho qualche giorno libero, provo a 
riscrivere in asm il codice di questo oggetto... vediamo se mi convinco 
ad abbandonare il C!
Marco / iw2nzm
ps. a ulteriore supporto di questo: chi lavora in azienda e ha a che 
fare con uC, si trova a programmare in asm ?

 a scegliere il micro.
Come si vede che tu con i PIC ci giochi solo, a livello professionale si 
usano solo linguaggi di alto livello per lo sviluppo delle applicazioni e si 
ricorre all'assembler per le eventuali routine time critical, cosa che 
capita molto ma molto raramente visto l'attuale livello dei compilatori C.
Bye 

 arrivato....
Purtroppo il problema è proprio il compilatore che usi, il CCS è molto 
carente sui numeri float, prova l'Hitec C e vedrai che l'uso della memoria è 
nettamente minore, comunque è sempre consigliabile lavorare solo con gli 
interi e poi convertire in float solo a fine dei calcoli.
Al posto della printf usa le normali funzioni di conversione formato tra 
numeri e stringhe e se il risultato finale dei tuoi calcoli è un float puoi 
sempre calcolarti facilmente la posizione della virgola per la 
rappresentazione su display e/o tramite terminale.
Bye 

 rappresentazione su display e/o tramite terminale.
Grazie anche a te delle risposte e dei suggerimenti!
Marco / iw2nzm

capita molto ma molto raramente visto l'attuale livello dei compilatori C.
Si, a livello professionale poi non va mai un cacchio e non si 
capisce perché ! Ah ah ah. Lo conosco bene il mondo "professionale".
Guarda che stiamo parlando dei PIC, non dell'8086 con il Dos che
è lento a scrivere a video allora si fanno le routine in assembler !
Riguardo al datasheet che hai citato: i primi pic sono stati pensati
per il basso livello, poi hanno accrocchiato l'architettura per 
permettere di farci girare codice dai compilatori (lo stack è un
esempio) perché la gente si spaventava davanti all'assembler (e
loro dovevano/devono vendere alla gente.)

fare con uC, si trova a programmare in asm ?
Ehm... 

 loro dovevano/devono vendere alla gente.)
Chissa perchè io programmo benissimo anche i vecchi modelli della serie 16 
in  C (picc Hitec) senza problemi e con ottimi risultati.
Bye

trasformazione in codice eseguibile.
Vabbè lasciamo perdere, è evidente che non conosci abbastanza 
approfonditamente le cose di cui parli.

 approfonditamente le cose di cui parli.
Io direi che è esattamente l'incontrario, io so molto bene di cosa parlo e 
tu no.
Bye 

Guarda che so molto bene cosa fanno i compilatori internamente.
E cosa fanno ?

 del messaggio iniziale.
dunque, senza polemica visto che ne so meno di voi e sto cercando di 
capire e di imparare. La discussione però è interessante.
Quel conto fatto con valori float mi occupa un certo spazio in memoria 
(stiamo sempre parlando del C in questo momento)
Avevo già provato a togliere la virgola per usare gli interi, cioè:
a = 217 * b - 61111;
ma in questo caso sono costretto a usare interi a 32 bit visto che 'b' è 
il risultato di una conversione A/D a 10 bit e quindi 217*1023=221991.
Bene, il codice risulta praticamente della stessa lunghezza di prima 
(del resto i float sono pure definiti su 32 bit).
Detto questo chiedo:
- come fareste per eseguire questo calcolo ? 'a' è il valore della 
temperatura in gradi centigradi, e le tre cifre decimali iniziali sono 
necessarie per garantire un errore compatibile con la risoluzione dell'ADC.
- se anche scrivessi *io* il codice assembler per eseguire il conto (o 
in generale per altre funzioni) sicuri che sarà piú compatto di quello 
generato dal compilatore stesso ? mi riferisco a alla frase di Bob:
"Il codice credo sia al massimo dell'efficienza, se ti vai a vedere
i sorgenti scopri delle furbate matematico/assembleristiche che
ti viene da meravigliarti di come cacchio le abbiano tirate fuori."
cioè, se il codice sputato dal compilatore è già il massimo 
dell'efficienza, come posso pensare di farlo meglio io ?
Ciao!!
Marco / iw2nzm

dell'efficienza, come posso pensare di farlo meglio io ?
Eh... il problema infatti è più complicato di quello che sembra.
Per questo dicevo che forse per fare troppi calcoli di quel 
genere magari un'architettura più "friendly" (per questo tipo
di cose) sarebbe stata meglio, oppure un "rilascio" dei 
vincoli del problema... (meno bit, meno precisione, ecc...)
In fondo non si può pretendere troppo! :-)
Oppure dovresti provare a trovare una soluzione più
furba... del tipo: visto che moltiplichi per 217... in fondo
non è molto distante da 256... moltiplicare per 256 
significa shiftare a sinistra di 8 bit. (Al limite puoi poi
togliere dopo 39 volte il moltiplicando).... anche se
la moltiplicazione in questo modo dovrebbe già farla
il compilatore... se non la fa allora una tua routine che
fa in questo modo potrebbe farti risparmiare, anche
perché moltiplicare 32 bit per 32 bit è diverso (in 
termini di quantità di codice) da moltiplicare 32 bit
per 8 bit.
Eccetera... 
PS:  In questo senso in certi casi usare l'assembler può
essere meglio e più veloce rispetto ad usare un 
linguaggio di alto livello.

 linguaggio di alto livello.
bene, direi che ora ho le idee piú chiare.
ad esempio, visto che i dati acquisiti li devo trasmettere a un'unità 
centrale di visualizzazione, invece di elaborare il valore acquisito 
dall'ADC con il micro remoto, trasmetto semplicemente il valore a 10 bit 
dato dal convertitore (quindi posso scrivere il programma direttamente 
in asm visto che è facile, cosí ne approfitto per fare esperienza...). 
Sarà poi l'unità centrale, che sceglierò tenendo conto di cosa deve 
fare, a farsi i conticini e a convertire in stringhe.
ciao e grazie!
Marco / iw2nzm

fare, a farsi i conticini e a convertire in stringhe.
!!!
(un bel 4 in pagella non te lo toglie nessuno, per non averlo fatto 
subito!)

 subito!)
sgrunt... ^___^
e chi si aspettava problemi simili ?
la prossima volta non ci penso su nemmeno mezza volta! ;-)
Marco / iw2nzm