Встроенные системы худшие методы?

Некоторые худшие методы на основе моего опыта работы во встроенных системах больше 8 лет и обучения встроенных систем:

1. Выбор типа данных - Встроенные системы являются недостаточным ресурсом. Если данные собираются колебаться от 5-200, нет никакого смысла из объявления их как интервал, Что требуется, только 8 битов, тогда как то, что используется, составляет 32 бита. Отходы 24 битов.

Неверные типы данных могут также иметь катастрофические последствия.

2. Выполнение большой работы в ISR - ISRs должен быть максимально коротким. Некоторые люди, которых я видел, реализуют всю логику в ISRs, который очень очень плох. Настолько плохо, что это должно быть перечислено как преступление. Используйте флаги вместо этого

3. Используя целые числа как флаги - Это - больше расширения точки 1. Вам нужен только один бит. Не используйте 16 или 32 бита для этого.

4. , Но худшее из всего, что я видел, обдумывает алгоритм много раз для получения лучшего и самого идеального подхода. Остановитесь!! Помните о лучших практиках и заставьте систему работать сначала.

существует партия больше. Вы можете читать некоторые из них здесь

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

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

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