Będę podsłuchiwać !

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

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 ?

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.

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

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 )

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

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.

Michoo wrote: [..]

Jak programista do dupy to i program skopany.

[..]

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

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

Two Wire Interface - Atmelowa nazwa na I2C.

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

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

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ź !

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

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

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

W dniu 2013-02-14 21:48 sundayman napisał(a):

No to BusPirate i pozamiatane.

Ale nie chodzi mi o "rozgryzienie" co tam leci (bo to wiem, a poza tym od tego mam analizator ), tylko muszę zrobić urządź, który ma odebrać te dane wysyłane do LCD, i wykorzystać po swojemu - znaczy mój urządź będzie w innym, nie moim urządziu - i stąd taka potrzeba :)

W dniu 2013-02-17 02:15 sundayman napisał(a):

Nie widzę problemu. Sprzęt zostanie ten sam, zrobisz tylko własny "wsad". Zobacz na schemacie BusPirate jaki tam zastosowali procesor. Podczepisz sobie do niego LCD czy co tam potrzebne.