Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Изменение текста программы при смене компилятора и чипа
Форум разработчиков электроники ELECTRONIX.ru > Сайт и форум > В помощь начинающему > Программирование
Страницы: 1, 2, 3, 4, 5, 6, 7
Палыч
Цитата(RW6MKA @ Nov 26 2011, 16:36) *
Стоп, так это ж мой вопрос!
Конечно, он - к Вам вернулся, поскольку Вы не удосужились сообщить хоть какую-нибудь информацию о Вашем приборе... Предлагаете телепатировать? Подазреваю, что выключение питания в момент движения антенны Вы считаете "нештатным", а в остальных случаях - "штатным". Или - нет? Тут только Вы сами должны определить: что же Вам нужно то?
Ну, а далее: алгоритм расписан выше: через ячейку EEPROM - штатно/нештатно...
По поводу увеличения циклов записи: 100 тыс циклов Вам мало? Каков назначенный срок службы Вашего устройства до капитального ремонта? Как часто будет переписываться ячейка? По поводу сохранения ресурса EEPROM на этом форуме обсуждения были не раз. Воспользуйтесь поиском.
sigmaN
Приветствую ))
А индикатор положения у нас сейачс уже не резистор, а энкодер с мышки, да?
Просто если всё ещё резистор - то проблема решается очень просто: при включении прибора он считывает последнее значение из EEPROM и вертит антену до совпадения её положения с этим значением.
Ну а если не резистор, то крутить до упора, а потом возвращаться на известное кол-во шагов...
Потому что как ни крути, а вариант с постоянной записью во время вращения всё равно не даёт 100% гарантии запоминания истинного положения + EEPROM заездить так можно значительно быстрее.
Да и если вдруг антена изменила своё положение, пока прибор был выключен - при включении вся ваша индикация собъётся.
toweroff
Интересно...
У меня вот мотоподвес спутниковой тарелки. Единственное, что "знает" мотор "с завода" - это позиция "0"
Все остальные прошиваются
Так вот если его тупо волтузить по дуге в поисках спутника, а потом ткнуть "идти на позицию" или "идти на спутник", то он четко едет кратчайшим путем, то есть никак не связано перемещение с проездом через "0" или проезду к какой-то крайней позиции
Надо посмотреть, что там в кишках у мотора, один битый валяется, но как-то до него руки не доходили
RW6MKA
Цитата(sigmaN @ Nov 28 2011, 15:51) *
Приветствую ))
А индикатор положения у нас сейачс уже не резистор, а энкодер с мышки, да?
Просто если всё ещё резистор - то проблема решается очень просто: при включении прибора он считывает последнее значение из EEPROM и вертит антену до совпадения её положения с этим значением.
Ну а если не резистор, то крутить до упора, а потом возвращаться на известное кол-во шагов...
Потому что как ни крути, а вариант с постоянной записью во время вращения всё равно не даёт 100% гарантии запоминания истинного положения + EEPROM заездить так можно значительно быстрее.
Да и если вдруг антена изменила своё положение, пока прибор был выключен - при включении вся ваша индикация собъётся.

Да, идикатором сейчас энкодер. Выставить в правильное положение не проблема, но при этом нужно что бы при включении что то напомнило что было отключение эл-гии. Вот простая напоминалка при включении и нужна (хотя это я представляю уже как исполнить) Вот поочерёдная запись ячеек EEPROM интересует. Я так понимаю нужно при записи всё время к адресу добавлять 1?
sigmaN
toweroff, я так понимаю у вас стоит что-то вроде переменного резистора и таким образом моторчик в любой момент времени знает своё абсолютное положение относительно нуля. И это не зависит от питания! Крутим двигатель руками, резистор просто меняет своё сопротивление и в любой момент можно подать питание и узнать в каком положении сейчас вал.

Но если же в качестве индикатора положения используется датчик относительного перемещения(а именно так оно и есть у автора), то тут и приходится при включении питания искать 0. Потому что энкодер ничего кроме информации о том на соклько "щелчков" и в какую сторону переместился вал - дать не может.
Собственно по этой причине и нужно после включения отматываться до нуля и уже от него считать нужное кол-во щелчков.
Любые другие алгоритмы управления в той или иной степени обречены на провал(при разных обстоятельствах). К этому можно прийти путём не сложных логических рассуждений wink.gif

Но топикстартер всё равно сделает по-своему, записывая положение в ЕЕПРОМ каждую миллисекунду прямо во время вращения вала и будет изобретать как же эту самую ЕЕПРОМ не протереть за пол года работы девайса ) А ещё скажет, что перемещение антенны, пока девайс выключен - крайне маловероятно и это не аргумент.
Но через те самые пол года эксплуатации таки накопится ошибка и индикация положения начнет портачить.
Тогда и начнем следующую доработку ))
toweroff
Цитата(sigmaN @ Nov 30 2011, 00:06) *
toweroff, я так понимаю у вас стоит что-то вроде переменного резистора и таким образом моторчик в любой момент времени знает своё абсолютное положение относительно нуля. И это не зависит от питания! Крутим двигатель руками, резистор просто меняет своё сопротивление и в любой момент можно подать питание и узнать в каком положении сейчас вал.

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

зы
покопался в гугле sm.gif
есть 93С46 как хранилище, авр типа 2313, релюхи, стабилизатор 7805 и транзюки на релюхах
есть три концевика - 0 и два спаренных по крайним положениям
ВСЕ!
sm.gif
sigmaN
ну и как в таком случае ваш прибор определит своё положение, если вы ему свернули голову, пока питание было отключено?
toweroff
Цитата(sigmaN @ Nov 30 2011, 14:31) *
ну и как в таком случае ваш прибор определит своё положение, если вы ему свернули голову, пока питание было отключено?

Ну, по ходу, сохраняется последняя позиция. От нее он и пляшет
и сворачивание бошки с питанием или нет - это порча имущества biggrin.gif
sigmaN
ну так я просто думал, что
Цитата
Так вот если его тупо волтузить по дуге в поисках спутника,
это и есть "сворачивание бошки".
Если же редуктор там такой, что сворачивание не представляется возможным без поломки - то тогда всё верно.
Однако же топикстартеру всё равно стоит обратить внимание на наличие концевиков в крайних положениях.
toweroff
Цитата(sigmaN @ Nov 30 2011, 17:22) *
ну так я просто думал, что это и есть "сворачивание бошки".
Если же редуктор там такой, что сворачивание не представляется возможным без поломки - то тогда всё верно.
Однако же топикстартеру всё равно стоит обратить внимание на наличие концевиков в крайних положениях.

тогда, возможно, ему проще обратить внимание на готовый мотор и протокол DiSEqC 1.2 ?
sigmaN
На его месте я именно так и поступил бы.
Однако я обратил внимание на наличие концевиков именно потому, что они присутствуют в промышленном образце(таким образом подтверждая необходимость их наличия в устройстве).

Глянул на DiSEqC 1.2... кажется тс оно не нужно.
А вот взять готовый движок с редуктором и прочими концевиками - вроде неплохая идея. Не в последнюю очередь тут важно, что всё это расчитано на всепогодную эксплуатацию.
toweroff
Цитата(sigmaN @ Nov 30 2011, 20:19) *
Глянул на DiSEqC 1.2... кажется тс оно не нужно.

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

Цитата(sigmaN @ Nov 30 2011, 20:19) *
Не в последнюю очередь тут важно, что всё это расчитано на всепогодную эксплуатацию.

о чем и речь. Вкупе с многократно проверенным интерфейсом - самое оно
sigmaN
Хотя это уже и не нам решать )))
RW6MKA
Цитата(sigmaN @ Nov 30 2011, 00:06) *
Собственно по этой причине и нужно после включения отматываться до нуля и уже от него считать нужное кол-во щелчков.
Любые другие алгоритмы управления в той или иной степени обречены на провал(при разных обстоятельствах). К этому можно прийти путём не сложных логических рассуждений wink.gif

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

Цитата
Но топикстартер всё равно сделает по-своему, записывая положение в ЕЕПРОМ каждую миллисекунду прямо во время вращения вала и будет изобретать как же эту самую ЕЕПРОМ не протереть за пол года работы девайса )

Конечно сделаю)). Данные в EEPROM у меня записываются не так часто как вы думаете, а лишь после прекращения вращения, и то если позиция поменялась. А применение датчика по напряжению или току конечно даёт свои плюсы, но и минусов у них очень много(начиная от необходимости очень высокой стабилизации питания датчика(особенно при больших перепадах температуры) заканчивая простым геморроем состыковки вала редуктора и вала переменника)

Цитата
А ещё скажет, что перемещение антенны, пока девайс выключен - крайне маловероятно и это не аргумент.

Именно так.)) Если антенна болтается с валом редуктора, то застрелите такого радиолюбителя))).

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

Да не нужны здесь концевики. Если их поставить, то применение МК в этом случае это стельба из пушки по воробьям. Управление сведётся к двум простым кнопкам, а индикацию сделать в виде светодиодного вольтметра))) Вся прелесть данной кострукции в полном управлении поворотом и индикации положения всего по трём проводам и минимуму деталей в датчике(самом уязвимом для погоды месте). Большая точность как в DiSEqC 1.2 не нужна, это не спутниковая антенна, угол излучения минимум 15-20 градусов. Антенна размерами ...Нажмите для просмотра прикрепленного файла и сразу видно куда она направленна. Вопрос о необходимости корректировки индикации будет виден невооруженным))) взглядом.

Цитата
А вот взять готовый движок с редуктором и прочими концевиками - вроде неплохая идея. Не в последнюю очередь тут важно, что всё это расчитано на всепогодную эксплуатацию.

А вот здесь всё помимо финансового вопроса упирается в габариты антенны и соответственно в момент инерции и ветровую нагрузку. Да любой позиционер от тарелок до 3-4м диаметра на этой антенне свернёт в дугу при первом нормальном ветре( 10-15м/с) а стоимость позиционеров от 5-9м тарелок исчисляется суммой на которую можно купить готовый девайс от Yaesu ещё и на мачту останется)))

Вот сколько писать пришлось wacko.gif , а всегото спросил как при записи и чтении в EEPROM каждый раз переходить к другому адресу? )))
RW6MKA
Да, вот ещё вопрос. Если отказаться от записи в EEPROM в процессе работы блока управления, а писать только в момент отключения питания? Т.е. на ногу питания МК повесить достаточно большой электролит и разделительный диод(чтобы кондёр не разряжался на всю цепь), и включить прерывание по изменению состояния на ноге порта В,подав на неё питание. В обработчике прерывания производить запись. Будет ли такой вариант работать и насколько надёжно?
И ещё. Можно ли вот этот код
Код
Start_Position = eeprom_read_byte(&eePosition);//читаем значение переменной из eeprom
Start_Position = Impuls;
eeprom_write_byte(&eePosition, Start_Position);//записать новое значение в eeprom

заменить на
Код
Start_Position = Impuls;
eeprom_update_byte(&eePosition, Start_Position);

и будет ли перед записью происходить проверка на совпадение данных если вот это
Код
n = eeprom_read_byte(&eePosition);
if (n != Impuls) {
eeprom_write_byte(&eePosition, Impuls);//записать текущее значение в eeprom
}

заменить на
Код
eeprom_update_byte(&eePosition, Impuls);
RW6MKA
Вот ещё назрел вопрос. Почему в коде
Код
void RotorR(void) {  //поворот по часовой стрелке

        OnBit(PORTD, RUN);   //включить поворот (RUN)
        OffBit(PORTD, REV);  //реверс не включать (REV)
        _delay_ms(300);
        while ((!(PIND & 1 << Button_R))|(StatusPovorot != Rstop)) {//пока нажата кнопка поворота
                 Led_Pos();                                         //вправо и поворот не запрещён
                 Shift_Reg();
                 Status_povorot();
        }
        OffBit(PORTD, RUN);   //выключить поворот
        OffBit(PORTD, REV);   //выключить реверс
        
}

при прекращении выполнения условия действие не выходит из цикла?
toweroff
Цитата(RW6MKA @ Dec 2 2011, 21:50) *
Вот ещё назрел вопрос. Почему в коде...

1UL <<
попробуйте

RW6MKA
Цитата(toweroff @ Dec 2 2011, 22:19) *
1UL <<
попробуйте

А это что rolleyes.gif ? Подробней для новичка.
Палыч
Цитата(RW6MKA @ Dec 2 2011, 21:50) *
Почему в коде при прекращении выполнения условия действие не выходит из цикла?

Вероятно, это происходит потому, что Вы неверно записали условие. Скорее всего, Вам нужно побитовое ИЛИ заменить на логическое (т.е. || )
RW6MKA
Цитата(Палыч @ Dec 3 2011, 10:59) *
Вероятно, это происходит потому, что Вы неверно записали условие. Скорее всего, Вам нужно побитовое ИЛИ заменить на логическое (т.е. || )

Да, я уже понял ошибку и исправил побитное | на логическое &&

Вопрос по EEPROM так и остаётся не освещённым((
toweroff
Цитата(RW6MKA @ Dec 3 2011, 10:06) *
А это что rolleyes.gif ? Подробней для новичка.

1UL - это явное указание типа единицы - unsigned long
хотя... это зависит от используемого Вами процессора. Если он 32-разрядный, то в подобных случаях явное приведение единицы к 32-разрядному типу есть гуд, потому как можно глюков нахватать, сам сталкивался
Но Палыч правильно говорит - "операции поразрядного ИЛИ" (|), там не надо
нужно применить операцию "логического И" - &&

Да и очередность операций это хорошо, но я стараюсь всегда явно указывать очередность скобками - на душе спокойнее, что не ошибусь и чего-то не упущу
Код
while ( (!(PIND & (1UL << Button_R))) && (StatusPovorot != Rstop) )
Палыч
Цитата(RW6MKA @ Dec 2 2011, 13:59) *
Можно ли вот этот код...заменить на ...
и будет ли перед записью происходить проверка на совпадение данных если вот это...заменить на...

Функции eeprom_update_xxx отличаются от функций eeprom_write_xxx тем, что перед записью проверяют содержимое.
Поэтому, ответ на оба вопроса - да.
RW6MKA
Остался один насущьный вопрос))) Почему в реальном железе счёт импульсов скачет через позицию или более?(т.е. в два-три раза быстрее, при этом сигнал с энкодера нормальный) Где ещё поставить задержки из учёта скорости поворота 1об/мин? Вот проект в студии Нажмите для просмотра прикрепленного файла и схема Нажмите для просмотра прикрепленного файла
314
В датчике ЛА7 на ТЛ2 (4093, 40106) в смысле с триггером Шмитта на входе заменить не хотите? Еще напрашивается добавить конденсатор 1нф параллельно R21 в датчике. Фильтр на дата выводе лучше переделать, поставив на выходе микросхемы просто резистор 1к наверху линии и такой же внизу. После него, параллельно входу контроллера конденсатор на - питания и диоды-стекляшки (кд521, 1N4148) на +/- питания. Внизу линию можно притянуть к - питания резистором 10к. Где-то так.
toweroff
Как-то стремно передавать ИМПУЛЬСЫ, тем более счетные, по длинной линии... имхо
314
Говорят, что когда передавали первую фотографию обратной стороны Луны, то время передачи одного пикселя было 2 часа, а тут всего каких-то 50м расстояние. Все зависит от соотношения сигнал/шум и скорости передачи, как ширины полосы этого сигнала.
RW6MKA
Цитата(314 @ Dec 3 2011, 14:27) *
В датчике ЛА7 на ТЛ2 (4093, 40106) в смысле с триггером Шмитта на входе заменить не хотите? Еще напрашивается добавить конденсатор 1нф параллельно R21 в датчике. Фильтр на дата выводе лучше переделать, поставив на выходе микросхемы просто резистор 1к наверху линии и такой же внизу. После него, параллельно входу контроллера конденсатор на - питания и диоды-стекляшки (кд521, 1N4148) на +/- питания. Внизу линию можно притянуть к - питания резистором 10к. Где-то так.

Не, лезть по такой погоде к датчику чтот не климатит))) Внизу фильтр с применением дросселя и кондёров нужен для отсечки ВЧ токов которые при работе на передачу наводятся на проводе, а вот притянуть к - 10к сопротивлением я пробовал - результат тот же. Диоды я не понял для чего ставить. Да, как бы не пришлось возвращаться к токовому интерфейсу и измерению времени заряда конденсатора(((Вот только соединять оси переменника и редуктора очень уж проблемная вещь. Но с другой стороны sigmaN прав, такой интерфейс удобнее и можно данные в EEPROM не заносить поскольку всегда понятна позиция датчика.Нажмите для просмотра прикрепленного файла
Вот ещё код Нажмите для просмотра прикрепленного файла может кто глянет, что я не так в USE_UART_DEBUG с UART делаю? smile3046.gif
314
просто lc-фильтр может звенеть на фронтах импульса, поэтому лучше применить rc-цепочку или добавить демпферный резистор последовательно с индуктивностью. Да и ЛА7 с такой нагрузкой на выходе может подвозбуждаться. А диоды нужны для защиты входа котроллера от импульсных напряжений (типа разряды всякие), просто сливают лишнюю энергию в питание.
sigmaN
Цитата
может кто глянет, что я не так в USE_UART_DEBUG с UART делаю?
Ну я не компилил(не на чем щас), но а что не так то?
Вы про вот это нагромождение?
Код
#ifdef USE_UART_DEBUG
                #ifdef UART_DEBUG_IMPULS
                    {
                        char digits[10];                        
                        itoa(Impuls, &digits[0], 10);
                        uart_puts_P("Impuls: ");
                        uart_puts(&digits[0]);
                        #ifdef UART_DEBUG_PRERYV
                            uart_puts_P(" | ");
                        #else
                            uart_puts_P("\r\n");
                        #endif
                        
                        #ifdef UART_DEBUG_PRERYV
                            itoa(Preryv, &digits[0], 10);
                            uart_puts_P("Preryv: ");
                            uart_puts(&digits[0]);
                            uart_puts_P("shtuk\r\n");
                        #endif
                    }
                #endif
            #endif
Вы поясните что вы хотите получить и что получаете в итоге? А то так не очень понятно что именно у вас не получается.
Оно мне тоже не очень нравится ) начать можно с того, что можно убрать проверку ifdef USE_UART_DEBUG и сразу написать ifdef UART_DEBUG_IMPULS, потому что ранее дефайны стоят так, что UART_DEBUG_IMPULS без USE_UART_DEBUG задефайнен быть не может. Ну и дальше подумайте там что куда можно перегруппировать чтобы было и понятнее и проще...
RW6MKA
Цитата(sigmaN @ Dec 4 2011, 03:45) *
Ну я не компилил(не на чем щас), но а что не так то?

Всё, разобрался. По запарке забыл нужные инклуды и тупо пытался скомпилить ну а компилятор понятно безбожно ругался)))

Цитата(314 @ Dec 3 2011, 22:12)
просто lc-фильтр может звенеть на фронтах импульса, поэтому лучше применить rc-цепочку или добавить демпферный резистор последовательно с индуктивностью. Да и ЛА7 с такой нагрузкой на выходе может подвозбуждаться. А диоды нужны для защиты входа котроллера от импульсных напряжений (типа разряды всякие), просто сливают лишнюю энергию в питание.

Вообщем примерно так должно получиться?Нажмите для просмотра прикрепленного файла
Ну в принципе эффекта никакого. Индикация скачет попрежнему. Сейчас подключу USART и гляну на мониторе что там с прерываниями и счётом импульсов.
RW6MKA
Вот результаты мониторинга(((Нажмите для просмотра прикрепленного файла (это в сокращенном виде конечно) Не пойму почему прерывание считает по два ну и соответственно количество импульсов идёт через один. А не может такого быть, что пока идёт обработка прерывания "в очередь" устанавливается ещё одно? Прерывание наступило, флаг сбрасывается, но он случайно не устанавливается сразу на место(до начала обработки прерывания)?
sigmaN
По-моему если проц уже заскочил в обработчик, то пока он оттуда не вылезет - все другие прерывания(с таким-же номером) будут просто тихонько проигнорированы. Как-бы именно поэтому обработчик прерывания всегда стараются сделать как можно быстрее.
MaslovVG
Внимательно проработайте подключение сигнала DATA. Если "горячий" проводник по вашей схеме до процессора просматривается более или менее нормально.То связь корпуса 561ЛА7 с корпусом процессора как то виртуальна или отсутствует. Оптрон здесь просится. так как земли развязаны.
RW6MKA
Цитата(sigmaN @ Dec 5 2011, 12:47) *
По-моему если проц уже заскочил в обработчик, то пока он оттуда не вылезет - все другие прерывания(с таким-же номером) будут просто тихонько проигнорированы. Как-бы именно поэтому обработчик прерывания всегда стараются сделать как можно быстрее.

Тогда откуда счёт через одну позицию я вообще не пойму. Скорость вращения достаточно мала. Задержки в обработчике я ставил от 100мс до 900мс и разницы как бы не заметил. Что делать? smile3046.gif
Палыч
Цитата(sigmaN @ Dec 5 2011, 12:47) *
По-моему если проц уже заскочил в обработчик, то пока он оттуда не вылезет - все другие прерывания(с таким-же номером) будут просто тихонько проигнорированы.
Не-а... Одно, всё-таки проскочит...
По условию прерывания будет взведён флаг прерывания, и, после выхода из процедуры обработки этого прерывания, будет сгенерировано ещё одно... Поэтому, перед выходом из процедуры обработки прерывания, наверное, нужно сбросить флаг прерывания (сбрасывается записью во флаг единицы ! ).
RW6MKA
Цитата(Палыч @ Dec 5 2011, 16:29) *
Не-а... Одно, всё-таки проскочит...
По условию прерывания будет взведён флаг прерывания, и, после выхода из процедуры обработки этого прерывания, будет сгенерировано ещё одно... Поэтому, перед выходом из процедуры обработки прерывания, наверное, нужно сбросить флаг прерывания (сбрасывается записью во флаг единицы ! ).

• Bit 5 – PCIF: Pin Change Interrupt Flag
When a logic change on any PCINT7..0 pin triggers an interrupt request, PCIF becomes
set (one). If the I-bit in SREG and the PCIE bit in GIMSK are set (one), the MCU will
jump to the corresponding Interrupt Vector. The flag is cleared when the interrupt routine
is executed.
Alternatively, the flag can be cleared by writing a logical one to it.
Насколько я понял флаг будет сброшен после выполнения обработчика прерывания, а в обработчике стоит задержка которой достаточно чтобы избежать любого дребезга.Откуда же второе подряд прерывание ведь если всё это время флаг установлен то инициализация другого прервания запрещена?Или я что то не так понял?
Палыч
Цитата(RW6MKA @ Dec 5 2011, 17:15) *
Или я что то не так понял?

Как только программа попала на JMP в таблице векторов - так сразу и "interrupt routine is executed".
RW6MKA
Цитата(Палыч @ Dec 5 2011, 19:01) *
Как только программа попала на JMP в таблице векторов - так сразу и "interrupt routine is executed".

Ага, значит если импульс был не один то пока идёт обработка первого прерывания уже установлен флаг второго?
Палыч
Цитата(RW6MKA @ Dec 5 2011, 19:11) *
пока идёт обработка первого прерывания уже установлен флаг второго?

Да. Об этом выше я и говорил.
RW6MKA
Цитата(Палыч @ Dec 5 2011, 19:22) *
Да. Об этом выше я и говорил.

Да, это именно то, что портило мне спокойный сон))) После принудительной очистки флага перед выходом из обработчика всё стало почти отлично, а когда флаг стал очищать и перед циклом поворота(видимо в момент включения реле и соответственно подачи питания на валкодер проходил какойто импульс который "взводил" флаг) жизнь вошла в своё русло)))
MaslovVG
Всетаки обратите внимание на мой пост 283.
Земляной провод сигнала DATA в зависимости от напрвления вращения двигателя проходит через разные диоды моста BR2 разные контакты реле К2, а в состоянии стоп двигателя, вообще висит в воздухе. Причем по этой же цепи течет ток двигателя. Наличие ложных сигналов на DATA просто неизбежно.
sigmaN
Цитата(Палыч @ Dec 5 2011, 16:29) *
Не-а... Одно, всё-таки проскочит...
По условию прерывания будет взведён флаг прерывания, и, после выхода из процедуры обработки этого прерывания, будет сгенерировано ещё одно... Поэтому, перед выходом из процедуры обработки прерывания, наверное, нужно сбросить флаг прерывания (сбрасывается записью во флаг единицы ! ).
Да. Вы правы. Недодумал немного насчёт флага.
RW6MKA
Цитата(MaslovVG @ Dec 5 2011, 21:25) *
Всетаки обратите внимание на мой пост 283.
Земляной провод сигнала DATA в зависимости от напрвления вращения двигателя проходит через разные диоды моста BR2 разные контакты реле К2, а в состоянии стоп двигателя, вообще висит в воздухе. Причем по этой же цепи течет ток двигателя. Наличие ложных сигналов на DATA просто неизбежно.

Но не добавлять же ещё один провод. Тогда проще валкодер вообще подключить отдельными проводами. Вопрос и стоял в том, что бы программно избежать всех этих ложных импульсов.
MaslovVG
Цитата(RW6MKA @ Dec 7 2011, 10:45) *
Но не добавлять же ещё один провод. Тогда проще валкодер вообще подключить отдельными проводами. Вопрос и стоял в том, что бы программно избежать всех этих ложных импульсов.

Любое переключение реле неизбежно будет приводить к появлению лишней пачки импульсов. Введение защитных пауз (запрет счета) к пропаданию импульсов. Причем если двигатель колекторный, то будут возникать помехи от искрения на колеторе. Прокладывайте 4-х жильный кабель.
toweroff
Но подождите... вернусь к тому же интерфейсу DiSEqC
там и питание, и передача данных. По коаксиалу. Ничего не глючит. Возможно потому, что импульсы передаются пачками тоновых посылок 22КГц с определенной длительностью?
sigmaN
Я считаю, что с учетом полученного опыта нужно пересматривать весь проект. Начиная от требований.
RW6MKA
Доброго всем времени. Схожий код и не пойму в чём проблема.
CODE

if (!(PIND&1 << Button_Run)) {
_delay_ms(100);//защита от дребезга
TCNT1=0;//обнуляем регистр TCNT1
TCCR1B = 0x05; //clk 1024, запуск таймера
while (Run_Time < (Selekt_Time*60)) {

Run();
}
OffBit(PORTD,Run_R);//выключаем
OffBit(PORTD,Run_L);//двигатель
TCCR1B = 0x00;//останавливаем счётчик
Selekt_Time = 0;
Run_Time = 0;
}
........................
void Run (void) {
Time_Sec = 0;
OnBit(PORTD,Run_R);//включаем вращение вправо
while (Time_Sec < 6); //задержка на 6сек

OffBit(PORTD,Run_R);//выключаем вращение
Time_Sec = 0;
while (Time_Sec < 2);

OnBit(PORTD,Run_L);//вкл вращение влево
Time_Sec = 0;
while (Time_Sec <6);

OffBit(PORTD,Run_L);//выкл вращение
Time_Sec = 0;
while (Time_Sec < 2);


}
..........................................
ISR(TIMER1_COMPA_vect) { //прерывание по совпадению таймера-счётчика1 канал А
TCNT1 = 0; //сбросить счётчик таймера1
Run_Time ++;
Time_Sec ++;
}

выполнение доходит до первого прерывания и прерывания следуют подряд не возвращаясь к коду, при этом переменные исправно увеличиваются, но выполнение условий не проверяется. До этого вместо циклов для задержки использовал кучу _delay_ms(1000) и всё работало.
RW6MKA
Ну что, никто не подскажет в чём проблема?
sigmaN
Переменные Run_Time и Time_Sec точно volatile?
Переменные длиной больше одного байта? Тогда как минимум не беспечивается атомарность их изменений(при обнулении может произойти прерывание).
Таймер действительно тикает раз в секунду?

А вообще мне не нравится ваш дизайн. Я бы не трогал таймерную переменную за пределами прерывания. Если хочется засечь время - нужно засечь значение Time_Sec в какой-нибудь локальной переменной(start_time например). Тогда пройденное время будет = Time_Sec - start_time.
Проблема переполнения Time_Sec не проблема при использовании беззнакового типа.
RW6MKA
Цитата
Переменные Run_Time и Time_Sec точно volatile?

Ну ёлы-палы, опять на эти же грабли))))))) Всё работает, спасибо.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.