Скрипач, пророк (21.01.2010 20:42, просмотров: 235) ответил Ксения на У меня всё на одной плате. Глюков не было, т.к. я всегда устанавливаю CS и сбрасываю его после прочтения. Но из-за этого у меня 4 штуки дополнительных (помимо ADuM) оптронных развязчиков (2 x HCPL063A) для каждого из сигналов DREADY. Такая конструкция... но не любой ценой.
-
- Так если б зависание было, но без проблем. А то тут из АЦП всегда что-то прочтешь и дури не заметишь. Проблема в том, что устройство работает НЕПРЕРЫВНО, не выключаясь месяцами. Вот и у меня мандраж на тему, что вдруг за это время один битик пропадет. - Ксения(21.01.2010 20:56)
- Ключевое - дурь прочтешь и не заметишь. "Дурь" должна быть высшей очистки :) Остальное полумеры и, частенько, самообман. - Скрипач(21.01.2010 23:42 - 23:51)
- правильно делаете, что боитесь. И не слушайте вредных советов по поводу ненужности синхронизации - koyodza(21.01.2010 22:26)
- Не правильно меня поняли. Просто я считаю что зря вы отвергаете схему "контроль СRC". Для данной задачи она более адекватна чем "мультивибратор". Скрипач(39 знак., 21.01.2010 23:28)
- АЦП никакого CRC не выдает, поэтому "дурь" проверить таким образом невозможно. - Ксения(22.01.2010 02:12)
- У вас "Free running conversion"? Тогда любой не-нулевой (все нули) ответ со стороны АЦП - гарантия корректного ответа. - Скрипач(24.01.2010 18:27)
- Можно время от времени читать содержимое какого-либо регистра с известным значением - Shura(22.01.2010 10:52)
- Вообще-то мысль! Но хотелось бы удостовериться, не дурью ли я сама маюсь - вдруг АЦП сам синхронизируется в моменты поднятия DREADY? Ведь не исключено, что в момент готовности очередной точки он забывает предысторию предыдущей, в том числе и частично Ксения(20 знак., 22.01.2010 12:57)
- Сама по себе синхронизация не решает проблемы контроля целостности данных. "CRC" контролировать все равно прийдеться. - Скрипач(22.01.2010 20:05)
- а нужен ли Вам DRDY? Может просто опрашивать с жёстким периодом, заведомо больше времени преобразования? - koyodza(22.01.2010 17:18)
- +1, это самое простое и надёжное. +20% к времени преобразования всё равно рояли не играет как правило - Shura(22.01.2010 17:27)
- А не способно ли такое решение само сорвать синхронизацию в тех случаях, когда DREADY угороздит выскочить во вреня моего опроса? Например, запрос у меня 3-байтный. Послала первые 2 байт - АЦП скушал, и тут DREADY выскочил, досылаю 3-ий байт - что я Ксения(440 знак., 23.01.2010 16:44)
- там буфер есть. Дочитаете то, что начали вычитывать. К тому же период нужно брать больше максимального времени преобразования, тогда описанная Вами ситуация может возникнуть только в аварийных случаях - koyodza(23.01.2010 17:50)
- Так период у сигма-дельта АЦП совпадает с периодом преобразования. Т.е. в периодическом режиме он непрерывно "накапливает" значение, а при окончании периода выдает DREADY, тут же приступает к "накоплению" в следующем периоде. В этом режиме у него нет Ксения(303 знак., 23.01.2010 18:40)
- что-то Вы уже как доктор, ответов на свои же вопросы не слушаете. Повторю: период нужно брать больше максимального времени преобразования, тогда описанная Вами ситуация может возникнуть только в аварийных случаях - koyodza(23.01.2010 22:15)
- не натолкнётся. Двойное буферирование: один буфер на преобразование, второй в интерфейсе. Внимательное изучение даташита поможет - koyodza(23.01.2010 21:34)
- Так период у сигма-дельта АЦП совпадает с периодом преобразования. Т.е. в периодическом режиме он непрерывно "накапливает" значение, а при окончании периода выдает DREADY, тут же приступает к "накоплению" в следующем периоде. В этом режиме у него нет Ксения(303 знак., 23.01.2010 18:40)
- там буфер есть. Дочитаете то, что начали вычитывать. К тому же период нужно брать больше максимального времени преобразования, тогда описанная Вами ситуация может возникнуть только в аварийных случаях - koyodza(23.01.2010 17:50)
- более того, чаще как раз фиксированное время и нужно - koyodza(22.01.2010 17:34)
- А не способно ли такое решение само сорвать синхронизацию в тех случаях, когда DREADY угороздит выскочить во вреня моего опроса? Например, запрос у меня 3-байтный. Послала первые 2 байт - АЦП скушал, и тут DREADY выскочил, досылаю 3-ий байт - что я Ксения(440 знак., 23.01.2010 16:44)
- +1, это самое простое и надёжное. +20% к времени преобразования всё равно рояли не играет как правило - Shura(22.01.2010 17:27)
- Так это ж проверить несложно если он есть под руками. Скорее всего оно так и есть. - Shura(22.01.2010 13:08)
- 1258 синхронизируется по отсутствию SCK в течении определенного времени (256 или 4096 периодов тактовой), я этим пользовался. У 1255 этого кажется нет - koyodza(22.01.2010 13:05)
- Есть: "If SCLK is held low for 32 DRDY periods, the serial interface will reset and the next SCLK pulse will start a new Ксения(81 знак., 22.01.2010 13:22)
- это совсем не одно и то же. В 1258 намного удобнее koyodza(107 знак., 22.01.2010 17:13)
- С длительным отсутствием всё ясно. Но происходит ли такая синхронизация в момент установки DREADY? Пока на этот вопрос никто не ответил, хотя я его задала в этой теме уже трижды. - Ксения(22.01.2010 13:09)
- Есть: "If SCLK is held low for 32 DRDY periods, the serial interface will reset and the next SCLK pulse will start a new Ксения(81 знак., 22.01.2010 13:22)
- Вообще-то мысль! Но хотелось бы удостовериться, не дурью ли я сама маюсь - вдруг АЦП сам синхронизируется в моменты поднятия DREADY? Ведь не исключено, что в момент готовности очередной точки он забывает предысторию предыдущей, в том числе и частично Ксения(20 знак., 22.01.2010 12:57)
- АЦП никакого CRC не выдает, поэтому "дурь" проверить таким образом невозможно. - Ксения(22.01.2010 02:12)
- Не правильно меня поняли. Просто я считаю что зря вы отвергаете схему "контроль СRC". Для данной задачи она более адекватна чем "мультивибратор". Скрипач(39 знак., 21.01.2010 23:28)
- Так если б зависание было, но без проблем. А то тут из АЦП всегда что-то прочтешь и дури не заметишь. Проблема в том, что устройство работает НЕПРЕРЫВНО, не выключаясь месяцами. Вот и у меня мандраж на тему, что вдруг за это время один битик пропадет. - Ксения(21.01.2010 20:56)