Архитектура микроконтроллера
Последняя часть этой серии была названа «Что движет автомобильной архитектурой программного обеспечения?», И я еще не акцентировал внимание на аспектах ограниченного микроконтроллера. Архитектура и ограничения микроконтроллера сильно влияют на архитектуру программного обеспечения. В этой части серии я хочу, чтобы вы получили представление об этом аспекте разработки автомобильного программного обеспечения.
Если вы пропустили Часть 2:
Микроконтроллеры - это процессоры с некоторыми дополнительными функциями, которые часто называют периферийными устройствами. Эти периферийные устройства расположены на той же микросхеме, что и ЦП, и обеспечивают подключение к сети, напрямую подключенным датчикам и устройствам, таким как электродвигатели.
Обычно вы подключаете некоторые датчики, такие как датчики температуры, непосредственно к аналого-цифровому преобразователю (аналогово-цифровому) микроконтроллера. Периферийное устройство аналого-цифрового преобразователя преобразует аналоговые значения напряжения, такие как 3,5 В, в цифровое число, например, 35. И они могут делать это периодически и очень быстро, например, каждые 100 микросекунд.
Хотите узнать пример использования аналого-цифрового преобразования? Вот и все: программное обеспечение в автомобиле будет контролировать напряжение аккумулятора, чтобы нормально отключиться, когда напряжение упадет ниже критической границы. В противном случае некоторые компоненты оборудования перестанут работать правильно.
Некоторое время назад мне пришлось реализовать такой компонент монитора, и мне пришлось рассмотреть несколько различных низковольтных границ. Была одна граница, на которой нам пришлось прекратить сетевое взаимодействие, потому что компонент CAN не работал должным образом. Другой определил, когда нам нужно было перевести электродвигатель в режим ожидания, потому что в противном случае он отключил бы питание других устройств в машине. Затем вам понадобится другая граница напряжения, чтобы вернуться к нормальному поведению. Если бы я выбрал одну и ту же границу для движения вверх и вниз, система рулевого управления будет подпрыгивать между выключением и включением, потому что напряжение аккумулятора часто колеблется. Конечный автомат с отдельными условиями движения вверх и вниз поддается решению этой проблемы.
Указанные границы напряжения аккумулятора являются фиктивными. Любое сходство с реальными автомобилями, которые все еще едут или разбились, чисто случайно. Когда вы строите график напряжения аккумуляторной батареи автомобиля, вы получаете волнистую линию в зависимости от текущего состояния других систем в автомобиле (например, двигателя внутреннего сгорания). На следующем графике напряжения батареи показано, когда система меняет состояние. Вы наверняка поймете, как он справляется с этим «дрожанием напряжения».
Вернемся к нашему микроконтроллеру. Почти все входные периферийные устройства микроконтроллера помещают свои данные в буферы, которые могут быть прочитаны программным обеспечением путем считывания значений из определенных адресов памяти. Это означает, что периферийные устройства, включая их буферы, отображаются в памяти микроконтроллера по определенным адресам. Чтобы справиться с этим в программировании на C, нужно определить указатель, скажем, на данные A / D:
Вы можете контролировать и настраивать периферийные устройства, также записывая данные по определенным адресам памяти.
В целом программному обеспечению достаточно легко получить доступ к периферийным устройствам микроконтроллера и управлять ими. На первый взгляд. Проблемы возникают, когда вы спотыкаетесь о временных аспектах этих периферийных устройств.
Ограничения микроконтроллера
Если вы привыкли к разработке веб-приложений или настольных приложений, вы будете шокированы, узнав о ресурсах, доступных разработчикам встраиваемых систем. Двумя яркими примерами микроконтроллеров для использования в системах рулевого управления являются семейство Renesas V850.
и семейство Freescale MPC5xxx
ЦП работает, например, с 80–160 МГц и 40–80 КБ ОЗУ! Да, это КБ, а не ГБ. Сравните размер ОЗУ микроконтроллера (80 КБ), показанный белым пикселем, с размером ОЗУ обычного ПК (8 ГБ), показанным синей областью:
Поэтому JVM не совсем подходит для такого типа микроконтроллеров. Это старый добрый C, который используется в качестве языка программирования. И многие вещи, которые обычно выполняются во время выполнения, определяются до запуска компилятора. Операционная система настроена точно для одной системы, и в результате конфигурации создается сгенерированный исходный код. Вы не можете создать процесс или поток во время выполнения. То же самое и с распределением памяти, особенно в критически важных для безопасности системах. Во время выполнения не выделяется память, так как у вас может не хватить памяти. Таким образом вы убьете свое программное обеспечение и неприятным образом повлияете на водителя. Вместо этого вы пытаетесь заранее определить все, что вам понадобится, в виде ресурсов, таких как память и мощность процессора.
Возможно, вам интересно, как можно загрузить программу в 80 КБ ОЗУ и запустить ее. На самом деле программа хранится в ПЗУ (постоянное запоминающее устройство) и выполняется оттуда. Он не загружается в оперативную память, как это обычно бывает на ПК. Размер ПЗУ, например, 1 МБ, чтобы вы могли хранить там приличный размер программы и свои постоянные значения.
Кроме того, вы обнаружите NVRAM (энергонезависимое ОЗУ) внутри микроконтроллера, где ваша программа может сохранять значения, которые вам нужны после выключения / включения.
Подразумеваемое
Каковы последствия архитектуры и ограничений микроконтроллеров?
- Вам, как архитектору, нужно заботиться о множестве низкоуровневых деталей.
- Следовательно, сложно придерживаться слоев в архитектуре программного обеспечения.
- Процесс сборки программного обеспечения становится довольно сложным.
- Инструменты разработчика, такие как профилировщики, которые должны улучшать программу для работы, ограничены и их сложно интегрировать.
- И еще несколько…
Я надеюсь, вы получили представление о некоторых силах, движущих в основе архитектуры программного обеспечения для автомобилей. Было бы слишком утомительно представлять их все. Вы должны испытать их, как всегда, в разработке программного обеспечения, независимо от типа программного обеспечения, которое вы создаете.
