ХЗ чего тут на эти митапы желчь извергают.
Для меня эти разработки тоже ничего сложного и интересного не представляют, но проблемы для себя не вижу. Смотреть посты, а тем более ходить никто не заставляет.
С такой позиции задрота, который может хоть как-то поддерживать самооценку опуская менее опытных людей, захейтить вообще все что угодно можно.
Не могу полностью согласится, я считаю, что тут дело в опыте и квалификации, и всех грести под одну гребенку я бы не стал. Если условный «Эмбеддер», к примеру, может понимать ассемблер для отлова багов, знать си для средних и мелких проектов, а также уметь в с++ для крупных (то бишь разрабатываемыми приличной командой), знает особенности архитектуры контроллера и именно встраиваемого программирования, понимает принципы RTOS(по необходимости), разбирается как в схемотехнике, так и в корректной трассировке плат, то почему бы и не совмещать эти роли. Тогда, это совсем не обязательно будет мелкая поделка. Очевидно, вышеописанный специалист всегда найдет себе работу с адекватными требованиями и соответствующей оплатой труда.
Очень полезная подборка, буду ждать подборку зарубежных.
У меня недавно был очень неприятный опыт общения с Чипом и Дипом. После сделанного и оплаченного на сайте заказа, где все позиции указывались как «доставка на следующий день», заказ застрял на этапе сборки на 3! недели. Но суть проблемы не в этом, с начала второй недели я каждый день по нескольку раз пытался дозвониться до менеджера моего заказа, и никто не брал трубку. Звонки по общему номеру ничего не давали, оттуда перенаправляют к твоему менеджеру, с обещаниями все передать изнутри и якобы менеджер позвонит вам. В итоге на третьей неделе полного игнора (напомню, что заказ уже был оплачен) начал искать в сети, и оказалось я совсем не один такой, яндекс отзывы забиты похожими случаями. В итоге, после того как я оставил там отзыв, мне позвонили, извинились, и все уладили.
Довольно грустно, что решить вопрос напрямую не представляется возможным, а только через публичные площадки, которые прямого отношения к магазину не имеют.
Справедливости ради, до этого случая периодически делал заказы, проблем и нареканий не возникало.
Почитал еще комментарии и хочу дополнить свой ответ. Я заметил, что вы смотрите на МК как на комплекс:
мьютексов, семафоров, очередей, и обеспечивать быструю работу с динамической памятью
Только дело в том, что это все понятия более высокого уровня абстракции, к реальному МК отношение не имеющие и придуманные человеком для решения определенных задач.
Возможно, если просто посмотреть на МК под углом того, что там есть хардварно, то может и окажется, что вашей системе, как и подавляющему большинству, это совершенно не требуется.
Полно вам, это же мегабайты оперативки нужны только на стеки, у микроконтроллеров редко бывает столько. И где может быть задача контроля «сотен алгоритмических процессов», которых нельзя кинуть на рабочую очередь?
Я и написал в последнем абзаце, что такие задачи на МК обычно не решаются.
ОС оправдана, когда мы хотим развязать отдельные модули устройства, не превращая его в запутанный клубок.
И при чем тут ОС? Никто не мешает НЕ делать запутанный клубок и без нее, ОС — НЕ панацея.
Если у вас не атомарная запись/чтение величин, то думать придется. Видите ли, даже голый МК с прерываниями — уже не «однопоточная» система. Голый МК без прерываний тоже может быть не однопоточной системой, поскольку периферия тоже умеет делать что-то сама по себе.
Есть понятие о том, что такое DMA и как именно оно работает? Понимае того, как именно чтение и запись раскладываются на ассемблере на Cortex, и что реально происходит в МК при прерывании? Осведомленность о «внутреядерной» возможности битовых масок практически для всей используемой периферии и SRAM? Это все к тому, что замечание не к месту, без понимаю сути процессов обсуждать нету смысла.
Потому что 90% статей по ембедедду рассматривают совершенно неправдивые примеры. RTOS применяют когда у нас есть несколько классов задач, выполнение которых явно важнее других задач. Грубо говоря, «RTOS» можно сделать на контроллере прерываний (NVIC), с включенным вытеснением прерываний. Но программная обертка над планировщиком будет поудобнее, нежели ручной контроль приоритетов и порядка выполнения.
Вот тут плюс. Тоже хотел бы посмотреть на реальную систему подобного рода, в которой RTOS реально спаситель, а не просто прихоть программиста.
Это говорит лишь о том, что желательно просто снижать частоту поступающих на CPU событий. Использование/неиспользование RTOS тут ничего не решает. Опять же, никто не заставляет на каждый чих заводить по отдельному потоку.
Тоже, что и вопросе про атомарность, переходы используются далеко не только в потоках, когда будет понимание того, как часто они используются- вопрос сам отпадет.
Счастливые разработчики, которым не приходится вникать в архитектуру процессора и системы, в которой они работают. Я таких среди своих коллег не знаю.
Вопрос в уровне «вкуривания». Я не говорю, что нужно задротить абсолютно любую мелочь, но когда ты знаешь все реальные процессы, происходящие в твоем МК, разрабатывать ПО становиться много легче.
Но даже при смене вендора внезапно оказывается, что периферия порой кардинально отличается (а в случае с ST, так и между сериями), так что процесс ее изучения начинается с начала.
А вот и нет. Контроллеры очень похожи между собой, в т.ч. и разные ядра(даже на просто си именно ядро ты вообще почти не видишь). Отлично зная одно, без труда освоишь и другое. Также, когда постоянно копаешься в даташитах, найти что-то нужное в новом — легко. и еще, После STM32f2xx структура периферии устоялась, например, перетаскивая CAN1&2 и USB, я просто скопировал модули и получил рабочую систему…
С Cortex M3 на Cortex M3 — это не «перелазить».
И ради чего это придирка? Я такого и не писал. Могу также ответить: Если для тебя это новость, то даже у STM32 ядро не только CORTEX-M3.
Если решить задачу можно без RTOS и это будет приемлемо по срокам, сложности, требованиям по масштабируемости и времени реакции, то выбор будет в пользу этого решения.
В том и суть, что распространено мнение, что FreeRTOS и ей подобные системы делают построение архитектуры системы удобнее, быстрее и проще. Но если потратить столько же времени на освоение архитектуры МК, то разница будет несущественной.
Написать код без RTOS, который бы учитывал приоритетность задач, синхронизировал доступ к ресурсам и т.п. можно, но это требует большего профессионализма, нежели, чем использование возможностей, предоставляемых RTOS
Я не совсем понимаю вопрос по приоритетам. А какой смысл в вашем примере учитывать приоритет задач. Что поменяется, если при нажатии кнопки вы потратите, допустим 5 миллисекунд на уже выполняемые задачи и затем по очереди попадете в обработку кнопки?
Но на определенном этапе может быть вынужденной необходимостью. Вряд ли с первого раза получится сделать «хорошо» без соответствующего опыта.
Я тоже думаю, что с первого раза не получится сделать так. Но если же не начать так делать, то никогда не получится.
По части ресурсов, насколько я понимаю, та же FreeRTOS не сильно прожорливая, планировщик, если верить статьям занимает порядка 250 байт в ОЗУ, задача — 64 байта плюс ее стэк.
По поводу прожорливости по памяти, я сделал такой вывод, так как все проекты, что мне попадали с OS были раз как минимум раз в 15-20 больше по объему памяти. Если то, что вы написали правда, то это действительно пустяки, и этот минус я для себя снял, спасибо.
Всегда приятно читать статьи подобного рода, фундаментально и все по полочкам, и я уверен, найдется куча людей кому это будет полезно, но в целом я не считаю такой подход правильным и вот почему:
Говоря о подходе, я имею ввиду выбор в пользу использование ОС на STM32 и других Cortex. Использование ОС может быть оправдано, когда количество задач переваливает за несколько сотен. И я тут говорю о более менее алгоритмически объемных задачах, а не просто записать какую-либо настройку в регистр.
Мне сложно представить проект, где использование той же FreeRTOS обеспечит реальное преимущество в скорости и тайминге, конечно при условии должного знания архитектуры используемого процессора, языка программирования (в том числе и ассемблера) и уровне оптимизации -O3. Зато повсеместно встречаются обратные примеры, когда вся многозадачность, к примеру, заключается лишь в считывании входов (цифра), выдаче результата на выходы и передаче по какому нибудь интерфейсу, с навешанными OS и HAL, конечно же без оптимизации как таковой.
Например, в статье описано, что на изменение состояния кнопки нужно реагировать максимально быстро. А это сколько? Даже запихнув все задачи из статьи последовательно в while(1) общее время выполнения цикла едва ли превысит несколько миллисекунд, это много меньше времени механического нажатия. На кнопку же, если это принципиально, можно просто поставить EXTI да и все.
По базе данных реального времени. Я бы просто выделил структуру/массив, а все возможные перемещения данных повесил бы на DMA, и думать о перемещении, распределении, достоверности и целостности не приходится вообще.
Основное заявляемое преимущество RTOS в том, что она может выполнять задачи строго нужное время по приоритетам. Но с ней код разбухает (имею ввиду количество машинных инструкций), и это теряет смысл, так как грамотно написав код напрямую, можно добиться гораздо лучших результатов вообще об этом не думая учитывая что перечисленные задачи в статье не имеют строгой привязки ко времени. Также не стоит забывать, что команды безусловных и условных переходов нарушают конвейерность процессора fetch/decrypt/execute, что при каждом вызове задачи и куче добавочных переходов в целом, превращает один такт в три.
В общем, я считаю что гораздо профитнее курить саму архитектуру процессора и научиться грамотно использовать ее фичи. Это принесет и другие плюсы, разработка любой неизвестной ранее периферии будет все проще и быстрее, а также, вопреки расхожему мнению, будет легко перебраться, например, с STM на LPC или Infenion.
И замечу, что я не против ОС вообще и на серьезных проектов использование ее рационально, но серьезные проекты требуют настоящих процессоров, а 99.9% того, что реализуют на МК Cortex Mx даже профессиональные разработчики, совсем не подходит под это и в частности приведенном в статье примере я не вижу оснований для использования ОС.
Для меня эти разработки тоже ничего сложного и интересного не представляют, но проблемы для себя не вижу. Смотреть посты, а тем более ходить никто не заставляет.
С такой позиции задрота, который может хоть как-то поддерживать самооценку опуская менее опытных людей, захейтить вообще все что угодно можно.
У меня недавно был очень неприятный опыт общения с Чипом и Дипом. После сделанного и оплаченного на сайте заказа, где все позиции указывались как «доставка на следующий день», заказ застрял на этапе сборки на 3! недели. Но суть проблемы не в этом, с начала второй недели я каждый день по нескольку раз пытался дозвониться до менеджера моего заказа, и никто не брал трубку. Звонки по общему номеру ничего не давали, оттуда перенаправляют к твоему менеджеру, с обещаниями все передать изнутри и якобы менеджер позвонит вам. В итоге на третьей неделе полного игнора (напомню, что заказ уже был оплачен) начал искать в сети, и оказалось я совсем не один такой, яндекс отзывы забиты похожими случаями. В итоге, после того как я оставил там отзыв, мне позвонили, извинились, и все уладили.
Довольно грустно, что решить вопрос напрямую не представляется возможным, а только через публичные площадки, которые прямого отношения к магазину не имеют.
Справедливости ради, до этого случая периодически делал заказы, проблем и нареканий не возникало.
Только дело в том, что это все понятия более высокого уровня абстракции, к реальному МК отношение не имеющие и придуманные человеком для решения определенных задач.
Возможно, если просто посмотреть на МК под углом того, что там есть хардварно, то может и окажется, что вашей системе, как и подавляющему большинству, это совершенно не требуется.
Я и написал в последнем абзаце, что такие задачи на МК обычно не решаются.
И при чем тут ОС? Никто не мешает НЕ делать запутанный клубок и без нее, ОС — НЕ панацея.
Есть понятие о том, что такое DMA и как именно оно работает? Понимае того, как именно чтение и запись раскладываются на ассемблере на Cortex, и что реально происходит в МК при прерывании? Осведомленность о «внутреядерной» возможности битовых масок практически для всей используемой периферии и SRAM? Это все к тому, что замечание не к месту, без понимаю сути процессов обсуждать нету смысла.
Вот тут плюс. Тоже хотел бы посмотреть на реальную систему подобного рода, в которой RTOS реально спаситель, а не просто прихоть программиста.
Тоже, что и вопросе про атомарность, переходы используются далеко не только в потоках, когда будет понимание того, как часто они используются- вопрос сам отпадет.
Вопрос в уровне «вкуривания». Я не говорю, что нужно задротить абсолютно любую мелочь, но когда ты знаешь все реальные процессы, происходящие в твоем МК, разрабатывать ПО становиться много легче.
А вот и нет. Контроллеры очень похожи между собой, в т.ч. и разные ядра(даже на просто си именно ядро ты вообще почти не видишь). Отлично зная одно, без труда освоишь и другое. Также, когда постоянно копаешься в даташитах, найти что-то нужное в новом — легко. и еще, После STM32f2xx структура периферии устоялась, например, перетаскивая CAN1&2 и USB, я просто скопировал модули и получил рабочую систему…
И ради чего это придирка? Я такого и не писал. Могу также ответить: Если для тебя это новость, то даже у STM32 ядро не только CORTEX-M3.
В том и суть, что распространено мнение, что FreeRTOS и ей подобные системы делают построение архитектуры системы удобнее, быстрее и проще. Но если потратить столько же времени на освоение архитектуры МК, то разница будет несущественной.
Я не совсем понимаю вопрос по приоритетам. А какой смысл в вашем примере учитывать приоритет задач. Что поменяется, если при нажатии кнопки вы потратите, допустим 5 миллисекунд на уже выполняемые задачи и затем по очереди попадете в обработку кнопки?
Я тоже думаю, что с первого раза не получится сделать так. Но если же не начать так делать, то никогда не получится.
По поводу прожорливости по памяти, я сделал такой вывод, так как все проекты, что мне попадали с OS были раз как минимум раз в 15-20 больше по объему памяти. Если то, что вы написали правда, то это действительно пустяки, и этот минус я для себя снял, спасибо.
Говоря о подходе, я имею ввиду выбор в пользу использование ОС на STM32 и других Cortex. Использование ОС может быть оправдано, когда количество задач переваливает за несколько сотен. И я тут говорю о более менее алгоритмически объемных задачах, а не просто записать какую-либо настройку в регистр.
Мне сложно представить проект, где использование той же FreeRTOS обеспечит реальное преимущество в скорости и тайминге, конечно при условии должного знания архитектуры используемого процессора, языка программирования (в том числе и ассемблера) и уровне оптимизации -O3. Зато повсеместно встречаются обратные примеры, когда вся многозадачность, к примеру, заключается лишь в считывании входов (цифра), выдаче результата на выходы и передаче по какому нибудь интерфейсу, с навешанными OS и HAL, конечно же без оптимизации как таковой.
Например, в статье описано, что на изменение состояния кнопки нужно реагировать максимально быстро. А это сколько? Даже запихнув все задачи из статьи последовательно в while(1) общее время выполнения цикла едва ли превысит несколько миллисекунд, это много меньше времени механического нажатия. На кнопку же, если это принципиально, можно просто поставить EXTI да и все.
По базе данных реального времени. Я бы просто выделил структуру/массив, а все возможные перемещения данных повесил бы на DMA, и думать о перемещении, распределении, достоверности и целостности не приходится вообще.
Основное заявляемое преимущество RTOS в том, что она может выполнять задачи строго нужное время по приоритетам. Но с ней код разбухает (имею ввиду количество машинных инструкций), и это теряет смысл, так как грамотно написав код напрямую, можно добиться гораздо лучших результатов вообще об этом не думая учитывая что перечисленные задачи в статье не имеют строгой привязки ко времени. Также не стоит забывать, что команды безусловных и условных переходов нарушают конвейерность процессора fetch/decrypt/execute, что при каждом вызове задачи и куче добавочных переходов в целом, превращает один такт в три.
В общем, я считаю что гораздо профитнее курить саму архитектуру процессора и научиться грамотно использовать ее фичи. Это принесет и другие плюсы, разработка любой неизвестной ранее периферии будет все проще и быстрее, а также, вопреки расхожему мнению, будет легко перебраться, например, с STM на LPC или Infenion.
И замечу, что я не против ОС вообще и на серьезных проектов использование ее рационально, но серьезные проекты требуют настоящих процессоров, а 99.9% того, что реализуют на МК Cortex Mx даже профессиональные разработчики, совсем не подходит под это и в частности приведенном в статье примере я не вижу оснований для использования ОС.