Таки дошли у меня наконец-то руки испробовать эти датчики в действии. Набросал
код.
Сразу наткнулся на дурость проектирования: если после команды "начать измерение" произвести считывание, датчик вернет 0 вместо того, чтобы сказать NACK. И в дальнейшем тоже будет возвращать 0. Т.е. нужно выдерживать после считывания паузу где-то в 10мс. Поллинг невозможен. Ну, да ладно: буду поочередно всем датчикам грозди слать команду "считай", потом по прошествии 10мс после последней команды поочередно читать. Надо еще подумать, чем коммутировать I2C. Пока думаю это делать дешевым мультиплексором на 8 каналов (не знаю, правда, получится ли).
По ходу работы наткнулся еще и на то, что я отЛУТил платки, не проверив предварительно в кикаде правильность. И прозевал две перемычки! Как ни странно, один датчик работает нормально, невзирая на это (хотя закоротить на +3.3В ногу выбора режима I2C вместо SPI нужно обязательно). Второй шалит в SCL, похоже пытается все-таки SPI делать (или я его спалил, когда паял). Напаять блямбу из припоя не помогло (либо не припаялась она нормально — попробуй к такому корпусу что-нибудь подпаяй; надо даже неиспользуемые ноги выводить подальше дорожками).
На будущее надо заЛУТить и спаять еще хотя бы одну платку, чтобы можно было проанализировать, насколько точны показания датчиков. Плохо только, что измерение температуры при их помощи требует расчетов по полиномам, т.е. STM32F042 стопроцентно этого делать не сможет — придется в начале работы с сервера запрашивать калибровочные коэффициенты всех датчиков, запоминать их, а затем уже преобразовывать.
И еще одна бяка: STM32F042 наглухо блокирует I2C в случае обнаружения другого мастера на шине, спасает только переинициализация. Надо читать мануал, почему такая гадость происходит.
