Если бы в них не было смысла, их бы не выпускали. :) Они полезны для случаев повышенной рассеиваемой мощности, где SMD уже не потянут (скажем, мощные токовые шунты), или повышенной нагрузки по напряжению (резисторы на «горячей» стороне ИП), и так далее…
Для сравнения: SMD0805 держит максимум 200 В, одноваттный углеродный — до 500 В.
Во-первых, система, помимо сбора статистики, управляет силовыми ключами. Частота коммутации там, конечно, не мегагерцы, но пара килогерц наверняка есть. Даже в таком случае, учитывая масштабы мощностей, софт должен реагировать на происходящее в силовом каскаде в течение микросекунд. Если, скажем, сразу два ключа в плече моста окажутся открыты, то в таком применении выгорит все, сразу и очень феерично.
Далее. Важна даже не столько скорость реакции, сколько предсказуемость времени отклика; это ключевое требование, предъявляемое к RTOS. Такая предсказуемость позволяет верно спроектировать аппаратную защиту в расчете на самый худший случай. Пускай система реагирует за 1 мс, но она должна всегда реагировать за 1 мс, а не так, как десктопный Linux — если повезет, за 100 мкс, а если не повезет — за две секунды.
Ну и конечно, надежность. Причем начиная с уровня плат. Там кто-то выше писал про сварку — нет никакой гарантии, что как раз таки дешевый одноплатник, ориентированный на потребительский рынок, не начнет сбоить в условиях промышленных помех. Там упор на технологичность и удешевление в условиях массового производства, а здесь требуется прежде всего надежность и долговечность.
Есть и еще масса причин — одноплатники строятся на основе печатных плат с большим количеством слоев (в Raspberry Pi — не меньше шести слоев), а чем больше слоев в плате, тем у нее хуже дела с устойчивостью к термоциклированию и вибрациям; в потребительской электронике часто не выполняют помехоустойчивую трассировку линий тактирования и т.п.
может быть можно какую-нибудь распберри с переходником влепить?
Разве только как плеер, чтобы кино водителю показывать в перерыв.
Linux (тем более тот, который стоит в таких изделиях) не относится к RTOS, не говоря уже о том, что его код никто не тестировал на соответствие MISRA (и скорее всего он таки не соответствует этому стандарту). Кроме того, такие громадные ОС избыточно сложны. Ошибки в них — обычное дело. Исправить их все — нереально, при этом, разумеется, никто не может гарантировать, что в какой-то момент они не сложатся так, что подвесят систему. При этом зависание такой системы неизбежно выльется в самый настоящий, физический бабах на сотни тысяч рублей.
Так что нет. Ну и не говоря уже о том, что сам по себе процессор одноплатника не подходит для таких задач по причине отсутствия нужной периферии в нужном количестве.
Как по мне, место расположения правительства страны, например, — вполне себе объект повышенной секретности. Музей, в котором хранятся экспонаты, стоимость которых сложно даже вообразить, может быть и не секретен, но перестраховаться все равно не помешает. И т.п. Потому странно удивляться тому, что в некоторой окрестности таких мест ощущаются все признаки работы специального оборудования, а обижаться на это и вовсе глупо.
При этом надо отметить, что невозможно сделать так, чтобы в радиусе, например, 300 метров от антенны РЭБ ее влияние достигало цели, а на расстоянии 301 метр вся электроника сразу работала как ни в чем ни бывало. Мало того, эффективный радиус покрытия зависит и от погоды, и от местности с учетом ее текущих изменений (грузовик припарковался, скажем, и т.п.). При этом логичная цель — сделать так, чтобы в пределах тех же умозрительных 300 метров, которые нам важны, обеспечить стопроцентное подавление в любых условиях, а что там будет за расчетными границами — как повезет. Вполне вероятно, что в типичных условиях выдаваемой мощности хватит не на 300 метров, а на два километра, что гораздо больше чем надо; но если расчеты показывают, что могут существовать ситуации, в которых именно такая мощность понадобится на 300 метров, выдавать будут именно ее. На всякий случай. И это разумно.
Не говоря уже об использовании глушилок и прочих спецсредств
Ага. А как только государство начинает использовать «глушилки и прочие спецсредства» в целях обеспечения безопасности (better safe, than sorry, знаете ли), ревнители свободы тут же вопят про «затягивание гаек» и ужасный тоталитаризм.
Как написано в книге Экклесиаста, «и это уже было». Я пытался вывести нечто такое еще два года назад.
Увы, большинство уверено в том, что «карандашного теста» и наблюдения камерой смартфона вполне хватает (хотя в той статье я писал, почему это не так).
Не последнюю роль сыграло и то, что упомянутый в статье коллега, который вроде бы выражал желание инвестировать в проект, в решающий момент превратился в тыкву. В общем, не знаю, вернусь ли я еще к этой теме.
В данном случае — не сказал бы. Там по условию задачи требуется полоса всего 5 кГц, при этом даже встроенные АЦП в популярных микроконтроллерах сегодня могут работать на скоростях до 1 MSPS. Тут не то что просто упростить аналоговую часть за счет увеличения частоты дискретизации, тут можно и передискретизацию устроить, чтобы поднять разрешение бита на два-три, а то и больше.
Noise Shaping работает в процессе квантования и связан с передискретизацией. По простому: если на более высокой частоте дискретизации отфильтровать шум, а после снизить частоту дискретизации (проредив данные), то можно получить увеличение разрядности за счет увеличения соотношения сигнал/шум. Так работают сигма-дельта АЦП.
К слову о субтитрах. Мне они никогда не помогали… В какой-то момент (довольно скоро) после начала просмотра я просто начинаю читать их и отключаюсь от речи. А еще и от действия на экране отвлекает.
Так что я просто смотрел (и смотрю, это интересно) обычные, никак не адаптированные, ролики на YouTube. Сначала мне было понятно, условно, 30%, или, может быть, около того. Остальное понимал по контексту. Со временем я понимал все больше, больше и больше. На данный момент в роликах типа такого я понимаю на слух более 90%, а где говорят помедленнее — там совсем проблем нет.
Новые слова можно вбивать на слух в google-переводчик — если что, он подскажет верный вариант написания. Заодно вырабатывается чувство орфографии языка.
Вывод: мощное средство изучения языка (причем чуть ли не любого) совсем рядом. Поначалу, конечно, тяжко смотреть ролик, в котором почти не понимаешь речь, но если перетерпеть это время, результат не заставит себя ждать. Главное — найти интересную для себя тему.
Может хоть вы покажете, чем придется платить в приведенном C++ном коде?
Ну так, для этого надо раздобыть компилятор с поддержкой C++11 хотя бы для AVR или на худой конец Cortex, написать тестовую программу, дизассемблировать ее и посмотреть.
Покажите мне компилятор с хорошей поддержкой C++11 хотя бы для какой-нибудь встроенной архитектуры, и будем сравнивать. Я не знаю такого.
динамической памяти
Динамическое выделение памяти прямо запрещается MISRA.
Понятное дело, нельзя жаловаться, что один инструмент не приспособлен для другого. :)
и теперь сами же обобщаете правила кода для STM8 на всю область
Я лишь о том, что решать задачи надо минимально необходимыми средствами, чтобы код (хотя бы не привязанный к железу напрямую) работал на максимальном количестве платформ. Иначе может быть очень обидно, когда нужная библиотека существует, и вроде бы в плане ресурсоемкости самого алгоритма должна бы работать на целевом чипе, но написана на языке/диалекте, который не поддерживается используемым компилятором, и потому требует правки, сравнимой с переписыванием.
я так понимаю, что вы для STM8 разрабатываете?
Я разрабатываю, в зависимости от необходимости, для STM8, MSP430, AVR и STM32, иногда с привлечением CPLD Altera. :)
Справедливости ради, прямо сейчас у меня на столе лежит плата, относящаяся к текущему проекту, и выполнена она на основе STM32F051R8T6.
вроде IAR для STM8 вполне себе может C++.
Только вы знаете, сколько стоит IAR? :) А вот Cosmic и SDCC бесплатны.
Понятное дело, что для хобби разницы в, э-э-э, некотором смысле, нет, но когда это продукт, то лучше использовать официально бесплатные инструменты.
В некотором смысле да. Мной «усиливают» в плане разработки электроники команду, состоящую из специалистов в предметной области (физиология/физика). Они понимают, что нужно сделать, а я — как. :) Разумеется, разработкой занимаюсь не я один; кроме меня есть конструкторы механики, это отдельные люди; при необходимости к нам присоединяются программисты Android и т.д. Но схемы/платы/прошивки электроники на мне.
Да, забыл сказать. Я тоже практикую распечатывание на бумаге макета платы в размере 1:1 и примерку критичных (или тех, которые использую впервые) компонентов. Выглядит не супер-профессионально, зато такой способ, при своей простоте, может сэкономить деньги на перезаказе плат. :)
Ну, это мы говорим об элементарных примерах. Но да, можно вообразить себе архитектуру, компилятор для которой не поддерживает даже #define. И вот там придется использовать числа в коде.
Здесь же код обсуждается, а не заблуждения на счет того, что считается embedded, а что нет.
Самый главный признак «embedded» в том, что там уже нельзя обсуждать сферический код в вакууме. Сразу возникают вопросы — для какой архитектуры, для какого конкретно компилятора, что там с поддержкой прерываний и пр.
Ну возьмите компилятор, который поддерживает C++11.
Покажите мне компилятор для, например, STM8, который поддерживает C++11, и будем сравнивать. Пока я не знаю, где такой взять. :)
Создание электрических схем и трассировка печатных плат становятся всё более простыми делами.
Распространение такого мнения не может не пугать. «Копипаст решения от производителя» и «разработка уникального устройства» — немного разные по сути задачи.
Так что фразу следует читать так: «сегодня все больше задач получают готовые решения, которые достаточно всего лишь аккуратно скопировать».
А как вы проверяете свои платы?
Поскольку у меня не стоит задача разрабатывать триста шестьдесят пять устройств в год (решения в основном штучно-специального плана), я даю каждому проекту «вылежаться» дня три перед тем, как отправлять его в производство, даже если к концу всех проверок непосредственно после окончания трассировки стопроцентно уверен, что ошибок нет. Далее снова проверяю плату. Если мне все еще кажется, что ошибок нет, то отправляю ее в производство.
А так все стандартно — DRC, ERC, проверка соответствия платы схеме, проверка электрического соединения цепей, ручная проверка топологии.
Если бы в них не было смысла, их бы не выпускали. :) Они полезны для случаев повышенной рассеиваемой мощности, где SMD уже не потянут (скажем, мощные токовые шунты), или повышенной нагрузки по напряжению (резисторы на «горячей» стороне ИП), и так далее…
Для сравнения: SMD0805 держит максимум 200 В, одноваттный углеродный — до 500 В.
Далее. Важна даже не столько скорость реакции, сколько предсказуемость времени отклика; это ключевое требование, предъявляемое к RTOS. Такая предсказуемость позволяет верно спроектировать аппаратную защиту в расчете на самый худший случай. Пускай система реагирует за 1 мс, но она должна всегда реагировать за 1 мс, а не так, как десктопный Linux — если повезет, за 100 мкс, а если не повезет — за две секунды.
Ну и конечно, надежность. Причем начиная с уровня плат. Там кто-то выше писал про сварку — нет никакой гарантии, что как раз таки дешевый одноплатник, ориентированный на потребительский рынок, не начнет сбоить в условиях промышленных помех. Там упор на технологичность и удешевление в условиях массового производства, а здесь требуется прежде всего надежность и долговечность.
Есть и еще масса причин — одноплатники строятся на основе печатных плат с большим количеством слоев (в Raspberry Pi — не меньше шести слоев), а чем больше слоев в плате, тем у нее хуже дела с устойчивостью к термоциклированию и вибрациям; в потребительской электронике часто не выполняют помехоустойчивую трассировку линий тактирования и т.п.
Разве только как плеер, чтобы кино водителю показывать в перерыв.
Linux (тем более тот, который стоит в таких изделиях) не относится к RTOS, не говоря уже о том, что его код никто не тестировал на соответствие MISRA (и скорее всего он таки не соответствует этому стандарту). Кроме того, такие громадные ОС избыточно сложны. Ошибки в них — обычное дело. Исправить их все — нереально, при этом, разумеется, никто не может гарантировать, что в какой-то момент они не сложатся так, что подвесят систему. При этом зависание такой системы неизбежно выльется в самый настоящий, физический бабах на сотни тысяч рублей.
Так что нет. Ну и не говоря уже о том, что сам по себе процессор одноплатника не подходит для таких задач по причине отсутствия нужной периферии в нужном количестве.
Не надо расти в плане бюрократии, ее и так везде хватает. :) Просто работайте. :)
При этом надо отметить, что невозможно сделать так, чтобы в радиусе, например, 300 метров от антенны РЭБ ее влияние достигало цели, а на расстоянии 301 метр вся электроника сразу работала как ни в чем ни бывало. Мало того, эффективный радиус покрытия зависит и от погоды, и от местности с учетом ее текущих изменений (грузовик припарковался, скажем, и т.п.). При этом логичная цель — сделать так, чтобы в пределах тех же умозрительных 300 метров, которые нам важны, обеспечить стопроцентное подавление в любых условиях, а что там будет за расчетными границами — как повезет. Вполне вероятно, что в типичных условиях выдаваемой мощности хватит не на 300 метров, а на два километра, что гораздо больше чем надо; но если расчеты показывают, что могут существовать ситуации, в которых именно такая мощность понадобится на 300 метров, выдавать будут именно ее. На всякий случай. И это разумно.
Ага. А как только государство начинает использовать «глушилки и прочие спецсредства» в целях обеспечения безопасности (better safe, than sorry, знаете ли), ревнители свободы тут же вопят про «затягивание гаек» и ужасный тоталитаризм.
Увы, большинство уверено в том, что «карандашного теста» и наблюдения камерой смартфона вполне хватает (хотя в той статье я писал, почему это не так).
Не последнюю роль сыграло и то, что упомянутый в статье коллега, который вроде бы выражал желание инвестировать в проект, в решающий момент превратился в тыкву. В общем, не знаю, вернусь ли я еще к этой теме.
Так что я просто смотрел (и смотрю, это интересно) обычные, никак не адаптированные, ролики на YouTube. Сначала мне было понятно, условно, 30%, или, может быть, около того. Остальное понимал по контексту. Со временем я понимал все больше, больше и больше. На данный момент в роликах типа такого я понимаю на слух более 90%, а где говорят помедленнее — там совсем проблем нет.
Новые слова можно вбивать на слух в google-переводчик — если что, он подскажет верный вариант написания. Заодно вырабатывается чувство орфографии языка.
Вывод: мощное средство изучения языка (причем чуть ли не любого) совсем рядом. Поначалу, конечно, тяжко смотреть ролик, в котором почти не понимаешь речь, но если перетерпеть это время, результат не заставит себя ждать. Главное — найти интересную для себя тему.
Ну так, для этого надо раздобыть компилятор с поддержкой C++11 хотя бы для AVR или на худой конец Cortex, написать тестовую программу, дизассемблировать ее и посмотреть.
Покажите мне компилятор с хорошей поддержкой C++11 хотя бы для какой-нибудь встроенной архитектуры, и будем сравнивать. Я не знаю такого.
Динамическое выделение памяти прямо запрещается MISRA.
Я лишь о том, что решать задачи надо минимально необходимыми средствами, чтобы код (хотя бы не привязанный к железу напрямую) работал на максимальном количестве платформ. Иначе может быть очень обидно, когда нужная библиотека существует, и вроде бы в плане ресурсоемкости самого алгоритма должна бы работать на целевом чипе, но написана на языке/диалекте, который не поддерживается используемым компилятором, и потому требует правки, сравнимой с переписыванием.
Я разрабатываю, в зависимости от необходимости, для STM8, MSP430, AVR и STM32, иногда с привлечением CPLD Altera. :)
Справедливости ради, прямо сейчас у меня на столе лежит плата, относящаяся к текущему проекту, и выполнена она на основе STM32F051R8T6.
Только вы знаете, сколько стоит IAR? :) А вот Cosmic и SDCC бесплатны.
Понятное дело, что для хобби разницы в, э-э-э, некотором смысле, нет, но когда это продукт, то лучше использовать официально бесплатные инструменты.
Это уже к m08pvv, например. :) Должен признать, что я не специалист в теории внутренней работы компиляторов.
Да, забыл сказать. Я тоже практикую распечатывание на бумаге макета платы в размере 1:1 и примерку критичных (или тех, которые использую впервые) компонентов. Выглядит не супер-профессионально, зато такой способ, при своей простоте, может сэкономить деньги на перезаказе плат. :)
Да я прочел. Правда, меня берут сомнения в том, что можно сделать компилятор C++11 для устройства с тридцатью двумя байтами RAM и килобайтом FLASH.
Самый главный признак «embedded» в том, что там уже нельзя обсуждать сферический код в вакууме. Сразу возникают вопросы — для какой архитектуры, для какого конкретно компилятора, что там с поддержкой прерываний и пр.
Покажите мне компилятор для, например, STM8, который поддерживает C++11, и будем сравнивать. Пока я не знаю, где такой взять. :)
Распространение такого мнения не может не пугать. «Копипаст решения от производителя» и «разработка уникального устройства» — немного разные по сути задачи.
Так что фразу следует читать так: «сегодня все больше задач получают готовые решения, которые достаточно всего лишь аккуратно скопировать».
Поскольку у меня не стоит задача разрабатывать триста шестьдесят пять устройств в год (решения в основном штучно-специального плана), я даю каждому проекту «вылежаться» дня три перед тем, как отправлять его в производство, даже если к концу всех проверок непосредственно после окончания трассировки стопроцентно уверен, что ошибок нет. Далее снова проверяю плату. Если мне все еще кажется, что ошибок нет, то отправляю ее в производство.
А так все стандартно — DRC, ERC, проверка соответствия платы схеме, проверка электрического соединения цепей, ручная проверка топологии.
Те, например, для кого SDCC — не «а что это такое?», а суровая реальность.