ViKo

На диаграмме видно, что DATA обновляется, когда ENA==1. У вас в куске проекта не видно ни ENA, ни DATA. Это стереокартинка. Недавно обсуждалась в "офтопике" :)

Думаю, у вас в проекте переполнение числа происходит. Нужно иметь на один разряд больше. Ну, и подавать, соответственно, на разряд сдвинутые выходы на DAC.

Примерно так, но не совсем. Измеряется время между моментом синхронизации и тактом частоты дискретизации. Оно коротенькое, не больше периода частоты дискретизации. Затем полученная реализация "втискивается" в нужное место в общем массиве сигнала, согласно рассчитанному времени. Через какое-то время забьются все свободные места в массиве. Разогнанные в 1.5 раза?! Дикари.

Старший бит могли и самом проекте потерять

Снова то же. Только с более старшим разрядом. Или с самым старшим. Паяете хорошо?

В этом АЦП есть CLK, CNV, DCO. Есть из чего сделать все, как надо. Генератор внешний получается, так он и был внешний :) Частоту преобразования задавать CNV с ПЛИС, а CLK будет более высокой, как требует ФАПЧ в ПЛИС. Данные в ПЛИС загонять по DCO, а внутри на высокой частоте защелкивать с учетом состояния DCO.

Один из вечных вопросов. Может, данная дискуссия поможет http://electronix.ru/forum/index.php?showtopic=77779

Мне попадался полином x^8 + x^2 + x + 1 (CRC-8-Dallas/Maxim) Для него я написал программу, но потом не использовал, так что в работоспособности не поручусь на 100%. /* *********************************************************************** * Расчет циклического избыточного кода CRC для массива сообщения * Используется полином x^8 + x^2 + x + 1 (CRC-8-Dallas/Maxim) * Задается указатель на начало рассчитываемых байтов в массиве, * количество байтов, участвующих в расчете (ровно) * начальный код CRC (если считается не с начала массива), * Для ускорения расчета используется таблица ***********************************************************************/ char calcCRC(char *Ptr, char Num, char CRC) { const char CrcTable[256] = { 0x00, 0x07, 0x0e, 0x09, 0x1c, 0x1b, 0x12, 0x15, // 00 0x38, 0x3f, 0x36, 0x31, 0x24, 0x23, 0x2a, 0x2d, // 08 0x70, 0x77, 0x7E, 0x79, 0x6C, 0x6B, 0x62, 0x65, // 10 0x48, 0x4F, 0x46, 0x41, 0x54, 0x53, 0x5A, 0x5D, // 18 0xE0, 0xE7, 0xEE, 0xE9, 0xFC, 0xFB, 0xF2, 0xF5, // 20 0xD8, 0xDF, 0xD6, 0xD1, 0xC4, 0xC3, 0xCA, 0xCD, // 28 0x90, 0x97, 0x9E, 0x99, 0x8C, 0x8B, 0x82, 0x85, // 30 0xA8, 0xAF, 0xA6, 0xA1, 0xB4, 0xB3, 0xBA, 0xBD, // 38 0xC7, 0xC0, 0xC9, 0xCE, 0xDB, 0xDC, 0xD5, 0xD2, // 40 0xFF, 0xF8, 0xF1, 0xF6, 0xE3, 0xE4, 0xED, 0xEA, // 48 0xB7, 0xB0, 0xB9, 0xBE, 0xAB, 0xAC, 0xA5, 0xA2, // 50 0x8F, 0x88, 0x81, 0x86, 0x93, 0x94, 0x9D, 0x9A, // 58 0x27, 0x20, 0x29, 0x2E, 0x3B, 0x3C, 0x35, 0x32, // 60 0x1F, 0x18, 0x11, 0x16, 0x03, 0x04, 0x0D, 0x0A, // 68 0x57, 0x50, 0x59, 0x5E, 0x4B, 0x4C, 0x45, 0x42, // 70 0x6F, 0x68, 0x61, 0x66, 0x73, 0x74, 0x7D, 0x7A, // 78 0x89, 0x8E, 0x87, 0x80, 0x95, 0x92, 0x9B, 0x9C, // 80 0xB1, 0xB6, 0xBF, 0xB8, 0xAD, 0xAA, 0xA3, 0xA4, // 88 0xF9, 0xFE, 0xF7, 0xF0, 0xE5, 0xE2, 0xEB, 0xEC, // 90 0xC1, 0xC6, 0xCF, 0xC8, 0xDD, 0xDA, 0xD3, 0xD4, // 98 0x69, 0x6E, 0x67, 0x60, 0x75, 0x72, 0x7B, 0x7C, // a0 0x51, 0x56, 0x5F, 0x58, 0x4D, 0x4A, 0x43, 0x44, // a8 0x19, 0x1E, 0x17, 0x10, 0x05, 0x02, 0x0B, 0x0C, // b0 0x21, 0x26, 0x2F, 0x28, 0x3D, 0x3A, 0x33, 0x34, // b8 0x4E, 0x49, 0x40, 0x47, 0x52, 0x55, 0x5C, 0x5B, // c0 0x76, 0x71, 0x78, 0x7F, 0x6A, 0x6D, 0x64, 0x63, // c8 0x3E, 0x39, 0x30, 0x37, 0x22, 0x25, 0x2C, 0x2B, // d0 0x06, 0x01, 0x08, 0x0F, 0x1A, 0x1D, 0x14, 0x13, // d8 0xAE, 0xA9, 0xA0, 0xA7, 0xB2, 0xB5, 0xBC, 0xBB, // e0 0x96, 0x91, 0x98, 0x9F, 0x8A, 0x8D, 0x84, 0x83, // e8 0xDE, 0xD9, 0xD0, 0xD7, 0xC2, 0xC5, 0xCC, 0xCB, // f0 0xE6, 0xE1, 0xE8, 0xEF, 0xFA, 0xFD, 0xF4, 0xF3 // f8 }; do CRC = CrcTable[CRC ^ *Ptr++]; while (--Num); return CRC; }

Вот именно.

А в одном масштабе по времени можете показать? А то непонятно, что вы интерполируете. А кривизна, скорее всего, от реализации - недостаточная разрядность или просто ошибка.

Как лицо, похожее на интеллигента, считаю, что выбрасывать отсчеты "на ветер" неразумно. Куда лучше их использовать для фильтрации, взять, хотя бы, среднее из восьми. Делается очень легко. Для топикстартера а назвать АЦП можете?

Не просветите, как это делается, и во сколько обойдется в конечном итоге. Заманчивое предложение.

А формулы, по которым считали, можете привести? Вот здесь я нашел конкретные формулы, а не голые слова http://gwyddion.net/documentation/user-guide-ru/index.html

Нет, у меня сдвиг по RGB - субпискельный. Примерно, как под цифрой 7 на рисунке по ссылке: http://ru.wikipedia.org/wiki/ClearType Это уже в самой программе рисования символов делается. Только, немножко однобокий сдвиг получается, неполный набор, для простоты. Только rgb, rgB, RGb, RGB (маленькие буквы - выключен субпиксел, большие - включен). И - никакой коррекции яркости. Выложите парсилку, отчего ж не посмотреть.

Похоже, вы правы. При частоте 3MHz (333ns) джиттер в 300ps составляет чуть меньше 1/1000. Для 10-разрядного АЦП это, может быть, и подошло бы... Из области "бредовых идей" - запустите АЦП от генератора 6MHz (если позволит), и прореживайте на 16.

Так не будет никакой PLL, чисто логика. Только из-за помех по питанию будут скакать пороги переключения, но для такой низкой тактовой частоты вряд ли это приведет к ощутимому джиттеру.

Не для программы на C, а для симулятора.

Ток от источника питания будет течь с разъема J2 через реле, драйверы, на землю и назад на разъем J2. Если плата разведена "не очень хорошо", на земляных цепях могут появиться падения напряжения, импульсы, которые повлияют на логику. А если земли много, то не страшно.

А что бы не взять генератор на 12 MHz, поделить на 4 и подать на АЦП, а неподеленную - в ПЛИС. Наверное, фазовый шум не сильно ухудшится? И поделить частоту прямо в ПЛИС?

Не тот проект, где использовалась связь на 433MHz и самопроизвольно стиралась flash-память? И в чем было дело?

STM32 или подобное от NXP - лучшее, на что можно потратить свое время. Книжки появятся, не сомневайтесь. А на английском уже есть. Документации, примеров, плат - куча.

С чего это вдруг? Каждое звено использует только то, что приходит к ним на вход. И не использует то, что сами рассчитали. А вот если охватить все эти звенья обратной связью, подать выходные данные на вход - получим IIR. Годится?

http://search.analog.com/search/default.as...CG&local=en

Из приведенных формул не совсем понятно, какие индексы подразумеваются для отсчетов y. Но если в выражении используются не только входные данные (x), но и выходные (y), рассчитанные чуть раньше, то это будет фильтр с бесконечной импульсной характеристикой (БИХ, по-английски IIR). Если бы использовались только входные данные, это был бы фильтр с конечной импульсной характеристикой (КИХ, по-английски FIR).

Ну, и какая картинка соответствует новой? Правая? Технологические нормы изменились? Так, может вы ее при пайке портите? Или статическим электричеством. Зима, как-никак...