Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 8
Попытаюсь описать процесс как можно детальнее. Для того, чтобы подать на динамик звук нужной тональности и длительности, необходимо переключать состояние пина с частотой заданной ноты и делать это на протяжении времени длительности заданной ноты. У меня этот процесс происходит в основном цикле и выполняется параллельно остальным задачам. Для этого я считаю длительность текущей ноты и ее частоту (константы здесь зависят от задержки в конце главного цикла и были подобраны вручную):Извините, а почему вы не стали использовать аппаратный ШИМ? Это было бы гораздо проще.
Если верить даташиту, их у вашей тини аж 4 штуки.
www.atmel.com/images/doc2543.pdf
О наличии ШИМ знаю но никогда им не пользовался по неопытности. Ваш комментарий заставил серьезно задуматься, возможно я переделаю эту часть на ШИМ ведь звук мелодии получился, мягко говоря, не очень.
Аппаратный шим это очень хорошее освобождение ресурсов.
Смысл в том, что когда надо дергать ногой с определёной частотой, вы вынуждены заботится о том, чтобы к нужному времени процессор был свободен.
Шим же дёргает ногой сам, вы ему лишь задаёте параметры, как дёргать, и ваше внимание нужно только для изменения режима работы.
Смысл в том, что когда надо дергать ногой с определёной частотой, вы вынуждены заботится о том, чтобы к нужному времени процессор был свободен.
Шим же дёргает ногой сам, вы ему лишь задаёте параметры, как дёргать, и ваше внимание нужно только для изменения режима работы.
Мой комментарий относится к статье косвенно, статья интересная и вообще DIY это классно!
НО:
У меня при виде Jenkins и подобных утилит возникает только один вопрос: Это как так на «мастер» можно закоммитить/пушить некомпилируемый код?
Я по работе с таким сталкивался, в основном, в смежных с моим проектом, и каждый раз это выливается в своеобразный ад. У нас есть специальный человек именуемыйпо шапке раздаватель CM инжернер, который, помимо своих прямых обязаностей по настройке общего окружения для сборки, следит чтобы инженеры, как минимум, не отправляли на мастер/релиз бранч некомпилируемый код. В целом, это какое-то халатное отношение — сабмитить, то что даже скомпилировать нельзя. Может стоит задуматься ЧЯДНТ, если такое происходит, и исправиться? Если не вышло с N+1 попытки, задуматься, а нужен ли такой инженер в команде, который даже компилируемый код написать/заинтегрировать не в состоянии?
Критика весьма субъективная, но имеет место быть.
НО:
У меня при виде Jenkins и подобных утилит возникает только один вопрос: Это как так на «мастер» можно закоммитить/пушить некомпилируемый код?
Я по работе с таким сталкивался, в основном, в смежных с моим проектом, и каждый раз это выливается в своеобразный ад. У нас есть специальный человек именуемый
Критика весьма субъективная, но имеет место быть.
Во-первых, билд валится не только по ошибке компиляции, а еще и вследствие невыполненных тестов, предупреждений от Style Cop (если включена опция «Считать предупреждения ошибками»).
Во-вторых, когда работаешь с распределенным проектом, в котором несколько модулей делаются разными командами, да еще есть ядро / фреймворк от еще одной команды, то репозиторий кода имеет очень непростой жизненный цикл. Разных стадий бранчи, например. Бывает так, что твой последний код по какой-то причине ссылается на то, что не положено в транк фреймворка или на твоей локальной машине состояние репозитория отличается от оного на машине сборки. Такие ошибки могут случиться и твой локальный билд не свалится, а на сервере свалится.
Во-вторых, когда работаешь с распределенным проектом, в котором несколько модулей делаются разными командами, да еще есть ядро / фреймворк от еще одной команды, то репозиторий кода имеет очень непростой жизненный цикл. Разных стадий бранчи, например. Бывает так, что твой последний код по какой-то причине ссылается на то, что не положено в транк фреймворка или на твоей локальной машине состояние репозитория отличается от оного на машине сборки. Такие ошибки могут случиться и твой локальный билд не свалится, а на сервере свалится.
У нас в проекте таже ситуация, много подсистем начиная от компилятора, коначая UI и мое сообщение скорее навеяно печаным опытом нежели какими-то здравыми ± самого Jenkins или OBS например. У нас был товарищ, который ломал корневые зависимости для 3 других подсистем по 5 раз на дню. Jenkins красиво показывал красную табличку, для нас означавшую, только одно — делать fetch/merge нельзя. В итоге после недели повторений человеку нашли другое занятие. И красная табличка в Jenkins больше не появлялась. Потому что остальные инженеры выполняют сборку с имеющимися подсистемами в т.ч. unit-тесты до отправки изменений на ревью. Я уже не говорю про сабмит на релизный бранч.
Все просто, наш проект компилируется в облаке, а мерж и коммит в SVN не всегда происходит без ошибок. Бывает, когда создаются новые классы вылетает из головы добавить их в package.xml, вот билды и падают. Бывает и по другой причине, например, разница в версиях метадаты. Да и светофор — это just for fun.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Очередной CI светофор. На этот раз attiny2313 и Node.js