#p164115,ARoot написал(а):Мне интересно что там упущено на Ваш взгляд? Я доработать хочу и попользоваться. Спасибо
Не за что... А как Вы собираетесь пользоваться, если автор (ГУФ sn_nn) не сказал самого важного - как этим прибором собственно пользоваться !?
Это во первых. Во вторых, очевидно, что автор говорит одно, а его прибор (и программа) работает немного иначе (не так как он пишет). Если это все не важно (точность частот воздействия, "резонансов", времени, выбора мощности, плавности и т.д.), то чего мы хотим добиться на самом деле !?
Если никаких "резонансов" и эффектов "прихода Ци" не наблюдается, а задача просто сделать любую мигалку, то это уже и так есть. Это работает. Нет самого главного как раз: будет ли терапевтический эффект от применения этого прибора, каким он будет, у всех ли будет, когда будет, как гарантировано его достичь и в каких случаях. Это самое главное как раз, и на это указали все понимающие о чем тут идет речь ВАГУФы. Если Вы поняли и знаете больше об этом и лучше понимаете, что Вы хотите делать и как, то не лишним будет рассказать - "как Вы собрались доработать и пользоваться".
#p164115,ARoot написал(а):Мигать то будет, я и не спорю, но несущая частота скажем для 80Гц, которую хотел использовать vik55, будет даже в Вашем причесанном коде ~83Гц и толку наверное не будет. Период для 80Гц = 1/80= 12,5мсек; long(целое) interval = 500/80 = 6мсек -половина периода, полный период соответственно 6*2 = 12мсек. Уже упущено 0,5мсек. Считаем частоту при этом периоде 1/12 = 83.33333 Гц, что и подтверждает симулятор в Протеусе.
Сам подход не правилен. Вы забываете, что Вы программируете для медленного 8-разрядного МК. А там у вас (и автора) формулы с вещественными типами переменных !? Зачем ? Это только усугубляет проблему. Много лишних тактов. Тактовая частота МК делится аппаратно целыми делителями (степени двойки). Если Вы программно далее делите, то нужно учитывать время выполнения критичных участков кода. Как Вы хотите точно разделить и получить на выходе МК частоту с точностью до десятых герца !?
Это не получится никак. Критичный по времени код (формирование одного импульса) нужно написать на ассемблере, нельзя доверять это компилятору. Далее уже по обстоятельствам, но нужно постоянно иметь ввиду время выполнения кода и наличие аппаратных прерываний, которые вы разрешили и обрабатываете, чтобы параллельно делать что-то другое (вывод на достаточно медленный индикатор, обработка кнопок и пр.).
И для трех градаций яркости - ШИМ не нужен. Зачем !? И лучше разделить: формировать основную (лечебную) частоту на одном выводе, а управление мощностью-яркостью свечения делать другими выводами МК. Так намного лучше, удобнее и правильнее. Можно сделать ЦАП на резисторах. Можно и ШИМ, но зачем он там опять же ? Если хотим "резонансы" получить, то
чем круче фронты импульсов, тем лучше. Если плавность хотим, то нужно синусоиду (полусинус) или подобную кривую формировать через ЦАП (на резисторах) или внешний ЦАП (отдельная микросхема, в ATMEGE нет его).
Плавную кривую, чтобы быстро и нормально работало, все люди делают по предрасчитанным таблицам. Не нужно бестолку тратить ресурсы МК.
Да и на Протеусе (симуляторах) не нужно зацикливаться. Это иногда вредит, а не помогает. В плату Arduino можно панельку припаять (встроить), если так уж жалко лишний раз МК перепрошить... Да и вообще, буратину эту - "в топку"... Пишите на "Си" лучше и программируйте программатором, хоть самым простецким, это будет гораздо больше "тонких" возможностей.