krux

https://sovtest-ate.com/equipment/testirova...-i-diagnostika/

если надо >10 кВт на час-два, и с хорошим ресурсом, то наша контора ставит на объекты батареи из 2-Вольтовых sonnenschein. на соответствующие ампер-часы. По размерам и весу они конечно просто огромные.

IAR сделан не только под миниатюрные микроконтроллеры, а документация у него общая. приведенный выше пример справедлив, например, когда есть тормозная флешка и быстрая и большая внешняя DDR. тогда cstartup как раз скопирует константу, к которой нужен быстрый и частый доступ в DDR.

у больших FPGA (живых, рабочих), если их VCCINT и GND прозванивать - бывает и 2 Ома.

в европах через обычных опсосов реализован резерв для ЖД (сигнализация), поэтому 2G(EGSM900 & DCS1800)/2,5G(aka EDGE) "совсем умрёт" не ранее чем лет так через 10-15.

вы так говорите, словно квартус был знаком с пелёнок. HDL знаете - а с остальным разобраться - выйдет быстрее, чем вы эту "маленькую платку строго под ваши хотелки" искать будете.

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

например, можно сконвертировать в оптический 3G-SDI, а потом наоборот. естественно, это дорого.

какой провод в клеммную колодку был подключен? одножильный? многожильный? многожильный оконцованный наконечником? многожильный облуженный?

вот вам выдержка из стандарта IEEE 802.3-2015 касательно 10base2 ieee_802_3_2015_expt.pdf

Flip-fl0p let's troll this troll! :disco:

давайте так сказать, "плясать от печки". в этой цепи предохранитель - был? если нет, то давайте на секунду допустим, что на разъеме и клеммной колодке было 50 Ампер. На которые ни разъем, ни клеммная колодка, ни дорожка на печатной плате естественно не рассчитаны.

я понял в чем проблема, в вашем чипе CLKCTRL так как я думал, работать не будет: https://www.altera.com/content/dam/altera-w...3_ciii51006.pdf слегка противный осадочек, когда понимаешь, что -1 поколение назад не всё было так прекрасно. тогда надо делать glitch-free clock switching, с выводом результата опять-таки на внешний пин, и закольцовыванием его снаружи. и констрейнить закольцованный входящий клок одновременно по всем правилам (сколько вариантов частот - столько и констрейнов). выводить можно куда угодно, заводить как обычно на GCLK заодно если при переключениях будут ошибки - сможете осциллом найти, ибо сигналтапом это нереально.

ViKo по делу - выкинуть и переписать. но для начала понять, сможете ли использовать CLKCTRL. т.е. сможете ли кинуть внешнюю (с пина на пин) петлю. дальше законстрейнить этот входной CLKCTRL под две тактовые. дальше по обстоятельствам зы. я в одном своем проекте делал переключение 2,5/25/125 МГц при помощи glitch-free схемы, работало нормально. проблемы были с hold-ами на низких температурах, решилось небольшим пайплайном.

текст, помеченный тегами [ b ] [ /b ] - моя писанина. module ClockDivider ( [b] // Блин эти аттрибуты бы вывести нахрен в топ-левел. и в топ-левел должны остаться только связи между модулями. никакой логики, а то это какой-то базар-вокзал.[/b] [b] // хуже того, заранее становится проблемой, к чему конкретно привяжутся констрейны. как обычно беда в названиях и их поиске и назначении констрейнов[/b] [b] // на соответствующие физические ячейки квартусом. всё не найденное будет проигнорировано.[/b] (* chip_pin = "84" *) input ResetN, (* chip_pin = "89", altera_attribute = "-name io_standard lvds" *) input ClkIn, [b] // вот это я так понимаю фигня из соседней темы[/b] (* chip_pin = "28" *) output ClkOut, (* chip_pin = "30" *) input ClkSel, (* chip_pin = "32" *) input DataIn, (* chip_pin = "33" *) output DataOut ); bit ClkDiv; always_ff @(posedge ClkIn, negedge ResetN) if (!ResetN) ClkDiv <= 0; else ClkDiv <= !ClkDiv; [b]// тут видно что ClkDiv тикает от ClkIn. ок. заделили пополам. ставим себе пометку - на температуре поплывёт.[/b] always_comb if (!ClkSel) ClkOut = ClkIn; [b]// тут видна достаточно конкретная жопа в случае с насасыванием со входа ClkSel "иголок" и прочего мусора[/b] else ClkOut = ClkDiv; [b]// если нужно стабильное поведение, ClkSel должен быть предварительно прорегистрен, хотя бы через double-flop[/b] [b]// далее, тут же видна жопа с моментом переключения из одного состояния в другое. следующим блокам просто необходим сигнал сброса при таком переключении[/b] [b]// если всё же необходимо изменять частоту без сброса, есть специальные техники glitch-free clock switching[/b] always_ff @(posedge ClkOut, negedge ResetN) if (!ResetN) DataOut <= 0; else DataOut <= DataIn; [b]// тут видно что DataOut тикает вместе с DataIn по ClkOut. в принципе тоже ок, но будет нормально работать только [/b] [b]// при отсутствии "иголок" и glitch-free переключениях частоты при помощи ClkSel)[/b] endmodule : ClockDivider set_time_format -unit ns -decimal_places 3 create_clock -name clk_in -period "100 MHz" -waveform {0 5.0} ClkIn [b]# OK. здесь квартус действительно увидит что 100 МГц действительно зашло на вход ClkIn.[/b] create_clock -name clk_virt -period "100 MHz" [b]# OK. создали "нечто" никуда не назначенное.[/b] create_generated_clock -name clk_div ClkDiv -divide_by 2 -source ClkIn [b]# OK. тактовую создали, название дали, источник показали. куда она дальше расходится будет - квартус не поймёт. нужна будет ещё одна подсказка.[/b] # derive_clocks derive_clock_uncertainty [b]# приняли значения по умолчанию из шаблона конкретной модели ПЛИС. ОК.[/b] set_input_delay -clock clk_virt -min 0.0 ClkSel [b]# не понятно что имелось ввиду # здесь фактически указано, что снаружи ПЛИС задержка от 0 до 1 нс[/b] set_input_delay -clock clk_virt -max 1.0 ClkSel [b]# поэтому нужно скорректировать её на внутренней логике от пинов до входов always_ff и always_comb где-то внутри по ресурсам ПЛИС[/b] [b]# но поскольку clk_virt ни к чему не привязан, квартус ничего не понимает[/b] set_input_delay -clock clk_virt -min 0.0 ResetN [b]# аналогично не понятно что имелось ввиду[/b] set_input_delay -clock clk_virt -max 1.0 ResetN set_input_delay -clock clk_virt -min 0.0 DataIn [b]# аналогично не понятно что имелось ввиду[/b] set_input_delay -clock clk_virt -max 1.0 DataIn set_output_delay -clock clk_virt -min -2.0 ClkOut [b]# аналогично не понятно что имелось ввиду[/b] set_output_delay -clock clk_virt -max -1.0 ClkOut set_output_delay -clock clk_virt -min -2.0 DataOut [b]# аналогично не понятно что имелось ввиду[/b] set_output_delay -clock clk_virt -max -1.0 DataOut с учетом вышесказанного - "более-менее" это хозяйство будет работать на частоте не выше 5...10 МГц. Для 100/50 придётся переделывать. на ClkOut констрейн не назначился - квартус его не нашел, возможно, из-за больших/маленьких букв, возможно из-за того что всё это в топ-модуле (или нет? отсюда не видно) поэтому на DataOut будет фигня от сборки к сборке.

сгенерите MegaWizard-ом/IP-Catalog-ом примитив ALTLVDS, после чего прицепите его входы/выходы корректно к вашей схеме. заодно будут учтены все тонкости статической/динамической настройки LVDS-трансивера конкретной ПЛИС. имхо это самый правильный вариант.

если речь про разработку софта, то мировые лидеры используют perforce

главное, что должен знать любой IT-шник - это то, что руководитель предприятия считает его накладником, читай: не производящим деньги пассивом. попутно: любая система, будь то PLM, или ERP, которую вы попытаетесь вырастить "снизу", будет утоплена в зародыше.

https://www.youtube.com/watch?v=4zLfCnGVeL4

думаю, скорее братья-славяне очешуевают от принятого на грудь самогона ;-)

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

с таким подходом - НЕТ. дело в том что я был в подобной ситуации, и для того чтобы задача легла на архитектуру плис её пришлось переписывать трижды. Уточняя "мелочи" в ТЗ, которые превращались в жирные кляксы, перечеркивая уже проделанную работу. 2 ТС умеете работать с x86 - берите DPDK в руки. это если нужен практический результат. если практический результат пофиг и вы пишете кандидатскую, ничего не зная про предметную область плис - вас на защите как катком раскатают. поясняю: парсинг в плис - это не 1000 раз сравнить один байт с "чем-то". для понимания в чем эффективность ПЛИС - нужно окунуться с головой в поиск по бинарному дереву, когда речь идёт не про сравнение строк, байтов ли чего ещё, а про сравнение СЛЕДУЮЩЕГО ПРИХОДЯЩЕГО БИТА. блин. нового решения по поиску исходя из сравнения очередного бита. за счет этого собственно производительность и достигается. в том числе, если необходима оперативность по передаче команд управления - то это делается до создания системы, и учитывается при создании протокола взаимодействия, но не после. а сейчас я вижу как производится попытка впихнуть некое "распарсивание" без понимания последствий. таким образом, налицо все попытки "скрыть это дерьмо" за какой-нибудь ПЛИС, которая будет никому не понятна, кроме тебя.

ничего личного, но начинает складываться такое мнение, да.

здесь мне видится рассуждение программиста, у которого за один такт может выполняться только одна вычислительная операция. для ПЛИС это тупиковый путь, и поэтому так не делают. этот вычислительный алгоритм должен быть полностью перелопачен для того чтобы его можно было эффективно реализовать на ПЛИС.

ответил в личку