Надо же, а мне казалось, что Бердяев писал достаточно доходчиво... Ладно, поясню по рабоче-крестьянски, в двух словах, о чем это его эссе.
Бердяев говорит о том, что искусство, которое мы любим называть "вечным", принципиально должно быть идейно направлено за пределы материального бытия. Искусство, имеющее цель, принадлежащую познаваемому, обречено на деградацию. Грубо говоря, такой аналог теоремы Гёделя. По этой причине, кстати, "натурализм" поныне противопоставляется искусству. Отсюда и рассуждения о Боге - это классическая абстракция непознаваемого. Но я понимаю, что на атеиста упоминание Бога действует слишком возбуждающе и мешает воспринимать все остальное. :)
Еще проще: можно создать великое произведение о любви, но нельзя - о сексе. Не получится. По этой причине и порнография классически не относится к высокому искусству.
Что же до причин Возрождения, то в наши дни, например, ресурсов еще больше, но что-то второго Ренессанса мы не наблюдаем, такие дела. Наоборот, в текущих условиях рост количества ресурсов приводит к стагнации искусства, и Бердяев поясняет, почему.
Напомню, что знаменитый квадрат Малевича - изначально декорация к спектаклю "Победа над солнцем". В этом контексте он и имеет смысл, как полное противопоставление круглому и яркому солнцу.
Вне контекста спектакля он смысла, конечно же, не имеет.
Сам спектакль очень показателен. Это, в сущности, сама по себе наглядная демонстрация того, что получится, если до конца пройти по дороге морального и философского релятивизма.
Рекомендуемое чтиво на тему:
Николай Бердяев, "Конец Ренессанса" - это попроще, о том, что не так с современным искусством и почему так получилось
Владимир Мартынов - "Конец времени композиторов" - эта книжка сильно сложнее и исследует вопрос конкретно применительно к музыке, зато гораздо глубже.
Ну, трудности от слабого освещения несколько преувеличены. :) Как я уже писал выше, основная проблема, особенно при использовании доступных устройств, не собственно низкий или высокий уровень освещения, а динамический диапазон. Обязательно нужно сделать так, чтобы как минимум то, что представляет интерес, было верно экспонировано.
В этом смысле на улице снимать гораздо труднее, чем в помещении, поскольку, особенно при ярком солнце, контраст в большинстве случаев будет превышать возможности камеры, и с этим крайне сложно что-то сделать. Профессионалы в таких случаях используют отражатели для снижения контраста в тенях, или даже мощные лампы, которые способны соревноваться с солнцем в освещенности.
Кстати лично мне больше нравится формат статей, а не видео. Но тема видеосъемки/аудиозаписи интересна мне в хоббийном плане, причем более всего я упираю на выжимание максимума из самых простых устройств. Потому поговорить об этом я всегда готов. :)
Вот насчет того, что превращать хобби в работу прекрасно, утверждение явно неоднозначное. :)
Лично для меня хоббийная деятельность характерна тем, что ей можно заниматься только тогда, когда хочется, и столько, сколько хочется. А если не хочется - можно не заниматься вовсе.
Работа же отличается тем, что ей приходится заниматься, потому что иначе будет не на что жить, вне зависимости от наличия желания и вдохновения. Потому такая деятельность зачастую бывает в тягость.
Стоит ли рисковать удовольствием от дела, переводя его в коммерческое русло? Каждый решает для себя.
Ну, во-первых, уговаривал автора снимать видео не я. :) Я только поделился опытом.
Во-вторых это сложный вопрос, на самом деле. Если заранее продумать расстановку камер в мастерской, то проблемы неудачного угла съемки не будет - мастерская, в отличие от динамичного уличного видео, ограниченное пространство.
Но вообще конечно да, видео отнимает больше времени. Хотя, с другой стороны, создание хорошей статьи тоже дело небыстрое.
На самом деле, практически любая, начиная от камеры телефона. Единственно только, чем проще камера, тем меньше возможностей в пост-обработке, потому больше внимания придется уделять освещению и компоновке кадра.
Сразу скажу, что для камер телефона, экшен-камер и прочих аппаратов с физически малой матрицей наиболее актуальна проблема динамического диапазона, потому, чтобы получить хорошее видео на такой прибор, нужно прежде всего озаботиться равномерным освещением, без серьезных теней и слишком ярко освещенных участков. С зеркальными фотоаппаратами в режиме съемки видео все проще, с профессиональными кинокамерами - еще проще. :)
Если будете что-то говорить в кадре, обязательно озаботьтесь петличным микрофоном (можно беспроводным). Без него звук будет очень так себе.
Из бесплатных видеоредакторов могу порекомендовать Shotcut.
Очень интересно, чем не угодили разработчики. Так-то, упоминаемый Кулибин как раз был в современном понимании разработчиком; а кто под разработчиком понимается тут?
Собственно, самое простое определение инженера/разработчика - это человек, результат труда которого можно потрогать; ну там, фен, стиральную машину, телевизор. Программист - не инженер, хотя их почему-то часто так называют. Хотя, конечно, способности к инженерии и программированию могут уживаться в одном человеке. Как правило, это характерно для специалистов по встроенным системам. Девопс, естесственно, тем более не инженер, если только это не "девопс" АСУТП.
В прочем, я уже давно в курсе, что инженеры - это люди, о которых мало что знают. Пожалуй, мы видим очередное подтверждение этого факта. Впрочем хорошо, что само понятие идет в массы.
ШИМ же позволяет сделать так чтобы светодиод не успевал сгореть от превышения тока.
Подход, достойный Ардуино. :)))
Нет. Нормальная схема должна гарантированно обеспечить штатный режим. Так что в данном случае резистор - самый адекватный выход. Городить что-то более серьезное смысла тут нет.
я единственный, кто последовательно, логично и с примерами отстаивает свою позицию.
Переход на аргументы ad hominem плохо сочетается с перечисленными добродетелями. :)
Вы правда хотите какой-то программой исправить вышеозначенные косяки аппаратуры, на которой эта же программа и исполняется?
В реальном мире никогда не будет идеальных условий эксплуатации — просто примите это. Причем чем специфичнее применение, тем условия, как правило, тяжелее. И программа, по-возможности, должна если и не спасать положение целиком, то хотя бы минимизировать финальный ущерб. Это достигается не только программными средствами, конечно; критичные функции всегда защищаются аппаратно, насколько это возможно.
Кстати, от выбивания битов в памяти не имунна полностью и «правильная» по вашему мнению элементная база. Да, в технологии с диэлектрическими подложками тиристорного эффекта не будет, но вероятность повреждения памяти заряженными частицами все равно есть. Предлагаете делать на лампах? Вот они да, 100% защищены от всех эффектов.
Сразу скажу, что свинцовая или какая-то другая защита не спасет. Попадание частицы с космическим уровнем энергии в материал вызывает лавину вторичных частиц, что усугубляет проблему. Как видите, есть много нюансов.
Жизнь сложна и многообразна; защищаться воплями «ЭТО НАРУШЕНИЕ ПРАВИЛ ЭКСПЛУАТАЦИИ ВЫ САМИ ВИНОВАТЫ!!!1111» — так себе вариант. Надо предполагать работу аппаратуры и в нештатных условиях. В том числе и не предусмотренных ТЗ, но вероятных, в том числе и в результате возможного раздолбайства.
Вы таки продемонстрируете код?
Эээ, вам написать switch, в котором в блоке default осуществляется вызов обработчика ошибки?
Ну, если человеку (не вам лично, я вообще) кажется хардкором отсутствие динамического выделения памяти — значит он очень далек от эмбеда. :)
Статическое объявление всего — вообще первая особенность программирования под железо. Во-первых, в 90% случаев отсутствует ОС, так что по умолчанию следить за памятью нечему, а реализации менеджера памяти в стандартной библиотеке не слишком оптимальны. При этом действительно хорошая реализация malloc() может занимать места столько же, сколько вся программа.
Ну и я уже не говорю о том, что выделение памяти, действительно, недетерминированная операция; нет никакой гарантии, что в нужный момент окажется доступным нужный объем памяти.
Да вот только правило говорит нам, что следует всегда использовать default.
Лучше перебдеть.
Действительно не поверю. Если программа гадит не пойми куда ...
Хехе, сразу видно программиста не-железячника.
Программа тут не при чем. Может прилететь частица и изменить бит в памяти (нормальная ситуация для аппаратуры на спутниках), может случиться скачок/просадка напряжения и повредить участок FLASH/EEPROM (например, если BOD настроен неверно и запись в NVM прошла при нештатном напряжении) или область RAM, может быть повреждена линия к внешней микросхеме памяти, и еще куча вариантов.
Только при чём тут default?
Это самый простой способ отловить неожиданное значение.
Иногда бывает полезно иметь скриптовый язык в устройстве, особенно когда стоит задача дать пользователю возможность слегка модифицировать логику работы, но при этом не дать натворить непоправимого.
Lua кстати — самый шустрый и легковесный вариант для таких случаев. По работе делал примерно то же самое, что описано в статье, для местного испытательного комплекса. Только у нас там еще и самописный WEB-сервер (сеть через Ethernet). Все вместе занимает 144380 байт во флеше STM32F429 (FreeRTOS + драйвера + Lua + стек TCP/IP + WEB-сервер).
Надо же, а мне казалось, что Бердяев писал достаточно доходчиво... Ладно, поясню по рабоче-крестьянски, в двух словах, о чем это его эссе.
Бердяев говорит о том, что искусство, которое мы любим называть "вечным", принципиально должно быть идейно направлено за пределы материального бытия. Искусство, имеющее цель, принадлежащую познаваемому, обречено на деградацию. Грубо говоря, такой аналог теоремы Гёделя. По этой причине, кстати, "натурализм" поныне противопоставляется искусству. Отсюда и рассуждения о Боге - это классическая абстракция непознаваемого. Но я понимаю, что на атеиста упоминание Бога действует слишком возбуждающе и мешает воспринимать все остальное. :)
Еще проще: можно создать великое произведение о любви, но нельзя - о сексе. Не получится. По этой причине и порнография классически не относится к высокому искусству.
Что же до причин Возрождения, то в наши дни, например, ресурсов еще больше, но что-то второго Ренессанса мы не наблюдаем, такие дела. Наоборот, в текущих условиях рост количества ресурсов приводит к стагнации искусства, и Бердяев поясняет, почему.
Напомню, что знаменитый квадрат Малевича - изначально декорация к спектаклю "Победа над солнцем". В этом контексте он и имеет смысл, как полное противопоставление круглому и яркому солнцу.
Вне контекста спектакля он смысла, конечно же, не имеет.
Сам спектакль очень показателен. Это, в сущности, сама по себе наглядная демонстрация того, что получится, если до конца пройти по дороге морального и философского релятивизма.
Рекомендуемое чтиво на тему:
Николай Бердяев, "Конец Ренессанса" - это попроще, о том, что не так с современным искусством и почему так получилось
Владимир Мартынов - "Конец времени композиторов" - эта книжка сильно сложнее и исследует вопрос конкретно применительно к музыке, зато гораздо глубже.
Ну, трудности от слабого освещения несколько преувеличены. :) Как я уже писал выше, основная проблема, особенно при использовании доступных устройств, не собственно низкий или высокий уровень освещения, а динамический диапазон. Обязательно нужно сделать так, чтобы как минимум то, что представляет интерес, было верно экспонировано.
В этом смысле на улице снимать гораздо труднее, чем в помещении, поскольку, особенно при ярком солнце, контраст в большинстве случаев будет превышать возможности камеры, и с этим крайне сложно что-то сделать. Профессионалы в таких случаях используют отражатели для снижения контраста в тенях, или даже мощные лампы, которые способны соревноваться с солнцем в освещенности.
Кстати лично мне больше нравится формат статей, а не видео. Но тема видеосъемки/аудиозаписи интересна мне в хоббийном плане, причем более всего я упираю на выжимание максимума из самых простых устройств. Потому поговорить об этом я всегда готов. :)
Вот насчет того, что превращать хобби в работу прекрасно, утверждение явно неоднозначное. :)
Лично для меня хоббийная деятельность характерна тем, что ей можно заниматься только тогда, когда хочется, и столько, сколько хочется. А если не хочется - можно не заниматься вовсе.
Работа же отличается тем, что ей приходится заниматься, потому что иначе будет не на что жить, вне зависимости от наличия желания и вдохновения. Потому такая деятельность зачастую бывает в тягость.
Стоит ли рисковать удовольствием от дела, переводя его в коммерческое русло? Каждый решает для себя.
Ну, во-первых, уговаривал автора снимать видео не я. :) Я только поделился опытом.
Во-вторых это сложный вопрос, на самом деле. Если заранее продумать расстановку камер в мастерской, то проблемы неудачного угла съемки не будет - мастерская, в отличие от динамичного уличного видео, ограниченное пространство.
Но вообще конечно да, видео отнимает больше времени. Хотя, с другой стороны, создание хорошей статьи тоже дело небыстрое.
На самом деле, практически любая, начиная от камеры телефона. Единственно только, чем проще камера, тем меньше возможностей в пост-обработке, потому больше внимания придется уделять освещению и компоновке кадра.
Сразу скажу, что для камер телефона, экшен-камер и прочих аппаратов с физически малой матрицей наиболее актуальна проблема динамического диапазона, потому, чтобы получить хорошее видео на такой прибор, нужно прежде всего озаботиться равномерным освещением, без серьезных теней и слишком ярко освещенных участков. С зеркальными фотоаппаратами в режиме съемки видео все проще, с профессиональными кинокамерами - еще проще. :)
Если будете что-то говорить в кадре, обязательно озаботьтесь петличным микрофоном (можно беспроводным). Без него звук будет очень так себе.
Из бесплатных видеоредакторов могу порекомендовать Shotcut.
Очень интересно, чем не угодили разработчики. Так-то, упоминаемый Кулибин как раз был в современном понимании разработчиком; а кто под разработчиком понимается тут?
Собственно, самое простое определение инженера/разработчика - это человек, результат труда которого можно потрогать; ну там, фен, стиральную машину, телевизор. Программист - не инженер, хотя их почему-то часто так называют. Хотя, конечно, способности к инженерии и программированию могут уживаться в одном человеке. Как правило, это характерно для специалистов по встроенным системам. Девопс, естесственно, тем более не инженер, если только это не "девопс" АСУТП.
В прочем, я уже давно в курсе, что инженеры - это люди, о которых мало что знают. Пожалуй, мы видим очередное подтверждение этого факта. Впрочем хорошо, что само понятие идет в массы.
Ооо! Ооо! Распаковать что ли свои запасы ATtiny10... Страшно сказать, я их лет пять назад покупал поиграться, и вот все никак руки пока не дошли...
Зато я в рамках работы применял "новые" серии, ATtiny2xx. Очень приятные чипы, мне понравились.
Подход, достойный Ардуино. :)))
Нет. Нормальная схема должна гарантированно обеспечить штатный режим. Так что в данном случае резистор - самый адекватный выход. Городить что-то более серьезное смысла тут нет.
А версия AVR-GCC, которую вы использовали, уже научилась не копировать константы в RAM при таком их объявлении?
Классически, чтобы читать константы из FLASH, не копируя их в RAM, надо было использовать avr/pgmspace.h и макрос PROGMEM.
Или вы сознательно решили пожертвовать частью RAM, чтобы не тратить FLASH на код загрузки из FLASH (pgm_read_xxx)?
Пробовать отладочные платы надо с осциллографом на столе и макеткой рядом, а то и паяльником в руках.
Кстати, если вы так настаиваете, я тоже перейду на личности и спрошу — а вы сами далеко ушли от Arduino? Похоже нет.
То, что наличие дополнительной обработки ошибок лучше, чем ее отсутствие, не очевидно?
Переход на аргументы ad hominem плохо сочетается с перечисленными добродетелями. :)
В реальном мире никогда не будет идеальных условий эксплуатации — просто примите это. Причем чем специфичнее применение, тем условия, как правило, тяжелее. И программа, по-возможности, должна если и не спасать положение целиком, то хотя бы минимизировать финальный ущерб. Это достигается не только программными средствами, конечно; критичные функции всегда защищаются аппаратно, насколько это возможно.
Кстати, от выбивания битов в памяти не имунна полностью и «правильная» по вашему мнению элементная база. Да, в технологии с диэлектрическими подложками тиристорного эффекта не будет, но вероятность повреждения памяти заряженными частицами все равно есть. Предлагаете делать на лампах? Вот они да, 100% защищены от всех эффектов.
Сразу скажу, что свинцовая или какая-то другая защита не спасет. Попадание частицы с космическим уровнем энергии в материал вызывает лавину вторичных частиц, что усугубляет проблему. Как видите, есть много нюансов.
Жизнь сложна и многообразна; защищаться воплями «ЭТО НАРУШЕНИЕ ПРАВИЛ ЭКСПЛУАТАЦИИ ВЫ САМИ ВИНОВАТЫ!!!1111» — так себе вариант. Надо предполагать работу аппаратуры и в нештатных условиях. В том числе и не предусмотренных ТЗ, но вероятных, в том числе и в результате возможного раздолбайства.
Эээ, вам написать switch, в котором в блоке default осуществляется вызов обработчика ошибки?
Статическое объявление всего — вообще первая особенность программирования под железо. Во-первых, в 90% случаев отсутствует ОС, так что по умолчанию следить за памятью нечему, а реализации менеджера памяти в стандартной библиотеке не слишком оптимальны. При этом действительно хорошая реализация malloc() может занимать места столько же, сколько вся программа.
Ну и я уже не говорю о том, что выделение памяти, действительно, недетерминированная операция; нет никакой гарантии, что в нужный момент окажется доступным нужный объем памяти.
Лучше перебдеть.
Хехе, сразу видно программиста не-железячника.
Программа тут не при чем. Может прилететь частица и изменить бит в памяти (нормальная ситуация для аппаратуры на спутниках), может случиться скачок/просадка напряжения и повредить участок FLASH/EEPROM (например, если BOD настроен неверно и запись в NVM прошла при нештатном напряжении) или область RAM, может быть повреждена линия к внешней микросхеме памяти, и еще куча вариантов.
Это самый простой способ отловить неожиданное значение.
2. Память контроллера, не поверите, может быть испорчена в рантайме. Или даже не память — некорректное значение может прийти через USART, например.
Вкратце: не всегда switch делается по членам enum'а.
Склоняюсь к тому, что это просто дело вкуса. Но лично мне в темной теме сложнее сфокусироваться на нужных элементах, и вообще глаз хуже адаптируется.
В тех системах, с которыми работаю я, MPU обычно нет. :)
Может тогда уж лучше TCL? :)
Lua кстати — самый шустрый и легковесный вариант для таких случаев. По работе делал примерно то же самое, что описано в статье, для местного испытательного комплекса. Только у нас там еще и самописный WEB-сервер (сеть через Ethernet). Все вместе занимает 144380 байт во флеше STM32F429 (FreeRTOS + драйвера + Lua + стек TCP/IP + WEB-сервер).