dix4192 и I2C

[r0cket]

Здравствуйте. Кто нибудь может подсказать по программированию этой микрухи ?
написал прогу для работы с и2ц. DS1307 работает все управляется нормально.

а эта микруха не отвечает. Могу прогу выложить. ДЛя пик18 ассемблер

[Alex]

а эта микруха не отвечает.

Адреса ей на 0 посадить не забыл, раз шлешь ей 0xE0 ?

P.S. по SPI проще.

[r0cket]

адреса посадил на 0. И ресет в начале сделал и задержки увеличил.
в даташите написанно что нужен SPI16 бит. а в пике он 8битный. поддержка ничего вразумительного сказать немогла (может я не так читаю)

[Turbo_man]

а в пике он 8битный

Так пошлите 2 байта, станет 16-ти битным.

[Alex]

в даташите написанно что нужен SPI16 бит. а в пике он 8битный.

Он почти везде 8-битный, а 16 бит решается посылкой CS через два байта.

[r0cket]

спасибо за совет, надо будет попробовать. Но если кто нибудь что нибудь знает про и2с буду тоже очень признателен )

[r0cket]

попробовал по СПИ. Тоже молчит. Есть какой нить способ как проверить что микруха вообще включилась или что она жива. А то танцы с бубном у трупа получаются.

по спи делал так

1) поднимаем опускам CS
2) шлем 01 (записываем в первую ячейку)
3) шлем 00
4) шлеи 3f
5) поднимаем опускам CS
6) шлем 81 (читаем из первой ячейки)
7) шлем 00
8) шлем ЕЕ (вроде не важно что слать на этапе считывания)

и микруха ничего не присылает в ответ =(

[pokos]

1) поднимаем опускам CS

Значит, дружище, в некоторых Техасовских микросхемах есть недокументированная фича - данные во входном регистре защёлкиваются по приходу положительного фронта CS. Так, например, обстоит дело со всеми PGA - попарился с ними тоже, в своё время.
Попробуй дёргать CS вверх опосля каждого байта.
Почему они не указывают это прямо в даташитах, я не понял. Хотя, на диаграмме это нарисовано, но непонятно, что это обязательно.

[r0cket]

попробую конечно но на диаграмме такого нет )

[pokos]

...но на диаграмме такого нет )

Смотри Figure 2 внимательно.

[Alex]

Не надо после каждого байта CS дергать.

Хотя, на диаграмме это нарисовано, но непонятно, что это обязательно.

Потому что это не только не обязательно, но и просто противопоказано в некоторых режимах.

Смотри Figure 2 внимательно.

Ты лучше на Figure 17 смотри внимательнее

[r0cket]

ага вроде как CS нужно что бы чтение и запись разделить, а если каждый раз дергать то он будет каждый раз адрес ячейки слать

[r0cket]

ап, мужики помогаем ))) как заработает выложу прошивку и схему могу нарисовать

[Turbo_man]

Я для аналогичных целей (управление периферией LM7001, 74HC595 итп.) вообще использую USART в синхронном режиме. Выше PIC16F628A ничего тут не нужно.

Вот кусочек кода из рабочей программы (передача 3-х байт в LM7001):
;--------------------------
PRD_7001
bsf PORTA,6
nop
nop
nop
nop
movfw DEL_0
call TX_W
movfw DEL_1
call TX_W
movfw UPR
call TX_W
bcf PORTA,6
return
;---------------------
TX_W
movwf TXREG
bsf STATUS,RP0 ; Перейти в 1-й банк
btfss TXSTA,TRMT
goto $-1
bcf STATUS,RP0 ; Перейти в 0-й банк
return






---------- Добавлено в 23:19 ---------- Предыдущее сообщение в 22:29 ----------

Паузы между байтами не являются проблемой совершенно.

[Alex]

Я для аналогичных целей (управление периферией LM7001, 74HC595 итп.) вообще использую USART в синхронном режиме.

USART в синхронном режиме - это классно, хотя и только мастер, но когда в проце мало полноценных SPI а надо больше и одновременно - USART сильно выручает. Я последнее время на SPI-шные дисплеи часто их использую.

[Turbo_man]

Offтопик:

хотя и только мастер

Почему? Мне пока не нужны были другие режимы, но передача-приём мастером-слейвом предусмотрены.

[r0cket]

заработало, 2 подряд микрухи были жженые ) вот жеж блин. всем спасибо. Если надо могу выложить прогу

[Alex]

Почему? Мне пока не нужны были другие режимы, но передача-приём мастером-слейвом предусмотрены.

Не во всех чипах USART может работать слейвом в синхронном режиме.

Если надо могу выложить прогу

Зачем? Да и ты ее уже выкладывал.