Добрый день всем. АЦП указанного камушка очень часто выдает лживые показания тяготеющие к крайним значениям разрядности. Нарисовать софтовый фильтр отсекающий эти выбросы и независающий при быстрых изменениях сигнала не удалось. Найти описание глюка у NXP и методы борьбы тоже никак. По поиску в инете и здесь на форуме вижу что проблема мне не приснилась. О ней говорят многие но вот никого поборовшего не встретил.. Посему творческий тупик.... Есть изделие с разведенной и натиражированной платой и нет софта, могущего быть отпущеным в жизнь.... КАК БЫТЬ???

Не знаю как у 1766, а LPC1768 АЦП работает без нареканий, думаю, что проблемы могут быть в софте. Возможно, у вас неправильное преобразование знакового числа.

Эти люди видимо тоже все не умеют преобразовывать знаковые числа при выводе отсчетов АЦП в терминал или на ЖКИ??? http://electronix.ru/forum/index.php?showt...99&hl=lpc17 Поделились бы лучче куском кода вокруг АЦП, глядишь бы всем полегчало. Мот вы филосовский камень в руках держите, а не знаете. Удачи.

Я брал пример из Кейла. Если конечно полегчает, пожалуйста.

"Здоровых нет - есть недообследованные" ©.
Рассказали бы что ли - в каком режиме АЦП работает, сколько каналов, какие настройки, кусочком кода поделились с народом. А то у меня на одной и той же физически плате, и с 99% одинакового С-кода, LPC2368 работает, а вот LPC1768 необъяснимые нули при измерении VBUS_USB (делитель 22k/22k) выкидывает изредка, причем только если по USB активный обмен идет. Цепляешь эту цепь VBUS на соседний канал, который спокойно до этого мониторил термодатчик - и он тоже начинает нули кидать. Помех 300МГц осциллоскопом не видно, даже триггер не срабатывает, 1000пФ стоит прямо у ноги. Как программно в DR ADC сформировать 0 - неясно ни разу, регистр же только на чтение. Физически нуля у меня там быть не может, поэтому фильтруется это дело "на раз" и на изделие не влияет, но загадка есть, однако. А я загадки не люблю.
P.S. Кстати, надо будет еще помониторить на предмет 0xFFF, а то у меня только нижний предел проверялся.

Вот и именно что эфэфэф...... замкнул вход ацп на землю кусочком медной проволочки длинной миллиметров 8-9. Сто раз в секунду запускаю преобразование, по прерыванию достаю содержимое ДР. Если больше переменной максимум_показаний то максимум_показаний=ДР, если меньше переменной минимум_показаний то минимум_показаний=ДР, ну и переменная последнее_показание=ДР. Вывожу все три переменные на экран жки. Через секунду-две переменная максимум_показаний рисует на экране опупительную цифирь 4095. Застрелиться.




Я видел этот пример, и пробовал его запускать, только переработав слегка, я вставил туда ловушки неверных отсчетов, как описал выше.... Ловушки ловили взахлеб. А вы уверенны что у вас не было 1/1000 ной неверных показаний???? Ваша последующая математика к ним чувствительна??? моя да...

Наверное для моей задачи это было не критично, я считывал показания раз в 2 сек. Попробую пожже на ките проверить может там действительно что то не то...
После проверки, вышеуказанных глюков не обнаружил. Тестил на разных скоростях, в burst и без него, считал минимумы максимумы за несколько секунд собирал данные - FFF и 0 не возникало.
Предлагаю выложить вашу реализацию, тогда может станет что то понятно.

LPC176x/175x 12-bit ADC design guidelines читал?
Сам использую LPC1768. Испытывал те же проблемы. Оказалось - не развязал земли.

Агаблинщас!

http://electronix.ru/forum/index.php?showtopic=93543

Спорить я с вами не собираюсь, могу в принципе и видео выложить.
Вот мой проект для теста АЦП.

Ребят, если не сложно. Кто реально тестировал процы на "проблему в LPC176x", указывайте по возможности все коды, что приведены на корпусе камня и сигнатуры, полученные через Flash Magic, например. Может по статистике что-то отловится. У нас пока только идёт внедрение LPC176x, но уже порядка 4-х видов массовых изделий отгружается. Программисты предупреждены, но пока не столкнулись с этим (почти у всех медианные фильтры в коде, на подробное изучение времени нет, а скорости АЦП низкие). Использовали LPC1763, LPC1767, LPC1768.