Для начала определитесь что у вас за устройство (slave/master).
Не вижу смысла тащить на slave (какой нить датчик например) даже мини компьютер, те что бы это плохо или хорошо, просто это избыточно. Плюс, все миниплатники подразумевают Linux — опять таки, зачем какой-то розетке все это?
Далее выберите wireless стек, с которым вам хочется/удобно/дешево/доступно работать. BLE/Wifi/zigBi — у всех этих технологий есть свое предназначение, и соответсвенно плюсы/минусы.
Что касаемо именно mcu, это могут быть практически любые MK, которые Вас не стесняют, и достаточно популярны/просты. Не хочу показаться хейтером, но я бы взял ARM-based типа STM, в противовес AVR например или тем же MSP430.
В случае с wireless+mcu, недавно вот заказал BLE nRF52832, так как с esp-стеком бороться уже не было сил. Что касается wifi то есть rtl8710, более дорогие и качественнее серия CC от TI.
По сути — дело вкуса и принципов, esp взлетела только из-за своей цены, по этому, народ и начал на ней клепать все что не попадя
Никаких, учитывая что чип esp8266.
Если есть выбор — перейти на более «нормальный» чип wifi+mcu (mt/rtl/cc), либо использовать BLE например (который как бы для этого и разрабатывался), но по видимому этот вариант Вам не подойдет.
Спасибо за подробны ответ.
То есть получается, ничего не мешает использовать ноутбучные, 15 дюймовые квадратики (типа флетрон) матрицы, для своих поделок? Они ведь так же LVDC совместимы.
Вы увидите, что поднимать сложную периферию на регистрах так же просто, как и обычный SPI
Та ну, некоторым и c GPIO сложно работать без RTOS.
Позвольте поинтересоваться, получается в данном случае, мы ограничены, в плане размера дисплея, лишь размером frame-buffer? Или частоты работы LTDS так же имеет значение?
Не слишком ли много пафоса?
Вроде тех. ресурс, а ощущения что на 4pda в обзоры попал. Лучше бы рассказали, о трудностях/сложностях, которые повстречали на своем пути.
За программу спасибо.
Я если честно, даже не сразу обратил внимание, а когда обратил — не сразу понял, что именно меня привлекло, то что сожжено энергии, или таки что размерность в Ваттах, а не в Джоулях)
Ну, мне кажется когда говорят «защита о перегрузок», то так же имеет ввиду что, в случае работы этой защиты, не страдают связанные в целевым объектом вещи. А в таком виде, это больше вредительство чем защитная мера.
Даже Ваш эксперимент с бутылкой, показал, что на нить (путь это будет кран и трос), в случаи срабатывания «защиты», прикладывается гораздо большая сила, чем в рабочем режиме. Последствия очевидны.
Еще раз, это не упрек именно в Вашу сторону, но «защитой» я бы это не называл.
Такой редуктор защищён от перегрузок… Магнитный редуктор просто провернётся и не сломается
Судя по результату на видео, недостаток превозносится, как преимущество.
Я имею ввиду сила направлена, в обратную сторону, при превышении нагрузки. Естественно все зависит от юзкейса. Но скажем, если это какая то линия подачи, то последствия непредсказуемы.
Как решение, возможно использовать большее количество магнитов, для того что бы уменьшить рабочий угол поворота каждого из них, а так же нужны компенсаторы.
Очень хотелось бы увидеть в свободной доступе инструмент для компиляции 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 модуля.
Если я правильно понимаю вопрос, у Юнити есть свой редактор анимаций и скелетных и тайловых, правда не знаю есть ли там еффекты растягивания/сжатия изображений базовых (как на видео с крылом)
STM32F103RBT6 — $10.37 STM32F303RBT6 — $8.45
F3 серия, понемногу вытесняет F1, в ценовом плане, имея примерно ту же производительность, и периферию.
F1 популярны, за счет того, что в свое время на них было написано тонна инфы и туториалов от сообщества, а человек по своей сути ленив, и не желает изучать/пробовать что то новое более лучшее.
Те кто плотно занимается этим вопросом, давно забыли об этой линейке, или используют F0 или F2/4.
Для «wireless» разработчиков, так же есть STM32WB, судя по документации, весьма годный продукт для IoT и т.п.
Да. Видео из разряда:
— Я сел в машину, нажал на педаль газа и она не едет
— Но вы же не включили зажигание, и передачу не выбрали
— Я нажал на педаль газа и она не едет.
Показательное, но мораль только одна — RTFM
Что такое rm0080 я не в курсе.
Проблема определенно в этом, а не в том, что длинная ерата в МК.
Мои слова, адресованы не конкретно вам, а всем тем, которые думают, что все МК одинаковы, и подход к ним такой же. Но это не так. Более того, никогда и нигде не будет «так как в ардуино» потому что ардуино — это подход к программированию МК, а не сам МК, и их сравнивать просто глупо.
А насчет ераты, я вот уже достаточно много всяких безделушек кодил под 103-ю линейку, и еще ни разу не стыкался с вопросом, который бы вел меня в ерата. Чаще всего дело именно во мне.
епрст… да какая головная боль? Ну возьмите голый PIC/AVR/MSP430 там не такая головная боль? О чем сравнение то?
ST вам дает за 3уе:
— борду
— отладчик/флешер
— халявную среду для конфигурации( не вкурсе о ПО для других камней), ее хотя бы можно юзать для подбора МК по пиреферии и понимании что есть в МК и даже можно нагенерить write-only кода, если что то понадобилось «на вчера».
И в замен на это, просит всего лишь открыть и почитать RM0080, что бы не выглядеть невежей но нет же.
У меня ардуино головного мозга.
натулим в while побольше кода, и задержек не забудем сказать что все сложно не очевидно/неправильно/глупо.
Насчет ераты:
Уже миллиарды разов было освещено что 10х серия — это первая линейка arm от st, и что она действительно была не особо удачна, в сравнении скажем с L-параллельными или более старшими.
ЗЫ. Доставило 13-ти (sic!!) минутное видео о том, что надо включать serial debug.
Странно что АРМ ядро, почему то у многих ассоциируется с продукцией STM, есть например такое вот. Такой же специализированный продукт, на известном ядре)
Может Вам стоит как то более логично закончить статью? Ну, там выделить какие то отличии, подчеркнуть в статье вещи, которые Вы вынесли в заголовок, ну, если они действительно как-то особо рассматриваются в Вашей статье (API, ionic). Километры исходников можно было не выкладывать — у Вас есть ссылка на гит хаб, кто в «теме» поймет без комментариев, кто не очень — пройдет мимо.
Я не хочу негативно высказываться, но «о чем Ваша статья»? Что я должен вынести для себя после прочтения ее? Что появился какой то очередной кросс-велосипед для моб. сегмента. Так этим никого не удивишь. Ни метрик, ни сравнений (хотя бы с аналогичным нативным).
Печально в общем…