Ну, во-первых, почему-то на AVR плавающая арифметика работает быстрее целочисленной. Из 4-х арифметических операций только деление медленее, остальные - быстрее и намного.
Во-вторых, почему 64*8=512 байтов не умещаются в память Uno? И почему 512*8=4к не умещается в память f103?
Хотя по абсолютным величинам результаты, по крайней мере для Maple, похожи на истину.
Писал программки для PIC16F на ассемблере, код минимальный, интересуюсь возможно ли это на 328 камне, а то простое моргание светодиодиком в сотню байт кода выходит )))
Писал программки для PIC16F на ассемблере, код минимальный, интересуюсь возможно ли это на 328 камне, а то простое моргание светодиодиком в сотню байт кода выходит )))
Возможно. Вот ассемблерные инструкции для AVR, вот книжки Евстифеева по "микроконтроллерам AVR" и Ревича по "практическому программированию микроконтроллеров AVR на языке ассемблера".
Писал программки для PIC16F на ассемблере, код минимальный, интересуюсь возможно ли это на 328 камне, а то простое моргание светодиодиком в сотню байт кода выходит )))
Аналогично.
Ассемблер для пика приятный, а с микрочиповским си как-то не сложилось. В принципе все работает, но библиотек минимально так что все ручками писать надо. Хотя у пика есть несомненное преимущество - сверхнизкая скорость тактования 32кГц. Для нескоростных проектов дает очень низкое энергопотребление.
А у ардуинки и библиотеки, и справочники, и форумы и паять не надо. Вот только STM32 в протеусе не эмулируется, а пик - запросто.
Это такой особый вид IT-окультизма -- не видя исходников, гадать о требованиях к памяти и предсказывать скорость вычислений? Я давал здесь ссылку на статью, но ее потерли. Наверное, чтобы окультисты не чувствовали себя обделенными и всегда могли блеснуть чем-нибудь, да произвести впечатление на легковерных.
FFT - это вполне конкретный алгоритм. Для того, чтобы оценить требуемый объем памяти и затраты времени на обработку, видеть конкретный код совершенно не нужно.
А если вдруг окажется, что результаты, демонстрируемые этим "конкретным кодом" сильно отличаются от оценок, можно безошибочно утверждать, что место этому коду - в мусрорной корзине, и в качестве демонстрационной задачи использовать этот код категорически нельзя.
чтобы окультисты не чувствовали себя обделенными и всегда могли блеснуть чем-нибудь, да произвести впечатление на легковерных.
Не переживай так сильно... держи хвост пистолетом... Слабым и тупым оппонентам всегда завистно... Ты ж сам когда-то истерил по малейшему поводу... не понимая о чём тебе говорят... Теперь тебя не понимают... ибо ты вырос... над самим собой...
FFT - это вполне конкретный алгоритм. Для того, чтобы оценить требуемый объем памяти и затраты времени на обработку, видеть конкретный код совершенно не нужно.
Все эти дэ и корэ марки и прочая хрень... только для приблизительного анализа... Поэтому очень серьёзно... их рассматривать не стоит... Да и... ИМХО... никто такой задачи изначально не ставил...
Но для любителей поспорить... это просто ЛАФА... ))))))
Все эти дэ и корэ марки и прочая хрень... только для приблизительного анализа... Поэтому очень серьёзно... их рассматривать не стоит... Да и... ИМХО... никто такой задачи изначально не ставил...
По производительности - "да" по всем трем пунктам.
А по объему памяти - линейный коэффициент вычисляется абсолютно точно.
До 65 раз доходит.
Какая-то странная табличка.
Ну, во-первых, почему-то на AVR плавающая арифметика работает быстрее целочисленной. Из 4-х арифметических операций только деление медленее, остальные - быстрее и намного.
Во-вторых, почему 64*8=512 байтов не умещаются в память Uno? И почему 512*8=4к не умещается в память f103?
Хотя по абсолютным величинам результаты, по крайней мере для Maple, похожи на истину.
Я правильно понимаю, что UNO хороший камень?
Я правильно понимаю, что UNO хороший камень?
UNO это не камень ,это модель платформы ардуино .так же есть Mega , DUE и т.д
хороший для чего ? вот скажем дом строить, так себе .
Угу. Каменный камень.
Угу, а ви с какой целью интересуетесь? ))
Я правильно понимаю, что UNO хороший камень?
хороший для чего ? вот скажем дом строить, так себе .
ну, в неумелых руках этот камень может превратиться в кирпич. А это уже не каменный век. Можно и строительство начинать.
Угу, а ви с какой целью интересуетесь? ))
Писал программки для PIC16F на ассемблере, код минимальный, интересуюсь возможно ли это на 328 камне, а то простое моргание светодиодиком в сотню байт кода выходит )))
Я правильно понимаю, что UNO хороший камень?
UNO это не камень ,это модель платформы ардуино .так же есть Mega , DUE и т.д
хороший для чего ? вот скажем дом строить, так себе .
мой приятель кстати дом постоил на изделиях на PIC контроллере )))
Писал программки для PIC16F на ассемблере, код минимальный, интересуюсь возможно ли это на 328 камне, а то простое моргание светодиодиком в сотню байт кода выходит )))
Возможно. Вот ассемблерные инструкции для AVR, вот книжки Евстифеева по "микроконтроллерам AVR" и Ревича по "практическому программированию микроконтроллеров AVR на языке ассемблера".
Угу, а ви с какой целью интересуетесь? ))
Писал программки для PIC16F на ассемблере, код минимальный, интересуюсь возможно ли это на 328 камне, а то простое моргание светодиодиком в сотню байт кода выходит )))
Аналогично.
Ассемблер для пика приятный, а с микрочиповским си как-то не сложилось. В принципе все работает, но библиотек минимально так что все ручками писать надо. Хотя у пика есть несомненное преимущество - сверхнизкая скорость тактования 32кГц. Для нескоростных проектов дает очень низкое энергопотребление.
А у ардуинки и библиотеки, и справочники, и форумы и паять не надо. Вот только STM32 в протеусе не эмулируется, а пик - запросто.
Вообще-то эмулируется.
Хотя у пика есть несомненное преимущество - сверхнизкая скорость тактования 32кГц. Для нескоростных проектов дает очень низкое энергопотребление.
дак это и у AVR есть, хоть от 1 Герца тактуй
Какая-то странная табличка.
...
Во-вторых, почему 64*8=512 байтов не умещаются в память Uno? И почему 512*8=4к не умещается в память f103?
Хотя по абсолютным величинам результаты, по крайней мере для Maple, похожи на истину.
И 64 и 128 умещаются в 328p разумеется, и общитываются побыстрей чем в таблице. Так что с абсолютными для Uno - лажа.
Это такой особый вид IT-окультизма -- не видя исходников, гадать о требованиях к памяти и предсказывать скорость вычислений? Я давал здесь ссылку на статью, но ее потерли. Наверное, чтобы окультисты не чувствовали себя обделенными и всегда могли блеснуть чем-нибудь, да произвести впечатление на легковерных.
FFT - это вполне конкретный алгоритм. Для того, чтобы оценить требуемый объем памяти и затраты времени на обработку, видеть конкретный код совершенно не нужно.
А если вдруг окажется, что результаты, демонстрируемые этим "конкретным кодом" сильно отличаются от оценок, можно безошибочно утверждать, что место этому коду - в мусрорной корзине, и в качестве демонстрационной задачи использовать этот код категорически нельзя.
чтобы окультисты не чувствовали себя обделенными и всегда могли блеснуть чем-нибудь, да произвести впечатление на легковерных.
Не переживай так сильно... держи хвост пистолетом... Слабым и тупым оппонентам всегда завистно... Ты ж сам когда-то истерил по малейшему поводу... не понимая о чём тебе говорят... Теперь тебя не понимают... ибо ты вырос... над самим собой...
FFT - это вполне конкретный алгоритм. Для того, чтобы оценить требуемый объем памяти и затраты времени на обработку, видеть конкретный код совершенно не нужно.
Все эти дэ и корэ марки и прочая хрень... только для приблизительного анализа... Поэтому очень серьёзно... их рассматривать не стоит... Да и... ИМХО... никто такой задачи изначально не ставил...
Но для любителей поспорить... это просто ЛАФА... ))))))
Все эти дэ и корэ марки и прочая хрень... только для приблизительного анализа... Поэтому очень серьёзно... их рассматривать не стоит... Да и... ИМХО... никто такой задачи изначально не ставил...
По производительности - "да" по всем трем пунктам.
А по объему памяти - линейный коэффициент вычисляется абсолютно точно.
Исходники kissFFT доступны. Никогда не мешает расширить свои представления.