controller_m30

Считаю, вполне рабочий вариант

Полностью поддерживаю! TL431 привёл только для примера. Раньше AD586 упоминался, как я понял, в качестве стабилизатора напряжения для питания фотодиода. А моё предложение - использовать ИОН только как эталонное напряжение для сравнения. Может быть, действительно, можно всё нагрузить на один AD586: и питание фотодиода, и ножку сравнения компаратора. Я смутно представляю себе этот узел, т.к. не знаю, от чего вся схема питается, что за фотодиод используется, какой компаратор, и т.д. Поэтому предлагаю дополнительно ко всему, что ранее обсуждалось - использовать отдельный ИОН, хоть TL431, хоть ещё один AD586.

Полагаю, АЦП проигрывает компаратору. У АЦП есть время преобразования результата, которое может быть достаточно большим, чтобы шторка успела проехать расстояние бОльшее, чем ей положено. Например: полностью открытому датчику (шторка далеко) соответствует напряжение 5В. Искомому положению шторки (половина датчика освещена, а половина в тени) соответствует напряжение 2.575В. АЦП один раз может засинхронизироваться с движением шторки, и намерить такую последовательность: 5.0, 4.75, 4.5, 4.25, 4.0, 3.75. 3.5, 3.25. 3.0, 2.75, 2.5 А в другой раз, синхронизация семплов может сместиться, и выдать: 5.0, 4.85, 4.6, 4.35, 4.1, 3.85, 3.6, 3.35, 3.1, 2.85, 2.6, 2.35 В первом случае микроконтроллер выключит двигатель после 11-го семпла, а во втором случае - после 12-го. И получится что событие будет происходить с задержкой плюс\минус один семпл АЦП. Это первая неточность. Кроме того, АЦП без ошибок младших бит я не встречал. А это уже вторая неточность. Ошибка в 1 LSB даст неточность +\- 300мкВ, ошибка 2 LSB = +\- 600мкВ. В итоге получим ошибки точности измерения, и ошибки времени реакции. А компаратор, по крайней мере, будет выдавать сигнал всегда в одно и то же время, относительно достижения шторкой нужного положения. Прикрутить к нему только хороший ИОН (напр.TL431), и думаю, будет работать.

Такой ещё момент. Если шторка тонкая, и болтается между стенками щелевого датчика (то к одной стенке ближе, то к другой) - тогда освещённость фотоприёмника будет разная. А значит и повторяемость может снижаться. На картинках модель щелевого датчика, но с излучателем света в видимом диапазоне. Можно видеть, как отличается тень при разном расстоянии шторки от фотоприёмника.

Мне кажется, что нет. Точно можно включать таким способом LP2951 (стр.26, и первая картинка внизу поста) - т.к. у него есть вход "Feedback", аналогичный входу "Adjustable" у LM317. А у LP2980 вход FB находится внутри, и уже занят резисторным делителем. Есть ещё вариант токового стабилизатора на двух транзисторах (вторая картинка). Применяется в интерфейсе "токовая петля".

А 30 мА не сильно много для светодиода? Или это его паспортная характеристика? Например на сайтах где торгуют деталями для Ардуино, в описании какого-то оптопрерывателя указан ток 13мА. Попробуйте ещё ток 20, 15, 10, 5 мА (предел для LM317, меньше не тянет).

Да, нужен. Яркость свечения светодиода определяется протекающим через него током. Если "поплывёт" сопротивление светодиода из-за температуры, то изменится и протекающий ток, а соответственно и яркость свечения. И прецизионный источник напряжения здесь не поможет. Увы. Если я правильно понимаю, требуется отслеживать такое положение шторки, когда она только частично отсекает свет от излучателя, а часть пропускает на фотодиод свободно (на картинке внизу). А если так, то требование к стабильности излучения такое же высокое, как и к точности измерения. Значит стабилизировать нужно не только фотоприёмник, но и излучатель.

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

Ещё вариант такой. По тексту программы, на светодиод выводится значение старшего бита 1-го канала АЦП. А из пояснений в первом посте следует, что переменный резистор подключен к каналу 0 АЦП, а канал 1, видимо, "висит" в воздухе. И возможно на этом 1-м канале, в неподключенном состоянии, напряжение больше пол-питания, и потому старший бит (и светодиод) всегда равны 1.

В тексте программы не видно команды инициализации порта A на вывод (а светодиод подключен к PA7, как я понял). Т.е. PA7 работал как вход. Поэтому, точно сказать отчего горел светодиод, трудно. Может от Pull-Up резистора входной линии. Или, из-за отсутствия питания на AVCC, что-то "глючило" на портах ввода-вывода. А если светодиод подключен анодом к VCC а катодом к порту, то при переводе порта на ввод, светодиод тоже может светиться в пол-яркости.

Два предложения. 1. Проверьте питание на ноге AVCC - равно ли питанию VCC контроллера? Попробуйте добавить конденсатор на эту ногу 0.1uF, и индуктивность 10uH (как в даташите на стр.106). 2. Если предыдущее не поможет. И если нет возможности быстро подключить дисплей, чтобы посмотреть регистры ADC и PWM. Добавьте на выход PWM схемку как на картинке (я пользуюсь номиналами из нижней схемы, но и номиналы верхней схемы тоже рабочие). Это для того, чтобы значения PWM смотреть в виде напряжения мультиметром напрямую. При VCC=5 вольт, и PWM=255 - на выходе цепочки будет 5 вольт. При PWM=128 - на выходе будет 2.5 вольт (пол питания), а при PWM=0 - на выходе 0 вольт. Т.е. получится такой себе DAC. Дальше попробуем измерить значение внутреннего источника 1.18v, и вывести на выход PWM - посмотрим сколько покажет. Потом тоже самое, но с опорным напряжением ADC=2.56v. Сколько покажет?

Попробуйте значения, считанные из АЦП, сначала поделить на 2 (команда LSR Rx), а потом загружать в PWM. Что получится?

Уточните, какие напряжения: 1. Питания контроллера 2. Переменного резистора, которым регулируете PWM 3. При каком напряжении на выходе резистора PWM сбрасывается в 0? Интересно узнать именно напряжение, а не просто какая часть шкалы.

Нужно подать на (VS-) отрицательное напряжение. Или, раз сделали "виртуальную землю" на делителе - подключать резистор R3 к этой "виртуальной земле", а не к настоящей.

Не знаю что и посоветовать. Я программирую на ассемблере, а к этому прилагаются и всякие познания о состоянии "железа" в разных ситуациях. Это обычная рутина программирования на низкоуровневом языке :laughing: А так чтоб статьи о работе железа, но для программистов на Си... чесслово, не знаю о таком. Может кто-то из программирующих на Си, предложит что-то интересное? PS. Может статьи о причинах зависания цифровых устройств, и средствах борьбы с этим (Brown-out Detector, Watch Dog timer) чем то помогут? Зависание ПК (вики), Зависание МК.

В Arduino нет никакого "загрузчика". А есть программа прошивки контроллера по UART, записанная в защищённую область памяти. Эту, защищаемую от перезаписи область памяти, фирма Atmel и назвала "Boot Loader". А содержимое этой области может быть любым. Например разработчик Arduino придумал хранить там программу-прошивальщик :laughing: Считать это "загрузчиком" можно лишь в контексте развлекательно-обучающей игрушки под названием Arduino. А при серьёзном применении контроллера, этот код лучше считать "бомбой, заложенной под основание" вашей программы. "Загрузчиком" очень удобно пользоваться на этапе отладки, но перед вводом в эксплуатацию готового изделия, этот код лучше стереть. Способов, как может программный счётчик "перепрыгнуть" на любой случайный участок кода множество. Например такая ситуация: при помехе по питанию, в ОЗУ контроллера, всего один бит переключился с 0 на 1 (или наоборот). А в этой ячейке как раз хранился адрес возврата из подпрограммы. По команде RET, с вершины стека снимется такое "повреждённое" значение и загрузится в программный счётчик, после чего выполнение программы "улетит в неизведанную даль". "Загрузчик" содержит реализацию алгоритма Self Programing, с соответствующими командами в коде. Случайное выполнение таких команд может приводить к повреждению программной памяти. Поэтому в конечной реализации вашей программы, всё, что могло бы повредить программный код, лучше удалить. Да. Заливать прошивку через ISP. Если у вас нет ISP-программатора, то его легко можно сделать из ещё одной Arduino, залив соответствующий скетч.

Моя версия. В контроллерах применяемых в Arduino присутствует программа-прошивальщик, зашитая на заводе (чтоб удобно было программировать через UART или USB). При помехах по питанию, программный счётчик может "перепрыгнуть" в том числе и на код прошивальщика, и рандомно что-то стереть/записать в памяти программ. Предложение - затереть код прошивальщика, и поменять "ардуиновские" значения бит BootRST и BootSize на стандартные.

Да, попробуйте убрать прерывание для TX канала DMA совсем. Флаг TX USART в режиме DMA обычно сбрасывается автоматически, поэтому дублировать его сброс программно не нужно. Зато есть такой нюанс: В большинстве известных мне контроллеров, прерывание USART TX происходит в начале передачи байта (буфер TX переписали в регистр сдвига - и тут же прерывание TX), а прерывание USART RX происходит в конце приёма байта (из регистра сдвига переписали в буфер RX - и только тогда прерывание RX). Если USART отключить по прерыванию TX, то прерывание на приём последнего байта пакета может не наступить. И канал DMA RX, соответственно, запрос на последний байт не получит.

В чём может быть дело не знаю. Тем более не известно какой контроллер :laughing: Мои варианты: 1. Попробуйте поменять местами каналы DMA: тот что был для RX сделать для TX, и наоборот. Если каналов DMA больше 2-х, попробуйте и остальные. (что-то, где-то читал, про приоритет каналов DMA на доступ к внутренней шине данных). 2. Уменьшите скорость SPI - например в 2 раза. Может пары дополнительных тактов хватит для "разруливания" ситуации? Также увеличьте скорость SPI ещё больше (если настройки позволяют) - не будет ли ошибка проявляться ещё чаще? 3. Попробуйте для режима чтения оставить прерывание только по RX, а для записи только по TX. Всё равно сразу два прерывания в каждом из режимов лишние, но вдруг это тоже что-то выявит.

Выходить из LPMx можно только по прерыванию. Значит используем какое-либо из незадействованных на данный момент (список векторов прерываний и их источников в даташите на конкретный контроллер). Прерывание должно перед своим завершением извлечь из стека сохранённый там регистр статуса SR, изменить флаг CPUOFF, и "положить" модифицированный SR на место. При завершении прерывания, по команде RETI, из стека считается изменённое состояние SR, и в основном цикле будет либо Active Mode, либо LPMx. Например: 1. Если WDT не занят, то использовать его прерывание в режиме таймера. Можно настроить 4 скорости срабатывания. 2. Прерывание таймера A или B - добавить в конце уже имеющегося обработчика такие действия: Перед выходом из прерывания, программа проверяет какой-то бит (или байт) в ОЗУ, и в зависимости от его значения модифицирует сохранённый в стеке регистр статуса SR. Если к примеру в ОЗУ был 0, это значит что основной цикл должен "бодрствовать", и программа прерывания сбросит CPUOFF в 0. Если в ОЗУ было <> 0, значит CPUOFF нужно установить в 1. И тогда после завершения прерывания, основной цикл будет "спать". А в основном цикле нужно только менять ячейку ОЗУ, чтоб сообщать обработчику прерывания о своей "занятости работой", или наоборот - об отсутствии дел.

Наверное нужно указать адрес компиляции (ассемблирования) файла IAR - в конце адресного пространства файла стека. Как по приведенной мной по ссылке советовали. Тогда, вероятно, файлы стека и прошивки не будут мешать друг другу.

Возможно в этом топике есть что-то полезное Easyelectronics. Мои предложения: 1. Проверить программатор-отладчик на другом устройстве, которое не прошито. 2. Стереть-прошить чип тем файлом, который был залит в него на заводе (найти файл в интернете, или считать с другого устройства). 3. Проверить доступ к чипу из другой программы: заводская утилита для прошивки/стирания (если такая существует), другая среда разработки. 4. Проверить настройки IAR (режим Debug/Release, модель чипа, галка "Run to -- main" в настройках Debugger, и прочее). 5. Попробовать отладку в симуляторе IAR (в симуляторе хотя бы IAR программу отлаживает?). 6. Попробовать сбросить настройки IAR. 7. Переустановить IAR. Установить IAR другой версии (младше/старше).

Наверное можно через внешние выводы: у обоих таймеров есть внешние входы тактового сигнала, и есть выходы модулей сравнения-захвата. С модуля сравнения одного таймера, вывести частоту для тактирования другого таймера. И при остановке одного - остановится и другой. Можно и ещё один модуль сравнения вывести наружу, и уже по его сигналу - разрывать связь двух вышеупомянутых выводов контроллера (но придётся, наверное, транзистор ставить, для коммутации, или лог.элемент). Только не совсем понятно, что значит "останавливать"? В зависимости от чего он должен останавливаться или запускаться? Но! Если надо останавливать именно внутренними механизмами, то только программно - через прерывание. Другого способа я не знаю :laughing:

Я скачивал несколько скетчей под эту плату, и результат был разный. Один скетч почему то не видел плату, другой не видел карт, третий некоторые карты читал с ошибками, и т.д. Поэтому нужно будет попробовать несколько вариантов с разных сайтов. PS. Пробовал и сам разобраться с инициализацией этой платы. Но настройки каких-то: модуляторов, режимов их работы, и т.д. оказались задачей для меня сложной. Тогда я стал искать готовый дамп настроек (не нашёл), а потом прибег к "читерству" - купил Ардуину :biggrin: и снял протокол оттуда. PPS. В режиме UART протокол обмена у этого чипа ещё проще и нагляднее. Кстати! Каким устройством вы формируете SPI команды? Насколько помню, требуется удерживать SS=0 на всё время передачи команд и данных. А то у некоторых контроллеров сигнал SS деактивируется после каждого байта, и из-за этого вполне могут быть неверные данные при обмене. А ещё попробуйте считать значения других регистров после сброса. В даташите у некоторых из них есть значения отличные от 00. И по результатам такого считывания можно будет более определённо судить, что и почему происходит.

Если есть Arduino, или хотя бы AVR тех-же моделей что для Arduino применяются - подключите плату к таком контроллеру, прошейте готовым "скетчем", и таким образом должно провериться. Можно будет осциллографом "подсмотреть" правильный обмен данными на шине. Я наловчился проверять подобные платы именно так. Специально купил простенькую Arduino, заливаю в неё "скетчи" которых полно на сайтах, и проверяю на работоспособность. Заодно снимаю готовые дампы инициализации устройств, при необходимости. Только у меня не осциллограф, а логический анализатор Saleae Logic.