Ну, мне кажется когда говорят «защита о перегрузок», то так же имеет ввиду что, в случае работы этой защиты, не страдают связанные в целевым объектом вещи. А в таком виде, это больше вредительство чем защитная мера.
Даже Ваш эксперимент с бутылкой, показал, что на нить (путь это будет кран и трос), в случаи срабатывания «защиты», прикладывается гораздо большая сила, чем в рабочем режиме. Последствия очевидны.
Еще раз, это не упрек именно в Вашу сторону, но «защитой» я бы это не называл.
Такой редуктор защищён от перегрузок… Магнитный редуктор просто провернётся и не сломается
Судя по результату на видео, недостаток превозносится, как преимущество.
Я имею ввиду сила направлена, в обратную сторону, при превышении нагрузки. Естественно все зависит от юзкейса. Но скажем, если это какая то линия подачи, то последствия непредсказуемы.
Как решение, возможно использовать большее количество магнитов, для того что бы уменьшить рабочий угол поворота каждого из них, а так же нужны компенсаторы.
Очень хотелось бы увидеть в свободной доступе инструмент для компиляции qt исходников из embedded edition, ибо простыня флагов не спасает, когда нужны определенные опции (не спасает из за отсутствия информации, что и когда можно отключить, особенно для linux, с его x11)
Предварительно я изучил вопрос о том, что нужно для создания движка на C, и, похоже, удобным для работы SDL будет Emscripten
странно, а почему автор cocos2d-x не попытается использовать?
Вобще, использовать монстров вроде unity/UE для 2d пиксельной прыгалки мне кажется не очень разумно… ровно как и ныть на поломанный там кем-то плагин, и не в состоянии его починить/написать, но заявлять что «щас я тут напишу вам правильный игровой движек»… или я не прав?
В частности, есть же box2d, opengl, да и тот же cocos как обертка вокруг всех этих вещей. Зачем заново что то изобретать? Получается какой-то критики пост.
В контексте «изучение микроконтроллеров» IDE и все ее инструменты, таки должны быть как можно проще… Вы же при чтении книг не начинаете со статей «устройство печатного станка»?
В целом, я никоим образом не говорю что против данных курсов, просто их ценность очень близка к «Курсам программиста/тестировщика за 10 дней в твоем городе».
Даже за 8 занятий, можно очень грамотно изложить материал: в меньшей мере настройка блокнота и make, в большей — целевой материал.
это вы так назвали единственный вызов make и ручное редактирование одного Makefile
И вызов MakeFile и какой то дебаг (ну да, он же не нужен), а завтра студент захочет вынести свой модуль в отдельный файл и опять редактируй файлы. Зачем заранее ограничивать людей в инструментах?
И в тоже время: Вот вам абстрактная ОС, зачем вам знать что такое цикл обработки, и программные счетчики?
Я в меньшей мере хочу показать насколько, уж простите, ущербный данный курс. Я пытаюсь у Вас (именно у Вас) спросить — чему вы хотите обучить студентов?
Использование ОС не обучит студентов грамотному подходу к работе с МК и его периферией. Более того, приняв это за догму, они будут отрицать все нормальные подходы.
И тогда: Если работа под ОС на МК не отличается, от обычного прикладного программирования, зачем тогда по сути вобще нужны эти контроллеры? Просто обучайте людей программировать… хотите ножек/светодиодов. Дайте людям Raspberry и обучайте — суть от этого не изменится, знания будут эквивалентны.
По поводу «практичности» (в противовес академичности) вашего курса, мне кажется, куда более лучше научить студентов использовать периферию в связи ADC+DMA, SPI+кольцевые буферы, и все это в контексте вашего МК (L151). Таким образои, они поймут в каких задача и что нужно использовать, а главное ПОЧЕМУ. И вот тогда, венцом вашей работы будет.."… теперь мы подошли к тому моменту, когда у нас 100500 обработчиков аппаратных и программных, куча вложенных прерываний и шанс что мы в этом запутаемся, поэтому давайте ознакомимся с ОС и проблемами которые они решают".
Людям, не нужна как вы выразились практичность, людям нужна доступность, и понимание «зачем это все» (вспомните себя на уроках геометрии/математики в школе), и вот когда они поймут зачем, они без вас смогут это использовать на практике.
ЗЫ. Выше подметили статьи от ДиХальта: посмотрите с чгео он начинает — с проблематики, и только потом решение.
Одна из причине, почему мы будем работать с RIOT OS и без использования каких-либо средств разработки (IDE) — в получающем в последнее время всё большее распространение магическом мышлении.
Перевернули с ног на голову. IDE — это плохо, будем корячиться в cmd. ОС это хорошо нам же не важно что там внутри МК.
(Собеседование на хардварщика)
— здравствуйте, реализуйте пожалуйста минимальный невытесняющий диспетчер задач для МК, используя только один аппаратный счетчик.
— хз о чем вы, я только умею использовать тип Tasks из <name_os> и программный таймер.
urllib — встроенная библиотека, поставляется вместе с интерпретатором python. request — внешняя зависимость, которую нужно установить, и в данном случае (один единственный GET запрос), как мне кажется совершенно не оправдана.
Если мне не изменяет память, то экспорт DLL функций в Python, разрешается только для C-extern объявления.
Можно получить немножко больше профита, если использовать SIP библиотеку, из недостатков в два раза больше правок в заголовках (для SIP нужны свои заголовочные файлы), из плюсов — нативный вызов в python коде, в виде export модуля.
Если я правильно понимаю вопрос, у Юнити есть свой редактор анимаций и скелетных и тайловых, правда не знаю есть ли там еффекты растягивания/сжатия изображений базовых (как на видео с крылом)
Даже Ваш эксперимент с бутылкой, показал, что на нить (путь это будет кран и трос), в случаи срабатывания «защиты», прикладывается гораздо большая сила, чем в рабочем режиме. Последствия очевидны.
Еще раз, это не упрек именно в Вашу сторону, но «защитой» я бы это не называл.
Судя по результату на видео, недостаток превозносится, как преимущество.
Я имею ввиду сила направлена, в обратную сторону, при превышении нагрузки. Естественно все зависит от юзкейса. Но скажем, если это какая то линия подачи, то последствия непредсказуемы.
Как решение, возможно использовать большее количество магнитов, для того что бы уменьшить рабочий угол поворота каждого из них, а так же нужны компенсаторы.
Что сказали то и указал… импортозамещение во всей красе)
А мне кажется это больше преимущество, нежели недостаток.
Как в противовес можно сопоставить python flask и django.
Если так как Вы говорите, то да, печально.
и захотел каких то подробностей.
Неужто бизнес настолько подгонял что не было времени вставить reCAPTCHA?
странно, а почему автор cocos2d-x не попытается использовать?
Вобще, использовать монстров вроде unity/UE для 2d пиксельной прыгалки мне кажется не очень разумно… ровно как и ныть на поломанный там кем-то плагин, и не в состоянии его починить/написать, но заявлять что «щас я тут напишу вам правильный игровой движек»… или я не прав?
В частности, есть же box2d, opengl, да и тот же cocos как обертка вокруг всех этих вещей. Зачем заново что то изобретать? Получается какой-то критики пост.
В целом, я никоим образом не говорю что против данных курсов, просто их ценность очень близка к «Курсам программиста/тестировщика за 10 дней в твоем городе».
Даже за 8 занятий, можно очень грамотно изложить материал: в меньшей мере настройка блокнота и make, в большей — целевой материал.
И вызов MakeFile и какой то дебаг (ну да, он же не нужен), а завтра студент захочет вынести свой модуль в отдельный файл и опять редактируй файлы. Зачем заранее ограничивать людей в инструментах?
И в тоже время: Вот вам абстрактная ОС, зачем вам знать что такое цикл обработки, и программные счетчики?
Я в меньшей мере хочу показать насколько, уж простите, ущербный данный курс. Я пытаюсь у Вас (именно у Вас) спросить — чему вы хотите обучить студентов?
Использование ОС не обучит студентов грамотному подходу к работе с МК и его периферией. Более того, приняв это за догму, они будут отрицать все нормальные подходы.
И тогда: Если работа под ОС на МК не отличается, от обычного прикладного программирования, зачем тогда по сути вобще нужны эти контроллеры? Просто обучайте людей программировать… хотите ножек/светодиодов. Дайте людям Raspberry и обучайте — суть от этого не изменится, знания будут эквивалентны.
По поводу «практичности» (в противовес академичности) вашего курса, мне кажется, куда более лучше научить студентов использовать периферию в связи ADC+DMA, SPI+кольцевые буферы, и все это в контексте вашего МК (L151). Таким образои, они поймут в каких задача и что нужно использовать, а главное ПОЧЕМУ. И вот тогда, венцом вашей работы будет.."… теперь мы подошли к тому моменту, когда у нас 100500 обработчиков аппаратных и программных, куча вложенных прерываний и шанс что мы в этом запутаемся, поэтому давайте ознакомимся с ОС и проблемами которые они решают".
Людям, не нужна как вы выразились практичность, людям нужна доступность, и понимание «зачем это все» (вспомните себя на уроках геометрии/математики в школе), и вот когда они поймут зачем, они без вас смогут это использовать на практике.
ЗЫ. Выше подметили статьи от ДиХальта: посмотрите с чгео он начинает — с проблематики, и только потом решение.
Перевернули с ног на голову. IDE — это плохо, будем корячиться в cmd. ОС это хорошо нам же не важно что там внутри МК.
— хз о чем вы, я только умею использовать тип Tasks из <name_os> и программный таймер.
Это пример, хорошего превентивного отношения к кандидатам, или шутка?
Можно получить немножко больше профита, если использовать SIP библиотеку, из недостатков в два раза больше правок в заголовках (для SIP нужны свои заголовочные файлы), из плюсов — нативный вызов в python коде, в виде export модуля.