next topic »

[Reply #45 on:]

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.

[Reply #46 on:]

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

[Reply #47 on:]

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/

[Reply #48 on:]

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.

[Reply #49 on:]

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??

[Reply #50 on:]

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.....

Sul connettore sono riportati anche i segnali per la programmazione del micro, ovvero Reset, MISO e MOSI.
In compenso mancano le resistenze di pull up per la I2C, sarebbe il caso di aggiungerle, due r da 3.3k vanno bene.

[Reply #51 on:]

Sul 2313 i segnali SDA e SCL viaggiano sugli stessi pin del MOSI e SCK dell SPI. Ma non avendo collegato il pin MISO la vedo difficile che possa dialogare col protocollo SPI. Per me è I2C.
Non ha neanche l'oscillatore esterno quindi usa quello interno.

Se il decoder fosse ancora funzionante, con un analizzatore di stati logici si potrebbe risalire al protocollo.

[Reply #52 on:]

e noto ancora che secondo la ricostruzione del polacco il display sarebbe pilotato in modalità ISP e non I2C, che ne pensate??

Non è possibile per i seguenti motivi:

Il display è collegato solo con cinque contatti al decoder, non bastano per la SPI.

Il display interrogato con I2Cscanner risponde correttamente e viene rilevato il suo address, se era SPI non ci sarebbe stata nessuna risposta.

Su i pin del connettore collegati al decoder arrivano solo le alimentazione, una pull up, SDA e SCL, impossibile che sia collegato come SPI.

[Reply #53 on:]

Bene, quindi è confermato che si sta lavorando in I2C e che BISOGNA aggiungere due R da 3k3 in funziona di pull-up suelle due linee SDA-SCL. Vituzzu, prendi nota e metti le R vediamo se cambia qualcosa.

Domanda per gli abili: se vito invia 4 byte consecutivi 0x00 eliminando il delay (che potrebbe disturbare l'interpretazione o il sincronismo della lettura), secondo voi non dovrebbe ottenere sempre 0000 sul display? Se così non è che tipo di codifica potrebbe essere stata adottata?

[Reply #54 on:]

che tipo di codifica potrebbe essere stata adottata?

Questo è un display a 7 segmenti comandato da un atmega328 --> https://www.sparkfun.com/products/11442
come vedi il protocollo prevede moltissimi comandi --> https://github.com/sparkfun/Serial7SegmentDisplay/wiki/Special-Commands

Cosa spedire quindi al display di vitos?
Boh!!

[Reply #55 on:]

messe 2 resistenze da 3,3kohm tra 5v e SDA e SCL recuperate dal cimitero, continua ad emettere simboli incomprensibili. ho anche provato a mandare 4 byte per fargli vivualizzare 0000 ma da sempre simboli incomprensibili che però cambiano forma

[Reply #56 on:]

Vito, la risposta di Paolo non lascia speranze, secondo me, fatte le dovute prove ormai appare ovvio che la casualità di ciò che mostra il display significa che esiste un protocollo di comunicazione che è impossibile da estrapolare. A questo punto, visto che hai tutta la connessione ISP sul connettore (considerando anche i pin inutilizzati), il 2313 puoi facilmente riprogrammarlo per gestire il multiplexer con una modalità ed un protocollo noto, a quel punto sai esattamente cosa mandargli e cosa far uscire quindi sul display.

[Reply #57 on:]

Se poi volete divertirvi qui trovate la libreria per i display a 7 segmenti --> https://github.com/sparkfun/SevSeg
e qui il firmware del display citato prima --> https://github.com/sparkfun/Serial7SegmentDisplay/tree/master/firmware/Serial%207-Segment%20Display/Serial_7_Segment_Display_Firmware
Compilato pesa poco più di 10k, ma stivarli in un 2313 la vedo dura. Bisogna eseguire un pò di taglia e cuci. Taglia soprattutto.

[Reply #58 on:]

allora per riprogrammarlo, utilizzando anche i pin non utilizzati, devo collegare:

attini2313            arduino uno
il pin MISO(pin18) al pin12
il pin reset(pin1) al pin 10
il pin MOSI(pin17) al pin11
il pin SCK(pin19) al pin 13

ed alimentare il tutto.
avrei in mente di fargli visualizzare l'ora impostando l'ora direttamente da sketch, per fare questo gli devo scrivere anche il bootloader??

[Reply #59 on:]

Paolo, penso non valga davvero la pena.......

Vito, non ricordo i collegamenti, segui la mia Guida o quella di Leo, e controlla se i segnali sono corretti, certamente sono quei 4, devi solo verificare se sono giuste le corrispondenze.

Ti serve ovviamente il core Tiny per la versione di IDE che stai usando

Non ti serve affatto un bootloader visto che programmi via ISP, scrivi il firmware, glielo carichi e funziona, ma se vuoi trasformarlo in un orologio stand-alone dovresti impostare la frequenza a 1MHz oscillatore interno ed aggiungere un quarzo da orologi (32768kHz), però con 2k di flash non vai da nessuna parte. Penso che, come ti ho detto prima, tu ti debba fare una normale gestione multiplexer dei display ed implementare un semplice protocollo (io sarei per la lettura dei 4 byte preceduta da un byte fisso di start e seguita da uno fisso di stop), poi trovi il pin che gestisce il dp del secondo display e lo colleghi a 5V tramite una R da 100ohm, così distingui le prime due cifre dalle seconde due (ore e minuti). Insomma tira fuori l'idea e si vede cosa si può fare...