БАНо
У меня подозрение на то, что прерывание обоих каналов просчитывается одним и тем же таймером. Не пойму как он определяет из какого канала получил длину импульса? готов отказаться от аварийки в пользу использования отдельных таймеров для каждого канала.
одозрение на то, что прерывание обоих каналов просчитывается одним и тем же таймером.
Пока МаркАнтоний занят давай копнем сами, ткни пальцем в тот исходник который ты используешь плиз и уточни куда именно у тебя что включено(схему). кстати исходник вместе с готовой моделью в протеусе будет соовсем не лишним, там конечно не более 15 минут ее делать, но…
кстати исходник вместе с готовой моделью в протеусе будет соовсем не лишним, там конечно не более 15 минут ее делать, но…
Поменял форму генератора в модели протеуса. Прикладываю архив, в нем и модель в протеус и агоритм в буилдере, схема подробно расписана в протеусе.
Опишу еще алгоритм словами:
Вкратце:
Имею Р/У модель:
Управляющие сигналы с приемника:
Прямоугольные импулься с периодом 10 мсек с шириной импульса 1-2мсек (измеренно осцилографом) амплитуда 5 вольт.
Канал 1 (Поворот сервомашинки)
Поворот направо 100% - 2мсек
Поворот налево 100% - 1мсек
Прямо - 1,5мсек
Канал 2 (Управление регулятором хода двигателя)
Полный газ 100% - 2сек
Полный назад 100% - 1мсек
Нейтраль - 1,5мсек
Сам алгоритм:
Канал 1
0,9-1,25мсек - мигает левый поворот
1,75-2,2мсек - мигает правый поворот
Канал 2
0,9-1,45мсек - светят стопы и габариты
1,55-1,75мсек - светят габариты
1,75-2,2мсек - светят габариты и фары
При пропадение канальных импульсов работает “аварийка”
Похоже причина наложения прерываний в отсутствии сдвига между импульсами в разных каналах. Завтра на работе измерю два канала одновременно осцилографом. Пока мои домыслы на вложенной картинке.
Пока мои домыслы на вложенной картинке.
Бывают оба варианта! но если чтение канальных импульсов написано с учетом этого, то глюков быть не должно
Ну что ж друзья, сегодня мои подозрения подтвердил осцилограф. Отсутствие временного сдвига каналов относительно друг друга. Придется отказаться либо от аварийки (один фиг она не будет у меня работать, так как при выключенном передатчике импульсы все равно идут и не меняются см.вторую картинку), либо от поворотников. Пытался вчера прикрутить Timer0 к поворотам - не получилось.
Отсутствие временного сдвига каналов относительно друг друга.
Тем проще. значит передний фронт всех импульсов одновременно. осталось вычислить задний. Не вижу причины унывать. на самом деле нужно обрабатывать канальные импульсы независимо друг от друга. и проблем больше не будет.
В том то и проблема. Так как для обоих прерываний используется один и тот же таймер. Передний фронт попадает в таймер одновременно с обоих прерываний, а вот задний либо который опроситься первым, либо как то еще. Если бы передние фронты сигналов были сдвинуты относительно друг друга, проблем бы с использованием одного таймера не возникло.
выходные каналы то разные? в чём проблема может быть? если прерывание с разных лап приходит, а стартовое можно использовать для запуска таймера и тем проще что оба канала паралельно генерят 😉
Если бы передние фронты сигналов были сдвинуты относительно друг друга, проблем бы с использованием одного таймера не возникло.
Так сдвиньте сами, в чем проблема? Один такт обрабатываете повороты, стопы пропускаете, следующий - обрабатываете стопы, повороты пропускаете. Да, такт обработки увеличится с 20 до 40 мс, но зато все станет универсальным и пригодным для любого варианта выхода приемника. В конце концов лампочками на машынке блымать - не хвостом на вертолете крутить 😃
Если бы передние фронты сигналов были сдвинуты относительно друг друга, проблем бы с использованием одного таймера не возникло.
Я думаю все дело в построении алгоритма.
Дело не построении алгоритма, а в том под что алгоритм писался. Когда я писал исходник, то делал это под свой спектрум, а там сигналы сдвинуты и всё работает. Если реально импульсы стартуют одновременно, то это фича аппы и тогда действительно надо с алгоритмом что-то решать.
Поставить счетчик каналов и по этому счетчику перебирать прерывания по каналам, поскольку пользуем один таймер.
Avto 4_5.rar
Или перейти всё-таки на мегу48 и использовать таймер2. Подумайте, порешайте…
Вот не пойму, чего так народ ломится на аттини? 😉 В tqfp32 мега48 дешевле, в дипе, правда на полбакса дороже, но ведь и начинка-то серьезнее… Не понятно…
Кстати pind2 и pind3 таки лучше подтянуть к +5В.
Когда я писал исходник, то делал это под свой спектрум, а там сигналы сдвинуты и всё работает.
Вот про это я и говорю алгоритм взят с расчетом что каждый канал обрабатывается индивидуально и при этом на остальные внимание не обращается - независимо от состояния входов.
Зато в случае когда нужна одновременная обработка алгоритм этот уже неработает. нужен собственный алгоритм обработки для такого варианта, но он не сможет гарантированно работать в случае сдвинутых импульсов.
Третий вариант когда каждый канал обрабатывается полностью независимо от остальных, одновременно или последовательно или вообще в разнобой. Вот этот случай будет работать всегда.
надо при обработке прерывания смотреть на второй канал прерывания и запускать таймер только если он не запущен и тормозить только в том случае если канал с более коротким импульсом уже прочитан либо ещё проще - читать таймер поочереди - сначала 1й канал, на следующем прерывании со 2го канала и тд… по флагам оринтироваться
надо при обработке прерывания смотреть на второй канал прерывания и запускать таймер только если он не запущен и тормозить только в том случае если канал с более коротким импульсом уже прочитан либо ещё проще - читать таймер поочереди - сначала 1й канал, на следующем прерывании со 2го канала и тд… по флагам оринтироваться
Просто нужно пользоваться таймером как то иначе. не сбрасывать его по началу каждого импульса, а только по первому из серии(первый канал например) а далее читать текущее значение на момент входа в прерывание различая состояния фронт/спад и сохраняя время начала/конца импульса в отдельной переменной индивидуально для каждого канала. Вообще судя по схеме в Avto4_4 каждый канал обрабатывается собственным прерыванием. совсем не ясно почему обеспечиваются глюки. исходник то есть?
Исходник и правда есть, для Алгоритм билдер…
Предлогаю, для случая с параллельными канальными импульсами, в обработчике прерывания External_1 просто прибить все оставив лишь единственно полезный момент - запись значения tcnt1 -> Period1. Все остальное, особенно обнуление Таймера1, считать вредным излишеством, тк он уже был обнулен, еще в обработчике External_0.
Впрочем там и других вопросов хватает, например зачем проверять номер обрабатываемого канала внутри “чужого” обработчика? это было бы разумно если бы все прерывания обрабатывались единым алгоритмом. С автором бы обсудить. Похоже что изначально задумывалось универсальное решение, но реализовано было лишь частное, отсюда выплыл глюк.
глючит потому что по каждому из прерывания происходит сброс-старт и стоп таймера, таймер один и тот же используют, а далее прога использует то что таймер насчитал
Probelzaelo, мы об одном думаем:)) тока разными словами.
внес в прогу счетчик каналов. см. мой пост выше.
внес в прогу счетчик каналов. см. мой пост выше.
что то я пытался найти отличие. не увидел…
Если реально импульсы стартуют одновременно, то это фича аппы и тогда действительно надо с алгоритмом что-то решать. Поставить счетчик каналов и по этому счетчику перебирать прерывания по каналам, поскольку пользуем один таймер. Avto 4_5.rar Или перейти всё-таки на мегу48 и использовать таймер2. Подумайте, порешайте…
С одним таймером вполне можно обходиться. Для случая с параллельными импульсами. нужно не забывая про приоритеты прерываний обнулять таймер по прерыванию INT0, остальных в этот момент можно проигнорить. А потом, по мере окончания импульсов просто присваивать текущее значение таймера соответствующему значению. кан импульса. тем более что, в данном конкретном решении, используется всего два внешних прерывания int0 и int1. для int1 весь обработчик может состоять из единственной строчки Импульс1=Таймер1, это будет чистейшей правдой, кроме случая когда импульсов нет совсем(приемник скис и тп… ))
cnt_channel. в обработчиках прерываний.
Есть предложение не тормозить таймер1 вообще, а в обработчиках захватывать числа из него по фронту и спаду управляющих импульсов. Затем из бОльшего вычитать меньшее.
Как автор самой первой версии могу сказать, что задумывалась вся эта шняга как БАНО, управление по одному каналу. Потом, когда появилось желание управлять от двух каналов, кто-то, а может и я, внес обработчик второго прерывания и такое использование таймера. Для стандартной аппы всё работало, у меня и сейчас есть проекты, где отрабатывается по двум входам и уверен, что при необходимости будет обрабатывать и больше, потому как импульсы каналов стартуют последовательно по времени.
Есть предложение не тормозить таймер1 вообще, а в обработчиках захватывать числа из него по фронту и спаду управляющих импульсов.
Ну да, примерно так. Но это годится только для приемников у которых импульсы стартуют параллельно. Получается такая петрушка что пока алгоритмы обработки не универсальны, или - или…
С другой стороны изобретается велосипед. ведь все это уже реализовывалось не однократно. например PPM SUM - это просто (очередное простое решение проблемы) и кстати - #40 не правда ли ожидается следующая знакомая ситуация? 3 канала одновременно, потом еще три, и потом остальные ))
Если реально импульсы стартуют одновременно, то это фича аппы и тогда действительно надо с алгоритмом что-то решать. Поставить счетчик каналов и по этому счетчику перебирать прерывания по каналам, поскольку пользуем один таймер.
На выходных остался без интернета и потому не читал тему. Решил таймер 0 который использовался для “аварийки” приспособить для поворотов. Все работает. См.вложение Avto 4_5(alternative).rar
Вот не пойму, чего так народ ломится на аттини?
К сожалению когда нашел данную тему и был в Новосибирске, читать ее времени не было. Поэтому купил то что использовал МаркАнтоний, надеясь просто прошить и радоваться, но столкнулся с проблемой параллельных импульсов и понеслось + еще хотелки разные.
Поставить счетчик каналов и по этому счетчику перебирать прерывания по каналам, поскольку пользуем один таймер.
Попробовал алгоритм в Proteus. Что-то не работает как надо. Но мысль понял. Попробую еще в железе.
Теперь вот думаю как организовать задержку выключения фар на 5 сек. после того как машина остановилась. В теле main паузу использовать нельзя, т.к. это тормознет всю программу на 5 сек. Надо чтобы отсчет времени происходил параллельно, и после того как отсчитаются 5 сек. некая переменная бы изменила значение и в основной программе проверять значание этой переменной. Для этого наверное можно было использовать таймер, но они и так уже кончились.
Еще хотел для габаритов и стопов использовать один и тот же светодиод.
Тут есть 2 варианта:
1.Можно конечно с двух ног через резисторы подавать сигнал на один светодиод. Через R1 допустим ток 5мА - это будет габарит, А если через R1 и R2 то будет допустим 5мА + 20мА и это будет уже стоп.
2.Использовать некое подобие ШИМ. Что и было сделано см.Вложение в Auto 4_6. Вот только при простое, когда ничего не должно светить появились кратковременные вспышки с плавающей частотой. Причем при выключении передатчика вспышки исчезают.
Также не логично выглядят горящие стопы при езде назад и загорающиеся фары при торможении при езде задом. Подумаю над логикой, как все это должно работать.
Вот не пойму, чего так народ ломится на аттини?
Все просто, для коммерческой реализации важна конечная стоимость. А она определяется не только ценой кристалла, но и количеством лапок, и размером платы, и ценой адаптера. Для задачи БАНО достаточно 13 тини. Для стопов или поворотников - 25 тини (поскольку там нужен кварц). Для совмещенной задачи - 24 тини (наличие кварца и соответствующего количества ног), причем таймер для обработки там нахненужен - только ловля приключений себе на задницу, что собссно и наблюдается в крайней странице данной темы.
Подумаю над логикой, как все это должно работать.
Золотые слова. Только делать это нужно до, а не после 😃