Newsgroup: it.hobby.elettronica.digitale
Titolo: Configurazioni Atmel

Ciao,
mi sto perdendo nel classico bicchiere d'acqua.
Ho una scheda di test con su un ATmega324P, il connettore a pin 10 ISP 
un led (PD3) e un pulsante (PD2). Oscillatore interno e reset a +Vcc 
tramite pull-up da 10k.
Ho scritto un programmino idiota per verificare il funzionamento e fare 
qualche prova con AVR Studio e WinAVR:
#include <avr/io.h>
#include <avr/wdt.h>
#define	LED	PD3
#define	BTN	PIND2
int main()
{
  	wdt_enable(WDTO_1S);
	ACSR &= ~_BV(ACD);	// Comparator off
	DDRA = 0x00;		// tutti ingressi
	DDRB = 0x00;
	DDRC = 0x00;
	DDRD = 0x08;		// uscita led
	PORTA = 0x00;		// pull-up disattivati
	PORTB = 0xFF;		// pull-up attivati
	PORTC = 0xFF;
	PORTD = 0xF4;		// pull-up sul pulsante ma non sul led
	for (;;) {
	   	wdt_reset();
		if (bit_is_set(PIND, BTN)) PORTD |= _BV(LED); else PORTD &= ~_BV(LED);
	}
}
Due domande:
1) Il codice del costrutto if è corretto? Nel senso: con questo 
compilatore è quello che risulta più ottimizzato?
2) Misurando la tensione sui vari pin che dovrebbero avere il pull-up 
attivato qualcuno lo trovo a +5V altri a 0V altri a 1V (?) altri ancora 
flottanti... Il micro è funzionante (testato su un'altra scheda con un 
firmware già scritto). L'alimentazione è stabile e filtrata.
Immagino che mi perdo qualche cosa da configurare o qualche periferica 
da spegnere... ma leggendo il datasheet non l'ho trovata.
Ciao!
Marco / iw2nzm

 ha scritto nel messaggio 
news:pTqTi.152518$U01.1...@twister1.libero.it...


 firmware già scritto). L'alimentazione è stabile e filtrata.
Bhe i pin con il livello farlocco sono sempre gli stessi o cambiano a 
random? Se sono sempre gli stessi, puoi postare quali sono? Magari, per 
qualche ragione, c'è qualche periferica attiva che ha preso il controllo 
del pin.
Ciao

 del pin.
Ciao Francesco,
anzitutto qui c'è lo schema, così parliamo la stessa lingua:
http://tinypic.com/view.php?pic=68tusx&s=2
I tre connettori che vedi sulla destra sono liberi (non c'è collegato 
nulla) e il MAX232 non è montato.
Il comportamento sembra ripetibile.
I pin flottanti (rumorosi, vanno a spasso, con spike) sono:
1 - 2 - 22 - 29
Quelli a livello alto:
3 - 4 - 5 - 8 - 14 - 17 - 20 - 21 - 26 - 27 - 28
A livello basso:
15
Quelli a livello bislacco (1-2V):
6 - 7 - 16 - 18 - 19 - 23 - 24 - 25
(anche dal 33 al 40 ma me lo potrei aspettare perché sono impostati come 
ingresso e non hanno il pull-up)
Ecco i fuses che ho usato (magari ho fatto qui una cavolata)
Brown-out at 2,7V
Watchdog enabled
Boot Flash size = 2048, address $3800
Boot Reset Vector Enabled $0000
Int RC Osc 6CK + 65 ms
Mi sento alquanto idiota ma non ne vengo a capo! :)
Marco / iw2nzm

 Int RC Osc 6CK + 65 ms
Ok.
Purtroppo non vedo nulla di strano. Il programma che hai scritto gira?
L'unica cosa che mi viene in mente è che siano programmati male i fuse 
bit. Che software di programmazione usi? Se non lo fa i già prova con 
AVR Studio che all'inizio è più facile.
Gli AVR sono semplicissimi da far partire, di default hanno quasi tutte 
le periferiche disattivate e i pin settati come ingressi e quindi in 
three-state.
Questo mi sembra un classico porblema di lateral thinking.
Tradotto significa che ci deve essere qualcosa che dai per scontato che 
invece non funziona come pensi :-)
Fammi sapere,
Ciao

 invece non funziona come pensi :-)
Esattamente quello che temo anche io! Mi capita spesso :)
Mi è anche venuto il dubbio che il pcb che ho fatto sia un po' 
balengo... al massimo provo su una breadboard tanto c'è SOLO il micro e 
la R di pull-up sul reset e niente altro!
Grazie,
Marco / iw2nzm

 impostarmi il vettore di reset all'indirizzo 0x0000?
No č alla rovescia. Se metti quel fuse a zero il reset vector parte dal 
boot loader! Per il normale funzionamento deve stare a 1. Guarda a 
pagina 279 del datasheet, c'č una tabellina molto chiara.
Ciao

 pagina 279 del datasheet, c'č una tabellina molto chiara.
Ah ecco! Ora ho capito.
Ho messo ora tutti i pin settati come ingresso con pull-up. Ancora 
abbiamo i pin:
3-6-7-16-17-18-19-22-23-24-34-36
a livello intermedio o indeterminato.
Perň impostandoli tutti come uscite a livello alto allora leggo i valori 
giusti: tutti a +5V.
Questo significa che il micro č sano e il pcb pure. E' piů probabile che 
debba spegnere qualche periferica che risulta accesa e impedisce 
l'abilitazione del pull-up.
Marco / iw2nzm

 l'abilitazione del pull-up.
Mi sembra veramente strano, se i pin come uscita funzionano dovrebbero 
funzionare anche i pullup.
Forse non significa nente, ma esiste un bit nel registro MCUCR che 
controlla globalmente l'abilitazione del pull-up. Come già detto al 
reset tutto è messo in modo da non fare danni, per cui questo bit 
dovrebbe lasciare attivo il pull-up.
Se vuoi darci un'occhiata è il bit PUD nel registro MCUCR, descritto nel 
dettaglio a pagina 91.
Altra domanda: non è che fai le misure con il programmatore jtag 
connesso? Mi è capitato una volta che i pin fossero a livelli strani 
quando era collegato il programmatore jtag.
Ciao.

 quando era collegato il programmatore jtag.
Uso un ISP no un jtag, ma cambia poco. Quando ho fatto le misure avevo 
scollegato il programmatore.
Boh, è davvero un periodo di sf..ortuna nera. Ho provato un altro micro 
che avevo in giro, un ATmega8 con un hex già pronto giusto per vedere se 
tutto funziona. Programmo e va tutto liscio. Pasticcio con i fuse per 
fare qualche esperimento e per errore imposto il clock ext anziché 
interno... beh l'ISP non ne vuole più sapere di entrare in modalità di 
programmazione! Anche aggiungendo il quarzo il micro continua a 
resettarsi una decina di volte al secondo ma non c'è verso di 
riprogrammarlo o resettarlo.
Sgrunt, come inizio non c'è male :(
Grazie della pazienza. Vedrò di fare altre prove nei prossimi giorni 
dopo aver fatto un giro a Lourdes (sperando di non trovare chiuso...)
Marco / iw2nzm

 riprogrammarlo o resettarlo.
Eheheh succede spesso anche a me. In questi casi l'unico modo per farlo 
ripartire è collegare un segnale generato da un oscillatore esterno.
Io mi sono fatto un oscillatorino con un quarzo e qualche porta CMOS, 
che uso nei (frequenti) casi di mala programmazione dei fuses :-)
Ciao

 che uso nei (frequenti) casi di mala programmazione dei fuses :-)
Ecco :)
Marco / iw2nzm


Ciao!
Ma poi sei venuto a capo dei problemi? visto che hai una buona esperienza 
coni pic potresti elencare il perche' del passaggio ad altri processori? 

 coni pic potresti elencare il perche' del passaggio ad altri processori? 
Alcune motivazioni sparse:
+ architettura interna più interessante (ad es. riguardo la paginazione, 
i registri general purpose, gli interrupt, ...)
+ periferiche on-board più adatte alle mie esigenze (micro con più di 
una UART e SPI o I2C, uscite PWM, DAC, ecc...)
+ pull-up configurabili per ogni pin di I/O
+ a parità di frequenza di oscillazione maggiore MISP
+ tool di sviluppo gratuito o low-cost (IDE + ASM + compilatore C + 
programmatore / debugger)
+ la Atmel fa anche processori di ben altro livello rispetto agli ARM: 
8051, DSP, ARM e altro
Rispetto ad altre famiglie interessanti (v. Texas Instruments ad 
esempio) gli AVR sono disponibili anche in package dual-in-line, che in 
alcuni casi sono ancora preferibili rispetto ai microscopici soic o i 
temibili qfn bga e compagni...
E poi - in generale - sono ancora all'inizio e ritengo giusto conoscere 
più di una famiglia di microcontroller. Così quando devi fare un nuovo 
progetto hai possibilità di scegliere con cognizione di causa, sapendo i 
vantaggi e svantaggi di ciascuno. Con il tempo ci sarà senz'altro una 
famiglia preferita, la più usata e quindi conosciuta nei dettagli, ma 
fossilizzarsi da principio non mi sembra una mossa furba :)
Ciao!
Marco / iw2nzm

 dopo. Terrò informato il NG degli sviluppi :)
Si, chiedo scusa al mio piccino AVR - piccino mica tanto è un ciccione 
da 40 pin!
Il problema risiede sicuramente nel PCB perché ho montato il solo 
integrato su una breadboard e senza cambiare una virgola tutti i pin 
erano al giusto livello. Unica eccezione per il PC4, mi sono poi accorto 
che era dovuta all'interfaccia jtag attiva.
Lo stampato è volato fuori dalla finestra....
Ciao e grazie a Francesco per la pazienza :)
Marco / iw2nzm

 Lo stampato č volato fuori dalla finestra....
Se non ricordo male  gia'  in passato avevi avuto problemi che poi erano 
stati ricondotti allo stampato, in quella occasione  avevo suggerito di 
controllare lo stagno. 

 controllare lo stagno. 
Infatti sto usando un altro rocchetto :(
Non ho fatto fotografie purtroppo ma l'oscilloscopio visualizzava 
segnali da film dell'orrore. Cose veramente oscene. Come può lo stagno, 
lo stampato o che altro causare simili aberrazioni?
Voglio dire, una pista in corto, un accoppiamento capacitivo o resistivo 
possono causare un blocco del micro o nel peggiore dei casi la sua 
morte... ma generare rumore, spike, clock a frequenze assurde (tipo 12 
Hz, 170 Hz, ecc...) come può essere?
Ciao!
Marco / iw2nzm