Встраиваемый C — бесплатный тест онлайн

Вопрос 1 из 30

Зачем указатель на регистр устройства с отображением в память объявляют `volatile`?

#define STATUS (*(volatile const uint32_t*)0x40001000u)

Чтобы изменить физический адрес регистра Чтобы принудительно включить кэширование MMIO Чтобы обращения к регистру не удалялись как лишние Чтобы навсегда запретить запись по этому адресу Чтобы каждое обращение автоматически стало атомарным

Вопрос 2 из 30

Чем опасна очистка регистра с очисткой записью единицы (`write-one-to-clear`) через `REG |= FLAG`?

REG |= FLAG; /* ошибочная операция чтение–изменение–запись для W1C-регистра */

Оператор `|` запрещён для регистров устройства `volatile` создаёт второй поток, который меняет регистр Макрос `FLAG` всегда вычисляется как ноль RMW может случайно очистить другие установленные биты Операция делает адрес регистра невыровненным

Вопрос 3 из 30

Почему следует сохранять чтение статусного регистра в локальную переменную?

uint32_t status=STATUS_REG;
if(status&RX_READY) ...

После первого чтения адрес регистра перестаёт быть действительным до следующего прерывания Локальная копия всегда читается одной инструкцией, а прямой доступ к регистру — несколькими независимо от архитектуры Чтение может вернуть новое значение или сбросить событие Квалификатор `volatile` запрещает повторно читать один регистр в пределах функции После первого чтения регистр автоматически возвращается к исходному значению, поэтому второе чтение всегда даёт то же число

Вопрос 4 из 30

Как обновить отдельное поле обычного регистра, сохранив остальные биты?

uint32_t r=CTRL;
r=(r&~MODE_MASK)|((mode<<MODE_SHIFT)&MODE_MASK);
CTRL=r;

Записать только значение поля, обнулив все остальные биты Очистить поле маской, вставить значение и записать регистр Очистить регистр через `memset` Сложить числовой адрес регистра со значением поля Сузить значение до `signed char` перед записью

Вопрос 5 из 30

Чего не гарантирует `volatile` при работе с MMIO?

`volatile` запрещает записывать новое значение в объект, объявленный через изменяемый указатель `volatile` не гарантирует, что выражение с регистром вообще будет вычислено, если его значение не используется `volatile` не сохраняет объявленный тип объекта после преобразований целых операндов Аппаратный порядок относительно других обращений; для него могут понадобиться барьеры `volatile` не позволяет прочитать значение, изменяемое периферией между двумя обращениями

Вопрос 6 из 30

Почему ISR должна быть короткой?

void uart_isr(void){
  uint8_t b=UART_DATA;
  ring_put_isr(b);
  UART_STATUS=RX_FLAG;
}

Стек обработчика не ограничен, поэтому длинный код вытесняет память основной программы Функции в обработчике запрещены как конструкция языка, даже если они разворачиваются `inline` Растут задержки других событий и риск пропустить дедлайн Доступ к `volatile` всегда выполняется медленнее любого допустимого дедлайна системы Компилятор допускает не более десяти операторов между входом и возвратом из прерывания

Вопрос 7 из 30

Какой риск создаёт общий 32-битный счётчик на восьмибитном микроконтроллере?

volatile uint32_t ticks;
void isr(void){ ticks++; }
uint32_t now=ticks;

После первого увеличения счётчик автоматически становится знаковым ISR навсегда останавливает основной цикл при первом вызове Тип `uint32_t` не существует на восьмибитных микроконтроллерах `volatile` гарантирует атомарность многобайтового доступа Основной код может прочитать смесь байтов до и после обновления счётчика в ISR

Вопрос 8 из 30

Почему динамическое выделение памяти внутри обработчика прерывания плохо сочетается с жёсткими требованиями реального времени?

void timer_isr(void){
  event *e=malloc(sizeof *e); /* непредсказуемо */
}

Время работы и блокировки распределителя непредсказуемо; возможны фрагментация и небезопасный повторный вход Обработчики прерываний не могут обращаться к глобальной памяти, где хранится состояние кучи Вызов пользовательской функции из обработчика запрещён независимо от её реализации Стандартная библиотека обязана возвращать `NULL` для любого `malloc` из обработчика Выделение памяти автоматически обслуживает сторожевой таймер и скрывает долгую задержку

Вопрос 9 из 30

Как основной цикл должен получать события из кольцевого буфера, который заполняет ISR?

buffer[head]=event;
/* барьер/атомарная публикация по платформе */
head=next;

Игнорировать индексы и читать первый элемент массива Соблюдать атомарный протокол публикации данных и индекса с нужными барьерами Копировать всю оперативную память при каждом событии Вызывать `printf` из ISR перед изменением индекса Выделять два новых блока через `malloc` для каждого события

Вопрос 10 из 30

Что нужно сделать с источником прерывания до выхода из ISR?

Ничего не делать: источник всегда очищается автоматически Полностью выключить питание устройства Изменить указатель стека перед возвратом Подтвердить или очистить источник способом из документации периферии Вызвать `main` ещё раз из обработчика

Вопрос 11 из 30

Почему частые `malloc` и `free` блоков разных размеров опасны при малом объёме RAM?

`free` существует только в программах с полноценной операционной системой и недоступен bare-metal коду `malloc` хранит служебные данные во Flash и постепенно изнашивает энергонезависимую память Фрагментация может оставить много памяти суммарно, но без подходящего непрерывного блока После первого освобождения куча становится доступной только для блоков точно того же размера Распределитель округляет каждый запрос до одного байта, поэтому блоки разных размеров перекрываются

Вопрос 12 из 30

Какой дефект в статическом кольцевом буфере?

uint8_t buf[N];
size_t head;
void put(uint8_t x){ buf[head++]=x; }

Индекс может безопасно расти без ограничения, если тип `size_t` шире количества элементов буфера `head` не переходит по модулю и выйдет за границу Тип `uint8_t` нельзя использовать для массива, который изменяется из обработчика прерывания Кольцевой буфер обязан выделяться динамически, иначе переход индекса к нулю невозможен Дефект состоит только в отсутствии `volatile`; добавление квалификатора ограничит индекс диапазоном массива

Вопрос 13 из 30

Что полезного о RAM показывает карта компоновки прошивки?

Энергопотребление каждой функции Только комментарии из исходных файлов Адреса и размеры статических секций и символов, позволяющие оценить бюджет RAM Все значения, которые когда-либо появятся на стеке Точный максимальный размер кучи во всех возможных запусках

Вопрос 14 из 30

Почему большой автоматический массив внутри глубокой функции опасен?

void process(void){
  uint8_t frame[4096];
  ...
}

`sizeof(frame)` становится равен нулю Локальный массив нельзя индексировать Любое прерывание немедленно уничтожает массив Буфер и глубина вызовов могут переполнить ограниченный стек Автоматические массивы всегда размещаются во Flash

Вопрос 15 из 30

Как обработать сообщение переменной длины при жёстком ограничении RAM?

Хранить одновременно две полные копии сообщения Проверить предел и обрабатывать сообщение частями в фиксированном буфере Обрабатывать каждый байт отдельным рекурсивным вызовом Всегда выделять память ровно по заявленной длине сообщения Отключить проверку целостности ради экономии памяти

Вопрос 16 из 30

Почему среднее время 1 мс не доказывает выполнение дедлайна 5 мс?

Погрешность таймера делает любое измерение среднего бесполезным для систем реального времени Дедлайн задаётся размером сообщения в байтах, а не временем выполнения Для гарантии важны худшее наблюдаемое время и обоснованная верхняя граница, а не среднее 1 мс Достаточно повысить оптимизацию: после `-O3` худшее время обязано приблизиться к среднему Среднее значение всегда не меньше максимального, поэтому один выброс не влияет на дедлайн

Вопрос 17 из 30

Какая последовательность событий создаёт инверсию приоритетов?

Задачи разных приоритетов используют отдельные стеки, но одинаковые адреса локальных переменных Прерывания отключены навсегда, поэтому планировщик не может запустить задачу низкого приоритета Высокоприоритетная задача получает ресурс первой и удерживает его до завершения всех средних задач Мьютекс не инициализирован, и все три задачи одновременно считают его свободным Высокий приоритет ждёт ресурс, а средний мешает владельцу

Вопрос 18 из 30

Почему цикл ожидания без верхней границы недопустим на критическом пути?

while(!(STATUS&READY)) { }

Процессор гарантированно зависает на первом чтении любого аппаратного регистра Циклы `while` запрещены в прошивках, потому что компилятор не умеет оценивать их длительность Без таймаута нет верхней границы ожидания и нет пути перехода в безопасное состояние отказа Квалификатор `volatile` позволяет компилятору полностью удалить цикл ожидания Ожидание аппаратуры разрешено только через `for`, у которого число итераций видно в заголовке

Вопрос 19 из 30

Что лучше уменьшает дрейф периодической задачи: задержка после работы или расписание по абсолютным моментам?

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

Вопрос 20 из 30

Что нужно оценить перед запретом прерываний вокруг критической секции?

disable_irq();
update_shared_state();
enable_irq();

Порядок байтов процессора: при big-endian запрет прерываний занимает больше тактов Размер исходного файла после препроцессирования, поскольку он определяет задержку выполнения Число строк внутри критической секции: одинаковое число операторов даёт одинаковое время на любом входе Имя функции: обработчики с коротким идентификатором быстрее возвращают управление Худшее время секции и задержку заблокированных прерываний

Вопрос 21 из 30

Как найти, почему прошивка перестала помещаться во Flash?

arm-none-eabi-size firmware.elf
arm-none-eabi-nm --size-sort firmware.elf | tail

Удалить все заголовочные файлы: каждый `#include` копируется в итоговый образ как текст Сократить имена локальных переменных: они напрямую занимают место во Flash даже без отладочной информации Сравнить карту компоновки, размеры секций и крупнейшие символы между рабочей и увеличившейся сборкой Отключить ошибки линковщика, чтобы он отбросил секции, не помещающиеся в память Проверить сеть командой `ping`, поскольку размер прошивки зависит от доступности сервера сборки

Вопрос 22 из 30

Зачем смотреть дизассемблирование функции, работающей с MMIO?

arm-none-eabi-objdump -dS firmware.elf > firmware.lst

Автоматически включить JTAG и настроить тактирование отладочного интерфейса Переключить стандарт языка, изменив только команду дизассемблера после компоновки Определить логический цвет регистра и режим отображения его значения в отладчике Подтвердить ширину, число и порядок реальных обращений и наличие барьеров Исправить ошибки электрической схемы по последовательности сгенерированных инструкций

Вопрос 23 из 30

Когда логический анализатор полезнее диагностического `printf`?

Для обнаружения утечек кучи по последовательности вызовов распределителя Для проверки синтаксиса прошивки до её загрузки в микроконтроллер Когда требуется измерить временные интервалы, но текстовый вывод даёт достаточно точную картину без вмешательства Для анализа содержимого строк в памяти без подключения к цифровым линиям устройства Для измерения длительности импульсов и обмена по шине, когда `printf` сам искажает критический путь

Вопрос 24 из 30

Что даёт аппаратная точка наблюдения JTAG?

Стирает Flash-память при срабатывании Сам изменяет значение наблюдаемого регистра Создаёт модульный тест из текущего состояния Шифрует наблюдаемую область памяти Остановит ядро при доступе к выбранному адресу

Вопрос 25 из 30

Почему отладка оптимизированной прошивки отличается от сборки `-O0`?

Сборка `-O0` всегда точно совпадает с поведением железа Оптимизация автоматически стирает Flash Оптимизация меняет инструкции и время; сбой может исчезнуть Все локальные переменные становятся `float` JTAG не работает с оптимизированным кодом

Вопрос 26 из 30

В какой момент правильно обслуживать сторожевой таймер?

if(sensor_ok && control_loop_advanced && comms_ok) watchdog_kick();

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

Вопрос 27 из 30

Как сделать обновление прошивки устойчивым к потере питания?

Записывать блоки в случайном порядке без журнала, полагаясь на повторную передачу после сбоя Отключить проверку контрольной суммы: незавершённый образ тогда можно принять как частичное обновление Хранить выбранную версию только в RAM и считать её действительной после любого перезапуска Сначала стереть действующий образ, чтобы освободить место и исключить загрузку старой версии Два слота и активация нового образа лишь после проверки

Вопрос 28 из 30

Почему прямая запись структуры в EEPROM через `memcpy` создаёт проблему переносимости?

memcpy(eeprom_addr,&config,sizeof config);

Формат зависит от заполнения, порядка байтов и размеров типов Для структуры нужно использовать `strcpy` `memcpy` слишком медленна для энергонезависимой памяти EEPROM не способна хранить нулевые байты Структуры языка C разрешено хранить только в RAM

Вопрос 29 из 30

Что должна сделать система при недопустимом показании датчика?

if(!sensor_valid(raw)){
  actuator_set_safe();
  fault_latch(SENSOR_FAULT);
}

Скрыть ошибку и выдать обычную команду Перезагружаться бесконечно при каждом чтении Перейти в заранее определённое безопасное состояние и зарегистрировать отказ Намеренно переполнить счётчик ошибок Продолжить с последним случайным значением без отметки

Вопрос 30 из 30

Зачем отделять аппаратный слой от логики управления?

uint32_t hal_read_sensor(void);
void controller_step(const input *in, output *out);

Такое разделение имеет смысл лишь для C++, где аппаратные объекты можно оформить классами Отказаться от функций и обращаться к регистрам только через макросы в прикладном коде Получить гарантированное ускорение: любой вызов HAL компилятор обязан заменить одной инструкцией Увеличить число исходных файлов, даже если граница между аппаратной и прикладной логикой не определена Изолировать регистры в платформенном слое, логику тестировать на хосте