Go Down

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

menniti

Astro, rileggi bene la "presentazione" del suo display, non sono sicuro che le due linee vadano usate così, potrebbe essere l'origine del fatto che mostra cose a casaccio
Manuale "Arduino e le tecniche di programmazione dei microcontrollori ATMEL"
http://www.michelemenniti.it/manuale_di_programmazione.html
http://www.michelemenniti.it/offerta.html
Articoli ElettronicaIN
http://www.michelemenniti.it/elettronica_in.html

astrobeed


Astro, rileggi bene la "presentazione" del suo display, non sono sicuro che le due linee vadano usate così, potrebbe essere l'origine del fatto che mostra cose a casaccio


Che il display lavori in I2C mi pare una cosa assodata, altrimenti lo sketch I2Cscanner non trovava l'address e inviando dati in sequenza non appariva nulla.
Ora tocca solo capire la logica di funzionamento, da come appaiono i digit ritengo molto probabile che sia quella che ho illustrato nel post precedente.
Scientia potentia est

vitoos



Astro, rileggi bene la "presentazione" del suo display, non sono sicuro che le due linee vadano usate così, potrebbe essere l'origine del fatto che mostra cose a casaccio


Che il display lavori in I2C mi pare una cosa assodata, altrimenti lo sketch I2Cscanner non trovava l'address e inviando dati in sequenza non appariva nulla.
Ora tocca solo capire la logica di funzionamento, da come appaiono i digit ritengo molto probabile che sia quella che ho illustrato nel post precedente.



e ma uno sketch per verificare quello che dici??
io ho provato a modificare quello che ho provato ma accetta solo numeri reali

astrobeed

Scientia potentia est

menniti




Astro, rileggi bene la "presentazione" del suo display, non sono sicuro che le due linee vadano usate così, potrebbe essere l'origine del fatto che mostra cose a casaccio


Che il display lavori in I2C mi pare una cosa assodata, altrimenti lo sketch I2Cscanner non trovava l'address e inviando dati in sequenza non appariva nulla.
Ora tocca solo capire la logica di funzionamento, da come appaiono i digit ritengo molto probabile che sia quella che ho illustrato nel post precedente.



e ma uno sketch per verificare quello che dici??
io ho provato a modificare quello che ho provato ma accetta solo numeri reali

prova a mandare il valore tutto 0 e vedi come risponde, devi per forza andare a tentativi, per capire se c'è una logica nella risposta del display.
Manuale "Arduino e le tecniche di programmazione dei microcontrollori ATMEL"
http://www.michelemenniti.it/manuale_di_programmazione.html
http://www.michelemenniti.it/offerta.html
Articoli ElettronicaIN
http://www.michelemenniti.it/elettronica_in.html

leo72

Ma così partite dal presupposto che il display riceva 1 e visualizzi 1. E se lavorasse con un piccolo protocollo? Non è dato sapere.

menniti

Leo, da un presupposto devi partire, quando brancoli nel buio, se il sisstema di comunicazione non è per segmenti e non è per bcd e non è nemmeno per codice ascii (o altro standard, se esiste) a quel punto diventa un'impresa scovare il "protocollo"
Manuale "Arduino e le tecniche di programmazione dei microcontrollori ATMEL"
http://www.michelemenniti.it/manuale_di_programmazione.html
http://www.michelemenniti.it/offerta.html
Articoli ElettronicaIN
http://www.michelemenniti.it/elettronica_in.html

leo72


menniti


Io dissaldavo il display...  ;)


no, tu semplicemente caricavi un tuo firmware nel tiny23 ed il display era pronto per lavorare "a modo tuo". ;)
Personalmente ci perderei un'oretta, cercando almeno di escludere gli standard.... in fondo basta inviare tre diverse stringhe per vedere se si riesce ad ottenere "0" sulla prima cifra :)
Manuale "Arduino e le tecniche di programmazione dei microcontrollori ATMEL"
http://www.michelemenniti.it/manuale_di_programmazione.html
http://www.michelemenniti.it/offerta.html
Articoli ElettronicaIN
http://www.michelemenniti.it/elettronica_in.html

leo72


no, tu semplicemente caricavi un tuo firmware nel tiny23 ed il display era pronto per lavorare "a modo tuo". ;)

Vero ah ah ah  :smiley-yell:


vitoos

allora ho fatto questo ragionamennto:
è un display,
ci sono 4 bcd 7segmenti,
quindi se mando "Wire.write (0b1111111111111111111111111111)" si dovrebbero accendere tutti e 28 i segmenti,
purtroppo non è così.
si accendono sempre random senza una logica, sarebbe bello capire cosa hanno scritto dentro all'attiny. se avete altre idee postate!
questo è l'ultimo sketch provato
Quote
#include <Wire.h>

void setup()
{
   Wire.begin(); // join i2c bus
}

void loop()
{
   Wire.beginTransmission(56); // transmit to device #44 (0x2c)
                               // device address is specified in datasheet
   Wire.write (0b1111111111111111111111111111) ;             // sends value byte 
   Wire.endTransmission();
   
   delay (1000);
}

tonid

#26
Jan 15, 2013, 07:03 am Last Edit: Jan 15, 2013, 08:01 am by tonid Reason: 1
Ciao,dal ragionamento che ti ha fatto astro che secondo il mio parere risulta logico
Quote
In base a quello che appare direi che è molto probabile che vengono controllati i singoli segmenti di ogni cifra in funzione dei bit del valore che invii, ovvero un byte è composto da 8 bit e 7 di questi corrispondono ai segmenti del display, se c'è anche il punto è legato all'ottavo bit.
Se invii una serie di valori dove metti a 1 solo un bit per volta per ogni byte in un attimo hai la codifica, usa il formato binario "0b00000000" mettendo a 1 solo un bit per volta.
Devi inviare 4 byte per volta, uno per ogni cifra del display, e non singoli byte per ogni invio.

dovresti fare una cosa simile a questa
Code: [Select]

#include <Wire.h>

void setup()
{
  Wire.begin(); // join i2c bus
}

void loop()
{
  Wire.beginTransmission(56); // transmit to device #44 (0x2c)
                              // device address is specified in datasheet
  Wire.write ((byte)0x00) ;             // primo byte
  Wire.write ((byte)0x00) ;             // secondo byte
  Wire.write ((byte)0x00) ;             // terzo byte
  Wire.write ((byte)0x00) ;             // quarto byte
  Wire.endTransmission();
 
  delay (1000);
}

In questo modo hai inviato 4 byte consecutivi tutti impostati a zero ed in teoria i segmenti del display dovrebbero risultare tutti spenti.
In ogni caso in base al risultato che otterrai potrai cercare di capire la codifica che è stata usata cambiando il valore dei byte come per esempio,se invii
Code: [Select]

   Wire.write ((byte)0x39) ;             // primo byte
  Wire.write ((byte)0x30) ;             // secondo byte
  Wire.write ((byte)0x37) ;             // terzo byte
  Wire.write ((byte)0x3F) ;             // quarto byte

e se non ho sbagliato i conti dovrebbe apparirti la scritta CIAO

tonid

A occhio,guardando le foto del cs che hai messo all'inizio si notano nella foto vista da sotto 4 transistor che sono probabilmente usati per abilitare i 4 display mentre i segmenti saranno pilotati direttamente dagli I/0 dell' attiny.
Ecco perchè vedo logico il discorso di astro,ognuno dei 4 byte che invii dovrebbero essere messi in memoria dell'attiny ed in base al valore di esso abilita il transistor relativo (ad esempio byte 1=transistor1)e trasferisce sul portx i dati relativi ai 7 segmenti(a,b,c,d,e,f,g) ad una data frequenza e continua a farlo finchè non cambi il valore dei byte.
Prova e facci sapere,ciao.

leo72


sarebbe bello capire cosa hanno scritto dentro all'attiny

Se il firmware non è protetto da lettura, potresti collegarti alla porta SPI del micro e fare il dump della memoria. Poi prendi un disassemblatore e trasformi il file binario in sorgente assembly e cerchi di studiarti il protocollo.
Molto difficile, ma non impossibile.


marcello.romani



sarebbe bello capire cosa hanno scritto dentro all'attiny

Se il firmware non è protetto da lettura, potresti collegarti alla porta SPI del micro e fare il dump della memoria. Poi prendi un disassemblatore e trasformi il file binario in sorgente assembly e cerchi di studiarti il protocollo.
Molto difficile, ma non impossibile.


Secondo me si fa prima a fare un reverse eng dell'hardware e riscrivere il codice da zero :)

Go Up