xvr

Я не собираюсь за вас делать вашу работу Да и ARM компилятора у меня нет. Но пишется это так же, как и на С - много временных переменных, чтение, сумирование и пр. Ваше полотенце gcc соптимизировал в ret И он прав Ваш bm static и равен нулю Если нужна эффективность, то алгоритм нужно переделывать, и не С ни ассемблер тут не помогут Intel компилятор под x86 это умеет. Про ARM не скажу. Да и интристики никто не отменял

спасибо, повесилили Это уже будет другой алгоритм. И этот другой так же можно на С написать (если компилятор не позволяет - смените компилятор) Преждевременная оптимизация - корень всех бед. Не надо всё вылизывать сразу - оформляйте потенциально узкие места в отдельные процедуры, потом оптимизируйте (если будет нужно) В какой то книжке был замечательный пример - группа таких вот 'оптимизаторов' нашла в ядре ОС очень горячий цикл (он исполнялся более 80-90% всего времени). Они его переписали на ASM, вылизали, и ускорили в несколько раз. Однако на работе ОС в целом это никак не сказалось. Пристальный анализ показал, что они переписали Idle цикл ОС Вам привет от поклонников Agile технологий (только поберигитесь, что бы не затоптали)

Единственный (ну почти единственный) кому потребуется постоянно рассматривать листинги после компилятора - это разработчик этого самого компилятора Если возникла такая необходимость - надо сменить компилятор Например, что бы что то наоптимизировать в ассемблере после gcc нужно очень (нет ОЧЕНЬ) сильно постараться. Может понадобится ассемблер если вы делаете какие то ну очень низкоуровневые (и железно специфичные) вещи, которые в С/С++ просто не выражаются. И ещё может понадобится ассемблер (точне не столько ассемблер, сколько знание архитектуры целевого CPU) если вы занимаетесь какой то очень архитектурно специфичной оптимизацией (например пытаетесь заставить этот %^%^&^*& компилятор векторизовать цикл). Но для CPU типа ARM Cortex M<чего нибудь> вам с этим вряд ли придётся столкнуться

Не надо этого делать. Схемы на 133 серии отличались очень демократичным отношением к глитчам, т.к. их быстродействие (а точнее 'медленнодействие') было такое, что все эти глитчи счастливо проглатывались. На FPGA этот номер не пройдёт - они все иголки вылавливают на ура, а 'припаять кондюк на ножку' (любимый способ подавления слишком толстых иголок) там тоже не пройдёт. FPGA сапры тут тоже не помогут - не расчитанны они на такие методы проектирования. Если я правильно помню, тут уже кто рассказывал страшилку о переводе аэродрома из 155 серии на FPGA - после прямого переноса получили абсолютно точную, и так же абсолютно неработающую копию Закончилось созданием с нуля синхронного дизайна по спекам исходного аэродрома.

2 TC - а вы уже знаете, какими алгоритмами вы будете преобразовавать сигнал с микрофона (который после оцифровки будет просто последовательностью чисел) в переключение RGB ленты (которая много много троек чисел R/G/B)? Просто подключить микрофон недостаточно

Если вы можете модифицировать вызовы new внутри классов - подсуньте туда свой - void* operator new(size_t, <your heap object>) Если нет, но авторы внутренностей предусмотрели возможность дать свой аллокатор (как в stl) - пользуйтесь предоставленным API. Если и такой возможности нет, то только переопределять глобальный operator new :(

Код не эквивалентный. 2й должен быть таким: always @(posedge clk_cmp or posedge RST_cmp) count_echo_cmp <= RST_cmp ? 2'h0 : end_frame_cmp && TSR_cmp ? 2'h0 : end_frame_orig && count_echo_cmp <= 2'd2 ? count_echo_cmp + 2'd1 : count_echo_cmp; Но писать так не стоит :)

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

Кажется на такие компоненты ругается PCB при импорте netlist'а (но точно не уверен) - попробуйте. Если допустимы ручное вмешательство после загрузки нетлиста - просто удалите 2й разъём руками.

А нет ли там пары защитных диодов между _N и _P?

А dev борды какие нибудь есть? И присоединяюсь в SII с вопросом по поводу доступности в нашем регионе.

У меня тоже - грелась она вся как печка

Частоты, которую удасться так получить, вам хватит? Посодить на ногу с прерыванием и считать их (прерывания) за интервал времени (по таймеру). Для подавления дребезга маскировать прерывание после срабатывания, снимать маску по таймеру (тоже из прерыания). Если частоты и таймеров хватит, то должно получиться

Математику не обманете :) При 5 MHz (округлил вверх) на выходе и 100 на входе у вас есть максимум 20 точек на период синусоиды (т.е. 5 на четверть периода). Это будет довольно 'грубая' синусоида. Если вас такая устроит (по спектру выходного сигнала), то дальше выбираете размерность аккумулятора и величину, которую будете прибавлять.

Возьмите щуп осцилографа 1:10. Возможно слишком большая ёмкость щупа (хотя и крайне маловероятно)

Мне уже жалко ваших клиентов Как ваш 'техник', который 'пришёл к клиенту' будет отличать, ктло именно его клиент? Тот, кто перед ним сидит с вашим прибором, или тот, что за стенкой сидит (с таким же прибором)?

Встраивают - Jetson Nano, Jetson AGX Xavier

Совместимы, ровно в той же степени, что и все остальные объекты С++ (тот же STL например) На стороне С++ VCL объекты представленны в виде указателей на них, а не самих объектов. Указатели очевидно передать можно, если нужны именно объекты, то придётся указатели заворачивать в smart поинтеры (не помню как они называются на стороне С++ VCL, но они точно есть) и передавать В любом случае это сугубо теоритические изыскания, т.к. собрать Qt билдеровским компилятором скорее всего не получится. Если нужен именно билдер, то std::map и/или std::unordered_map Даже не буду пытаться - в споры на религиозные темы я не вступаю :) Под GPL - бесплатна. Никоим образом. Про билдер речь вообще не шла.

Тогда вам подойдут (наверное) контейнерные типы из Qt. QMap или QHash Угу, а в списке у вас поиск делается телепатически, или всё же есть критерии, по которым объекты сравниваются? Что вам мешает этот критерий в map отдать? Аллокатор там есть встроенный (почти всех он устраивает), и итераторы далеко не всегда нужны (и без них можно с map'ом общаться)

Судя по приведённому 'коду' передача по USB происходит чисто телепатически. Ибо, как правльно заметил Skryppy для общения с FTDI чипом одной шины данных недостаточно (я уже не говорю, что общение с ней на тактовой частоте FPGA и без всякой синхронизации вообще приведёт к букету глюков чудных) Про Verilog RTL вообще молчу, (мат здесь вроде не приветствуется)

Мысль интересная, буду иметь в виду :)

Хм, попробую, как понадобится в следующий раз :)

Перед разрешением прерываний прочтите состояние INT4 (или что там у ATmega), что бы сбросить pending прерывание.

До wolfram mathematica пока не дошёл, а вот ImageJ - огонь! Большое спасибо за наводку. Hough_Circle работает, но к сожалению не на всю плату - приходится выделать окресности каждого отдельного пина и запускать (несколько геморойно, но работает) Там есть какое то скриптование - может получится автоматизировать. Если запускать на всю плату находит массу окружностей, включая те, которых даже отделённо нет (реальные окружности тонут в море мусора )

Господа, не подскажете, есть ли в природе программа что бы в неё можно было загрузить картинку печатной платы и получить различные размеры, например координаты пинов/отверстий, их диаметр и пр. ? Пытался загрузить в inkscape и сделать векторизацию (есть у него такой плагин), получил из отверстий набор кривых бубликов