Небольшой оффтоп по поводу логарифмов. Предположим, вы начнете считать логарифмы вручную... Так вот, на 16 мегагерцах контроллер делает примерно 8 миллионов математических операций... Если вы будете тратить на какое-то вычисление 1 секунду (например, при умножении в столбик на одну циферку 1 секунда), то 8 миллионов операций вы сделаете примерно за 270 рабочих дней... А контроллер на это потратит одну секунду...
если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе
при взгляде на многих сверху ничего не меняется...
Just_Fluffy, Eats.
Вы, похоже, пишите про обычный ассемблер. Это старое программирование из прошлого века. Я на нём, практически, ничего не писал, только в самом начале, когда изучал МК.
В, условно говоря, современном ассемблере, есть функция логарифма, вызов которой – одна строчка программы.
Необходимо ещё разобраться с используемыми регистрами, это всё-таки ассемблер. Надо почитать описание функции, регистры, которые требуется сохранить, забросить в стек, а после извлечь из стека. Это будет ещё пару строк программы.
Займёт по времени, скажем, десяток минут – вот и всё время для логарифма.
Это не «изыск», а обычная работа на современной программе, вполне подойдёт для зарабатывания «денешшшшек».
Ради интереса посмотрел объём, заняло 526 байт.
Этот логарифм знаковый. Если аргумент меньше условной единицы (это число 1024), то выдаёт отрицательные значения, как и полагается. Правда, в сторону минуса работает недалеко, на один шаг аппроксимации.
Знаковый логарифм несколько больше по объёму, но удобен для разработки измерителей концентраций веществ. Обычно сигнал при распространении затухает по экспоненте в соответствии с концентрацией вещества, требуется логарифм. Если появляются отрицательные значения, надо провести калибровку прибора.
float никогда не использовал, плохо представляю, когда может понадобиться. Если только при использовании старой программы, но я на такой не работаю.
Как я понял, вы работаете в прерывании. В прерывании пишу только самый необходимый минимум, всё остальное – в основном цикле. Для меня работа в прерывании – источник всяческих проблем, зачем они нужны. Правда, ситуации бывают разные.
AQ29 спутал программу "ассемблер" с интегрированной средой разработки, частью которой ассемблер является. И все функции в этой среде появляются при подключении линкером объектной библиотеки, которая тоже является ещё одной частью среды разработки. Я не говорю о какой-то конкретной среде - во время моей "производственной деятельности" у меня был "чистый" ассемблер, а плавучку и функции для устраивающего меня компромисса меж точностью, быстродействием и расходом памяти писал сам.
А вооще забавно: провозглашать ненужность float - и тут же - про логарифмы?! Даёшь только целочисленные логарифмы!
lg (2) = 0, lg(9) = 1.
Мы с котом Мурзиком долго смеялись
СпойлерНапоминает из бессмертного "Недоросля" :
[uquote="AQ29",url="/forum/viewtopic.php?p=4388064#p4388064"]Это не «изыск», а обычная работа на современной программе, вполне подойдёт для зарабатывания «денешшшшек».[/uquote]Вы попробуйте донести эту мысль до Andrey_B, который пишет (в другой теме, в своей):
[uquote="Andrey_B",url="/forum/viewtopic.php?p=4386620#p4386620"]такие проекты это скорее демосцена, выдавливание всей до капли производительности МК.[/uquote]И далее делает вывод:
Достойно, интересно, но в массовом сегменте применить практически невозможно.
А для меня не проблема как выбор оптимального языка программирования, так и получение экстремального (по тому или иному критерию) результата.
Как я понял, вы работаете в прерывании. В прерывании пишу только самый необходимый минимум, всё остальное – в основном цикле. Для меня работа в прерывании – источник всяческих проблем, зачем они нужны. Правда, ситуации бывают разные.
Это задачи бывают разные, а не ситуации. Все задачи для МК можно условно разбить на две большие группы: вычислительные и задачи управления процессами. В действительности, конечно, для управления процессами тоже надо производить какие-то вычисления, но они там не первостепенны. А и в вычислительных задачах надо как-то ввести исходные данные и как-то куда-то вывести результат, то есть общаться с периферией, но это общение в таких задачах не первостепенно. Тем не менее несмотря на некоторую расплывчатость границы между этими двумя типами задач, различие между ними хорошо видно.
Так вот в вычислительных задачах прерывания совершенно не нужны. Задачи же управления напротив, в 100% случаев гораздо эффективнее решаются на прерываниях, лишь бы была их аппаратная поддержка в конкретном контроллере. Мне чаще приходится решать задачи по управлению процессами, поэтому у меня основной цикл нередко выглядит так:
Завершающая скобка там осталась от int main(void){. А источник всяческих проблем находится не в прерывании, а в голове, то есть в непонимании работы контроллера и языка программирования для него.
Just_Fluffy
При наличии больших программ в прерываниях надо тщательно анализировать всю программу, что будет, если прерывания возникнет в каждом месте.
Это трудоёмко и легко допустить ошибку.
Может случиться совсем неприятная ситуация, когда сбой при прерывании возникает только в одной точке программы. Если ещё прерывание происходит нечасто, тогда сбой может проявляться очень редко, например, раз в неделю. Искать такой дефект трудно.
Для себя считаю наличие больших программ в прерывании плохим программированием.
Использую простой алгоритм: в прерывании – необходимый минимум действий и выставляется флаг, обработка прерывания в основном цикле в окне прерываний.
Насчёт float и возраста программы. Вам понадобился логарифм, и вы были вынуждены использовать float. У меня современная программа, там есть встроенный логарифм на целочисленной арифметике, мне float не нужен.
[uquote="Jack_A",url="/forum/viewtopic.php?p=4388305#p4388305"]AQ29 спутал программу "ассемблер" с интегрированной средой разработки, частью которой ассемблер является.
А вооще забавно: провозглашать ненужность float - и тут же - про логарифмы?! Даёшь только целочисленные логарифмы!
lg (2) = 0, lg(9) = 1.
Мы с котом Мурзиком долго смеялись[/uquote]
Я не спутал ассемблер и интегрированную среду разработки.
В посте предварительно для краткости написал слова «условно говоря, современный ассемблер».
Интегрированная среда разработки, в которой есть все ассемблерные команды и т.д. – это долго писать.
Лозунг «Даёшь только целочисленные логарифмы!» для меня уже устарел, я такой использую.
Кот Мурзик может продолжать смеяться, для вас поясню.
Выше в посте писал, что единице соответствует число 1024, т.е. будет не lg(2), а lg(2048). Впереди ещё есть множитель, значение не помню, надо смотреть в описании логарифма.
Вообще, целочисленная арифметика – довольно интересное и увлекательное занятие.
AQ29, с вами спорить - себе дороже.
Если у вас прерывания зависают на таком простом камне как АВР - значит вы их готовить не умеете.
И короткие прерывания у вас будут зависать точно так же.
Прерывание может вызываться в любом месте программы. И программа не должна даже догадаться, что вдруг прилетело прерывание.
Для этого достаточно сохранить SREG и используемые регистры. а потом не забыть их восстановить.
--
Касательно логарифма - покажите всем команду вычисления логарифма в современном ассемблере.
Фрагмент кода или скрин подойдет.
А то мы тут такие тупые блондинки, нихрена не понимаем, пользуемся устаревшими флоатами и аналоговыми логарифмами....
OKF, как говорил кот Матроскин - я еще и на машинке строчить умею.... )))
Вы не поверите, я еще и в паяльник с хлорным железом умею...
AQ29 писал(а):Если ещё прерывание происходит нечасто, тогда сбой может проявляться очень редко, например, раз в неделю. Искать такой дефект трудно
Неверный метод тестирования.
AQ29 писал(а):для себя считаю наличие больших программ в прерывании плохим программированием.
Запретите прерывания в начале обработчика, разрешите в конце - и можете писать сколь угодно большой обработчик. И это будет хорошо. Плохо - непонимание механизма работы прерываний и неумение им управлять.
Martian, в AVR, когда зашел в обработчик прерывания, прерывания УЖЕ запрещены, и дополнительно запрещать их не недо.
а когда выходишь из обработчика, прерывания разрешаются автоматически, и принудительно их разрешать не надо.
Мудрость приходит вместе с импотенцией...
Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Замечу. Когда из обработчика выход по RETI, да прерывания разрешаются. Бывает, иногда, полезно выходить по RET, в этом случае можно использовать команды BRIE и BRID.
а еще иногда бывает, что при входе в обработчик полезно сразу же разрешить прерывания, чтобы очень важное событие обработало собственное прерывание с минимальным опозданием.
Мудрость приходит вместе с импотенцией...
Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Starichok51, Да. Но это редкие случаи и в таком варианте действительно правильней делать прерывания максимально короткими.
Если мне не изменяет память, Ридико Л.И. какой то свой генератор делал - у него почти весь код генератора был в огромном таком прерывании. А ошметки процессорного времени отводились на управление этим генератором...
Ну, не такие уж и редкие. Но и в таких случаях необязательно делать обработчики максимально короткими . Если я уверен, что нет риска переполнения, зачем? И именно за этим надо следить. А то можно наплодить кучу вложенных процедур из основного цикла, что точно также всё обрушит и без прерываний. Или одним малюсеньким прерыванием, после чего обвинить его во всех грехах )
В общем, нельзя из какого-то метода делать догму и потом лениво следовать ей, это ограничивает.
AQ29, Я так понимаю, на вопрос про команду логарифма в современном ассемблере ответа не будет....
Предупреждение :
RCALL и ICALL - это команды прямого и косвенного перехода, но не директивы вычисления логарифма.
Just_Fluffy
Как уже писал, большая программа в прерывании – источник проблем:
- можно затереть какую-нибудь переменную,
- может возникнуть проблема из-за использования какого-нибудь аппаратного устройства (таймер, SPI и т.д.), которое используется в основном цикле,
- может возникнуть проблема из-за времени, поскольку программа слишком долго находится в прерывании,
- при работе в прерывании МК не реагирует на другие прерывания, если запретить, можно пропустить важное прерывание,
- сложности с дальнейшим развитием программы и т.д.
Конечно, можно все проблемы решить, но зачем.
При обработке прерываний в основном цикле всё гораздо проще.
Достаточно времени, свободны ресурсы МК, хороший контроль работы и т.д.
Вероятность совершения ошибки гораздо меньше, поэтому предпочитаю такую работу, так что дело не в том, что «не умею готовить».
Это вообще-то довольно большая тема.
Предупреждение насчёт RCALL и ICALL очень ценное, учту.
К счастью, логарифм вызывается другой командой:
A = Log_10_2 V n
10 – десятичный логарифм, 2 – аргумент 2 байта.
Здесь V – двухбайтная переменная, А - двухбайтная знаковая переменная.
n – множитель, чтобы сразу привести результат к нужному значению.
Например, если надо получить результат на 20 % меньше, надо написать 0,8.
Сама программа – около 17 строк.
Вообще-то логарифм на целочисленной арифметике давно выкладывался в интернете.
Не знаю, как делаются ссылки, напишу текстом.
Это сайт easyelectronics.ru, на форуме раздел Valhalla, на 3 странице подраздел Алгоритм билдер (описания, без программ), последний пост от Alexander_1 от 26 марта 2016 года.
Как совпало, сегодня прошло ровно 7 лет, для программирования это большой срок. Так что Jack_A сильно запоздал с лозунгом про целочисленные логарифмы, народ уже давно пользуется, 265 скачиваний.
Там логарифм написан на АБ.
Сама программа относительно несложная, а вот расчёт точек разбиения и коэффициентов довольно непростой.
Аппроксимация даже разная: вдали от нулевого значения функции - пересечение, а вблизи – касательная, она лучше прилегает к логарифму.
