Go Down

Topic: l'atmel display recuperato dal decoder (Read 7 times) previous topic - next topic

leo72


Direi che 56(dec) == 70(oct) == 38(hex) == 00111000(bin).
A quanto ne so, il compilatore non si cura della base in cui viene specificato un int literal (a parte l'ovvia distinzione sintattica).

E' esatto. Il "formato" di un numero serve solo a noi umani, al compilatore non gliene frega niente se il numero è in formato decimale, esadecimale o altro, perché quando il firmware verrà scritto nel micro, esso sarà trascritto in formato binario.

vitoos


Come valore nulla, d'altra parte se quello è l'indirizzo non ne puoi usare un altro. Il dubbio di tonid è che il protocollo adottato nel tiny preveda che gli si debba dare l'indirizzo I2C in formato esadecimale invece che decimale, non si sa mai...
Io un'altra prova che farei sarebbe quella di cambiare completamente indirizzo, per vedere se il display reagisce comunque o rimane correttamente spento


Michele ho già provato a cambiare l'indirizzo e non funziona, funziona solo con l' indirizzo 56 (0x38). Provo a riscriverlo divernamente. Vorrei precisare due cose, sul decoder il display non lampeggiava ma a me si in base al tempo di delay impostato, la seconda cosa che vorrei precisare è che il display non visualizzava immediatamente il numero del canale scelto, addirittura durante lo zapping veloce saltava la numerazione

vitoos

allora ho provato a cambiare il formato dell'indirizzo ma non cambia niente, i caratteri rimangono uguali

Googlando ho trovato un polacco che ha trovato il mio stesso display da un decoder simile ed ha ricostruito il circuito originale, vi posto il link

http://grylewicz.pl/mini-plytka-testowa-avr-z-odzysku/

astrobeed


Il dubbio di tonid è che il protocollo adottato nel tiny preveda che gli si debba dare l'indirizzo I2C in formato esadecimale invece che decimale, non si sa mai...


Al tiny non interessa minimamente la base numerica del valore che inserisci nello sketch, lui capisce solo il binario, le varie basi sono solo un modo di rappresentazione dei numeri che usiamo noi umani, poi ci pensa il compilatore a tradurre la base numerica utilizzata in binario.

Michele Menniti

#49
Jan 15, 2013, 05:12 pm Last Edit: Jan 15, 2013, 05:14 pm by Michele Menniti Reason: 1
sì, ora la cosa è chiara, l'intento era capire se stesse elaborando dati a casaccio in quanto non riconosceva correttamente il proprio indirizzo o meno, ovviamente perché non ho mai usato l'I2C, Ora è chiaro che il display lavora perché riconosce che gli stanno arrivando dei dati. Interessante la ricostruzione dello schema; ciò che intendevo dire all'inizio era se non fosse necessario aggiungere alle linee I2C delle pull-up, che in questo schema non vedo, ovviamente, perché se ben ricordo servono per il BUS e non per ogni slave, potrebbero essere importanti???
L'altra cosa è che su quel connettore è collegato il pin 18 del micro, forse serve per una qualche funzione di sincronismo, comincio a vederla dura.....
e noto ancora che secondo la ricostruzione del polacco il display sarebbe pilotato in modalità ISP e non I2C, che ne pensate??
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