ViKo

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

Из чересстрочной развертки методом интерполяции сделать прогрессивную. Не DSP? Синхроимпульсы выделить. То, что выходит с селектора каналов, сразу на АЦП и не подашь. А усилить, детектировать. А АРУ? Отфильтровать видео от аудио. Декодировать цвет... и др.

Я бы не убирал дроссель, а переставил его на вход линейного стабилизатора, который от НЧ помех избавит, а вот от ВЧ уже не сможет. А проблема, мне кажется, чисто в программе. Не стабильно работает, потому что так написана. Я не нашел, Вы сравнивали содержимое PIC после сбоев со своим кодом?

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

Так это - к автору темы. Можно, вроде и в AD ПЛИСы раскладывать. Но он то делал в Quartus, в графическом редакторе. Спрашивал, можно ли зафиксировать. Я обычно раскидываю ноги (ПЛИСы :)), глядя на корпус, чтобы красиво разводилось на плате.

В схемном редакторе для каждого сигнала делаете Locate in Assigment Editor, назначаете ноги, получаете такого вида картину. Так и останется в будущем. Если разложится. В P-CAD или AD подводите нужную цепь к нужному выводу.

Если б писали на Verilog, можно было бы задать атрибут, например (* chip_pin = "60" *) output DIVOUT Для схемы, возможно, будет так же. В хэлпе посмотрите.

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

Вот и я ... с конспектом :) в виде компьютерного текста. Даже не столько для будущего чтения, сколько для теперешнего осознания читаемого. Признаюсь, я даже не знаю, что это такое, хотя и видел упоминания на форуме. (удалил флуд)

даже с той точки зрения, что, переводя, вникаешь в каждую букву текста, потом это формулируешь, что непременно приводит к лучшему пониманию...? Я думаю, мыслить на иностранном языке не научишься никогда. Научишься говорить. Вернешься - так же быстро забудешь. Мне это не нужно. Стешенко переведет :) Вообще, мне непонятно такое агрессивное восприятие хорошей задумки. Кому будет плохо, если рядом с оригинальным текстом стандарта будет перевод?

Я думаю, с размещением текста проблем нет. Мне наиболее логичным представляется на местном ftp. Уже не так. По крайней мере для Altera. Это совсем другая работа. Ценность ее приближается к тем оценкам, которые давали противники перевода стандарта. Я подписываюсь только под буквальный перевод стандарта. для dxp http://ru.wikipedia.org/wiki/%D0%AF%D0%B7%...%BA%D0%BE%D0%BC надеюсь, ссылка верная. Я не призываю ни к одной крайности, ни к другой. Я и сам использую комментарии на английском иногда, для быстроты. Истина, как обычно, где-то посередине.

:bb-offtopic: Я написал бы "снять активность процессорной шины", или "убрать", "очистить"... вариантов много. И ничего не потерял бы в смысле. С моей точки зрения, даже полезно, когда об одном и том же говорится разными словами. Если в комментарии повторяется то же, что написано в коде в сокращенном, но логически понятном виде, то и комментарий такой не нужен. to Vadim (in English :)) Подождем еще какое-то время, посмотрим, вдруг найдутся энтузиасты?

А как же! Ведь что получается: при (A = '1') B становится равным 1, а когда оно будет другим? Пока что видно - никогда! После выхода из блока В остается в 1. Вот и защелка.

Не сказал бы, что у меня есть проблемы с английским (кроме времен :)) И комментарии в свое время писал на английском, потом вернулся к русскому. Подумал, зачем эти понты. Качество комментариев изменилось (надеюсь, в лучшую сторону :)). На английском писать было удобнее тем, что раскладку клавиатуры переключать не нужно :) А переменным и функциям в программах всегда давал имена от сокращения английских слов. Когда я что-то перевожу, то усваиваю это лучше. Наверное, в данный момент какой-нибудь "писатель", например Стешенко, в поте лица переводит данный стандарт. Потом книжку издаст. Я куплю.

Еще лучше было родиться в США и думать на английском. Как ни крути, а по-русски мы воспринимаем информацию быстрее, и точнее.

Готов принять участие в переводе нескольких глав из стандарта IEEE 1800-2009. Предлагаю присоединиться всех желающих. Легче потратить неделю на перевод и пользоваться уже переведенным, чем каждый раз переводить то, что нужно в данный момент. Да и забывается оно. На мой взгляд, нужно перевести первые две части. Только нужно выработать для начала единый стиль. Естественно, желательно, чтобы было как можно ближе к оригиналу, только с терминами на "нашем" языке. И хорошо бы нашелся "диспетчер", раздающий задания, принимающий "работу", и т.п. Кто-то из "корифеев". Расскажу, как делаю я. Пишу всю документацию в OpenOffice, со стилями и т.п. Из него можно и в MS Office сохранить (делаю только по крайней нужде по требованию заказчика), и в pdf экспортировать. Копирую абзац, который хочу перевести, перевожу вручную, с использованием Artefact Dictionary (у него есть несколько словарей, в том числе словарь компьютерных терминов). Переводил куски из старых стандартов, из нового нет ничего. Знаю, что все равно каждому придется что-то переводить и хранить где-то, пусть хотя бы "самое важное". Так почему бы не сделать это сообща?

У меня был (и есть) проект, где был процессор PIC и ПЛИС, которые работали каждый от своего тактового генератора. В процессоре была программо созданная шина - 8 данных (PortB), адресов штук 5, чтение, запись (PortA). А в ПЛИС был набор регистров, к которым можно было доступиться из процессора этой по шине. Так как регистры были в том числе и многобайтовые (и даже к памяти был доступ через регистры), имелись счетчики, которые после каждой записи или чтения инкрементировались и указывали на следующий байт. Такое устройство сразу стало работать ненормально! То запишется что-то, куда не надо, то не запишется то, что надо... Тыкание пробником осциллографа меняло картину работы, но все равно было плохо. Я тогда предполагал, что какие-нибудь отражения возникают в сигналах, и т.п. Теперь же думаю, что это и были те самые метастабильные состояния, когда управляющие сигналы приходят в ПЛИС несинхронно с тактовой частотой. Поэтому сигнал записи мог не дойти до регистров внутри, мог дойти, когда уже не надо... Я переделал проект. Добавил сигнал ALE (Address Latch Enable), которым защелкивал адрес с шины. Необходимость в счетчиках отпала. А на запись и чтение в ПЛИС создал схемы, я называл их "фильтры". Эти сигналы на входе ПЛИС должны были находиться в постоянном состоянии несколько тактов ПЛИС подряд, и тогда по концу сигнала записи или чтения формировался внутренний сигнал записи или чтения в регистры. Такая схема работает уже в более сотни экземплярах. Сбоев я не наблюдал. О така херня, малятки! P.S. А осциллографом метастабильные состояния не увидишь, если специально не выведешь наружу что-то изнутри.

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

Выход переполнения счетчика (который выдается наружу) нужно брать не с выхода суммы последнего сумматора, а с выхода переноса. Вот - "правильный" счетчик, со всеми достоинствами - регулярной структурой, предсказуемым быстродействием, и компакный. Только выбирайте синхронный выход переполнения (там их два). module CountPrim #( parameter WIDTH = 8, // number of bits parameter DIRECT = "UP" // count direction: "UP" or "DOWN" ) ( input rst_n, // async reset input clk_en, // clock enable all flip-flops input clk, input cnt_en, // count enable input load, // hi-level sync load input [WIDTH-1:0] data, // data for sync load output bit [WIDTH-1:0] cnt, // bits of counter output bit rcry, // ripple carry output bit tcry // triggered (sync) carry ); wire [WIDTH:-1] cnt_cry; carry cryin ( .in (cnt_en), .out (cnt_cry[-1]) ); genvar i; generate for (i=0; i<WIDTH; i++) begin : bitgen if (DIRECT == "DOWN") carry crycnt ( .in (cnt_cry[i-1] & !cnt[i]), .out (cnt_cry[i]) ); else // "UP" carry crycnt ( .in (cnt_cry[i-1] & cnt[i]), .out (cnt_cry[i]) ); dffeas dffcnt ( .clk (clk), .d (cnt_cry[i-1] ^ cnt[i]), .ena (clk_en), .asdata (data[i]), .clrn (rst_n), .sload (load), .q (cnt[i]) ); end endgenerate assign rcry = cnt_cry[WIDTH-1]; dffeas dffcry ( .clk (clk), .d (rcry), .ena (clk_en), .clrn (rst_n), .q (tcry) ); endmodule

Я его сделал (Quartus, Coutner, Carry)! :) module CountCarry #(parameter WIDTH = 24) ( input rst, input clk, input clk_en, input cnt_en, input load, input [WIDTH-1:0] data, output [WIDTH-1:0] cnt, output cout, cout2 ); wire [WIDTH:0] cnt_reg; wire [WIDTH:0] cnt_next; wire [WIDTH:0] cnt_carry; wire [WIDTH:0] cnt_init = {1'b0, data}; genvar i; generate for (i=0; i<=WIDTH; i++) begin : dff_gen carry carry ( .in ((i ? cnt_carry[i-1] : cnt_en) & cnt_reg[i]), .out (cnt_carry[i]) ); dffeas dffeas ( .clk (clk), .d ((i ? cnt_carry[i-1] : cnt_en) ^ cnt_reg[i]), .ena (clk_en), .asdata (cnt_init[i]), .clrn (rst), .sload (load), .q (cnt_reg[i]) ); end endgenerate assign cnt = cnt_reg[WIDTH-1:0]; assign cout = cnt_reg[WIDTH]; assign cout2 = cnt_next[WIDTH]; endmodule 28 ЛЭ для ACEX, один из которых - чисто инвертор для load. Не зря в хэлпе говорится, что CARRY оставлен для совместимости с проектами на MAXPlus. Благодарю "коллективный разум" форума, и des00 персонально! :cheers:

Да на форуме ссылок на книжки и др. документы - завались! (если не ссылок, то упоминаний, а дальше - интернет в помощь!) Я уже насобирал где-то под сотню. Прочитать бы. А в бумажном виде имею всего одну жалкую книжонку :(

Вопрос принципиальный. Можно конвертировать из *.tdf в *.v (если б это что-то упростило:), синтезировать счетчик в упакованном виде. Что же не дает? Может быть, настройки какие-то хитрые есть, атрибуты?

Но мегафункция-то работает! В Квартусе, на Verilog (ну, или AHDL, какая разница). Смотришь в эту функцию lpm_counter.tdf - ничего не понимаешь :) Тоже, наверное, индусы писали :)

Я работал в MaxPlus+II, с ACEX. Там ничего этого не было. Да и сейчас, насколько понимаю, для ACEX этого нет. Мое предварительное мнение (статьи я читал, и не только эти, но практически не пользовался) - роль TimeQuest с констрейнами несколько преувеличена для достижения нужных результатов. TimeQuest может задать раскладчику, куда кинуть логический элемент, и каким путем к нему добраться. Что даст возможность манипулировать временем в районе 1 ns. Возможно, я не прав. Когда возьмусь за него конкретно, поговорим на форуме. А для проверки - да, согласен, годится!

Ja-ja, naturlich! (как-то так :) Меня терзает предчувствие, что не упакуется сумматор с триггерами даже если между ними и забить CARRY_SUM. Все больше склоняюсь к этому. Уже проверил, где там у меня MAXPlus+II инсталлятор :)