Помогите начинающему по ATmega8515

[alvadep]

Лучше вот сюда посмотреть. Лучше книги по двоичной арифметики не видел! Все, начиная от простого сложения, заканчивая синусом!

Тоже не плохая книга. В общем, есть по чему осваивать математику для процессоров. И совсем не обязательно для математических вычислений использовать Си со своими библиотеками. Аналогичные библиотеки можно составить и на ассемблере только конкретно под свои нужды и по мере надобности подключать их в проект.

[Pajatel]

Фуххх ...котелок скоро треснет, спасибки за инфу, грызу потихоньку.. Извиняюсь , что вклинился в не свою тему со своими вычислениями, ну наверное многим будет полезно почитать..
Я вот иногда на этих сайтиках кое что заимствую, вполне адекватно работают некоторые коды:
The AVR Assembler Site
Binary calculations in AVR Assembler
А по поводу своих вычислений, так чумствую несколько дней еще повишу, хочется отработать кусок математики чтоб был как можно покороче и побыстрее, похоже , этот кусок мне ещё не раз понадобится..
Задачка в принципе тривиальная - посчитать обороты мотора изходя из длительности между импульсами, как бы ничего особенного и в инете этих тахометров вродь как хватает... но как всегда, или точность никакая или считают обычно просто количество импульсов за время, как частотомер, что тоже меня не устраивает... общим пыхтю

[pinco]

Понравилась больше первая ссылка , спасибо

....Задачка в принципе тривиальная - посчитать обороты мотора изходя из длительности между импульсами, как бы ничего особенного....

Ну тут немного ошибаетесь - не совсем тривиальная в плане реализации на одном только контроллере без дополнительной логики - если я правильно понял то определяется длительность импульса и на первых же импульсах тогда уже вычисляются обороты - это не простой обычный подсчет самих импульсов за фиксированное время 1 или0,1 сек или 0,01 сек как в частотомерах - а получается что инфа о длительности импульса должна быть получена быстро, в течении первых допустим нескольких импульсов , с приемлемой точностью - тогда придется этот интервал между импульсами для его определения длительности - заполнять более высокой частотой и эту частоту считая - вычислять длительность импульса ,а из него - обороты .Правильно понимаю ? Допустим если макс частота импульсов с датчика движка до макс 1000 Гц ,грубо. сколько конкретно - поправьте , обороты считаем до десятых точность допустим ,тогда если пока принять что идет один импульс на оборот (если другое - поправьте) то частота заполнения в каждом импульсе для макс вкорости вращения должна быть не менее 10.000000 Мгц - сам контроллер имеет тактовую уже соизмеримую с этой частотой - поэтому для точного измерения такой частоты придется самый первый счетчик возможно делать аппаратный на логике отдельной микросхемой , а остальные счетные за ним уже не такие быстрые нужны - можно реализовать и в контроллере ,ну и пересчет в обороты естественно в нем же .Вы применяете внешние первые делители с считыванием инфы с них в контроллер , или у Вас настолько низкие частоты вращения движка что оказалось достаточно и быстродействия одного только контролера для реализации первых и остальных счетчиков ?

P.S. И еще при таком способе уже начинает влиять устойчивость , фазовая точность что-ли , на показания потому как дрожание в мкс уже - влияет на дрожание полученного результата в последних единицах при поступающей на измерение 10.000000 Мгц частоте, так что и сам датчик импульсов должен выдавать импульсы с мотора очень четкие и стабильные по фазе при стабильных оборотах текущих , и причем во всем диапазоне возможной регуляции оборотов настраиваемого движка .У Вас хорошие датчики ?

[Pajatel]

Ну в принципе поняли правильно, только не так всё страшно. Вот только хотел обьснить почему.... и похоже наткнулся на ошибку в своей формуле... надо всё перепроверить..
Ну если в общих чертах то будет примерно так, точность нужна плавающая, т.е. с 6000 до 4500 шаг у мну получается 20 об/мин, с 4500-3000=10, с 3000-2000=5, с 2000-1400=2, с 1400-50=1, что немного всё упрощает. Точность нужна в момент заводки, а это 150-200об/мин, потому как в этот период как раз всё самое интересное на моторе и происходит.. Ну вообщим побёг пересчитывать.. Вот поговоришь с умными людьми, сразу понимаешь, что надо учиться, учиться, учиться..
...неее, всё правильно у меня посчитано, просто запутался в ноликах при преоброзовании в целые числа.. Вообщим ситуация такая - за обоорот имеем 2 входных импульса, между которыми и замеряем тики таймера. Можно большую точность получить чем описана выше, тогда при тактовой 16мгц для таймера делим на 64, получаем 250кГц и тик будет =4мкс, что позволяет получить ещё выше точность, но этого не нужно. У мну тактовая хотя и больше 16МГц, но тик я имею 15,625мкс, потому как таймер используется для более важных задач. Ну и самое вредное, это расчёт... Считается по простой формуле "обороты/мин=30/длительность(с). Все просто, но начинаем считать, скажем 320тиков насчёлкало- 320*15,625=5000мкс=0,005с ; 30/0,005=6000об/мин ,или же насчёлкало 38400тиков*15,625=600000мкс=0,6с ; 30/0,6=50об/мин. Если избавится от запятых, то числа получаются в 32 и 24 разряда, что не есть гут.Ну с умножением я придумал просто - запускаю таймер с переполнением допустим FF и в каждом прерывании по переполнению добовляю известное число и в результате имею время, а вот с делением пока ещё вишу, изучаю всяческие алгоритмы... ну может ещё какую хитрость придумаю..

[ut1wpr]

Pajatel, рекомендую. http://ru.numberempire.com/equationsolver.php
Очень помогает переходить к целочисленным вычислениям от дробных. И избавляет от путаниц с ноликом.

[alvadep]

Несколько рекомендаций.
1. На больших оборотах измерения будут не стабильны, нужно усреднять.
2. Пересчитывать обороты за один оборот не кому не нужно, все равно на индикатор выводить нужно не чаще одного раза в секунду (более-менее нормально для восприятия). Из этого и предыдущего пункта вытекает, что и измерения нужно производить за секунду.
Формула для вычисления несколько усложняется, но это на первый взгляд.
Обороты = К*N/T, где К – коэффициент (для Вашей частоты тиков, К = 1920000), N - количество входных импульсов, T - период измерения (количество тиков за интервал измерения).
Алгоритм такой. Подсчет тиков (Т) как обычно. По каждому входному импульсу инкрементирование N (можно сразу вычислять числитель, т.е. суммировать К) и проверка счетчика тиков (период измерения). Если период измерения больше или равен секунде, то произвести вычисление оборотов. При этом нам останется только поделить (К*N) на T. По любому это будет многобайтное деление, без него ни куда.
Кстати частоту тиков можно снизить еще в 4 раза, при этом единичная точность будет до 16000 об/мин.

P.S. Коэффициент рассчитывается так К = 30 * Т, где Т – количество тиков за секунду (30 потому, что 2 входных импульса за оборот).

[Pajatel]

Несколько рекомендаций.

..всё правильно, и такой метод проще.. но..но..но.. , как говорил ранее, он мне не подходит по одной такой причине - индикация оборотов будет присутствовать, но это не главное и высокие обороты меня тоже мало волнуют, не более чем как показометр для общего развития.. А вот на маленьких, тут другое дело.. Идёт обработка не только времени между импульсами, но и длительность самого импульса + пересчёт результатов, коррекция и выдача нужных импульсов обратно... А расчёт оборотов нужен для привязки других данных к скорости вращения ну и конечно для показометра, так сказать для общего счастья.. Проблема с делением получается из того, что мало свободных регистров + оно занимает много тактов, пока не углублялся, но гдет получается более 300. Вот и пытаюсь хитрить так чтоб уменьшить эти тактики хотяб до сотни какой. По одной умной книжке сча разбираюсь с одним методом, может что и выгорит..

....чтобы умножить 976 на коэффициент 0,48576, следует сначала
последний "вручную" умножить, например, на 216 = 65 536, и таким образом
получить числитель соответствующей двоичной дроби (у которой знаменатель
равен 65 536)— он будет равен 31834,76736, или, с округлением до целого,
31 835. Такой точности хватит, если исходные числа не выходят, как у нас, за
пределы трех-четырех десятичных разрядов. Теперь мы в контроллере
должны умножить исходную величину 976 на константу 31 835 и полученное
число 31070 960 (оно оказывается 4-байтовым— $01DA1AF0) сдвинуть на
16 разрядов вправо

;в ddHH:ddH:ddM:ddL число $01DA1AF0,
;его надо сдвинуть на 16 разрядов
clr cnt
divl6L: /деление на 65536
Isr ddHH /сдвинули старший
ror ddH /сдвинули 3-й
ror ddM /сдвинули 2-й
ror ddL /сдвинули младший
inc cnt
cpi cnt,16
brne divl6L /сдвинули-поделили на 2 в 16
В результате, как вы можете легко проверить, старшие байты обнулятся, а в
ddMiddL окажется число 474— тот же самый результат. Но и это еще не
все — такая процедура приведена скорее для иллюстрации общего принципа.
Ее можно еще больше упростить, если обратить внимание на то, что сдвиг на
восемь разрядов есть просто перенос значения одного байта в соседний
(в старший, если сдвиг влево, и в младший — если вправо). Итого получится,
что для сдвига на 16 разрядов вправо нам нужно всего-навсего отбросить два
младших байта и взять из исходного числа два старших ddHH:ddH — это и
будет результат. Проверьте— $01DA и есть 474. Никаких других действий
вообще не требуется!

[alvadep]

Вы с дробями запутаетесь.

чтобы умножить 976 на коэффициент 0,48576

проще коэффициент 0,48576 умножить на 65536 и получите 31835 (с округлением), а потом произведение 976*31835 поделить на 65536. Так проще для понимания.
А может Вам вообще хватит умножения на 256 (один байт туда-сюда подвигать).

[pinco]

Несколько рекомендаций....
Алгоритм такой. Подсчет тиков (Т) как обычно. По каждому входному импульсу инкрементирование N (можно сразу вычислять числитель, т.е. суммировать К) и проверка счетчика тиков (период измерения). Если период измерения больше или равен секунде, то произвести вычисление оборотов..

Так это же тот самый частотомерный режим посчета импульсов за опред период времени в 1, 0.1 или 0.01 сек от которого Pajatel давно отказался .

[pinco]

... .. Проблема с делением получается из того, что мало свободных регистров + оно занимает много тактов, пока не углублялся, но гдет получается более 300. ..

При 16 Мгц тактовой например эти 300 займут 18 мкс примерно - разве этого времени недостаточно с головой выше крыши ? Если пересчитать от этого частоту обработки то грубо получается обработка всего этого с частотой 53 кГц , ну могу допустить что многовато , но и не требуется обрабатывать именно каждые 2 Ваши импульса просчитывать эти пары строго все до одного без пропусков ,ИДЕЮ УЛОВИЛИ ? - все равно визуально не то что бы 53 кГц - да и 1 кГц не усмотришь - а посему и тогда время обработки может быть хоть сколько большим - да хоть 1 мс - а это 16000 тактов контроллера - и на глаз все и так сверхбыстро , и море свободного времени появляется для обработки результатов - а значит не надо загоняться по спецалгоритмам что-то там выискивать покороче - делайте свободно как Вам захочется , а то что некоторые рабочие пары импульсов с датчика будут пропущены - в общем-то не беда - определите для себя сколько их может быть пропущено для небольшого общего некоторого замедления системы , чтобы примерно сохранялась общая быстрая реакция - вот Вам и еще к 300 тактам +300 еще , и +300 еще , и так далее - так что времени для обработки и всего прочего - да вагон просто .

P.S. Про нехватку регистров - а чего ОЗУ не используете - там ячеек ОЗУ байтовых таких же как и регистры - несколько сотен , а не только 32 основных регистра AVR-а - считаю что и этой емкости для творчества - тоже почти вагон , запоминайте там что угодно , благо адресация памяти в AVR линейная и не надо жонглировать еще и банками памяти как в 51 или PIC-ах (тоже считаю преимуществом архитектуры AVR-а).

Так что возможно Вы просто не в то уперлись , а времени и ресурсов AVR-а при толковом распределении для Вашей системы - еще достаточно много , просто море до того как могут возникнуть настоящие проблемы нехватки чего-либо .