Jump to content

El-Shang

Members
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

3 Обычный

About El-Shang

  • Rank
    Новенький
  • Birthday 12/24/1988

Контакты

  • ICQ
    245-872-217

Информация

  • Пол
    Мужчина
  • Город
    Киев

Электроника

  • Стаж в электронике
    10-20 лет
  • Сфера радиоэлектроники
    Embedded Development

Recent Profile Visitors

234 profile views
  1. А это как посмотреть. Мой бывший коллега реализовал на его основе систему управления SRM - двигателем (это разновидность бесколлекторных электромоторов) в составе молочного сепаратора. Управляемый разгон, защита, стабилизация скорости - полный фарш. Программа заняла, если не ошибаюсь 95-98% свободного места. Правда, написана была на ассемблере, едва-ли на Сях получилось бы туда все вписать (ну, у меня не вышло ). Снимаю перед его мастерством шляпу. Тоже своего рода религия. Чуть что — так нафиг восьмитки, давайте нам 32-х разрядные армы. И неважно, что у них чудовищная производительность, которая просто не нужна в любительских проектах (да и не во всех профессиональных тоже, но там еще другие факторы оказывают влияние). Неважно что их невероятная гибкость достигается усложнением конфигурирования (сравните, что нужно сделать для того, чтобы запустить кварцевый генератор в AVR и STM32). Неважно, что для четкого понимания их внутренностей надо перелопатить десятки и сотни страниц документации. Главное, что это круто. И точка. Я Вас уверяю, если Вы поймете, как работает самый простой восьмибитный контроллер, то с легкостью перенесете и дополните эти знания на его старших собратьях. Да и современные AVR-ы ушли далеко вперед в сравнении с классикой. У них давно на борту есть и цифроаналоговые преобразователи, и процессорно-независимая переферия и конфигурируемая логика и многое другое. Что правда, так это их меньшая распространненость и доступность, но у нас, на Украине, вполне можно заказать AtTiny214/414/814, в которых все это есть. В общем, учитесь, разбирайтесь и никого не слушайте. Выучите алфавит - научитесь читать что угодно. Дорогу осилит идущий. Успехов!
  2. Отнюдь. Я всего лишь имел ввиду, что автор до конца не выяснил первопричину своей проблемы и предпочел просто обойти ее. Это в ряде случаев вполне приемлимо, в тех-же одноразовых задачах. В конце-концов если оно работает и выполняет свою функцию, то что еще надо? Лишняя полировка также вредна как и безбожная халтура обмотанная синей изолентой. Кстати, заметка автору. Если Вы пишете на языке скетчей (не знаю, как он точно называется), то старайтесь по максимуму использовать уже готовые средства и не допускать мешанины из функций и регисторовых операций. Оберните последние в выделенную функцию с вменяемым именем. Оно и выглядеть и читаться будет гораздо приятней. Оффтоп. Что касается ардуины. Все эти бесконечные метания фекалий в ее сторону по моему мнению происходят либо от недопонимания ее целевого назначения либо из профессионального шовинизма, дескать, вон я какой крутой, пишу сразу в машинных кодах, а ардуинщики в своих скетчиках путаюся. Ха-ха-ха! Балбесы! Но. Давайте не будем забывать, что этот комплекс (а понимать ее надо именно как комбинацию языка, базы ("материнской платы") и переферийных модулей (шилдов) ) изначально разрабатывался как платформа для обучения студентов программированию "железа" и взаимодействию с "реальным" миром, и лишь опосля к ней подтянулись самодельщики и аматоры всех мастей. Получился эдакий "Basic" в мире низкоуровнего программирования, изрядно здавшего свои позиции в конце восьмидесятых - начале девяностых, когда начали уходит со сцены классические 8-ми и 16-ти битные компьютеры и начавшимся повальным переходом 32-х битных на операционную систему Windows, в коей прямой доступ к переферии в отличие от того-же DOS затруднен или вообще невозможен. И это уже не говоря о постепенном исчезновение класических портов, вроде LPT, Game Port, да и того-же RS-232, посредством которых можно было напрямую щелкать реле, зажигать лампочки, что-то читать и прочее. И вот эту нишу и заняла ардуино. Стандартные модули, простой в освоении язык (вспоминаем basic, ага), широченный набор модулей - бери и пользуйся. И не надо нырять в дебри регистровых модели, системы команд, организации памяти и прочее. В нише "быстренько что-то сбацать" ей равных нет. Что-же в этом плохого? Да и в профессиональной сфере она тоже бывает полезна. Практический пример. Вы - механик-конструктор. Вы разработали прототип какого-то устройства и вам надо провести первоначальные ресурсные испытания, скажем, покрутить двигатель 10 секунд в одну сторону, остановиться, потом покрутить 10 секунд в другую, паралельно запоминая количество циклов. Вы можете пойти в соседний отдел электроники (если он у вас есть) и поставить задачу тамошним парням. А они ее сделают, как только найдут время (если найдут). Или вы можете заказать в первом попавшемся магазине ардуину, шилд с LCD и кнопками и парочку модулей с реле. Потратить полдня, чтоб прикрутить это все к доске, соединить проводами, набросать скетч, который всем этим управляет и запустить. И какой-же вариант предпочтительней? В общем, ардуина всего-лишь инструмент, не более того. И этим инструментом можно пользоваться правильно, а можно нет. И считать глупцами тех, кто этот инструмент освоил (или осваивает) и использует по назначению - это как минимум некрасиво, а как максимум показывает Вашу собственную ограниченность.
  3. Эм, а Вы в каком даташите такую таблицу видите? В последней версии доступной на сайте микрочипа таблицы из раздела 9 заканчиваются на индексе 9-2... Да и сам раздел 9 про прерывания, а не про тактирование. Да пожалуйста. Все с чего-то начинают. Хвала в небесам в школах и в институтах еще не посылают сразу в учебники, как только у учащихся вопросы возникают. А то совсем худо было бы. Это странно, ибо говорит о том, что прерывание таймера выводит контроллер изо сна, а значит, что режим энергосбережения не "Power Down", а "IDLE" - это режим в котором останавливается только тактирование процессора и флеш-памяти, все остальное продолжает работат в штатном режиме. Как-то это не согласуется с тем что у Вас в коде написано. Надо смотреть в отладчике, что же на самом деле туда записывается, а то это догадки на кофейной гуще получаются. А вот Ваше решение есьм "костыль", коих нужно избегать всем приличным технарям (любителям тоже). Лучше разобраться в природе явления и в будущем подоходить к решению подобных проблем осознанно.
  4. Конечно. Но иногда хочется позанудствовать. Право, не знаю, где именно Вы это увидели. Таблица 6-5 в разделе 6.2.2 Calibrated Internal 4.8/9.6 MHz Oscillator говорит о "Start-up Time from Power-down" равном 6CK, т.е. 6-ти тактам. Но лично мне столь быстрый выход из глубокого сна кажется подозрительным. Но, повторюсь, я никогда не использовал столь экзотические режимы работы микроконтроллеров. Едва ли. Быстрая пробежка глазами по исходникам модуля, содержащего эту функцию, говорит о том, что в ее основе лежит таймер 0, по переполнению которого банально инкрементируется 8-ми байтная переменная. Никаких сторожевиков там нет да и быть не может. Как бы не плевалось профессиональное сообщество на ардуину, но ее создатели были далеко не глупцами и оставить такой "подводный камень" было бы просто непростительно с их стороны. Но что-то автор сей ветки куда-то запропастился. Может быть даже навсегда и мы никогда не узнаем, что же у него там приключилось на самом деле.
  5. Ну, я AVR'ы оставил в уже достаточно далеком прошлом, могу в чем-то и ошибаться, тем более в режимах энергопотребления (не доводилось мне работать с батарейными приложениями). Однако утверждение: как-бы не совсем верно. В штуках-то да, но при входе в режим "Power Down" производится остановка тактового генератора, соответственно при выходе из него он перезапускается. Время запуска задается во фьюзах и с виду опасений не внушает, так как составляет всего 6 тактов. Плюс еще 4 такта, заявленные для срабатывания прерывания. Вроде как и слезы, но я не уверен, что оно ведет себя именно так. Равно как я не доверяю измерениям автора, где он заявляет об 1 микроампере потребления. Надо больше вводных. Но вариант с неверным конфигурированием внешнего прерывания мне кажется наиболее вероятным. Для опровержения чей гипотезы авторо надо всего-ничего — сказать, при каких именно условиях он наблюдает указанное поведение. Или немного поэксперементировать, в конце-концов. Да, и еще одно надо учесть, что в режиме "Power Down" INT0 дететирует только низкий уровень.
  6. Не обращай внимания. :-) Я за этим форумом лет десять наблюдаю и едва только появляется элементарный вопрос от новичка или просто человека, который "не в теме", но ему надо решить одноразовую задачу, как его сразу перемешают с экскрементами, пошлют в книжку или порекомендуют Мастера (да-да, именно с большой буквы для пущей важности и самозначимости). Но это все лирика. Конкретно по твоей проблеме могу предположить следующее. Режим "сна" ты включаешь правильно. И в нем контроллер действительно будет находится до того момента, пока не возникнет внешние прерывание на линии INT0. Как ты и задумал. Но дело в том, что внешнее прерывание само по себе может быть сгенерировано несколькими событиями (а вот про них таки надо читать в соответствующем разделе даташита, раздел 9.2 External Interrupts), а именно: низкий уровень на линии; изменение уровня на линии; по нарастающему фронту; по спадающему фронту; Установка конкретного осуществляется в регистре MCUCR (биты ISC01 и ISC00), который у тебя в коде не упоминается. Думаю, что в нем содержится значение по-умолчанию, а именно нули. Это соответствует событию 1. Из кода и описания непонятно, какое именно значение у тебя по умолчанию на INT0. Мне кажеться, что как раз нуль. В таком случае контроллер у тебя после инструкции sleep_cpu() практически сразу же проснется и пойдет исполнять оставшуюся часть кода, затем вернется в начало loop опять погрузится в сон и вновь из него вывалится. И так до бесконечности. А разница в энергопотреблении с и без ControlDoor появляется за счет того, что: если последний отсутствует, то после пробуждения исполнение практически сразу же возвращается в начало loop, где вновь пытается уснуть; а если присутствует, то (точно не могу понять), исполнение или совсем зависает в ControlDoor или все-таки пробегает его до конца и вновь возвращается в начало loop; Я думаю, очевидно, что в последнем случае длительность "активной" фазы заведомо больше. За счет нее и возникает повышенное потребление. Понял, в чем оплошность и как ее исправить? :-)
  7. Ну так в приведенной Вами статье как раз и упоминается о проблеме джиттера. Причем автор приводит результаты измерений на очень коротком интервале времени, порядка единиц-десятков микросекунд, а это снижает достоверность, поскольку типичная частота переключений задач составляет порядка 1 КГц (1000 мс), а значит и измерения нужно проводить на интервале хотя-бы на порядок, а лучше на 2-3 больше. Так что прежде всего Вам нужно оценить, на сколько предсказуемо считываются пины, какова максимальная задержка/джиттер. Это даст Вам представление о максимальной частоте входного сигнала, который Вы сможете достоверно считать и обработать.
  8. Да хотя бы в том, чтобы убедиться, что на кольце энкодера все метки в порядке. В частности, в приведенной автором ссылке обращалось внимание на важность правильного соединения энкодера с валом, поскольку при биениях появляется риск затирания кольца об оптопары, что приводит к повреждению меток. Зная заявленную разрядность энкодера, и воспользовавшись выходом N (в терминологии материала по ссылке) можно подсчитать фактическое количество испульсов на оборот, а значит и оценить состояние кольца/исправность энкодера в целом. Это то, что сраз пришло в голову. Возможно, есть и другие сценарии. Другой вопрос, что для выполнения этой задачи хватит любого контроллера. Достаточно лишь завести выходы энкодера на счетный входы таймеров/счетчиков либо, если таковой есть в наличии, на вход готового аппаратного модуля инкрементального энкодера. Таковым располагают многие ARM'ы, в частности всеми любимые STM32. Как и зачем прикручивать сюда малину я, откровенно говоря, тоже не до конца понимаю. Разве что исходя из того, что автор знаком с этой платформой лучше, чем с чем либо еще. Но тогда ему надо понимать, что программный опрос или поллинг пинов на "гребенке" это, скажем так, несколько ненадежный подход, поскольку происходить он будет, в общем случае, с определенным джиттером вызванным работой ОСи. Но до определенной границы, конечно, работать будет.
  9. Massive Overkill. Это все равно что забивать гвозди не просто, а электронным микросокопом. Самый простой импульсный стабилизатор собирается на компараторе, одном полевике и индуктивности. Причем последняя вполне покупается в магазине и даже мотать ничего не надо.
  10. Ну, здесь присутствуют два варианта развития событий, так сказать: Вскрываем блок питания и ищем в нем токоограничетельную цепь, после чего меняем ее параметры таким образом, чтобы выполнялись Ваши требования. Самый простой вариант, но во-первых, требует определенных знаний в схемотехнике, во-вторых может получится так, что токоограничение будет встроено прямо внутрь контроллера блока, тогда изменить его уровень будет как минимум сложнее, если не невозможно вообще, ну и в-третьих черт его знает как этот китайский продукт себя поведет в таком режиме, все-же это источник напряжения, а не тока. Установить на выход Вашего блока питания отдельный стабилизатор тока. А вот какой именно - зависит от Ваших навыков и доступных материалов. И в конце, а аккумулятор-то сам точно 48-ми вольтовый? Просто если Вы так или иначе ограничите ток на выходе стабилизатора, то подключив к нему 12-ти вольтовый аккумулятор вы его не просто зарядите, а вскипятите (или как там это называется?). Напряжение-то выше 12-ти вольт не поднимется, и ток до самой смерти аккумулятора будет 5 или 3 ампера. :-)
  11. А каково целевое назначение сего "стабилизатора"? Свет? Зарядка аккумуляторов? Гальваника? Ответ на этот вопрос даст пищу, для рассуждение о возможных вариантах.
  12. Не, батенька, "на коленке" такую вундервафлю сделать не получится, господа правы. Либо ищите людей, способных выполнить такие работы под заказ, либо можете попытать счастья древним индейским методом, слушая землю. :-) Цимус в том, что внутри труб имеются те или иные дефекты + отводы от магистрали выполняются под углом, наверняка даже 90 градусов. А это означает, что поток воды будет создавать вполне ощутимый шум, который вполне можно уловить заглубленным микрофоном. Конечно, дальность обнаружения будет зависеть от массы факторов, как-то скорость потока, состояние труб, типа грунта, его влажности, наличие чего-то шумящего рядом и еще черт знает чего, но это хотя-бы выглядит принципиально реализуемо и проверяемо. Вам же, как минимум, известна точка входа водовода на вашей територии. Вот можно послушать, слышно ли там чего. А потом и решить, стоит ли овчина выделки. К слову, во времена ВоВ подобный метод использовали немцы, когда испытали несколько подрывов радиоуправляемых фугасов. В них помимо радиовзрывателя был, если мне не изменяет память, еще и самоликвидатор с часовым механизмом имелся. А у часового механизма - подзавод, который, вроде как издавал характерные звуки. Вот их-то саперы и выслушивали. Правда, не знаю чем именно, может банальными стетоскопами, может чем по круче, но возможностей у них в любом случае меньше было, чем сейчас. Ну а самым надежным методом будет банальное подмешивание красителя, который коммунальщики используют для выяления протечек. Название загуглите. Одна упаковка в подходящий момент — и гипотетический любитель халявы будет выведен на "чистую" воду. Правда, потом придется слить все это добро из трубопровода, но сия субстанция заявлена как безвредная.
  13. Ну, I2C это лишь посредник. По ту сторону там все равно должен быть контроллер, который, опять таки, должен работать по все тому же 4-х или 8-ми битному непосредственно с дисплеем. Возможна вариация, если верить гуглу, когда вместо контроллера используется расширитель портов ( и там и там возможны ошибки как в схемотехнике, так и в инициализации ). В общем, упомянутая проблема с 4-х битным интерфейсом по-прежнему может иметь место. В любом случае плавный пуск или кольца это борьба со следствием, но не причиной. Не должен хорошо продуманное устройство так себя вести. :-) Или, как минимуму, такие события должны возникать крайне редко. Но, для любительского проекта вполне себе вариант, да.
  14. А что там за дисплей-то? Я так полагаю классический цифробуквенный на 16 символов в две строки? Если так, то рекомендую обратить внимание на то, как именно он подключен — по 8-ми или 4-х битному интерфейсу и если последнее верно, то проследить подключение вывода E. Цимус в том, что при работе в 4-х битном байт команды или данных загружаются в два этапа - собственно по 4 бита за раз, и каждая операция инициируется перепадом H —> L на упомянутом мною выводе E. Так вот, любой глитч на этой линии, источником которой вполне может служить запуск ваших насосов, пусковой ток-то там наверняка кратно больше номинального, и это может стать причиной возникновения помехи того или иного рода, приведет к тому, что внутренняя логика контроллера рассинхронизируется с вашими ожиданиями. Вы будете считать, что закачиваете первый полубайт, а для него это будет уже второй. Результат — всякие "крякозябры" на экране. Помочь в таком случае мог-бы сброс контроллера дисплея, но, судя по всему, программно это выполнить невозможно, а "железный" вывод RST не завезли. Ествественно, что в нормальном, 8-ми битном режиме такой ситуации быть не может. Могу предположить следующее лечение: 1) Пожестче "подтянуть" E к плюсу питания, в зависимости от схемы или уменьшить номинал подтягивающего резистора, или, если используется только встроенная подтяжка пина порта AVR, то установиь внешний, номиналом, скажем, около 1 килоома. Также можно попытаться установить конденсатор в несколько десятков пикофарав от E на землю. 2) Надеть на провода, подключающие насосы к реле, ферритовые кольца. 3) И, наконец, плавно пускать насосы, допустим, с помощью NTC резистора включенного последовательно с ними или дополнительного реле с обычным резистором.
×
×
  • Create New...