Вопросы на собеседовании: Embedded-инженер

Я разделю три временных контура и явно задам владельцев оборудования.

• Задача сбора данных с периодом 1 мс будет просыпаться по уведомлению таймера или DMA, ставить метки времени и отправлять записи фиксированного размера без работы с CAN.
• Задача публикации с периодом 10 мс будет владеть передачей CAN, а задача диагностики с периодом 100 мс получит приоритет ниже обеих критичных по времени задач.
• Данные пойдут через ограниченные очереди, а у каждой периферии будет один владелец, чтобы не брать общие блокировки драйверов на пути 1 мс.
• Стеки будут рассчитаны по измеренным минимальным остаткам под худшей нагрузкой с запасом не менее 25% в пределах 128 КБ.

Я назначу фиксированные приоритеты по дедлайнам, поставив задачу управления с периодом 2 мс выше остальных.

• FreeRTOS запускает готовую задачу с большим числовым значением приоритета, поэтому можно назначить управлению 4, телеметрии 3, а журналированию 1.
• Отложенная обработка прерываний, способная разблокировать управление, получит подходящий приоритет, но обычное журналирование не окажется выше телеметрии.
• Каждая задача в простое будет блокироваться на задержке, очереди или уведомлении, освобождая процессор задачам ниже.
• Я проверю время отклика по измеренному худшему времени выполнения и блокировкам, потому что одни номера приоритетов не доказывают дедлайн 2 мс.

Я использую vTaskDelayUntil, чтобы запуски оставались привязаны к исходной сетке 10 мс.

• До цикла инициализирую TickType_t lastWake через xTaskGetTickCount, затем на каждой итерации вызову vTaskDelayUntil с pdMS_TO_TICKS(10).
• В отличие от vTaskDelay, это не добавляет переменное время выполнения от 1 до 3 мс к моменту следующего запуска.
• Я буду ставить метку времени на каждом старте и фиксировать перегрузку, если прошлая итерация дошла до следующего запуска или пересекла его.
• Частота тика должна достаточно точно представлять 10 мс, а для более строгой точности фазы нужно уведомление от аппаратного таймера.

Расчетная загрузка по WCET равна 50%, поэтому набор задач проходит достаточный тест по загрузке, но окончательно я приму его только после анализа времени отклика.

• Загрузка равна 0,4/2 + 1/5 + 2/20 = 0,50 по худшим временам выполнения, а не по измеренной средней загрузке CPU.
• При приоритетах rate-monotonic достаточная граница Лью и Лейланда для 3 задач составляет около 0,779, поэтому 0,50 проходит этот консервативный тест.
• До окончательного решения я добавлю время прерываний, переключений контекста, jitter запуска и худшую блокировку на mutex.
• Я проверю, что рассчитанное время отклика каждой задачи меньше ее дедлайна 2 мс, 5 мс или 20 мс, и подтвержу исходные оценки на целевом устройстве.

Я использую ограниченную очередь минимум на 12 элементов и выберу 16 элементов для измеренного запаса.

• ISR вызовет xQueueSendFromISR для 16-байтного значения или, что лучше, для индекса в заранее выделенном пуле отсчетов.
• Очередь из 16 значений займет 256 байт плюс метаданные и поглотит 16 мс входного потока.
• После паузы 12 мс потребитель выгрузит все доступные элементы, а не обработает только один за пробуждение.
• Я посчитаю случаи переполнения и заранее определю политику: отбросить новый отсчет, самый старый или поднять ошибку потери данных.

Я инициализирую счетный семафор значением 6, чтобы он представлял число свободных DMA-дескрипторов.

• Задача берет один токен перед извлечением дескриптора из защищенного списка и запускает DMA только после успеха обеих операций.
• ISR DMA отправляет индекс готового дескриптора через xQueueSendFromISR; задача драйвера возвращает его в свободный список под mutex и отдает один токен.
• Метаданные свободного списка защищает отдельный короткий mutex, потому что счетный семафор управляет количеством, а не взаимным исключением.
• Каждый запрос получает ограниченный тайм-аут из своего дедлайна, чтобы исчерпание всех 6 дескрипторов стало видимой ошибкой, а не бесконечным ожиданием.

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

• ISR отдает семафор через xSemaphoreGiveFromISR и запрашивает переключение, если готовой стала задача с более высоким приоритетом.
• Работник берет семафор, один раз читает все GPIO, выполняет подавление дребезга и снова блокируется.
• Повторная отдача уже доступного семафора не считает еще один фронт, что соответствует требованию повторного чтения.
• Если нужно сохранить каждый из 200 фронтов в секунду, я выберу счетное уведомление или очередь.

Я защищу всю I2C-транзакцию mutex FreeRTOS, которым владеет контекст задачи.

• Mutex покрывает адрес, настройку передачи, завершение и восстановление, чтобы байты двух клиентов не перемешались.
• Mutex FreeRTOS поддерживает наследование приоритета, а бинарный семафор нет, поэтому для общего владения нужен именно mutex.
• Каждый вызывающий код использует тайм-аут из своего дедлайна и освобождает mutex на всех путях успеха и ошибки.
• Обратные вызовы не должны рекурсивно брать тот же mutex, а долгие задержки повторных попыток останутся вне критической секции 2 мс.

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

• Владельцы линка, DHCP и синхронизации времени устанавливают биты 0, 1 и 2 при готовности и немедленно очищают свой бит при потере состояния.
• Зависимая задача вызывает xEventGroupWaitBits с ожиданием всех битов и конечным тайм-аутом повторной проверки 1 с.
• Готовность является уровнем состояния, а не числом событий, поэтому группа подходит лучше трех очередей.
• После пробуждения задача повторно проверяет реальные состояния подсистем, потому что установки и переподключения могут пересечься с результатом ожидания.

Я применю прямое уведомление задачи вместо выделения очереди или семафора.

• ISR вызывает vTaskNotifyGiveFromISR, затем portYIELD_FROM_ISR, если установлен xHigherPriorityTaskWoken.
• Задача вызывает ulTaskNotifyTake без очистки при выходе, если нужно посчитать каждое из 20 000 завершений в секунду.
• Если важно только последнее состояние буфера, я включу очистку при выходе и позволю повторным завершениям объединяться.
• Такой дизайн ограничен одним известным получателем, именно поэтому он меньше и быстрее универсальной очереди.

Я исключу неограниченное выделение памяти во время работы и сделаю бюджет 64 КБ проверяемым при сборке и запуске.

• Стеки задач, очереди, протокольные буферы и запросы драйверов будут находиться в статической памяти или пулах фиксированного размера.
• Если heap_4 остается для начального создания объектов, после инициализации выделение запрещается, а минимальный остаток heap записывается.
• Фиксированные пулы явно задают исчерпание и максимальную задержку, тогда как повторные выделения разных размеров могут фрагментировать heap за 5 лет.
• Я измерю минимальные остатки стеков под стрессом и оставлю не менее 20% запаса для худшего наблюдаемого пути.

Я предоставлю память для каждого объекта ядра и включу поддержку статического выделения FreeRTOS.

• Каждая задача получит блок управления StaticTask_t и фиксированный массив StackType_t, переданные в xTaskCreateStatic.
• Каждая очередь получит StaticQueue_t и правильно выровненный байтовый буфер, а каждый mutex будет создан через xSemaphoreCreateMutexStatic.
• Приложение предоставит статическую память для idle-задачи и задачи таймеров через обязательные callbacks FreeRTOS, если эти задачи включены.
• Все 8 стеков и 8 объектов синхронизации имеют время жизни программы, а link map подтверждает итоговый расход RAM.

При протоколе немедленного потолка приоритетов граница блокировки H за один запуск равна 700 мкс, поэтому дизайн превышает бюджет блокировки 500 мкс.

• Потолок обоих ресурсов равен приоритету H, потому что H берет и SPI, и калибровку, что исключает циклические цепочки блокировок в выбранном протоколе.
• Граница равна max(700, 300, 200) = 700 мкс, а не сумме всех критических секций задач ниже.
• Потолок устраняет неограниченную инверсию, но не сокращает 700 мкс, поэтому я разобью SPI-передачу L на безопасные для протокола части короче 500 мкс, вынесу ее из окна H или применю другой контроллер.
• Я измерю реальные времена удержания и повторю анализ времени отклика H, M и L с учетом потолка и переключений контекста.

Я сделаю отмену кооперативной и направлю каждый исход через один структурированный путь очистки, который точно знает набор захваченных ресурсов.

• Локальное состояние операции хранит владение SPI, буфером или дескриптором, файловой системой и признак начала устойчивой записи.
• Mutex файловой системы ожидается ограниченное время; при тайм-ауте или отмене задача не начинает новую работу и освобождает только реально захваченные ресурсы в обратном порядке.
• Задачу нельзя принудительно удалить с захваченным SPI, а chip select, DMA, дескрипторы и SPI mutex возвращаются или отменяются по документированной процедуре владельца драйвера.
• Постоянные изменения используют staging и commit marker, поэтому очистка оставляет старую или новую полную запись, а fault injection проверяет каждую точку отмены.

Я задам каждому дескриптору состояния FREE, DMA_OWNED и WORKER_OWNED, а исчерпание пула сделаю явным overrun.

• ISR сохраняет status завершения и ID дескриптора до требуемой очистки write-one-to-clear, переводит DMA_OWNED в WORKER_OWNED и публикует ID через xQueueSendFromISR с условным yield.
• Задача проверяет ID и generation, обрабатывает данные и возвращает именно этот дескриптор в FREE через список свободных элементов владельца драйвера.
• На 10 кГц пул покрывает только 800 мкс отставания; без FREE-элемента применяется аппаратное backpressure или остановка DMA, а при отсутствии поддержки кадр отбрасывается и считается без перезаписи занятых данных.
• Под худшей нагрузкой сохраняются queue-full, максимальная занятость пула, наибольшее отставание задачи, нарушения состояний и пропуски sequence numbers.

Только ISR с числовыми приоритетами от 5 до 15 могут вызывать разрешенные API FreeRTOS с суффиксом FromISR.

• В Cortex-M меньшее числовое значение приоритета NVIC означает большую срочность, то есть направление противоположно номерам приоритетов задач FreeRTOS.
• Приоритеты от 0 до 4 слишком срочные для входа в ядро и должны передавать аппаратное состояние разрешенной ISR или задаче для поздней обработки.
• CMSIS NVIC_SetPriority обычно принимает несдвинутое значение от 0 до 15, а configMAX_SYSCALL_INTERRUPT_PRIORITY в типичных портах использует представление со сдвигом для регистра.
• Я включу configASSERT и проверю конфигурацию порта, чтобы обнаружить случайный вызов xQueueSendFromISR из ISR с приоритетом 4.

Я сохраню тик 1 кГц для активного планирования и включу tickless idle для интервалов простоя 30 с.

• Тик 1 кГц дает шаг 1 мс, но без подавления будит CPU 1000 раз в секунду.
• Tickless idle программирует малопотребляющий таймер на ближайший дедлайн и после пробуждения продвигает счетчик тиков ядра.
• Я проверю дрейф малопотребляющего таймера, максимальный подавляемый интервал и все источники пробуждения на полном сне 30 с.
• Для цикла 2 мс все равно измеряется задержка, а требование к фазе меньше тика следует реализовать аппаратным таймером, а не ускорением общего тика.

Я запрограммирую малопотребляющий таймер на ближайший deadline ядра или приложения, поэтому этот сон закончится не позже чем через 5 с.

• Deadline приложения регистрируется на той же монотонной шкале времени до расчета числа тиков, которые scheduler может подавить.
• Перед сном код атомарно перепроверяет готовую работу и ближайший deadline, затем применяет требуемые платформой барьеры, чтобы не потерять прерывание между проверкой и WFI.
• После пробуждения порт переводит измеренные тики low-power таймера в прошедшие тики RTOS и продвигает время ядра документированным tickless-механизмом до запуска готовой работы.
• При позднем пробуждении задача получает реальное прошедшее время, записывает опоздание, один раз обрабатывает просроченное событие и входит в заданный safe fallback при превышении допуска.

Я измерю худшее время отклика релизной сборки под намеренно тяжелой параллельной нагрузкой.

• Аппаратный захват таймера или DWT_CYCCNT запишет циклы от запуска до завершения функции при включенных прерываниях и DMA.
• Я выполню не менее 10 миллионов периодов с максимальным трафиком шин, разными состояниями cache и всеми ISR более высокого приоритета.
• Результат включает вытеснение и блокировки mutex, а не только среднее время изолированной функции.
• Я сопоставлю наблюдаемый максимум с 500 мкс, указав накладные расходы измерения и обоснованный инженерный запас.

Я измерю реальные фронты обновления аппаратными метками и разделю джиттер запуска и выполнения.

• Переключу запасной GPIO при запуске задачи и записи регистра PWM, затем захвачу не менее 1 миллиона интервалов логическим анализатором или входным захватом таймера.
• Рассчитаю минимум, максимум и гистограмму, а приемку проведу по худшему отклонению от 1 мс, а не только по p99.
• Второй канал трассы отметит долгие ISR или блокировки планировщика, чтобы связать выбросы с маскированием прерываний.
• Если пробуждение задачи превышает 20 мкс, критичное по фазе обновление перейдет на compare таймера или DMA, а задача будет готовить следующее значение.