roboforum.ru

Michael_K писал(а):посмотрите код прошлом моем посте - когда лучше(и правильнее) писать OCR2
(это величина "до которой считать" Таймеру2) ?

"1) OCR2 пишем когда захотим, внутри программы в обработчике переполнения Т0 работающей, а Т2 тупо сам работает по своему прерыванию по переполнению. Возможные перебои во время переписывания Т2 - не отвлекаемся."
Это возможно только в некоторых режимах работы таймера (корректная фаза и частота)

"2) OCR2 пишем только в начале самого прерывания по переполнению Таймера2, там-же где и его "общий счетчик" TCNT2."
Это - самый "красивый" и управляемый путь. На ваших частотах я бы использовал именно его.
Только не забудьте, что переменная, в которой хранится будущее значение OCR2
1. Должна быть объявлена как "volatile"
2. Запись в нее должна быть обрамлена в критическую секцию (если она двухбайтная и оба байта используются)

Добавлено спустя 13 минут 18 секунд:
Re: Прошу помощи - одновременное исп. трех таймеров на Atmega8

Alex_Sor писал(а):так они (насколько я понял вас) и так не разрешаются...

Зависит от того, что генерирует ваш компилятор. На асме можно написать и так, и сяк... и об косяк.

Alex_Sor писал(а):Т.е. получается что Atmega совсем тупое изделие, и его таймеры предназначены ТОЛЬКО для того чтобы рулить его "выходными ногами" ?

Как раз нет - все там управляемо: хочешь разрешай прерывания, не хочешь - не разрешай. Но этим именно нужно управлять. Я просто не знаю, как ведет себя CVAVR, чтобы конкретно что-то посоветовать.

Alex_Sor писал(а):тогда этим придется везде по ходу длинного кода заниматься...

Да, если код длинный (долгий) и разветвленный, то это неудобно.
У меня просто обычно "основной цикл" очень простой и быстрый-короткий получается...
Так почему-то повелось...

Alex_Sor писал(а):Это как раз не извращение.

Ну вот я бы как раз по этому пути пошел. Вообще я обычно стараюсь все временнЫе функции на один таймер вешать...
Тоже не факт, что именно так и надо - ну просто лично у меня так мозги работают...
Традиция

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


для того что я хочу сделать надо смотреть в сторону вот этого:
http://www.softelectronics.ru/docs/micro/C8051F340.pdf
но это недешовое удовольствие...

подробности напишу отдельно.
Для потомков так сказать... чтобы не питали иллюзий и не повторяли моих ошибок.

Alex_Sor писал(а):...поставленная мной задача не решается на Атмегах...

Alex_Sor писал(а):...прошлая прога контроллера была...

Но иллюзии то разрушены!

Что-то мне подумалось, что проблема ТС не совсем в таймере, а в самом алгоритме регулирования напряжения, т.е. в отсутствии ПИД регулятора. Или пока вы не добились хоть какого-то управления ШИМом?

Michael_K писал(а):

Alex_Sor писал(а):...поставленная мной задача не решается на Атмегах...

Alex_Sor писал(а):...прошлая прога контроллера была...

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

Добавлено спустя 21 минуту 14 секунд:

HarryStar писал(а):Что-то мне подумалось, что проблема ТС не совсем в таймере, а в самом алгоритме регулирования напряжения, т.е. в отсутствии ПИД регулятора. Или пока вы не добились хоть какого-то управления ШИМом?

шимом как раз легко...
а вот поставленную мной в первом посте задачу - фиг!

по-порядку:
1) в атмегах одноуровневые прерывания без диспетчера и иерархичности, т.е. прерывание это общее прерывание проца и без вариантов... из этого следует что прерывание должно быть только одно, + ваш "основной цикл по опросу" типа while(1) в котором у вас вволю флагов и переменных для раздумий и принятий решений... Программы в которых более одного прерывания по таймеру - обречены на провал изначально. аминь.

2) если прерывание по таймеру - то забудьте о функциях типа delay(xxx); навсегда - время задержек будет увеличиваться пропорционально частоте использования прерываний... т.е. если у вас 2 сек делай + прерывание от таймера то вы попали. Задержки будут 2 сек + число прерываний * время отработки одного прерывания. убежать от этого можно только отказавшись от delay(xxx);

3) единственный способ чем-то наружным управлять шимом или двумя-тремя шимами - это fast pwm БЕЗ прерывания, и рулить только вгрузкой в таймеры OCRx величин БЕЗ прерываний. Тут можно себе позволить какое-то одно прерывание но если оно от таймера- то сам этот таймер будет работать рвано - так что его можно только как единственный "маркер времени" это можно использовать - а остальная прога - в режиме проверки флагов и некритичности к времени исполнения своего кода.

в общем - грустно... читаю про ATXMega - там наворотили поинтересней... уже можно делать красиво...
но если что-то серьезное делать - то мне рекомендуют смотреть в C8051xxxx ...но там уже все серьезных денег стоит и С-компилеры правильные от 1500 баксов... шара не катит.

в общем неделя была потрачена на "просветление" и прозрение в области "что на не пишут в даташитах". Жаль что контроллер этот придется как-то доделать прогу и ... забыть - перспектив с этим процессором там нет.

Re: Прошу помощи - одновременное исп. трех таймеров на Atmega8

Alex_Sor писал(а):в атмегах одноуровневые прерывания без диспетчера и иерархичности

Это так. Всю иерархию (если она нужна) нужно делать вручную. И это гораздо более гибкое решение, чем любой железный "диспетчер".

Alex_Sor писал(а):Программы в которых более одного прерывания по таймеру - обречены на провал изначально. аминь.

Это полная ерунда.

В вашей программе основная проблема в том, что два "независимых асинхронных процесса" занимают один и тот же ресурс. Например лезут в АЦП. Представьте один процесс инициализировал АЦП, запустил преобразование и ждет, когда АЦП отработает. И "вдруг" просыпается другой процесс, который тоже инициализирует АЦП, запускает его... Абсолютно естественно, что первый процесс уже никогда не дождется корректного результата. Ровно то же самое было бы в любой другой системе - и в компе и в чем угодно. Чтобы такого не происходило, нужно пользоваться критическими секциями. А лучше проектировать программу так, чтобы независимые процессы не лезли в один и тот же ресурс.

Другая проблема вашей программы в том, что прерывания, вероятно, физически не могут отработать за нужное время - это потенциально приведет к всплытию стека. Грубо говоря, вы каждые 200 микросекунд хотите получить два значения из АЦП (их измерение занимает 130 микросекунд), но при этом вы хотите воткнуть между этими циклами еще одно прерывание, которое тоже хочет прочитать два значения из АЦП (то есть еще на 130 микросекунд). Ну оно же физически туда не вписывается - очевидно же.

Alex_Sor писал(а):если прерывание по таймеру - то забудьте о функциях типа delay(xxx);

Да. Если функция delay() опирается не на таймер, а на скорость выполнения цикла. Точно так же ведет себя любая другая система - например, компьютер.

Alex_Sor писал(а):единственный способ чем-то наружным управлять шимом или двумя-тремя шимами - это fast pwm БЕЗ прерывания, и рулить только вгрузкой в таймеры OCRx величин БЕЗ прерываний.

Полная ерунда.

Alex_Sor писал(а): Тут можно себе позволить какое-то одно прерывание но если оно от таймера- то сам этот таймер будет работать рвано

С чего это он будет "работать рвано", если оно "какое-то одно".

На самом деле, с такими временами как у вас - десятки-сотни микросекунд (сотни-тысячи тактов процессора) можно сделать почти все что угодно даже на СИ.

На ассемблере не очень сложно выдавать критичные ко времени события с точностью кварца (если это действительно нужно), даже не используя аппаратных возможностей таймера.

Alex_Sor писал(а):ATXMega - там наворотили поинтересней

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

Alex_Sor писал(а):перспектив с этим процессором там нет.

Ну и ладненько.
Удач, несмотря ни на что.
P.S.
Про С8051 - доставило.

Полностью согласен с Михаилом. Не вижу никаких сложностей реализовать задумку на атмеге.
Сейчас делаю видеовыход программный на атмега32, там строчные импульсы 15750 Гц, 50 мкс на формирование изображения во время развертки строки, плюс еще звук оцифрованный, выводящийся через ШИМ и I2C одновременно работает у меня. Все на чистом Си с прерываниями. И как-то успевает и не глючит. И с разными таймерами.

Нужно вам просто кардинально переделать работу с прерываниями и все получится.

По моему проще и быстрее всего будет использовать RTOS.Один таймер на максимально необходимой вам частоте даёт прерывание , внутри счётчики тикающие от необходимого значения до нуля, по обнулению заталкиваем в очередь на исполнение задачу счётчик которой обнулился.В диспетчере ставим приоритет процесса программного ШИМа над всеми и вуаля))

Grofus писал(а):По моему проще и быстрее всего будет использовать RTOS.

"Не плодите сущностей сверх меры" (с) бритва Окккама

я уже выкрутился и решил свою задачку так как хотел.

Решение оказалось простое:
1) Таймер0 используем в режиме "фаст ШИМ", т.е. он сам считает по вечному циклу, генеря прерывания по "переполнению", я только прескалером + "сколько считать" задаю ему параметры один раз при старте проги. Счетчик циклов я не пишу каждый раз - он задан раз и навсегда в установках, считывается и устанавливается при первом(после выкл.питания) старте программы. Внутри программы идет проверка на граничные напряжения (мин--макс) и соответствие токов заданным значениям (если есть нагрузка), с формированием строчки: OCR2=число; Всё пролетает без циклов за один проход проги прерывания. Расчет на то что если "не угадали" в этот раз - то будет еще 1000 попыток в секунду потом для корректировки и точного попадания.

2) Таймер1 - использую как "коммандоаппарат" который стартует 1 раз в 0.5сек (чаще мне не надо, да и всегда можно перегрузить его счетчик). Счетчик циклов вгружается в него первой строчкой при прерывании по переполнению. Внутри обрабочика прерываний поместилось много чего полезного

3) Таймер2 - это мой ШИМ который ногой OCR2 мне формирует свечение светодиода оптопары ОС микросхемы БП. Прерываний не генерит вообще!
Настроен как "фаст ШИМ" на частоту считания со сравнением с OCR2 - когда досчитывает до ОСR2 - выходной порт стает "1", как досчитал до "счетчика", сбрасывается в "0". Управление идет "на лету" - прога из обработчика Таймера0 тупо пишет: OCR2=число; операция не требует запрета прерываний и не рвет выходную последовательность ШИМ таймера2.

Сложность была в том, что на "отладчике" невозможно предугадать как поведет себя БП при старте, и неизвестна его "тау"(время выхода на рабочее напр. ХХ).
Поэтому при старте проги тупо стоит задержка на 500мсек, за это время успевает (проверено кучей опытов) стартовать БП и уже потом его управление подхватывает процессор. В некоторых случаях интересно получается - проц "поднимает с пола" напряжение если идет сбой по 220В или "искрение" при вставке вилки в розетку. Скорость реакции меня устраивает. Можно гнать хоть до 1000 раз в сек. проверку - но смысла нет - БП весьма задумчивое устройство - реагирует на воздействие не сразу. Думал считать "время реакции"(первая производная по времени роста напряжения) и по нему предугадывать что выдать в БП - но это уже слишком будет для такой схемы обычный перебор типа: ХХ++; решает проблему вместе с проверкой на "попадание в коридор" нужного тока-напряжения. Да, возможны колебания, но устройство не требует суперточности на выходе.

Сейчас сижу пишу "логику работы".
Железо и управление более не проблема. И это хорошо!

Получилось реально три параллельных процесса которые сами собой рулят по правилам которые я пишу. Что и хотелось изначально

Таки перешли то есть на железный ШИМ?

Да - Таймер2 это "fast PWM" со всеми вытекающими.
Железный ШИМ который живет сам по себе - в него только КОГДА Я ХОЧУ я загоняю данные в "регистр сравнения".