SciFi (28.08.2020 08:04, просмотров: 690) ответил Dingo на Смоделировал в эксельке свой способ. Дополнительная ось для
выходов, чтобы видно лучше было. α = 3/256;ส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้
-
- Я один и тот же код для PIC переписывал с long'ов на плавучку. И
стало быстрей. Потому, что long'и 32-битные (а в 16 бит не лезет),
а плавучка в не-PRO Hitech-C версии хорошо оптимизирована на
ассемблере руками и 24-битная. Причём там мантисса-то 16-битная
вовсе (которую нужно долго перемножать). Просто меньше операций, не
говоря уж, что прорамма сильно проще и короче. Проблема
целочисленных вычислений, что нужна немеряная разрядность (особенно
если у тебя в выражении fk0(164 знак., 28.08.2020 11:33)
- 1) Зачем нужна немеряная разрядность, если АЦП 16- разрядный? 2)
Что за фантазия считать в 16 разрядах, если все 16-разрядные машины
имеют умножитель, дающий 32-разрядный результат? - Kpoк(28.08.2020 15:49)
- Затем, что x2 например. Или результат умножения в том же фильтре. И не лезет либо снизу, либо сверху. Т.е. вообще осмысленный результат влезает, но с другим множителем. А поскольку аргументы той же суммы отнормированы по одной единице, то кто-то уже не умещается. Фантазия возникает на PIC18 или x51, у которых каждый байтик нужно протаскивать через игольное ушко регистрое DPTR или WREG, что в общем-то не быстро (и ещё переноса где-то нет). На MSP430, PIC24 или fk0(39 знак., 28.08.2020 16:55)
- Почему генератор? Полосовик на 16q16 получается устойчивым. Другое
дело, что на ПИК такое умножать вспотеешь. Или речь про 16р на всё?
А с плывучкой тоже проблема, если нет бочечного шыфтера.
Нормализаццыя-денормализаццыя легко может затрахать. - mse homjak(28.08.2020 12:02)
- 16q16 -- это таки 32-бита. Шифтер же сейчас есть даже у пиков,
более того у, даже трёхцилиндровых (pic24/dspic), есть относительно
быстрый делитель. А как у любительких армов? У некоторых нет вот. - fk0(28.08.2020 12:31)
- Дык, про 24/30/33 и речи быть не должно. Даже для 32 бит. Сратый
АВР должен такое легко пережёвывать. С млачшими ПИКами, да, могут
быть проблемы. - mse homjak(28.08.2020 12:46)
- Младшие пики - это у которых нет аппаратного умножителя. А, скажем, ДСПИК при 32 разрядах делает один шаг фильтра за 6 шагов. - Kpoк(28.08.2020 13:44)
- Дык, про 24/30/33 и речи быть не должно. Даже для 32 бит. Сратый
АВР должен такое легко пережёвывать. С млачшими ПИКами, да, могут
быть проблемы. - mse homjak(28.08.2020 12:46)
- 16q16 -- это таки 32-бита. Шифтер же сейчас есть даже у пиков,
более того у, даже трёхцилиндровых (pic24/dspic), есть относительно
быстрый делитель. А как у любительких армов? У некоторых нет вот. - fk0(28.08.2020 12:31)
- 1) Зачем нужна немеряная разрядность, если АЦП 16- разрядный? 2)
Что за фантазия считать в 16 разрядах, если все 16-разрядные машины
имеют умножитель, дающий 32-разрядный результат? - Kpoк(28.08.2020 15:49)
- На плавучку принято жаловаться, что она неточно. Любой умножитель в
16-разрядных машинах даёт 32-разпядный результат. Плавучка хранит
только 24 из них. - Kpoк(28.08.2020 09:26)
- если исходные данные имеют три значащих разряда, а остальное шумы - то и 24-х разрядная плавучка будет иметь 3 значащих разряда, а не 24. - Mahagam(28.08.2020 10:37)
- Я один и тот же код для PIC переписывал с long'ов на плавучку. И
стало быстрей. Потому, что long'и 32-битные (а в 16 бит не лезет),
а плавучка в не-PRO Hitech-C версии хорошо оптимизирована на
ассемблере руками и 24-битная. Причём там мантисса-то 16-битная
вовсе (которую нужно долго перемножать). Просто меньше операций, не
говоря уж, что прорамма сильно проще и короче. Проблема
целочисленных вычислений, что нужна немеряная разрядность (особенно
если у тебя в выражении fk0(164 знак., 28.08.2020 11:33)