Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Мне кажется, алгоритм, который вы приводите
Выбора у вас, по большому счету — два. Либо оптимизировать алгоритм, либо увеличивать мощность платформы.
В условиях поджимающих сроков второе предпочтительно. Но отдавайте себе отчет, что сам подход с использованием неоптимальных алгоритмов — это плохо.
И не ожидайте, что любой DIY алгоритм может быть перенесен в серийное устройство без глубокой переработки.
Я думал, вы решение проблемы ищете…
while (1) {— это пример несложной задачи и ее неоптимального решения. То, что вы упираетесь в последствия неоптимальности — это нормально, и связано с нормальным ростом требований к устройству.
Запрет_прерываний;
// определяем момент перехода через 0
// делаем задержку включения
// Включение; Задержка_на включение; Выключение;
// Разрешение прерываний;
// пауза перед началом очередного цикла
};
Выбора у вас, по большому счету — два. Либо оптимизировать алгоритм, либо увеличивать мощность платформы.
В условиях поджимающих сроков второе предпочтительно. Но отдавайте себе отчет, что сам подход с использованием неоптимальных алгоритмов — это плохо.
И не ожидайте, что любой DIY алгоритм может быть перенесен в серийное устройство без глубокой переработки.
Я думал, вы решение проблемы ищете…
Спасибо, конечно )
Все же хотел бы заметить, что второе — то есть увеличение мощности (смена) платформы представляется автору коментария предпочтительным на фоне необходимости оптимизации алгоритма.
Весь пафос поста и заключался в том, что многие из современных разработчиков избегают решений, связанных с глубоким проникновением в суть процесса, который и необходим для оптимизации хоть алгоритма, хоть библиотек, поскольку, прежде чем что-либо улучшить, надо разобраться, как оно работает.
Может, конечно, раньше трава была зеленее, но мы такими не были.
Все же хотел бы заметить, что второе — то есть увеличение мощности (смена) платформы представляется автору коментария предпочтительным на фоне необходимости оптимизации алгоритма.
Весь пафос поста и заключался в том, что многие из современных разработчиков избегают решений, связанных с глубоким проникновением в суть процесса, который и необходим для оптимизации хоть алгоритма, хоть библиотек, поскольку, прежде чем что-либо улучшить, надо разобраться, как оно работает.
Может, конечно, раньше трава была зеленее, но мы такими не были.
Кстати, я не очень понял итоговую посылку поста —
А голосование в конце поста меня окончательно сбило с толку. Короче, ответьте, чего в итоге хочет автор?
- если требуется ответ коллективного разума на вопрос «можно ли совместить фазовое управление мощностью с ограничением задержки в 65мкс» — то ответ «ДА» (но это и в посте написано).
- если требуется ответ на вопрос «как конкретно реализовать совместную работу фазового управления и уложиться в 65мкс задержек» — то мой опыт — аппаратный детектор нуля на выпрямителе, потом прерывание с контролем правильности длительности полупериода (упрощенный подавитель дребезга), в котором взводится таймер на заданную длительность импульса на открытие триака.
- если требуется ответ «обоснован ли отказ от семейства микроконтроллеров из-за недостатка опыта программирования в условиях поджимающих сроков» — ответ для менеджера проекта — «ДА, но программиста пора менять», ответ для программиста — «НЕТ, ты занимаешься этим в том числе для того, чтобы приобрести опыт».
А голосование в конце поста меня окончательно сбило с толку. Короче, ответьте, чего в итоге хочет автор?
Вы абсолютно верно поняли основную мысль поста — необходимо думать разработчику, а не тупо перебирать МК и библиотеки в надежде, что все само как нибудь получится.
А голосование в конце — это ко всем моим постам независимо от содержания — пытаюсь понять уровень детализации изложения. Наример, в этом не удержался и дал коротенькое описание методов димирования, вот и пытаюсь понять — не зря ли, может все всё про него и так знают.
А голосование в конце — это ко всем моим постам независимо от содержания — пытаюсь понять уровень детализации изложения. Наример, в этом не удержался и дал коротенькое описание методов димирования, вот и пытаюсь понять — не зря ли, может все всё про него и так знают.
Тогда поставлю на полях отметку «крик души».
Вот, кстати, еще парочка замечаний:
При выборе платформы (ну, в данном случае было наоборот, взяли готовую заготовку, но вы понимаете, о чем я) нужно же закладывать некоторый запас по ресурсам? Так вот, запас по «latency» — такой же ресурс как объем памяти или MIPS. И нужно помнить об этом запасе при рассмотрении каждого нового требования или хотелки. Это, кстати, через годик становится весьма ценным куском опыта, т.к. появляется возможность до начала реализации фичи прикинуть в уме (по нескольким ранее реализованным или отклоненным) и сказать на раннем этапе — «мы не помещаемся в запас по latency», сэкономив немножко времени на прототипировании. Даже один такой аргументированный ранний отказ — это конкретный профит и он обычно приветствуется окружающими.
Появляется и дополнительный аргумент для неиспользования кривых алгоритмов — если алгоритм пожрал 80% запаса по какому-то из ресурсов (как, например, в приведенном псевдокоде — пожрал 100% latency), то, ясен перец, второй подобный алгоритм уже не запихаешь, да и более скромные алгоритмы уже не добавишь.
Вот, кстати, еще парочка замечаний:
При выборе платформы (ну, в данном случае было наоборот, взяли готовую заготовку, но вы понимаете, о чем я) нужно же закладывать некоторый запас по ресурсам? Так вот, запас по «latency» — такой же ресурс как объем памяти или MIPS. И нужно помнить об этом запасе при рассмотрении каждого нового требования или хотелки. Это, кстати, через годик становится весьма ценным куском опыта, т.к. появляется возможность до начала реализации фичи прикинуть в уме (по нескольким ранее реализованным или отклоненным) и сказать на раннем этапе — «мы не помещаемся в запас по latency», сэкономив немножко времени на прототипировании. Даже один такой аргументированный ранний отказ — это конкретный профит и он обычно приветствуется окружающими.
Появляется и дополнительный аргумент для неиспользования кривых алгоритмов — если алгоритм пожрал 80% запаса по какому-то из ресурсов (как, например, в приведенном псевдокоде — пожрал 100% latency), то, ясен перец, второй подобный алгоритм уже не запихаешь, да и более скромные алгоритмы уже не добавишь.
Где-то мы пересекли тот тонкий момент перехода с дорогого железа и дешевого времени на дешевое железо и дорогое время. Сейчас время разработчика значительно дороже железа, поэтому такой подход.
Темболее в современных реалиях тотального усложнения искать решение проблемы может оказаться неоправданным расточительством когда проще и дешевле решить проблему хорошо прогнозируемыми методами.
Темболее в современных реалиях тотального усложнения искать решение проблемы может оказаться неоправданным расточительством когда проще и дешевле решить проблему хорошо прогнозируемыми методами.
Ну в приведенном мной идее реализации нет НИЧЕГО сложного. То есть вообще ничего, что потребовало бы более 1 дня работы. То есть сейчас разработчик НАСТОЛЬКО дорог?
Не говоря уж о том что главный капитал — а именно опыт разработки, при моем подходе только возрастает. И, все таки, не будем выпускать из вида то, что решение проблемм стандартными методами никогда разработчика не выведет на уровень переднего края, где действительно нужно выжимать ВСЕ из железа и софта, а наоборот, постепенно низведет до уровня индусского программера.
Не говоря уж о том что главный капитал — а именно опыт разработки, при моем подходе только возрастает. И, все таки, не будем выпускать из вида то, что решение проблемм стандартными методами никогда разработчика не выведет на уровень переднего края, где действительно нужно выжимать ВСЕ из железа и софта, а наоборот, постепенно низведет до уровня индусского программера.
Ну, 1 день это очень оптимистичная оценка… такое время в более-менее сложном проекте уйдет только на «оценку ущерба». Цель ведь не сделать любыми средствами, а сделать так чтобы не развалилось в коде который полностью не умещается в мозгу одного человека.
Один день — это восемь часов. Если не читать хабр, не запускать птичек и не спорить на тему «а можно ли так сделать, а нельзя ли сделать по другому, а не лучше ли перейти на другой МК и тд» и знать МК, для которого реализуешь предлагаемый алгоритм (а иначе что мы тут делаем), то этого вполне достаточно. Ну по крайней мере для меня, не буду говорить за других. И что тут может не уместиться в мозгу одного человека, в этом данном конкретном случае, описанном в посте?
Вот мне интересно, откуда в вас столько желчи? :) Так и плещет в комментариях. Я бы на вашем месте бы аккуратнее в выражениях. Здесь желчи обычно не терпят.
В нашем проекте атмегами занимался один конкретный разработчик. Он посчитал, что не справится с этой задачей и решил уйти из проекта. Вся история с зигби началась именно с его атмеговских разработок. Искать другого разработчика, который осилит зигби у нас сейчас нет финансовых ресурсов. На доработку всего этого аппаратного хозяйства, чтобы хорошо работало с зигби нет временных ресурсов.
Плюс важный момент — лично мне хочется как аппаратные, так и программные разработки по проекту делать открытыми народу. Для этого они не должны перешагивать определенного порога сложности, по двум причинам: 1) чтобы можно было легко донести их до людей без вашего многодесятилетнего опыта разработки и 2) если вложить в разработку софта одного диммера 100-200 тыс рублей (а это не самая большая ставка профессионального разработчика за 1,5-2 месяца фултайма) личных денег, то у меня рука уже не поднимется просто взять и выложить это для всех. Не рационально.
Этот «порог» по зигби уже четко понятно, что будет перешагнут. Плюс идея нашего проекта в том, чтобы у людей было удобное решение для кастомизации «по своему велению». В зигби по факту для кастомизации готовой прошивки потребуется недюжая квалификация. Тоже мимо.
Мы делаем «ардуино» в области умного дома — это вам совсем не понятно?
В нашем проекте атмегами занимался один конкретный разработчик. Он посчитал, что не справится с этой задачей и решил уйти из проекта. Вся история с зигби началась именно с его атмеговских разработок. Искать другого разработчика, который осилит зигби у нас сейчас нет финансовых ресурсов. На доработку всего этого аппаратного хозяйства, чтобы хорошо работало с зигби нет временных ресурсов.
Плюс важный момент — лично мне хочется как аппаратные, так и программные разработки по проекту делать открытыми народу. Для этого они не должны перешагивать определенного порога сложности, по двум причинам: 1) чтобы можно было легко донести их до людей без вашего многодесятилетнего опыта разработки и 2) если вложить в разработку софта одного диммера 100-200 тыс рублей (а это не самая большая ставка профессионального разработчика за 1,5-2 месяца фултайма) личных денег, то у меня рука уже не поднимется просто взять и выложить это для всех. Не рационально.
Этот «порог» по зигби уже четко понятно, что будет перешагнут. Плюс идея нашего проекта в том, чтобы у людей было удобное решение для кастомизации «по своему велению». В зигби по факту для кастомизации готовой прошивки потребуется недюжая квалификация. Тоже мимо.
Мы делаем «ардуино» в области умного дома — это вам совсем не понятно?
Что то я не понял — вы от ЗИГ отказались?
Если не отказаллись, то как совместить применение закрытой бибилиотеки с желанием сделать разработки открытыми народу?
Если имеется в виду, что проект должен быть понятен с точки зрения легкого допиливания, то это один подход.
А если ВЕСЬ проект должен быть понятен и модифицируем, то это другой подход, и, конечно, другие затраты.
Что касается нерациональности выкладывания результатов… вся концепция открытого софта на этом базируется и неплохо себя чувствует. Не скажу, что все, что я видел в опен, представляет собой шедевр, но есть и вполне приличные разработки, и люди ими реально делятся с другими.
Ну и чуть в сторону. На мой взгляд, одна из проблем индустрии встроенного ПО в нашей стране в том, что у нас нет профессионального сообщества, как в других странах. Лично я с завистью читаю сообщения о ивентах разработчиков даже не в Штатах и Европе, а в Бразилии, например. Если бы оно существовало, то просто для получения определенного статуса в глазах близких тебе по духу людей многие делились бы своими достижениями (в соответствии с пирамидой потребностей). Не знаю, как другие авторы, но я пишу именно для этого. Ну нельзя все выгоды сводить только к монетизации знаний, неправильно это.
Насчет желчи… со стороны, конечно, виднее, но я думал, что выражаю свою глубокую озабоченность состоянием дел в индустрии, которой отдал большую часть своей жизни. Причем такое состояние не только у нас, если верить тематическим иноязычным сайтам. А что касается аккуратности в выражениях, то я свое мнение (часто саркастическое) по поводу отдельных аспектов окружающей нас «объективной реальности, данной нам в ощущениях» (интересно, сколько хабровчан узнают автора цитаты) не скрывал и в те времена, когда это действительно было небезопасно, а уж в наше время — «минусов бояться, честно не писать » — так, что ли?
Ну и в заключение — если предложение поработать 8 часов в день приравнивается к троллингу, значит все еще хуже, чем я думал.
Если не отказаллись, то как совместить применение закрытой бибилиотеки с желанием сделать разработки открытыми народу?
Если имеется в виду, что проект должен быть понятен с точки зрения легкого допиливания, то это один подход.
А если ВЕСЬ проект должен быть понятен и модифицируем, то это другой подход, и, конечно, другие затраты.
Что касается нерациональности выкладывания результатов… вся концепция открытого софта на этом базируется и неплохо себя чувствует. Не скажу, что все, что я видел в опен, представляет собой шедевр, но есть и вполне приличные разработки, и люди ими реально делятся с другими.
Ну и чуть в сторону. На мой взгляд, одна из проблем индустрии встроенного ПО в нашей стране в том, что у нас нет профессионального сообщества, как в других странах. Лично я с завистью читаю сообщения о ивентах разработчиков даже не в Штатах и Европе, а в Бразилии, например. Если бы оно существовало, то просто для получения определенного статуса в глазах близких тебе по духу людей многие делились бы своими достижениями (в соответствии с пирамидой потребностей). Не знаю, как другие авторы, но я пишу именно для этого. Ну нельзя все выгоды сводить только к монетизации знаний, неправильно это.
Насчет желчи… со стороны, конечно, виднее, но я думал, что выражаю свою глубокую озабоченность состоянием дел в индустрии, которой отдал большую часть своей жизни. Причем такое состояние не только у нас, если верить тематическим иноязычным сайтам. А что касается аккуратности в выражениях, то я свое мнение (часто саркастическое) по поводу отдельных аспектов окружающей нас «объективной реальности, данной нам в ощущениях» (интересно, сколько хабровчан узнают автора цитаты) не скрывал и в те времена, когда это действительно было небезопасно, а уж в наше время — «минусов бояться, честно не писать » — так, что ли?
Ну и в заключение — если предложение поработать 8 часов в день приравнивается к троллингу, значит все еще хуже, чем я думал.
</сарказм> Не благодарите :)
Интересно, хватит ли свободных ресурсов, чтобы сделать программный ФАПЧ с приемлемой точностью (например, 5 градусов) на частоту 50Гц?
Например, оцифровывать аналоговый сигнал напряжения сети (достаточно будет порядка пары десятков измерений за период 20 мс), исходя из оцифрованных значений вычислять текущую частоту и фазу, и соответственно предсказывать переходы через ноль и соответственно заряжать PWM таймер на периодическое срабатывание с нужной скважностью? Нужен будет еще один свободносчитаемый таймер для временной оси (необязательно завязанный на прерывания), с него программно можно считывать показания в обработчике прерывания АЦП, сохраняя пары (время: значение)
Например, оцифровывать аналоговый сигнал напряжения сети (достаточно будет порядка пары десятков измерений за период 20 мс), исходя из оцифрованных значений вычислять текущую частоту и фазу, и соответственно предсказывать переходы через ноль и соответственно заряжать PWM таймер на периодическое срабатывание с нужной скважностью? Нужен будет еще один свободносчитаемый таймер для временной оси (необязательно завязанный на прерывания), с него программно можно считывать показания в обработчике прерывания АЦП, сохраняя пары (время: значение)
Интересное предложение, но потребует АЦП и делителя.
Хотя делитель входного напряжения в устройстве уже наверняка есть, хотя бы для питания.
Мне кажется, что даже детектора больше/меньше при длительности циклов в 100-200 ( а это 1-2 секунды) должно хватить для начальной настройки.
Хотя делитель входного напряжения в устройстве уже наверняка есть, хотя бы для питания.
Мне кажется, что даже детектора больше/меньше при длительности циклов в 100-200 ( а это 1-2 секунды) должно хватить для начальной настройки.
Если мне не изменяет память там блок питания на гасящем конденсаторе так что делителя для вычисления уровня напряжения питающей сети в БП нету, а есть ли он отдельно… у меня большие сомнения, скорее всего переходом через ноль ограничились.
Еще можно отдать расчет момента включения на откуп аналоговой части — заряжать конденсатор через резистор от выпрямленного мостовым выпрямителем сетевого напряжения (приведенного к диапазону АЦП естественно) — тогда напряжение на конденсаторе примерно будет пропорционально площади (то есть мощности), «отрезаемой» от полного периода сигнала части. Если на кристалле есть компаратор с программно-устанавливаемым порогом, то нужно просто рассчитать его величину соответственно необходимой мощности в нагрузке, а выход компаратора соединить с управлением симистора. Если же компаратора нет, а есть просто АЦП — то тогда обрабатывать по прерываниям в однократном режиме, и проверять значения программно. Нужно только как-то обеспечить, чтобы после выдачи управляющего сигнала конденсатор оставался зашунтированным, готовым к интегрированию напряжения в следующем цикле (в двухполюснике, которым является ваш выключатель, такое условие соблюдалось бы автоматически, если бы не двухполупериодный выпрямитель, который не даст разрядиться конденсатору через открытый симистор)
Насколько я знаю, в атмеловских контроллерах есть возможность задать таймеру частоту переполнений одним из регистров сравнения, вторым можно задавать скважность, по прерыванию перехода через ноль сравнивать «остаток» таймера и корректировать его скорость — это буквально несколько строчек на ассемблере.
основная проблема это в оффлайне пересчитывать значение регистра сравнения под необходимую скважность — это задача более сложная, но может подождать решения до 2-3 полупериодов.
В одном проекте на PICe лет 10 назад вообще ничего такого небыло — ШИМ был программный на таймере, таймер считал время от начала сетевого периода и программно отсчитывалась точка полупериода который не получилось поймать — в том камушке очень скромные возможности по прерываниям, можно было поймать либо только фронт либо спад но не оба одновременно. И что же… на 4Мгц тактовой частоте все работало и не шуршало. А тут, как я понимаю мегагерцы частоты, быстрый конвеер исполнения инструкций и «ничего не работает»?
основная проблема это в оффлайне пересчитывать значение регистра сравнения под необходимую скважность — это задача более сложная, но может подождать решения до 2-3 полупериодов.
В одном проекте на PICe лет 10 назад вообще ничего такого небыло — ШИМ был программный на таймере, таймер считал время от начала сетевого периода и программно отсчитывалась точка полупериода который не получилось поймать — в том камушке очень скромные возможности по прерываниям, можно было поймать либо только фронт либо спад но не оба одновременно. И что же… на 4Мгц тактовой частоте все работало и не шуршало. А тут, как я понимаю мегагерцы частоты, быстрый конвеер исполнения инструкций и «ничего не работает»?
Для ответа на «почему вы братцы просто не умеете их готовить» — чОтко.
Для «вызов принят» — не хватает кода.
Тут просто нужен PoC. Про себя я скажу так — у меня тиристорное управление + математика + довольно нагруженный протокол по UART работают без проблем на ADuC 847 на 6 мгц
Для «вызов принят» — не хватает кода.
Тут просто нужен PoC. Про себя я скажу так — у меня тиристорное управление + математика + довольно нагруженный протокол по UART работают без проблем на ADuC 847 на 6 мгц
Ну главная идея реализации правильного метода изложена — написать еще и код было бы, на мой взгляд, перебором, надо же читателю оставлять место для фантазии ).
И Ваш пример подтверждает главную мысль поста — делайте все аккуратно и не придется переходить на другой МК. Рад, что не все современные разработчики перешли в «кое-какеры».
И Ваш пример подтверждает главную мысль поста — делайте все аккуратно и не придется переходить на другой МК. Рад, что не все современные разработчики перешли в «кое-какеры».
Кстати, подскажите в личку, плиз, как результаты голосования по опросу посмотреть?
А то затеял оценку уровня сложности, а результатами воспользоваться не могу ((.
Уже нашел )))).
А то затеял оценку уровня сложности, а результатами воспользоваться не могу ((.
Уже нашел )))).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт одного инженерного расследования