alexPec 3 3 февраля, 2011 Опубликовано 3 февраля, 2011 · Жалоба Последовательный синхронный интерфейс, если по входу SCLK проскочит ложный импульс (помеха или програмно ошибочно) или наоборот нехватит, то все данные сдвинутся и пойдет ересь пока не сбросиш. Нада осцилом проконтролировать этот вход и устранить помеху или сбрасывать перед каждым циклом АЦП, посылая 4 байта FF FF FF FF в АЦП. Кстати да, такая фигня была с dds-ом. Ткнешся тестером на ногу интерфейса - и привет, пока master reset не дернешь - ничего не прочитаешь и не запишешь. Там даже фреймовой синхронизации нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 24 4 февраля, 2011 Опубликовано 4 февраля, 2011 · Жалоба С чтением ID и калибровок нашел ошибку у себя - просто еще из прерывания проезжался по чтению (все время видел одну и туже картину, не мог понять почему, alexpEC подтолкнул, :a14: ). А вот с чтением измеренного значения дела обстоят так. При запуске однократного преобразования, нужно как можно скорее, после завершения преобразования, прочитать данные. Данные остаются годными для времени преобразования: 32 миллисекунды - надо прочитать в течении 32 мс 40 мс - в течение 24 мс 48 мс - в течение 18 мс 60 мс - в течение 8 мс Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 4 февраля, 2011 Опубликовано 4 февраля, 2011 · Жалоба Данные остаются годными для времени преобразования: 32 миллисекунды - надо прочитать в течении 32 мс 40 мс - в течение 24 мс 48 мс - в течение 18 мс 60 мс - в течение 8 мс Всё более-менее логично. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alexPec 3 4 февраля, 2011 Опубликовано 4 февраля, 2011 · Жалоба Данные остаются годными для времени преобразования: 32 миллисекунды - надо прочитать в течении 32 мс 40 мс - в течение 24 мс 48 мс - в течение 18 мс 60 мс - в течение 8 мс Похоже на то что входной sampling amplifier имеет свое УВХ, построенное наверняка на конденсаторах, кторые держат заряд примерно 60 мс, а преобразование наверняка начинается по клокам синхронного интерфейса. Не прочитали за 60 мс - все, заряд ушел... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
firstvald 24 4 февраля, 2011 Опубликовано 4 февраля, 2011 · Жалоба Да не логично. Однократное преобразование. Закончилось - данные перенслись в дата регистр, в статусе сбросили занятость. А потом почему все это портится со временем? Все должно остановиться. Там видно автомат продолжает молотить и схема куда-то улетает. Какие то атавизмы от последовательного преобразования остались. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tolyaha 1 7 февраля, 2011 Опубликовано 7 февраля, 2011 · Жалоба Там видно автомат продолжает молотить и схема куда-то улетает. Какие то атавизмы от последовательного преобразования остались. Специально проверил АЦП 7793, выполняя следующую последовательность действий: SendByteAD (0xff); // сброс АЦП (4 посылки 0xff) SendByteAD (0xff); SendByteAD (0xff); SendByteAD (0xff); - пауза 1 ms для сброса АЦП; SendByteAD (0x10); // настройка АЦП для записи в CONFIG регистр SendByteAD (0x10); // запись в CONFIG регистр HB (однополярный режим, усиление 1) SendByteAD (0x10); // запись в CONFIG регистр LB (1 канал c буфером) SendByteAD (0x08); // настройка АЦП для записи в MODE регистр SendByteAD (0x20); // запись в MODE регистр HB (Single Conversion) SendByteAD (0x01); // запись в MODE регистр LB (Internal 64 kHz Clock, 4 ms conversion) - пауза 5 s для проверки предположения об утрате данных АЦП; SendByteAD (0x58); // настройка АЦП для чтения данных ReadByteAD (); // чтение данных АЦП 1 байт ReadByteAD (); // чтение данных АЦП 2 байт ReadByteAD (); // чтение данных АЦП 3 байт Данная последовательность дает правильное значение измерения, все работает как положено и данные не теряются. Смотрите внимательнее свой алгоритм работы с АЦП. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться