Все, нашел косяк.
Извиняюсь за возможный излишний гонор и благодарю за то, что заставили меня-таки усомниться в своей правоте
Мой косяк заключался в том, что я совершенно упустил тот момент, что после семплирования АЦПшкой последнего (нулевого) бита по спаду, должен происходить еще один фронт на SCK, перед тем, как поднимется CS... Вот это и было фатально. Получалось, что часть логики АЦПшки отрабатывала (за канал А), а другая часть ожидала фронта, который так и не приходил...
Второй косяк заключался в достаточно вольном трактовании разработчиком компилятора режимов SPI. Таким образом, как мне казалось, я пробовал режим 1 и режим 2, а на самом деле вместо режима 2 был режим 3 (а осциллографом в этот момент я, увы, не посмотрел — наблюдал активно и вымерял тайминги только в режиме 1). Почему я выбрал режим 1 не знаю. Видимо, смутило то, что свободное состояние SCK может быть нулевым и семплирование идет по спаду. Но необходимый при этом дополнительный импульс в конце я упустил
В общем, установил я жестко битами в регистрах режим 2 и оно все заработало. Так что, еще раз огромное спасибо! Пойду переписывать штатный модуль SPI по нормальному...
Да, за одно уж, на всякий случай: SPI.WriteByte делает первое, т.е. чекает, передает и снова чекает (и только потом передает управление назад). Так что там все стерильно, тем больее, на этот предмнет я осцилом смотрел внимательно (это было у меня самое первое предположение, что что-то, возможно, недопередается).
Отзовитесь кто работал с ЦАП TLV5638
Oct 6 2010, 01:43
