Самые вредные методы встраиваемых систем?

Ответ 1

• Неинициализированные векторы исключений (вы знаете, для тех, которые "никогда не будут достигнуты" )
• Скажите это со мной: глобальные переменные. Особенно те, которые разделяют между ISR и задачами (или передними циклами) без защиты.
• Невозможно использовать "летучие", если это необходимо.
• Имея подпрограммы DisableInterrupts(), а затем EnableInterrupts() в паре. Понял? Не RestoreInterrupts(), но ENABLE. Да, гнездование.
• Нет GPIO для переключения при тестировании.
• Нет контрольных точек на борту.
• Нет индикаторов или последовательного порта для просмотра состояния системы во время выполнения.
• Нет измерения того, как занят/не работает процессор.
• Использование встроенной сборки для всех, кроме самых тяжелых случаев. Напишите краткую выноску.
• Использование для (i = 0; я < 1000; я ++) {} для "задержки бит". Да, это тебя не укусит сто разными способами.
• Не использовать const везде, чтобы сохранить RAM и уменьшить время загрузки (без копирования/инициализации переменных)

У меня есть тонна больше, но это должно заставить нас начать...

Ответ 2

Кто-то остановит меня, прежде чем я навредил себе.

Кстати, я понимаю, что не все из них строго специфичны для встроенной разработки, но я считаю, что каждый из них по крайней мере столь же важен во встроенном мире, как в реальном мире.

• При составлении расписания, продолжайте и предположите, что все будет работать в первый раз.

• Подход к подходу к плате без осциллографа и/или логического анализатора. Особенно область, которая никогда не бывает полезной.

• Не учитывайте электропитание во время проектирования. Проблемы, такие как тепло, эффективность, влияние пульсации на показания АЦП и поведение системы, излучение ЭМП, время запуска и т.д., Не важны.

• Независимо от того, что вы делаете, не используйте контроллер reset (тип 5-процентного IC), просто используйте RC-схему (надеюсь, в ней есть много высокочастотного переменного шума)

• ИЗМЕНИТЬ БОЛЬШОЙ БАНГ!!! Не развивайте маленькие кусочки постепенно и часто объединяйтесь, глупый дурак!!! Просто закодируйте в течение нескольких месяцев, вместе с коллегами, а затем шлепните все это вместе в ночь перед большой демонстрацией выставки.

• Не программируйте код с инструкциями отладки/трассировки. Видимость плохая.

• Сделайте много вещей в своих ISR. Сортировка пузырьков, запросы к базе данных и т.д. Эй, шансы, что никто вас не прерывает, у вас есть слово, наслаждайтесь приятелем!!!

• Игнорировать раскладку платы в дизайне. Пусть автотрасса отправится в город по таким согласованным импедансным трассам и высоковольтному высокочастотному источнику питания. Эй, у вас есть более важные вещи, о которых нужно беспокоиться, партнер!!!

• Используйте новый, бета, неизданный, ранний кремний, особенно если он критичен в безопасности (авиационный, медицинский) или большой объем (интересно вспомнить 1 миллион единиц). зачем идти в Вегас, когда новая кремниевая выборка на этом 4-ядерном, 300 МГц 7-ступенчатом конвейере?

Ответ 3

OK round 2.... всего лишь несколько:

• Не используйте сторожевой таймер (особенно встроенный)

• Используйте типы и подпрограммы с плавающей запятой, когда достаточно масштабированной целочисленной математики

• Используйте RTOS, если это не оправдано

• Не используйте RTOS, если это действительно имеет смысл

• Никогда не смотрите на сгенерированный код сборки, чтобы понять, что происходит под капотом

• Запишите прошивку, чтобы она не могла быть обновлена ​​в поле

• Не документируйте какие-либо предположения, которые вы делаете

• Если вы видите что-то странное во время тестирования/отладки, просто игнорируйте его, пока это не повторится; это, вероятно, не было чем-то важным, как сбой, пропущенное прерывание, признак повреждения стека или какая-то другая мимолетная и прерывистая проблема.

• При настройке стеков лучшая философия состоит в том, чтобы "начать с малого и продолжать увеличиваться до тех пор, пока программа не перестанет сбой, тогда мы, вероятно, хорошо"

• Не используйте средства профилирования времени выполнения, такие как Micrium uC/Probe (я уверен, что есть другие)

• Не включайте тесты самообслуживания на устройство перед запуском основного приложения - он запускает загрузочный код, что, возможно, не работает?

• Определенно не включайте тест RAM в POST (выше), который вы не собираетесь внедрять

• Если у целевого процессора есть MMU, для всего, что свято, не используйте этот страшный MMU!!! Особенно не позволяйте ему защищать вас от записи в пространство кода, выполнение из пространства данных и т.д.

• Если вы тестировали, отлаживали и интегрировали с определенным набором параметров компилятора (например, нет/низкая оптимизация), УБЕДИТЕСЬ, ЧТОБЫ ОБРАТИТЬ ПОЛНУЮ ОПТИМИЗАЦИЮ до вашей окончательной сборки! Но включите оптимизацию, если вы не собираетесь тестировать. Я имею в виду, вы уже несколько месяцев тестировали - что может пойти не так?!??!

Ответ 4

Динамическое распределение памяти после инициализации. Пул памяти должен оставаться статическим после запуска и запуска системы.

Ответ 5

• Скремблирование на каротажном объекте. Встроенные системы трудно отлаживать, и вам нужно много журналов.
• Невозможно разрешить уровни ведения журнала. Одна система из многих будет демонстрировать странное поведение, и вам нужно установить уровень отладки этой системы на более подробный.
• Не разрешить какой-либо выходной порт разрешить ведение журнала, например, консоли.
• Невозможно "пройти" код.
• Отсутствие возможности профилировать код, чтобы вы могли видеть, какие биты нужно оптимизировать, например. в ассемблере.
• Не разрабатывается какой-либо "тест на здравомыслие", поэтому вы можете быстро проверить работу устройства после загрузки и перед отправкой.
• Основы дизайна на некоторых "домашних" ОС

Ответ 6

Попытка разработать без доступа к фактическому оборудованию, для которого вы разрабатываете.

Ответ 7

Используйте несколько процессоров в своем решении и убедитесь, что они имеют противоположную ориентацию. Затем убедитесь, что интерфейс между ними является одним из них, имеющим прямой доступ к другой памяти.

Да, я запрограммировал эту архитектуру раньше.

Ответ 8

Предположим, что endianess будет одинаковым навсегда.

(Расширьте его до размера регистров и все, что связано с техническими характеристиками)

(Объяснение случая в комментариях).

Ответ 9

Без определения "встроенного программирования" немного больше, тогда невозможно сказать, какая хорошая или плохая практика.

Многие из методов, которые вы могли бы использовать для программирования 8-битного микро в изворотливом нестандартном диалекте "C", были бы совершенно неуместными на платформе CE или XPe, например.

Абстракция во многих случаях является (чрезмерной) дорогостоящей роскошью, поэтому "избегать ее" может быть хорошим, а не плохим.

Ответ 10

Вот несколько:

• Не создавайте легко объясняемую архитектуру, которую могут понять как ваши разработчики, менеджеры и клиенты.

• Встраиваемая система почти всегда является дорогостоящей платформой. Не планируйте HW медленнее (дешевле) и не планируйте новые функции в критическом пути данных.

• Большинство встроенных систем "без головы" (без клавиатуры или мыши или любого другого HID). Не планируйте в своем графике писать инструменты отладки. И не ресурс, по крайней мере, одного разработчика для их поддержания.

• Обязательно недооценивайте, сколько времени потребуется, чтобы получить приглашение. Это то, как долго требуется, чтобы центральный процессор находился в точке, где он может разговаривать с вами и с вами.

• Всегда предполагайте, что подсистемы HW работают из коробки, как память, часы и мощность.

Ответ 11

Не

• Оставьте неиспользуемые векторы прерываний, которые не указывают нигде (в конце концов, они никогда не будут запущены, поэтому, где вред в этом...), вместо того, чтобы заставить их перейти к неиспользуемому по умолчанию обработчику прерываний, который делает что-то полезное.

• Не знакомы со спецификой используемого процессора, особенно если вы пишете драйверы низкого уровня.

• Выберите версию семейства процессоров с наименьшим количеством вспышек на том основании, что вы всегда можете "обновить позже", если только затраты не сделают это неизбежным.

Ответ 12

• Предположим, что микро-то, что в листе данных говорит, что оно делает/не делает то, что в листе данных promises не будет.
• Положите процедуру обслуживания сторожевого таймера на прерывание с высоким приоритетом, так что, что бы еще ни случилось, сторожевой таймер никогда не потерпит неудачу.
• Используйте любой код, просматриваемый в Интернете, особенно если он находится на сайте Arduino/Pic.
• Предположим, что существует какое-либо стандартное определение чего-либо от одного компонента к другому, например Tx/Rx (у нас есть единица Sony здесь с 2-мя коммуникационными портами, одна имеет Tx/Rx, обратную по отношению к другой).
• Подумайте, что клиент позаботится о том, чтобы проверить/проверить что-либо, пока они не продали не менее 100 единиц.
• Предположим, что любые другие игроки в поле действительно знают, что они делают (у нас есть стандартный документ, в котором говорится: "Мы думаем, что это то, что сделал наш старый протокол, но никто не помнит" )

Ответ 13

Важной вещью во встроенных системах является оценка технологии, как программного обеспечения (компилятора, библиотек, os), так и оборудования (наборов микросхем) независимо от вашего приложения. Предотвращение использования тестовых кроватей для них опасно. Нужно либо купить оценочные комплекты, либо построить собственные тестовые кровати.

Ответ 14

• Напишите свой FW-модуль полностью универсальным, принимающим все возможные параметры в качестве переменной, даже если уровень выше вас будет всегда с теми же параметрами.

• Используйте memcpy везде в коде, даже если у вас есть механизм DMA в системе (зачем беспокоиться о HW).

• Создайте сложную многоуровневую архитектуру FW, а затем получите доступ к модулю напрямую к глобальным переменным, принадлежащим модулям более высокого уровня.

• Выберите RTOS, но не утруждайте себя проверкой его фактической производительности (не можем ли мы доверять номерам, предоставленным поставщиком?)

Ответ 15

Printf.

Если вашему устройству трассировки требуется контекстный переключатель и/или прерывания, вы никогда не сможете отлаживать что-либо даже смутно связанное с этим время.

Напишите в буфер памяти (бонусные баллы для memcpy'ing перечислений вместо s (n) printf) и прочитайте его в другое время.

Ответ 16

Это, скорее всего, скорее аппаратный ответ, но для запуска новых проектов с нуля недооценка требований к ресурсам является большой проблемой, особенно при работе с небольшими автономными микроконтроллерами без простого расширения размера кода/хранилища.

Ответ 17

Это не только для встроенных систем, но и все это время находит ошибки (отладки) вместо того, чтобы избегать ошибок с классными вещами вроде, например. обзоры кода - это, безусловно, одна из наиболее часто применяемых худших практик.

Еще один способ позволить одному огромному процессору выполнять всю работу, а не разбивать проблему на небольшие проблемы, например. с большим количеством процессоров. Помните COCOMO?

Ответ 18

Это зависит от типа контроллера, для которого вы программируете. Иногда стоимость - это самая важная вещь, и вы пытаетесь пройти как можно меньше. То, что у меня обычно лодка. Вот некоторые худшие практики, которые я использовал:

• Не сосредотачивайтесь на улучшении своих процессов. Просто попробуйте немного сложнее в следующий раз. Позже, когда мы не заняты выпуском новых продуктов поспешно, поддерживая все эти ошибки в этой области, мы можем беспокоиться об этом.
• Избегайте разработки инженерного инструмента, чтобы сделать вашу жизнь проще, и если вы ее создаете, не разрешайте ей отправлять недопустимые входы на устройство.
• Не ставьте под вопрос оптимизацию. Это волшебство. Компилятор знает, что он делает. Никогда не будет ошибок компилятора, особенно для вашего 7-битного субмикроконтроллера PIC вашего клиента. Слишком много людей заметили бы правильно?
• Разделите и размножайте, как будто вы запускаете физический движок, не беспокойтесь о переполнении, потери точности, округляя до нуля.
• Если ваше время, похоже, работает, не проверяйте, выключено ли вы на 1, или если вы сошли с течением времени. Вы играли в перкуссию в старшей школе, вы заметили, если разница между 7200000 тактов и 7200001.
• Полагайтесь на тестирование системного уровня из группы, которая ничего не знает о вашей прошивке
• Работайте как можно больше различных устройств. Проведите несколько сеансов отладчика в разных средах разработки. Работа над разработкой одного продукта во время тестирования другого и попытки воспроизвести полевую проблему на третьем.
• Выпустите новую версию кода в спешке, потому что вы только изменили одну вещь, и вы, вероятно, ее не сломали. Производственная линия не работает, мы не можем тратить время!
• У вас нет какого-либо теста, чтобы предупредить вас, если оптимизация отключена. Вероятно, это будет неправильно? Новая версия IDE, которую вы только что установили, не могла нарушить этот параметр.
• Запишите код достаточно хорошо, чтобы работать. Проведите 75% времени, получая его на полпути.
• Не вносите никаких изменений в конструкцию функций. Разрешить любой функции собирать дни информации о состоянии. Не пытайтесь вводить эту информацию о состоянии для теста. Это даст вам свободное время, пытаясь воспроизвести ошибки, которые люди видели в поле, и продюсеры также оценят свое свободное время.

Ответ 19

С точки зрения программного обеспечения, не тратя время на изучение аппаратного обеспечения.

Ответ 20

Немного лишних:

• Оставляйте разработку и тестирование аппаратно-зависимых частей до самого конца, только чтобы обнаружить, что аппаратное обеспечение не работает, не работает должным образом или имеет некоторые недостатки, которые не могут быть исправлены в программном обеспечении (например, линейные искажения, которые нарушают всю дальнейшую обработку сигнала).
• Простая конструкция аналого-цифровых схем, не задумываясь о том, как происходящее в цифровой части может и может влиять на аналоговую часть (например, перекрестные помехи, приводящие к плохим данным, считываемым из АЦП).