Ну всё. Вот эта - точно последняя.

Да, индикация исправилась, идёт плавно. Напрягает только одно. Если пределы тиков выставлены не точно, то индикация не задействует все 48 светодиодов. Да, ещё проскакивают иногда крупные отрицательные значения тиков и это приводит к срабатыванию концевиков. Тут меня мысль посетила. Есть свободный пин, на него посадить кнопку setup при нажатии которой в течении 3-5с кнопки управления переходят в режим записи конечного правого и левого положения соответственно.(т.е. нажимаем кнопку вращения вправо доводим датчик до нужного момента и кратковременно нажимаем setup, вкл поворот влево и вращаем датчик до крайнего левого положения и опять setup) Данные записывать в eeprom и при запуске кода они извлекаются и заносятся на свои места в коде. Ну как идея?
Да, забыл файлик.Нажмите для просмотра прикрепленного файла

Минусы? Опять минусы? Не было же уже их в WALKING_LED_TEST! Откуда они там берутся то. Я в шоке )))
Эхх, железо бы сюда! Как же неудобно отлаживать вот так удалённо ))


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

А к чему вся эта возня с пином setup и eeprom, если изделие не серийное - я не понимаю. Прогнал программу с выводом на UART, записал значения на бумажку, вписал в файл, скомпилил и дело в шляпе, как говорится ))

А если вот так прямо сейчас WALKING_LED_TEST сделать - минусов есть?
Блин, вот тут у меня уже и идеи даже кончились насчёт этих минусов то.. . и в протеусе я их уже не наблюдаю..... да и так им там взяться не откуда вроде.....
Щас ещё подумаю... что-то ведь упустил значит, раз они таки есть... но было бы не так странно, если бы они и на WALKING_LED_TEST были...

added:
вот сейчас файлик увидел. всё не так уж плохо на самом деле )))) уже почти рабочий девайс.
но где-то глюк сидит - это факт...

added2:отлично! поймал минус в протеусе. разберемся.

Отказался я от извращенного метода программного увеличения разрешения 8ми битного таймера и переделал всё по уму )
В общем, сейчас доступно время с ~миллисекундной точностью(на таймере 0) для всяких таймаутов и прочих нужд, а 16ти битный таймер 1 полностью задействован под сенсор и работает вроде очень даже хорошо и стабильно... но опять таки, это в протеусе )) а как будет в реале - не понятно.

Ещё добавил таймаут на вращение в одну сторону. Это поможет в случае сбоя сенсора или иных проблем, препятствующих определению позиции антенны...
В hwconf.h есть ROTATION_TIMEOUT, я поставил туда 3 секунды... подгоните под реальное значение.
Всё-таки не хочется, чтобы кабель намотало на мачту


Уже даже не буду говорить, что это последний вариант кода )

А зря, это видимо он и есть)) Погонял минут 10 - ни одного сбоя. Вот файлик Нажмите для просмотра прикрепленного файла
А возможна ли реализация 3-4минут?(именно за это время делается 1 оборот)
Так, а вообще зачем тогда вся эта возня с усовершенствованием кода?)) Мой то вариант рабочий и "полегче" будет(всего 64% памяти)? Да потому что так правильнее, лучше и удобнее. Без этого конструкция какая то незавершенная получается.
Пройдёт год-другой и датчик полюбому менять придётся(на высоте 15м)) ) но через это время проблемы насущные практически напрочь сотрут инфо в башке о всей этой возне с терминалами, и придётся мучительно морщить лоб, лихорадочно вспоминая чё да как))

И ещё вопросик. Из кода я понял как реализовать вывод инфо через UART, а вот как вводить данные через него? Где бы почитать об этом?

Да легко! Сейчас переменную 32бита сделаю и будет 2^32 = 4294967296ms == 49.7 суток ))))

Я сам давно никаких поделок не делал...соскучился немного за контроллерами и вам хотел показать чем программа на Си отличается от быдлокода на нём-же. А то вот так люди то быдлокодят и не знают даже к чему и стремиться то )) Места там ещё навалом.
Мало того, что сам драйвер UART места отхавал, так ещё и все эти букавки место занимают...
А вообще, я думаю, там даже и вместе с UARTом полезет работа с EEPROM...
Плюс ещё надо с опциями сборки проекта поиграться... ещё процентиков выгадать можно по любому...

В файле uart.c или uart.h да, скорее в .h будет больше каментов я не шучу.

Добавил таймаут 3:30, но можно и 49 суток туда загнать - не вопрос )
Вот ещё раз хочу обратить Ваше внимание на то, как легко вносятся изменения в более-менее правильную программу.
Всегда стремитесь к этому. Если понимаете, что внести изменения в код будет сложно - сразу переделывайте )

Тут вот ещё вопросики возникли Почему при включении USE_UART_DEBUG так резко увеличивается занимаемое место в памяти?или файл uart.h полностью принимает участие в компиляции? Что то я этот момент с инклудами до конца не понимаю. это откуда? и как работает?

Ну вообще-то не uart.h, а uart.c содержит исполняемый код, который занимает место )
Кроме того, как я уже говорил, занимают место строки. Строки sensor position: UART OK, STOP LEFT и т.д. каждая буква - один байт.
Вот и считайте... Плюс, конечно же сам драйвер, как я и говорил... Но если строки выкинуть - экономия будет неплохая.
Немного переписать надо, чтобы UART_DEBUG включал именно отладку, а допустим USE_UART просто включал драйвер уарта.. тогда можно будет легко понять кто сколько занимает. Но ещё такой момент: нужно вызвать нужные функции хоть один раз. Иначе компилятор поймет, что мы инклудим файл, а функции не используем и он выбросит весь неиспользуемый код при оптимизации.

Это атрибуты gcc. смысл в том, что мы таким образом сообщаем компилятору, что из функции выходить никто не собирается. и ещё OS_task там тоже какую-то инициализацию в начале функции убирает(опять таки из расчёта, что из функции выходить никто не будет и входить в неё тоже будут только один раз)...
Можно нагуглить очень легко всё это. И проверить можно - действительно экономит 16 байт )

Т.е. при передачи чисел в компьютер потратится 4-5 байтов?ну конечно в зависимости от нужных чисел.
Да, вот ещё может подскажите, в какой среде лучше создать окно интерфейса под винду? А то я только в дельфи немного практиковался, а там паскаль((

Ну если знакомы с Delphi - проще всего будет C++ Builder версию 6 наверное лучше всего найти... не надо этих 2005 и прочих наворотов...

Не понял вопроса. Если я вывожу строку UART is OK\r\n я занимаю во флешке 12байт для хранения этой самой строки. А вообще даже не 12, а 13 ибо ещё ноль в конце строки сохраняется.
Что значит передача чисел в компьютер мне пока не понятно.... Если число в оперативной памяти(переменная) и мы хотим передать её по UART - то для начала значение переменной(скажем 175) из одного байта(допустим переменная была байтовая) превращается в строку. Для этого используется буфер в оперативной памяти и он должен быть не менее 4 байт, чтобы вместить символы 1 7 и 5 + нуль в конце строки. Таким образом это работает.
Если же я просто хочу вывести UART is OK, то глупо для этого использовать оперативку, мы ложим эти строки во флеш.

А обязательно нужно число превращать в строку? мне ж не нужно делать вывод его на монитор. нельзя его так байтом и передать, а в программе(в копьютерной части) этот байт присвоить переменной и использовать уже в коде софта?

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

Возникла пара вопросов. Если я правильно понял, в инклудах файл с расширением .c содержит описание функций и компилируется(тоже вопрос весь файл компилируется или только нужный фрагмент?), а файл с расширением .h содержит указания по использованию этих функций? А если не использовать инклуд для UART, а необходимые настройки сделать в коде, места используется меньше?

Вы, как всегда, так задаёте вопрос, что реально непонятно что тут вообще имеется ввиду? Не использовать предложенный драйвер UART, а самостоятельно реализовать его(напрямую писать в регистры и т.д...)? Это вы имеете ввиду?

Компилируются все файлы. .h тоже может содержать исполняемый код. Однако так принято, что в .h файле размещают прототипы функций, константы, описание типов данных, с которыми работают функции(опять таки в прототипах эти типы и используются).
И вот тут вы бы почитали вообще что такое прототип функции и зачем он нужен?
В общем ВСЁ это дело компилируется, а то, что не использовано - умный компилятор выбрасывает(но это не есть обязательно). Что-то, для чего уже достаточно данных на этапе компиляции - он считает "в уме", а в код подставляет уже результат.

Вам там действительно не хватает места для чего-то?

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

Начальную установку - это загнать константы в EEPROM?

Да-да, используя кнопку setup и кнопки управления вращением двигателя.

а вот это

контроллер тоже в рантайме считать будет? )))))

тут придётся выкручиваться... переходить на фиксированную точку....
всё это возможно и я даже очень советую вам взяться и таки разобраться и научиться программировать! но придётся попотеть )


а ещё вопрос: зачем в этом девайсе UART вместе с EEPROM. отладили же и про UART можно забыть? нет?
вообще способы оптимизации размера программы существуют. от реорганизации кода, до игр с опциями компилятора
http://www.avrfreaks.net/index.php?name=PN...20f2b40a6fa93da
http://www.avrfreaks.net/index.php?name=PN...pic&t=75909

и на этом форуме как-то обсуждались подобные темы помню..

не удержался... таки поигрался с настройками компилятора... код не трогал вообще.

исходный вариант( Makefile(standard) ):
полная UART отладка: 93.2% Full
без UART: 70%

с небольшой добавкой опций компилятору( Makefile(+opts_but_not_combine) )
полная UART отладка: 88.6% Full
без UART: 59.7%

радикальный подход к опциям компилятора(ручное редактирование мэйкфайла Makefile(combine) )
в этом режиме не работает меню Build -> Compile. Но он и не нужен. есть Rebuild All ведь
полная UART отладка: 84.2% Full
без UART: 56.3%

меньше уже не будет наверно...
ну только если немного покрошить init.. поубивать неиспользуемые прерывания, ещё кое-чего там...
но это наверно байт на 30 потянет...если на 50 - то я буду очень рад.

ещё можно было бы отделаться от деления в функции static uint8_t sensor_val_to_led_number(uint16_t sensor_val)
ну т.е. заменить делитель на степень двойки, а деление - сдвигом.
но делитель у нас зависит от калибровочных констант датчика и не всегда ровняется степени двойки.. от этого там идет вызов библиотечной функции деления и тратятся лишние байтики ))
можно в прошивке жестко задать пределы, чтобы получилось 8поинтов на 1 диод, а реальную подгонку этих пределов под показания датчика провести в аналоговой части. кстати, это и избавить от геморроя с EEPROM. подкрутил резисторы min, max - и делу конец )

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

при добавлении новых файлов в проект - придётся вручную редактировать makefile. это не сложно, но я Вас должен был предупредить )
редактирование существующих в проекте файлов - без ограничений.


в симуляторе вроде работает.... но, как всегда, посмотрим как оно на практике себя покажет...

кстати, подумайте насчёт регулировки в аналоге. хорошая, простая и надежная идея ИМХО.

UART я не хочу отбрасывать, поскольку в будущем планирую завязать железо на комп. Регулировка резисторами идея неплохая, но при механическом соединении ротора переменника с валом редуктора вращения трудно соблюсти точность, поэтому всё смотреть и подстраивать придется непосредственно на месте(12-15м высоты). Кстати, как показывает практика, время для возни с антеннами хватает только зимой)))
Так что буду делать setup. Общий алгоритм я определил, а в код загоню по приезду домой.

ну так а делители все эти на плате тут внизу разместить не получится?

Не желательно их размещать внизу т.к. возрастет количество проводов идущих к поворотке.

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

Да, только питание идет на движок, а он кушает 6-7А

Ну глюки обеспечены на 20м кабеле.... кажется грамотнее будет сделать интерфейс антенна - устройство токовым.
Преобразовывать в напряжение и мерить его уже тут, на земле, возле телевизора.
А то как-то там получается у вас нагромождение делителей и мизерный ток.
Метров 20 сигнального провода, проложенного параллельно активно коммутируемому питанию 6-7А + искрящий коллектор..... )

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

ну спрашивали про возможность - про возможность и ответили: она безусловно есть ))

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

я за переменный резистор и токовый интерфейс между антенной и девайосм.

Вот наступит весна, установлю железо на свою мачту и посмотрим в реальности насколько помехи будут мешать)) Тут вот вопросик по теории возник. Можно ли использовать прерывания в обработчике прерываний?

Ага, а потом лазить туда ещё раз.
Эти недоработки надо исключать сразу. Не так то и много там изменени й внести в схемотехнику, а надежность повысится точно. Ещё и детектировать обрыв сигнального провода можно будет))

Прерывание либо возникает, либо не возникает.
Если оно возникает, то во время входа в обработчик остальные прерывания запрещаются cli();, а после выхода из обработчика - разрешаются снова sei();
те прерывания, которые возникли, пока процессор был в обработчике - начинают вызывать свои обработчики в соответствие с таблицей приоритетов и всё по тому-же принципу(запрет прерывания обработчика прерывания).
Однако, если за то время, пока процессор сидел в обработчике(какого-то другого прерывания), произошло, скажем, два прерывания от таймера(или 10) - по выходу из того обработчика, процессор не может знать сколько раз произошло прерывание таймера. он просто видит флаг запроса прерывания от таймера и послушно выполнит его обработчик. Но, к сожалению, только один раз )
Вот почему обработчик прерывания должен исполняться как можно быстрее.

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

А вот что значит это ваше я не понял.
Выражайтесь по возможности конкретнее и точнее... слишком часто вы пишете так, что понять Вас без телепатии невозможно.
Программист, я скажу Вам, просто обязан уметь чётко, логично и последовательно выражать свои мысли. Об этом говорили/писали не раз и не в одной книге.

Насколько я понимаю вы предлагаете в датчике менять не напряжение а потребляемый датчиком ток? Или...?

Да, на мачте смонтирован источник тока, а переменный резистор регулирует его параметры(собственно, ток). при этом не важно какое напряжение будет в линнии - важен ток. к примеру 5ма - крайнее левое положение; 50ма - крайнее правое. А в устройстве ток преобразуется в напряжение на резисторе и измеряем уже напряжение тем-же способом, что и сейчас. Но интерфейс уже токовый получается и помехозащищенность у него огого какая ))

Вот, например, источник тока простейший http://www.reuk.co.uk/LM317-Current-Calculator.htm

т.е. там в антенне ничего архи сложного не нужно будет монтировать...

Доброго времени sigmaN. Столкнулся с проблемой записи в eeprom. И попутно вопрос по прерываниям. Одно прерывание будет при удержании кнопки setup более 3с при этом переменной StatusSetup присвоится единица. Если кнопка снова нажмется более 3с снова прерывание переменная станет = 2(ведь она же не сбрасывалась)?Код в файле.Нажмите для просмотра прикрепленного файла
Прошу не удивляться моему возвращению к своему коду, но ковыряя ваш код я не всё понимаю. Такой резкий скачок пробил огромную брешь в моей цепочке причинно-следственных связей Нужно к такой форме кода подходить постепенно и самому иначе постоянно будет

Нет, всё, хватит ))
Не хочу разбираться с Вашим кодом.
Как приблизительно должна выглядеть программа на Си я показал и довел её до полностью работоспособного состояния.
Лучше бы разобрались как всё работает. Тем более, что добавить туда обработку зажатой кнопки Setup проще простого.

Тогда просто подскажите как работать с eeprom в студии. В коде вижн достаточно просто обьявить переменную в eeprom и потом просто работаешь через = и всё. В студии это не катит((

не а студии, а в WinAVR. студия - просто оболочка, код она не компилит.
вам помочь нагуглить пример работы с еепром?

Не подскажите, почему компилятор выдаёт предупреждение
warning: passing argument 1 of '__eewr_word_tn2313' from incompatible pointer type
на каждую строку где есть обращение к eeprom?

не знаю

Извиняюсь. Затупил. Исправил.

Не подскажите, как в данном случае избавится от дребезга?Нажмите для просмотра прикрепленного файла

гуглить пробовали?
http://masteroid.ru/content/view/726/33/
и ещё сотня подобных ссылок

и поиск по форуму. дребезг уже обсуждался тыщу раз....

Да, наверно я немного не так выразился.Используется оптический энкодер, по коду всё считает, но в железе идёт проскок в индикации на 10-15 позиций. Похоже на дребезг, но установка задержек результатов не даёт(( И может подскажите, что я упускаю при инициализации прерываний по изменению состояния выводов(не INTn)
Вроде весь даташит перелопатил, всё перепробовал, а компилятор ругается.

что конкретно говорит компилятор?

нет, ну если задержка вставлена в нужном месте - должна помогать по идее.

корденсатор не помогает?

А аппаратно прерывание на каждом из фронтов входных сигналов (обоих)?

Компилятор поглючил и успокоился, всё компилится без проблем. Но вот дребезг лечится не до конца,нет-нет и скакнет на 1-2 позиции.Может мне в обработчике сбрасывать флаг следующего прерывания если он установится? Вот обработчик прерываний
Если помните схему, там по входу два кондёра и дроссель(сопротивления я убрал), я думаю этого достаточно.


Не понял, это как, объясните новичку. Кстати энкодер с одинарной оптопарой т.к. знать направление вращения мне не надо.

И вопросик по Протеусу. Не пойму как заставить читать его eeprom?

Все вопросы снимаются. Всё выличилось заменой схемы валкодера. Он давал целую серию импульсов при медленном прохождении диска.

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

В Вашем приборе предусмотрено "штатное выключение"? И МК имеет информацию о том, что прибор "штатно" отключают? Тогда, примерно, так же как это сделано в Windows: в начале своей штатной работы МК в определённую ячейку EEPROM записывает некое значение, а перед штатным отключением - стирает. Если при подаче питания на МК в ячейке EEPROM что-то записано - прибор был отключен не штатно.

Нет, штатного выключения прибора нет, но когда питание выключается в момент простоя, то данные о последнем направлении записаны в EEPROM и при последующем включении они просто оттуда считываются. При выключении питания в момент вращения, данные о новом положении ещё не записаны в EEPROM и при последующем включении считываются данные о предыдущем, а не фактическом положении антенны. Но мы то можем забыть что "...эти козлы опять свет вырубили в самый нужный момент" ))). Вот и необходимо чтобы прибор нам напомнил об этом печальном факте.

Как же тогда Ваш прибор определит: 1) это Вы выдернули вилку из розетки, потому что прибор нужно выключить и идти отдыхать или 2) "эти козлы" вырубили электричество?

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