caxapa.ru :: Если вдаваться в детали:

=AK= (30.07.2020 15:14, просмотров: 756) ответил =AK= на Хочу то ли страшилку рассказать, то ли в жилетку поплакаться. Пока сам не знаю.

Если вдаваться в детали:

EEPROM это I2C, и SHT35 - это тоже I2C. К сожалению, в конкретном устройстве они развязаны не полностью. Сигнал SCL у них общий, вот беда.

В промежутках между записями в EEPROM МК держит обе линии в нуле: SCL=0, SDA=0. Это возможно, поскольку общение с EEPROM однонаправленное. Чукча не читаль, чукча писатель.

В это время линия данных Н_SDA датчика SHT35 находится в 1, подтянутая резистором. Только когда идет общение с SHT35 - тогда МК начинает дергать ее вниз-вверх.

Однако в даташите на SHT35 сказано, что дерготня на SCL в то время как Н_SDA=1, воспринимается сенсором как "сброс интерфейса" - при условии что количество импульсов на SCL больше или равно 9, а затем следует START. Описание даташита неоднозначное и допускает разные толкования.

Однако "сброс интерфейса" по идее не должен влиять на результаты, считанные из SHT35. Кроме того, добавление всяческих программных сбросов перед дем как считать данные из SHT35 ничего не меняет - результаты все так же "осциллируют"

Питание устройства более-менее стабильно и ни фига не "осциллирует".

Ответить

- Я бы сделал вместо "частично развязанного" честный общий I2C. Samx(263 знак., 31.07.2020 17:43)
  - Я бы с удовольствием сделал все заново. Но реалии таковы, что я должен использовать имеющееся железо, в котором SCL сделан общим. =AK=(221 знак., 01.08.2020 02:41)
    - Осталось сделать общим и SDA (можно программно), чтобы получить честную I2C-шину с двумя девайсами. Samx(125 знак., 01.08.2020 12:39)
- еще гипотеза. используется I2C аппаратный или программный? Программный по правильному нужно делать через управление TRIS (эмуляция ОК/OD) а не PORT. По стандарту Slave может затягивать SCL. Если управлять через PORT, то редко (но возможно) появление конфликта (Slave удерживает SCL в нуле если не готов, а Master тянет его к 1) - отсюда лишние токи и/или неправильное считывание данных и/или подвешивание Slave (с автоматическим "развешиванием" последующим общением). - Илья(30.07.2020 18:29)
  - I2C программный. "Затягивание SCL" не используется. =AK=(414 знак., 31.07.2020 03:12)
    - я имею в виду что клок (SCL), т.е. длительность клоков Илья(797 знак., 31.07.2020 10:13, ссылка)
      - Все устройства на I2C известны, все 20 с лишним лет работало без проблем. =AK=(843 знак., 31.07.2020 11:57)
- > SCL=0, SDA=0. lloyd(23 знак., 30.07.2020 17:20)
  - Почему? Совершенно законная и очень обыденная комбинация. Например, после START и перед STOP всегда SCL=0, SDA=0. - =AK=(31.07.2020 03:17)
    - Но это не режим ожидания. Ожидающая шина - оба сигнала в единице - lloyd(31.07.2020 22:06)
      - А что в спецификации I2C запрещает мастеру выдать START, подождать сколько угодно, а потом выдать STOP? - =AK=(01.08.2020 02:59)
- А если анализатор прицепить и посмотреть, что по I2C читается? - Evgeny_CD(30.07.2020 15:21)
  - Завтра осциллом собираюсь смотреть времянки, хотя вряд ли чего путное увижу. =AK=(300 знак., 30.07.2020 15:30)
    - Но должна же быть причина, отличная от магии! - Evgeny_CD(30.07.2020 15:47)

Микроконтроллеры PIC