Jak podsłuchać dane I2C z procesora do LCD z użyciem PCF8584 w odpowiedniej częstotliwości?

Thu Feb 14, 2013 9:48 pm   

Skoro mogą różne CBA, CBŚ i inne, to i ja mogę.
Mianowicie chciałbym podsłuchać tajną i konspiracyjną wymianę po I2C
między pewnym podejrzanym procesorem a jeszcze bardziej podejrzanym
buforem wyświetlacza LCD.

I no - potem - świecąc lampą w oczy - muszę wyciągnąć potrzebne mi
informacje.

Wymyśliłem sobie, żeby jako przesłuchującego wykorzystać PCF8584 - ma
tryb monitor. Podsłuchane dane wysyłać do prokuratora Atmega, a on już
znajdzie odpowiedni paragraf...

Tylko zastanawia mnie taka rzecz - zmierzyłem, że częstotliwość na SCL
to ok. 76.92 kHz. Tak jakby trochę ni w pięć ni w dziewięć..?

Ponieważ ten PCF8584 wymaga zewnętrznego taktowania (ma tam odpowiedni
preskaler do tego celu), to jaka powinna być właściwie ta częstotliwość
dla niego ?

Dawno już nie miałem z I2C do czynienia - jak to jest, muszą być te
częstotliwości precyzyjnie dobrane ?

Thu Feb 14, 2013 11:04 pm   

W dniu 2013-02-14 21:48, sundayman pisze:

Taktowanie w I2C wyznacza master i częstotliwości taktowania mogą być
dość dowolne (w granicach określonych przez współpracujące układy). W
trakcie komunikacji częstotliwość taktowania nawet nie musi być stała...

Slave może jednak spowolnić taktowanie (gdyby z jakichś powodów nie
wyrabiał) poprzez tzw. "clock stretching" -- tj. poprzez przytrzymywanie
linii zegara w stanie niskim.

PCF8584 nigdy nie stosowałem więc się nie wypowiadam.

pzdr
mk

Thu Feb 14, 2013 11:51 pm   

W dniu 2013-02-14 23:04, mk pisze:

Czyli to by chyba znaczyło, że w sumie najlepiej taktować tego PCF jak
najszybciej, bo w sumie to wpływa tylko na timingi jego samego - czyli
jak szybko on zareaguje , i jego rejestry do odczytu itp...

Tak mi się wydaje ?

Fri Feb 15, 2013 12:16 am   

On 14.02.2013 23:51, sundayman wrote:

No dobra, ale czemu nie podepniesz po prostu SCL na int0/int1 w atmedze
a SDA na jakiś pin wejściowy? Odczytanie transmisji I2C będzie sporo
prostsze niż czytanie dokumentacji jak to skorzystać za PCF.

--
Pozdrawiam
Michoo

Fri Feb 15, 2013 1:02 am   

W dniu 2013-02-14 21:48, sundayman pisze:

http://www.nxp.com/documents/data_sheet/PCF8584.pdf
Strona 8 ,tabela 3

Masz dostępne możliwości na Clkin, następnie ustawiasz właściwe bity i
pcf wie dalej co i jak.

Jeżeli pracuje jako monitor to prawie tak samo jak slave tyle że nie
wystawia potwierdzeń.

IMHO musi sobie poradzić w pewnym zakresie f na scl. Wszystkie scalaki
jakie widziałem akceptuje scl >1kHz < 100kHz

PCF8584 akceptuje z tego co widzę od DC - 100kHz ( brak minimalnej f )

Fri Feb 15, 2013 2:08 am   

Ano dlatego po prostu, że chcę uniknąć dłubania w assemblerze, a to by
trzeba było zrobić, żeby ten podsłuch był pewny i stabilny imho.
Zależy mi na czasie, i wolę mieć z głowy sam protokoł I2C - konfiguracja
tego PCF nie wygląda strasznie.

Całe ustrojstwo mi potrzebne w 4 egz. więc parę dodatkowych zł nie robi
różnicy.

A akurat tryb monitora jest tam dość prosty - trochę się raczej obawiam,
żeby mi atmega nadążała za odbieraniem i zapisywaniem danych - dam
Atmega664PA z kwarce 18.342 Mhz.

Jak toto podzielę przez 4 w timerze 0 , a potem w PCF (za tabelką z
datasheeta PCF'a) to wyjdzie 1.5285 MHz - czyli chyba wystarczająco
bliska wskazanego 1.5MHz).

Fri Feb 15, 2013 4:31 am   

On 15.02.2013 02:08, sundayman wrote:

Jakim assemblerze? Najszybsza "normalna" prędkość to 300kHz. Nawet przy
8MHz to daje 26 cykli na odczytanie stanu i zrobienie przesunięcia - sporo.


Imho assembler to najkrótsza droga do niepewnego i niestabilnego programu.



Raczej automatu zajmującego się stanami I2C i tak nie unikniesz.


A atmega644(?) nie ma przypadkiem TWI z obsługą multi master? Wtedy
czytasz co się dzieje na lini tyle, że nie wystawiasz ACK.


--
Pozdrawiam
Michoo

Fri Feb 15, 2013 10:48 am   

Michoo wrote:
[..]

Jak programista do dupy to i program skopany.

[..]
--
AlexY
http://nadzieja.pl/inne/spam.html
http://www.pg.gda.pl/~agatek/netq.html

Fri Feb 15, 2013 5:01 pm   

W dniu 20

Jak nie, jak tak - PCF8584 odbiera w trybie monitor wszystko z I2C, i
wyrzuca to równolegle - do doczytania są ze dwie-trzy flagi ,
informujące o aktualnym stanie całego procesu.



A co to jest to TWI, bo jakoś nie miałem okazji (wstyd ?) ?

Fri Feb 15, 2013 5:40 pm   

On 15.02.2013 17:01, sundayman wrote:

Hmmm, będę musiał przeczytać dokumentację.


Two Wire Interface - Atmelowa nazwa na I2C.

--
Pozdrawiam
Michoo

Sat Feb 16, 2013 2:56 am   

Aaa, taka zamianaaaa !
No to muszę zobaczyć.

Co prawda siem już nastawiłem na tego PCF, ale jakby się dało z tego TWI
prosto skorzystać, to byłoby "eleganciej"...

Sat Feb 16, 2013 3:07 am   

No zgadza sie, ma to. Ale dlaczego w "multimaster". A nie jako slave po
prostu ?

Sat Feb 16, 2013 3:47 am   

No poczytałem, chyba to TWI atmegowe się da obsłużyć w miarę prosto, no
to rezygnuje z tego PCF.

Dzięki Michoo za podpowiedź !

Sat Feb 16, 2013 4:23 am   

Aaaa, zdrada !
Może jednak się nie dać ; wg . dataszita :

bit 6 TWEA - TWI enable - ACK bit ; wpisując zero, urządzenia jest
wirtualnie odłączane od I2C (to by można jeszcze zrozumieć - że tylko
"od strony mastera jest niewidoczne").

Ale dalej piszą, że "address recognition can then be resumed by writing
TWEA bit to one again".
Czyli - przy skasowanym nie będzie ACK, ale też nie będzie działać całe
to TWI.

Ktoś to potwierdzi albo obali ??

***

na AVR freaks znalazłem taki projekt :

If problems on the I2C bus occur, it was needed to see all data transfer
on it. The easiest way was using an AVR and send data over the UART.

But no ATmega can be used, because they can not listen only, not signal
a start and not receive different addresses.
So only the Attiny with USI can be used.

Thus the sniffer use the ATtiny85.
The output was done as text (hex numbers) at 115200 baud with 255 byte FIFO.
A crystal of 14.7456MHz was used to match the baud rate.

Version 2 added with some improvements. The C source can work with up to
230400 baud, the assembler source up to 460800 baud.

***

No, ale attiny dla mnie za mały...

Jeśli problem z tym wyłączaniem ACK się potwierdzi, to znaczy,
że muszę się przeprosić z tym PCF...

Sat Feb 16, 2013 4:49 am   

Tu jest niby sposób, żeby tego ACK nie "dopuścić" do I2C (wstawiona dioda) ;

http://alex.kathack.com/codes/avr/i2c_sniffer/index.html

ale nie bardzo rozumiem, po jaką cholerę wtedy autor chce korzystać z
SPI a nie normalnie TWI (tak zrozumiałem)...