_pv

шлангу как-то без разницы, он даже вот это прожевал, без static и даже const, а gcc (для АВРов особенно) скорее всего тупить будет. str[0] = (char[]){"0123456789ABCDEF"}[(TWSR>>4) & 0x0F]; str[1] = (char[]){"0123456789ABCDEF"}[(TWSR ) & 0x0F]; ldr r0, .LCPI0_0 ldrb r1, [sp, #3] .LPC0_0: add r0, pc, r0 ldrb r1, [r0, r1, lsr #4] ldrb r2, [sp, #3] strb r1, [sp, #3] and r1, r2, #15 ldrb r0, [r0, r1] strb r0, [sp, #3] add sp, sp, #4 bx lr .LCPI0_0: .long .L.str-(.LPC0_0+8) .L.str: .asciz "0123456789ABCDEF"

где там в этих трёх строчках хоть один вызов функции? 🙂 вот бы дисассемблер посмотреть...

const char hex[] = "0123456789ABCDEF"; str[0] = hex[(TWSR>>4) & 0x0F]; str[1] = hex[(TWSR ) & 0x0F];

возможно, но имхо лишнее сохранение регистров в прологе функций та же экономия на спичках что и c call/ret. да, вызовы функций не бесплатны, но и не надо делить код так чтобы на каждое отдельное действие и чтение запись отдельного байта были распиханы по мелким функциям. если уж sqlite'у это настолько сильно помогло, для мелких проектов в МК если специально не писать код так чтобы там было что оптимизировать таким образом разница будет ещё меньше. Если у кого есть какие-нибудь бенчмарки на сколько amalgamation действительно помогает с оптимизацией в более менее реальных проектах было бы интересно посмотреть. А если что-то "не влазит" по скорости на эти 5%, то менять там надо явно не оптимизацию сборки, особенно таким образом.

Как имея в этом же юните компиляции код других функций, как правило не особо связанных (они ведь изначально в разных файлах не просто так оказались) можно ими увеличить быстродействие чего-то? Экономия инструкции call на встраивании функци, или знание что какие-то аргументы константные (-flto это поди учитывает), это будут те самые упомянутные 5%, ценой размера. Оптимизации DSP всё-таки немного про другое, эффективное использование кучи шин/алу чтобы друг другу не мешали, там действительно легко можно наговнокодить, что производительность на порядок упадёт от максимально возможной. Но наличие кода левых функций тут никак не поможет с оптимизацией по скорости. Запихивание всё в один файл с #include "scr1.c" #include "scr2.c" #include "scr3.c" ..., разве что с системой сборки может помочь, gcc all.c и всё, а не эти ваши дурацкие мэйкфайлы

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

а можно в двух словах, зачем? я смог только придумать наличие каких-нибудь "глобальных" static функций/переменных, которые надо чтобы не торчали наружу из этой единицы компиляции, но при этом были доступны друг другу из src1/2/3.cpp. но у файлов расрширение .cpp а не .с и соответственно наличие namespace для таких случаев.

пример бы привели, что именно не так. в целочисленных 32х разрядах 9 с половиной десятичных порядков динамического диапазона.

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

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

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

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

положите на ваш пьезо элемент гирю, и на нём после этого, как на ёмкости, тоже будет постоянно присутсвовать напряжение, в статике, пока этот заряд не растечётся.

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

я сварщик не настоящий, но у сверхпроводящих резонаторов там градиенты ускорения - какие-то десятки МэВ/м, для получения сотни-другой кэВ связываться ещё и с криогеникой - ну такое себе развлечение. врядли это размеры вообще уменьшит. Электронные микроскопы электростатикой вполне обходятся как-то до нескольких сотен кэВ.

ну как наступите несколько раз на грабли что размеры int и long могут произвольно меняться в зависимости от архитектуры процессора и даже от компилятора. так сразу stdint.h станет понятнее и привычнее. стандарт вроде гарантирует только что размер char <= short <= int <= long, поэтому иногда встречаются и 16-ти битные char и 16-ти битные int.

это будет слишком просто, ТСу об этом в первом же сообщении написали и на этом тему можно было бы и закрыть.

не уверен что его можно на 100МГц запустить, и скорее какой-нибудь i2s или похожие аудио интерфейсы, у stm там вроде не все SPI так умеют, только некоторые. с просто SPI надо аккуратно, там, в зависимости от одарённости разработчиков, он как мастер иногда не умеет гнать непрерывный битовый поток, довабляя какой-нибудь лишний бит паузы между словами.

как уже сказали он не компилируется, а include тупо вставляет содержимое, а ругается скорее всего потому, что где-то до этого делается инклюд какого-нибудь другого файла, который делает #include "h1.h" https://gcc.gnu.org/onlinedocs/cppinternals/Guard-Macros.html

если не носиться вокруг меняя координатную систему, и наблюдать всё в статике, то ВСЕ уравнения которые внезапно взаимосвязаны только через d/dt в этом частном случае становятся не такими уж и связанными и позволяют рассматривать их по отдельности.

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

ну так вы в ЦАП подряд засунули все значения, с паузой в несколько тактов между записями, там у ЦАПа settling time поди сильно дольше. что он по вашему показать должен был? uint32_t i = 0; while(1) SAC0DAT = (i++)>>6;

Mathematica, LeastSquaresFilterKernel рандомно натыкал мышкой в картинку графика чтобы точки получить, h - FIR коэффициенты для длины 3, 5, 7, 9, если с нормированием частоты нигде не ошибся.

вот тут говорят что можно замешать порошковые пьезоелектрик и ферромагнетик, потом спечь вместе или хотя бы залить эпоксидкой (зависимость от поля почему-то в разные стороны при этом получается) https://sci-hub.se/https://doi.org/10.1021/acsami.0c12765

хз что это за таблица нагуглилась, но выглядит адекватно. Maximum Cable Length (meters) Maximum Baud Rate* 1600 600 800 1200 400 2400 200 4800 100 9600 50 19,200 25 38,400 16 57,600 8 115,200