Какие есть фундаментальные труды по этому направлению? Интересует не как помигать светодиодом или записать что-нибудь в регистр, а какие существуют архитектуры приложений, с какими распространёнными проблемами можно встретиться, почему код нужно писать в таком стиле, а не в другом. До этого момента прочитал "Test-Driven Development for Embedded C" и "Design Patterns for Embedded Systems in C".
Здравствуйте, cppguard, Вы писали:
C>Какие есть фундаментальные труды по этому направлению? Интересует не как помигать светодиодом или записать что-нибудь в регистр, а какие существуют архитектуры приложений, с какими распространёнными проблемами можно встретиться, почему код нужно писать в таком стиле, а не в другом. До этого момента прочитал "Test-Driven Development for Embedded C" и "Design Patterns for Embedded Systems in C".
Иди поработай в ЦНИИ РТК, за несколько месяцев прочувствуешь всё
Здравствуйте, cppguard, Вы писали:
C>Какие есть фундаментальные труды по этому направлению? Интересует не как помигать светодиодом или записать что-нибудь в регистр,
Сомневаюсь, что есть что-то фундаментальное по этой теме, потому что embedded — это просто встроенное решение, разновидность компа внутри технической системы.
Соответственно, это очень технарская тема, и теорию она берет из общей теории по архитектуре вычислительных систем, просто со своими требованиями (тот или иной алгоритм планирования задач, те или иные стандарты отрасли по техническому исполнению, не только железо, но и например DSL для разработки прикладного ПО).
С технарской т.з. все сводится к тому, что вот например, есть процессор, а есть память, они соединены шиной, и шина не просто какая-то десктопная, а например ARM'овская AMBA.
Или вот есть ОС, но она ни венда, ни POSIX, а РТОС со своим API.
Или вот есть компилятор gcc, но по умолчанию он генерит ELF для исполнения в толстой ОС, а нам надо без RTTI, без стандартной библиотеки и еще с заданной явно картой сегментов, эмуляцией FPU и проч.
А главный фундамент там связан с предметной областью, из которой уже логически вытекают возможные архитектуры. А области очень разные. Одно дело проверять код от дверного замка и совсем другое — двигать манипулятором робота.
>а какие существуют архитектуры приложений,
В общем случае такие же, как и везде.
В простейшем случае примитивный цикл: читаем значения датчиков, прогоняем итерацию вычислений, пишем контрольное действие в актуаторы, повторяем пока солнце не поджарит Землю со всей ее техникой.
>с какими распространёнными проблемами можно встретиться,
слишком общий вопрос. Основная проблема — сложнее организовать тестирование и отладку, потому что ваша вычислительная подсистема может быть частью сложной и дорогой системы от заказчика.
Предусмотрел заказчик симуляторы/фейки/прототипы для тестированя — хорошо, нет — будете на каждый чих к нему идти на поклон.
Сложнее организовать диагностику проблем, т.к. продвинутое журналирование может быть затруднено (недопустимое влияние на производительность, всякие аспекты ИТ-безопасности и проч.) или например, система контролирует технологический процесс, и ее нельзя просто взять и перезагрузить, чтобы проверить изменения, потому что остановка агрегатов — процесс нетривиальный и иногда может привести к их физической порче.
>До этого момента прочитал "Test-Driven Development for Embedded C" и "Design Patterns for Embedded Systems in C".
надо еще понять, сколько там от именно по "Embedded", может быть, просто пару предложений, а остальное — обычный C.
Лет 15 назад понравился на эту тему Жан-Жак Лабросс, автор RTOS μC/OS, μC/OS II и μC/OS III.
Kнига "μC/OS: The Real-Time Kernel".
Существует, соответственно, тоже в трёх переизданиях.
Вторая лежит совершенно свободно, выскакивает даже в гугле на первой же странице выдачи.
Полистайте, и если ляжет душа, то покупайте последнее издание.
Тематика более высокоуровневая, нежели моргание диодиком и ногодрыжество портами, а именно задачи, потоки, диспетчеризация, schedul'инг, ресурсы, приоритеты, критические секции, блокировки и т.д, и запихивание всего вышеперечисленного в микроскопические камни. Соответственно, если читать одновременно и книгу, и исходники одноимённой ОСРВ, то вышеупомянутые понятия предстают перед читателем не просто красивыми абстракциями, непонятно как внутри реализованными, а вполне себе во всех деталях, кишочками наружу
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Тематика более высокоуровневая, нежели моргание диодиком и ногодрыжество портами, а именно задачи, потоки, диспетчеризация, schedul'инг, ресурсы, приоритеты, критические секции, блокировки и т.д, и запихивание всего вышеперечисленного в микроскопические камни. Соответственно, если читать одновременно и книгу, и исходники одноимённой ОСРВ, то вышеупомянутые понятия предстают перед читателем не просто красивыми абстракциями, непонятно как внутри реализованными, а вполне себе во всех деталях, кишочками наружу
Можно Рихтера про Win32 почитать, там про всё то же, только специфика виндовая. Или Стивенса — там специфика юниксовая. А в эмбеде — это всё обычно нах не нужно, пробовали FreeRTOS — отказались, гемора на порядок больше, чем пользы. В эмбеде основная проблема — поднять периферию, можно месяц трахаться, пытаясь её заставить работать, глаза вытекают на тысячестраничные даташиты, а оно не работает из-за какой-нибудь тупой фигни, которую проглядел, или, что ещё веселее, аппаратной особенности/бага в аппаратуре, про который надо было искать в эррата (но далеко не факт, что оно там есть).
Навскидку, например, я вроде SBUS поднимал, это инвертированный UART, но там вроде четность. Ну ока, поднимал на STM32 UART в режиме 8 бит + бит четности. Не работало. На макете, который нам дали на RPI — всё работало с настройками UART 8бит+бит четности. Долго парился, на помощь были подняты корифеи работы с STM. Оказалось в итоге, что у STM32 битность при настройке UART — это биты данных плюс бит четности, а не биты данных и отдельно есть/нет бит четности — если внимательно читать даташит, то это можно было заметить. Но вот не заметили. Или, не я парился, ещё до меня — у Миландра прерывания по UARTу возникает до того, как приходит последний бит данный, и там был хороший трах с этим потерянным битом. Это не вспоминая про всякие шины типа SPI/I2C/CAN/etc, и не вспоминая, что по этим шинам могут быть подключены самые разнообразные микрухи, которые сами по себе мозготрахательные. Была какая-то микруха — LED драйвер — 100500 режимов работы с 7/8/9-сегментными интикаторами, вот я затрахался, чтобы просто отдельными светодиодами управлять. Зато она удобная (типа) — сама всё умеет, и всего три линии MCU занимает по SPI. Ха-ха-ха-ха, это электронщики решили, что нам, программистам, будет проще с ней, а не через GPIO MCU работать.
Короче, у эмбедера обычно совсем другие проблемы, которые обычному человеку понять сложно
В эмбеде ОС если и нужна, то только на уровне абстракции от железа в виде какой-то прослойки типа драйверов периферии, чтобы с ней работать переносимо, и чтобы она сразу работала, без траха. Остальное нах не нужно
M>Можно Рихтера про Win32 почитать, там про всё то же, только специфика виндовая. Или Стивенса — там специфика юниксовая.
В том-то всё и дело, что после Рихтера остается впечатление понимания этих сущностей "по верхам", в виде непрозрачных чёрных ящиков.
M>А в эмбеде — это всё обычно нах не нужно, пробовали FreeRTOS — отказались, гемора на порядок больше, чем пользы.
На это есть разные мнения. Я тоже лет 15 назад, когда увлёкся ARM–микроконтроллерами и сделал пяток заказов, почитал-почитал про uC/OS и Freertos, да и забил. Для малых проектов сложности было больше, чем пользы, однако бывалые люди поговаривают, что с ростом сложности это не так.
M>В эмбеде основная проблема — поднять периферию, можно месяц трахаться, пытаясь её заставить работать, глаза вытекают на тысячестраничные даташиты, а оно не работает из-за какой-нибудь тупой фигни, которую проглядел, или, что ещё веселее, аппаратной особенности/бага в аппаратуре, про который надо было искать в эррата (но далеко не факт, что оно там есть).
О дааа, это правда. Помимо errata есть ещё такой увлекательный процесс, как отладка осциллографом и логическим анализатором
Здравствуйте, zx zpectrum, Вы писали:
M>>Можно Рихтера про Win32 почитать, там про всё то же, только специфика виндовая. Или Стивенса — там специфика юниксовая. ZZ>В том-то всё и дело, что после Рихтера остается впечатление понимания этих сущностей "по верхам", в виде непрозрачных чёрных ящиков.
А сильно оно надо, копать в глубину в этом вопросе?
M>>А в эмбеде — это всё обычно нах не нужно, пробовали FreeRTOS — отказались, гемора на порядок больше, чем пользы. ZZ>На это есть разные мнения. Я тоже лет 15 назад, когда увлёкся ARM–микроконтроллерами и сделал пяток заказов, почитал-почитал про uC/OS и Freertos, да и забил. Для малых проектов сложности было больше, чем пользы, однако бывалые люди поговаривают, что с ростом сложности это не так.
Я 4 года занимался контроллерами, коллеги — вообще лет по 10 в этом. Проекты были не маленькие. В итоге все решили, что никакая ОС не нужна
ZZ>О дааа, это правда. Помимо errata есть ещё такой увлекательный процесс, как отладка осциллографом и логическим анализатором
Это хорошо ещё, если оно есть Осцилы у нас были, а вот про лог анализаторы до меня народ то ли не знал, то ли забыл Я эту тему пробил, народ был в восторге
M>Навскидку, например, я вроде SBUS поднимал, это инвертированный UART, но там вроде четность. Ну ока, поднимал на STM32 UART в режиме 8 бит + бит четности. Не работало. На макете, который нам дали на RPI — всё работало с настройками UART 8бит+бит четности. Долго парился, на помощь были подняты корифеи работы с STM. Оказалось в итоге, что у STM32 битность при настройке UART — это биты данных плюс бит четности, а не биты данных и отдельно есть/нет бит четности — если внимательно читать даташит, то это можно было заметить. Но вот не заметили. Или, не я парился, ещё до меня — у Миландра прерывания по UARTу возникает до того, как приходит последний бит данный, и там был хороший трах с этим потерянным битом.
Как раз те самые случаи, когда можно до посинения читать ДШ с errata'ми, и пропустить нужное (если оно вообще там есть), а можно взять осциллограф (ЛА, если линий на шине больше двух), сесть на шину, и шустренько нащупать отличие в рабочей референс-плате и многострадальной своей.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Как раз те самые случаи, когда можно до посинения читать ДШ с errata'ми, и пропустить нужное (если оно вообще там есть), а можно взять осциллограф (ЛА, если линий на шине больше двух), сесть на шину, и шустренько нащупать отличие в рабочей референс-плате и многострадальной своей.
Так устройство шлёт одни и те же данные, а вот демка на RPI их принимает, а у меня в STMку какой-то мусор валится. Чем тебе осцил поможет?
M>Я 4 года занимался контроллерами, коллеги — вообще лет по 10 в этом. Проекты были не маленькие. В итоге все решили, что никакая ОС не нужна
Живой пример: SDK для ESP8266 и ESP32 вертится поверх FreeRTOS. Удачи, как говорится, её нафиг выбросить и раскидывать, с нуля и врукопашную, таймслоты между WiFi/Bluetooth и пользовательскими задачами. Понятно, что оно, при большом желании, теоретически решаемо, вопрос только в уровне головняка.
Здравствуйте, zx zpectrum, Вы писали:
M>>Я 4 года занимался контроллерами, коллеги — вообще лет по 10 в этом. Проекты были не маленькие. В итоге все решили, что никакая ОС не нужна ZZ>Живой пример: SDK для ESP8266 и ESP32 вертится поверх FreeRTOS. Удачи, как говорится, её нафиг выбросить и раскидывать, с нуля и врукопашную, таймслоты между WiFi/Bluetooth и пользовательскими задачами. Понятно, что оно, при большом желании, теоретически решаемо, вопрос только в уровне головняка.
КА — это не так сложно. И отлаживать гораздо удобнее, чем многопоточку, особенно на железке. Я и говорю, наш совет эльфов посовещался, и решил, что без всяких ОС головняка гораздо меньше. Пичаль, конечно, если ОС вкорячена в SDK конкретной железки, тут да, либо есть кактус с этой ОС, либо выдирать нужное и ручками колхозить
M>КА — это не так сложно. И отлаживать гораздо удобнее, чем многопоточку, особенно на железке. Я и говорю, наш совет эльфов посовещался, и решил, что без всяких ОС головняка гораздо меньше.
Ну да, настоящему индейцу вообще ничего не надо, кроме графа конечных автоматов, общающихся друг с другом через неблокирующие очереди Впрочем, без вытеснений любой ринг-буферный FIFO автоматически становится неблокирующим без лишних костылей синхронизации. Однако, WiFI и Bluetooth дюже развесисты в протокольном плане, и обуздать экспоненциальный взрыв количества состояний будет непросто. Это вам не какие-нибудь UART и SPI. Второй контр-довод: с КА происходит вырождение от вытесняющей многозадачности до кооперативной, и необходимо будет держать под контролем тайминги шагов исполнения каждого КА: разделяемая радиосреда опозданий не прощает.
Здравствуйте, zx zpectrum, Вы писали:
ZZ>Второй контр-довод: с КА происходит вырождение от вытесняющей многозадачности до кооперативной, и необходимо будет держать под контролем тайминги шагов исполнения каждого КА: разделяемая радиосреда опозданий не прощает.
Это не проблема. Большую часть времени MCU молотит пустой цикл, все реакции на внешние воздействия обрабатываются быстро, на колхозном ElapsedTimer'е можно легко делать микросекундные задержки, если самому автоматы писать лениво, можно корутины заюзать, для этого есть библиотеки на макросах, которые псевдопотоки даже для сишечки предоставляют.
При всей кажущейся сложности это всё равно отлаживать проще, чем многозадачность
Здравствуйте, Marty, Вы писали:
M>это всё равно отлаживать проще, чем многозадачность
Чем проще-то? Простейший многозадачный монитор не делает ничего, кроме переключения контекстов — там даже стек можно не переключать, всю информацию держать в структуре контекста, а если многозадачность сугубо кооперативная, то держать на стеке только то, что не жаль потерять при переключении. Зато не нужно плодить 100500 состояний и помнить все варианты переходов между ними — если поток оказался в какой-то точке, его предыстория сразу видна по этому месту и контексту.
Здравствуйте, cppguard, Вы писали:
C>Какие есть фундаментальные труды по этому направлению?
Из фундаментального лучше почитать литературу по разработке драйверов/загрузчиков лет 60-70-х. Там и про особенности работы с аппаратурой, и про экономию ресурсов, и про отсутствие удобного высокоуровневого окружения, и про сложности отладки. К программированию для ранних МК все это применимо в полной мере, а для современных многое уже не актуально — возможностей и ресурсов стало сильно больше, народ разбаловался. Но для общего развития таки полезно.
Здравствуйте, Евгений Музыченко, Вы писали:
M>>это всё равно отлаживать проще, чем многозадачность
ЕМ>Чем проще-то? Простейший многозадачный монитор не делает ничего, кроме переключения контекстов — там даже стек можно не переключать, всю информацию держать в структуре контекста, а если многозадачность сугубо кооперативная, то держать на стеке только то, что не жаль потерять при переключении. Зато не нужно плодить 100500 состояний и помнить все варианты переходов между ними — если поток оказался в какой-то точке, его предыстория сразу видна по этому месту и контексту.
Предысторию я по логам вижу — у каждой большой платы я заставил наших электронщиков делать отладочный UART, в который сру логами. Даже если нет лишнего UART'а, STMки через отладчик позволяют срать текстом, хотя там большие объемы хуже пролазят. Мелкие автоматы для работы с перифкой один раз отлажены и работают. А бизнес-логику жирной платы отлаживаешь по логам. Вполне себе ничего получается. Вытесняющая многозадачность вносит ещё кучу проблем, которые и на большом компе отлаживать сложно, а у IDE под МК вобще нет никаких средств вспомогательных, они про ОС внутре ничего не знают. А кооперативная многозадачность — так её без ОС легко сделать — берёшь какой-нибудь PROTOTHREADS и пожалуйста. Никакая ОС не нужна
Здравствуйте, Marty, Вы писали:
M>А кооперативная многозадачность — так её без ОС легко сделать — берёшь какой-нибудь
Так я именно про кооперативную, ее и без "какого-нибудь" сделать элементарно.
По сути, вытесняющая нужна только там, где какие-то потоки могут заниматься вычислениями столь долго, что более другие потоки начинают голодать. Это возможно только в программах "расчетного" типа, завязанных на обработку данных, или в неправильно сделанных программах управления. В правильно организованных управляющих программах расчеты или сами по себе скромны, или вынесены в аппаратуру, которая выполняет их быстро. Так что реакция на любое событие сводится к недолгой обработке поступивших данных и ожидании следующего, а это и при вытесняющей, и при кооперативной многопоточности работает одинаково. Кооперативной ничто не мешает тоже использовать приоритеты, несколько очередей ожидания и все остальное.
Здравствуйте, cppguard, Вы писали:
C>Какие есть фундаментальные труды по этому направлению?
Embedded он большой и трудоёмкий, я думаю, общих трудов очень мало.
Тут надо определиться какая область embedded (FPGA, Firmware для микроконтроллеров, RTOS, Embedded Linux) нужна, и там уже искать литературу.
Здравствуйте, Евгений Музыченко, Вы писали:
M>>А кооперативная многозадачность — так её без ОС легко сделать — берёшь какой-нибудь
ЕМ>Так я именно про кооперативную, ее и без "какого-нибудь" сделать элементарно.
Вообще-то, мы тут дискутируем о том, нужна ли ОС в эмбеде или нет. А что ты хочешь сказать, я так и не понял
