Newsgroup: it.hobby.elettronica.digitale
Titolo: Banalità su puntatori

Ciao,
sicuramente ho fatto una stupidata così grossa che non vedo l'errore, ma 
in effetti mi perdo in un bicchiere d'acqua. Parliamo di un AVR 
(ATtiny2313) e WinAVR:
void read(uint8_t *high, uint8_t *low) {
	uint8_t a, b;
.
.
.
	*high = a; // come test ho provato anche un valore letterale
	*low = b;  // *high = 0x55; *low = 0x33;
}
nel main scrivo:
uint8_t a, b;
read(&a, &b);
in a e b ottengo valori "strani" così come mi vengono modificate altre 
variabili e il micro stesso ha comportamenti poco consoni...
Ho anche provato ad appoggiarmi a due puntatori espliciti:
Il codice sembra corretto? Se si, vado a cercare la cavolata da un'altra 
parte :)
Marco

 parte :)
E' un po' poco per valutare, ma sembra di sì.
A me sa tanto di sfondamento dello stack, auguri!
-- 
  _|/ Francesco Sacchi - Develer S.r.l., R&D dept.
   |\ 
http://www.develer.com/
 - 
http://www.bertos.org/

 A me sa tanto di sfondamento dello stack, auguri!
Urca, non ho molto altro nel codice.
Solo una funzione che mi spara sulla seriale i dati proprio per vedere 
cosa succede.
Però in effetti ci sta con il comportamento che rilevo.
Provo a indagare.
Ciao!
Marco

 Provo a indagare.
Non so se era sfondamento dello stack o altro.
Comunque ho risolto cambiando una routine di conversione hex -> ascii. 
Prima usavo una look-up-table di 16 caratteri, ora ci sommo gli offset 
dei caratteri '0' e 'A' in base al valore.
Strano perché la RAM occupata era al 50% e non avevo altre allocazioni 
"impegnative" all'interno delle funzioni.
Marco

 dei caratteri '0' e 'A' in base al valore.
E' più efficiente aggiungerci '0' e, se il risultato è maggiore di '9',
aggiungerci 'A'-'0'.

 aggiungerci 'A'-'0'.
Se non prendo abbagli a me compila sempre con 8 istruzioni:
char hex(uint8_t value) {
	value &= 0x0F;
	value += '0';
	if (value > '9') value += 'A'-'0';
	return value;
}
char hex(uint8_t value) {
	value &= 0x0F;
	if (value < 0x0A) return value + 0x30; else return value + 0x37;
}
Marco

 Se non prendo abbagli a me compila sempre con 8 istruzioni:
Può darsi benissimo, dipende dal compilatore. Queste sono cose che,
generalmente, scrivo in assembly (anche perché così posso usare l'struzione
swap).
Per curiosità, ti fa otto istruzioni anche così?
return(value > 9 ? value + ('A' - '0') : value + '0');

 return(value>  9 ? value + ('A' - '0') : value + '0');
Si, 8 istruzioni tutta la routine. La riga ne fa sempre 5.
Marco

swap).
Bravo, anch'io uso l'assemler per questo e anche molto altro, e uso anche altre
istruzioni come ad esempio Icall che l'ugly non usa mai.
Poi il 2313 con solo 128 bytes di ram è abbastanza difficile da usare col C, e
per la verità anche con l'asm arrivi presto al limite.
Io ad esempio ho dovuto mettere un Mega88P al posto del Tiny2313 perchè per
multiplexare dei led RGB avevo bisogno di almeno 192 bytes di ram, a parte il
buffer per la USART e anche qualche byte per lo stack.
A proposito, il Mega88P funziona bene anche a 22.118.400 Mhz nel range  5 -70 C°
alimentato a 5.5V, come del resto faceva anche il suo predecessore.
--
ciao
  Stefano

 alimentato a 5.5V, come del resto faceva anche il suo predecessore.
Dicevo giusto ieri a Piccio che il mio timer per la pasta, attaccato alla
cappa della cucina dove passa almeno un paio d'ore al giorno sotto sole
diretto, è più di un anno che funziona 24/24 (come orologio) a 5V con un
mega48, un ULN 2003 per i catodi e nessuna resistenza sui segmenti dei
display da 1 pollice.

display da 1 pollice.
Non mi meraviglia, gli AVR sono aggeggi molto robusti.
--
ciao
  Stefano

 funzionano benissimo.
In effetti è roba tosta, credo più per altro per il fatto che non ha senso
fare CI più piccoli di tanto, altrimenti sono solo bonding pad. Però non
sono dati per 6,5 mA o ricordo male?

sono dati per 6,5 mA o ricordo male?
No, i 74HC595 possono dare fino a 35mA per pin con i bus driver outputs, ma si
deve considerare anche la corrente massima per il chip di 70mA.
In ogni caso nonostante siano sempre sul filo degli abs. max. rating e a volte
anche oltre non si rompono.
Oramai sono quattro anni con diverse migliaia di chips e gli HC595 sostituiti
sono stati 3 o 4 in tutto.
Not bad,
--
ciao
  Stefano

 AVR.
Vero, può essere più appagante.
Però c'è da considerare il tempo necessario per sviluppare il codice e 
manutenerlo soprattutto se si tratta di progetti di medio-alta complessità.
A volte se i progettini sono semplici uso anche il l'asm. Ma comincia a 
gestire una porta USB, un file-system, un web-server o qualche altra 
diavoleria e onestamente per quanto uno possa essere in gamba la vedo 
dura a fare tutto (nello stesso tempo) in asm piuttosto che in C.
Che poi il codice sia più ottimizzato e straefficiente nel primo caso 
potrei anche essere d'accordo, maaaaa... perché? :)
Se non c'è questa necessità preferisco rendermi la vita più facile e 
spendere 10 cent in più per il micro con più flash...
Ciao!
Marco

spendere 10 cent in più per il micro con più flash...
Certo, è la strada più seguita, come quella del C&P, ma io mi sento ancora  come
un pioniere, forse sono solo un dinosauro come dice FB
--
ciao
  Stefano

 un pioniere, forse sono solo un dinosauro come dice FB
Un dinosauro pioniere? ;-)