ViKo

А я ставлю на то, что резисторный делитель от проходящего тока нагревается, возможно и соседа своего, подключенного к средней точке, греет слегка. В результате их сопротивление возрастает. Все это приводит к тому, что делитель, состоящий из резистора в обратной связи и выше упомянутых, создающий пороги переключения, начинает делить меньше. Т.е. пороги переключения (гистерезис) растут, времена заряда-разряда конденсатора увеличиваются, частота уменьшается. (а написано - увеличивается. как же так? :)) Решение - увеличить на два порядка сопротивления резисторов, и на столько же уменьшить емкость конденсатора, и ТКЕ сменить.

и нагревается эта емкость тем самым резистивным делителем

Как правильно заметил xemul, один только резистивный делитель R394, R395 будет рассеивать, конкретно 25mW

... последовательно с 2.4K + 510/2, и параллельно с 36К. Хотя суть вопроса отражает не это. И это всё? Генератор ни к чему не подключен? А проводник, идущий вправо? upd. и вообще, что там еще рядом имеется?

А нагружен генератор на что? А элементы лучше ставить точные, потому что они еще и более стабильные. Когда ОУ работает, он нагревается, и нагревает своих ближайших соседей. А X7R, по-вашему - хороший ТКЕ?

1. До недавнего времени самыми быстродействующими были микросхемы ЭСЛ логики, которые обычно запитывались от -5V, а пороги срабатывания у них были что-то около -1...-2V.

его и имел в виду Так, как у вас написано, и человек не сможет определиться с выбором. Можно сделать так, например casex (sel) 4'b1xxx : rezult = data_e; 4'b01xx : rezult = data_d; 4'b001x : rezult = data_c; 4'b0001 : rezult = data_b; 4'b0000 : rezult = data_a; endcase

Ну почему же "не соответствует"? Обратная связь есть. Рассмотрите нижний блок, подайте на свои входы логические сигналы и посмотрите, что получится.

Ну, вот здесь, например. Кстати, в соответствии с выше приведенной цитатой :) http://electronix.ru/forum/index.php?showt...st&p=851601

Спасибо. Да, просто и со вкусом. И, как мне на первый взгляд кажется, отсутствуют "недопустимые" коды, т.е., нет избыточности. Конечно, если потерять хотя бы один байт, весь остаток кода будет испорчен. Но в ПЛИС даже часть правильного кода не нужна. Надо взять на вооружение. Рояльти платить не требуется? :) И еще, по-моему, ничего страшного не произойдет, если послать в ПЛИС чуть больше кода. Лишние биты проигнорируются.

Не могли бы вы показать, во что превратится код из примера в сообщении №6, закодированный © Ivan Mak, а то из вашего описания я не понял, как он работает.

Вот именно :)

Может быть, все-таки 16-й разряд никакого влияния не оказывает на работу схемы? Задача ПЛИС - что-то принять по входам, обработать, и что-то выдать наружу. Если на прием входных сигналов или выдачу выходных этот разряд не влияет, то он будет выброшен синтезатором.

Я понимаю символьную синхронизацию как синхронизацию по передаваемому символу, например, 0x55. То есть, приняли символ "U" (0x55) - значит, это начало передаваемого сообщения.

Дело не в символьной синхронизации, а в том, что синхронизируется UART по стартовому биту в начале приема символа. И к концу приема набегает погрешность. Если частота кварца сдвинута на 3%, то к 10-му биту момент выборки бита сдвинется на 30%. Еще нужно учесть, что обычно выборок бита берется несколько, сдвинутых по времени, и бит определяется мажоритарным способом. Поэтому при большей погрешности уже нельзя будет правильно определить последние биты в передаваемом слове.

Перед децимацией вам нужен фильтр, который предотвратит наложение спектра из-за того, что частота дискретизации уменьшилась в 20..40 раз. Т.е., он должен отрезать все, что больше (Fs/20)/2 ... (Fs/40)/2. Фильтром КИХ с 5-ю отводами это сделать невозможно. Наверное, нужно иметь не менее 20...40 отводов. Другое дело, если спектр входного сигнала изначально уже обрезан. Можно попытаться сделать децимацию в 2 этапа, например, сначала в 8 раз, потом в 5. А форма окна - даже треугольная будет лучше прямоугольной. Боковые лепестки АЧХ уменьшатся, за счет расширения, к сожалению, основного лепестка. Можете выбрать коэффициенты, ближайшие к кратным степени 2, простейший пример: 0.25 0.5 0.25 (конечно, этот фильтр не для вашего случая). А что, если сделать не в 2 этапа, а в 5, например?

Какой длины регистр, отводы от каких разрядов? А спектр как смотрели? По-моему, он не должен быть равномерным, а sin(x)/x огибающая, зависящая от тактовой частоты, и внутри куча палок, зависящая от периода повторения последовательности (длины регистра). Хотя, может, и ошибаюсь. Сейчас гляну куда-нибудь. Глянул - все так, как я сказал. Т.е., только в самом начале спектр примерно равномерный, потом спадает...

Можно сделать еще "хитрее", если подмешать источник шума на ПСП к сигналу, а после преобразования его же вычесть математически из полученного кода.

А так...? static const char image[131000] = {bla, bla, bla ...}; Без static каждый раз константная переменная в функции создается заново при входе (звучит по-идиотски, конечно :))

Я отвечал XVR, показал, что компилируется. Что там у TC, не вникал. Не сомневаюсь, что тоже реализуемо.

Такое годится? Трудно понять, но, кажется, делает, что задумано. Ни ошибок, ни предупреждений. static const uint8_t a = 'A', b = 'B', c = 'C', d = 'D'; static const uint8_t *pa = &a, *pb = &b, *pc = &c, *pd = &d; static const uint8_t **ptr[] = {&pa, &pb, &pc, &pd}; for (int32_t i=0; i<4; i++) GPIOA->ODR = **ptr[i]; Результат компиляции: ;;;210 static const uint8_t a = 'A', b = 'B', c = 'C', d = 'D'; ;;;211 static const uint8_t *pa = &a, *pb = &b, *pc = &c, *pd = &d; ;;;212 static const uint8_t **ptr[] = {&pa, &pb, &pc, &pd}; ;;;213 for (int32_t i=0; i<4; i++) GPIOA->ODR = **ptr[i]; 0000b4 4965 LDR r1,|L1.588| 0000b6 2000 MOVS r0,#0 0000b8 3120 ADDS r1,r1,#0x20 |L1.186| 0000ba f8513020 LDR r3,[r1,r0,LSL #2] 0000be 681b LDR r3,[r3,#0] 0000c0 781b LDRB r3,[r3,#0] 0000c2 f8c2380c STR r3,[r2,#0x80c] 0000c6 1c40 ADDS r0,r0,#1 0000c8 2804 CMP r0,#4 0000ca dbf6 BLT |L1.186|

Так я ж не спорю о том, что Digit[j] и *(Digit + j) - это одно и то же. Наоборот, подтверждал. :) А удивляюсь я тому, что известное правило отказываться от индексной арифметики в пользу адресной для ARM не работает. Может быть, для многомерных массивов все "вернется на круги своя"... Должна компилироваться!:) Скорее всего, что-то не так определено.

Насчет скобок - согласен, можно без них. Просто тяжелее воспринимать. Убрал. В книжках их, кстати, пишут. По той же причине. Насчет взятия элементов с конца массива - упустил из виду. Не сомневаюсь, что результат не изменится. Зря не сомневался :) Начинать-то нужно с нуля, потом инкрементировать счетчик и сравнивать с 10. Стало на 2 байта больше. А система команд - Thumb-2 называется. Виноват. Имел в виду систему команд от фирмы ARM. Опять же, это чисто качественный пример. Для ARMv4 команды для двух арифметик тоже будут разные.

;;;202 static const uint8_t Digit[10] = {'0','1','2','3','4','5','6','7','8','9'}; ;;;203 const uint8_t *pDig = Digit; 000092 4870 LDR r0,|L1.596| ;;;204 for (int32_t j=9; j>=0; j--) GPIOA->ODR = *(pDig++); 000094 4970 LDR r1,|L1.600| 000096 2209 MOVS r2,#9 |L1.152| 000098 f8103b01 LDRB r3,[r0],#1 00009c f8c1380c STR r3,[r1,#0x80c] 0000a0 1e52 SUBS r2,r2,#1 0000a2 d5f9 BPL |L1.152| 0000a4 4a6b LDR r2,|L1.596| ;;;205 for (int32_t j=9; j>=0; j--) GPIOA->ODR = Digit[j]; 0000a6 2009 MOVS r0,#9 |L1.168| 0000a8 5c13 LDRB r3,[r2,r0] 0000aa f8c1380c STR r3,[r1,#0x80c] 0000ae 1e40 SUBS r0,r0,#1 0000b0 d5fa BPL |L1.168| Это ничего не меняет. Отличия именно в адресации элементов массива. Похоже, разработчики ARM специально "подрихтовали" процессор под C.

То, что показал - лучшее. Прошелся по всем вариантам оптимизации. На мой взгляд, компилятор не должен быть настолько умным, как вы говорите. :) Еще попробовал заменить тип переменных в массиве на uint16_t и uint32_t. В первом случае коды для адресной и индексной арифметик сравнялись, а во втором индексная арифметика опять вырвалась вперед.