Петрушинин М.П.
ПРОЕКТИРОВАНИЕ ДРАЙВЕРА ДЛЯ РАЗРАБАТЫВАЕМЫХ КОНТРОЛЛЕРОВ *
Аннотация:
цель работы – спроектировать драйвер для разрабатываемых контроллеров NOR-памяти типа FLASH и SRAM. В качестве устройств были взяты CY62167EV30 и S29GL для SRAM и FLASH памяти соответственно. Особенность контроллера для этих типов устройств в том, что существует множество вариаций работы. Необходимое условие для работы драйвера – это возможность работы без операционной системы, так называемый Bare Metal
Ключевые слова:
драйвер, SRAM, FLASH, импортозамещение, проектирование, Bare Metal
УДК 627.7
Петрушинин М.П.
студент магистратуры кафедры математического обеспечения
и стандартизации информационных технологий
Российский технологический университет МИРЭА
(г. Москва, Россия)
ПРОЕКТИРОВАНИЕ ДРАЙВЕРА
ДЛЯ РАЗРАБАТЫВАЕМЫХ КОНТРОЛЛЕРОВ
Одним из важных вопросов при создании информационной системы является вопрос создания средств коммуникации между устройством и программистом. Таким средством является драйвер. Появление новых технических устройств требует развитие драйверов для них. Вопросом создания драйверов занималось достаточно большое количество специалистов и организаций. Однако, рассматривая устройства для обращения с внешней памятью, или не разработаны совсем, или требуют существенной доработки. Таким образом, задачей работы является разработка API драйвера для управления контроллером.
Основным требованием для разработки контроллера NOR-FLASH/SRAM – это предусмотреть возможность расширения функционала контроллера на любом этапе его проектирования. Таким образом, драйвер становится способным работать с разными режимами, устройствами и так далее.
Благодаря такому подходу создаваемый драйвер можно легко адаптировать под различные изменения устройства.
Драйвер для контроллера должен уметь работать как с памятью типа FLASH, так и SRAM.
Для FLASH памяти будет использована архитектура NOR. Данная архитектура использует логическую операцию «ИЛИ НЕ» для преобразований входные напряжений в выходные.
С точки зрения программирования FLASH память является более сложной. Так, чтобы осуществить какую-либо операцию необходимо заблаговременно осуществить несколько циклов команд. Они представляют из себя запись определенных параметров в заранее известные адреса.
Например, операция записи может выглядеть так:
И только после этого в контроллер необходимо записывать буфер. И, когда все данные будут подготовлены, записать 0x0029 по адресу сектора, что даст контроллеру команду о начале записи.
SRAM в этом плане выглядит проще. Для записи требуется только адрес, куда идет запись и сами данные.
У разных устройств могут быть предусмотрены дополнительные режимы работы контроллера, такие как:
Также, у разных устройств отличаются временные параметры, которые должны настраиваться автоматически.
В процессе разработки контроллера может возникнуть ситуация, когда будет меняться внутренняя логика работы. Для таких ситуаций также предполагается создать уровень абстракции, который позволит в таких ситуациях добавить или изменить существующую логику без необходимости переделывать все остальное, а также сохранить старые наработки.
В разных системах на кристалле может быть поддержаны только определенные версии контроллеров. Драйвер должен иметь возможность использовать конкретную версию контроллера. При необходимости заменить в системе на кристалле одну версию на другую или добавить новую.
Данный уровень абстракции должен быть самым высоким. Функции, реализованные здесь, не должны знать о том, как работает устройство и были ли внесены какие-либо изменения.
Таким образом, получившийся драйвер должен быть разделен на уровни, показанные на рисунке 1.
Рис. 1. Общая архитектура драйвера.
Из рисунка 1 видно, что драйвер разделен на следующие уровни абстракции:
В результате проектирования драйвера получилась структура, благодаря которой возможно легко добавлять новые устройства. Этому факту свидетельствует то, что в реализованном драйвере уже присутствуют несколько версий и СНК. По грубым расчетам, для поддержки нового контроллера, необходимо будет потратить одну рабочую неделю в самом не благоприятном случае.
При реализации использовалась архитектура, представленная на рисунке 1.9. В проекте были реализованы следующие уровни:
Разработка драйвера началась с уровня «driver». Здесь были реализованы методы обращения с устройством.
На рисунке 2 показан код реализации команды очистки для FLASH памяти.
Рис. 2. Реализация методов очистки для FLASH памяти.
Можно наблюдать, что для реализации были использованы операции разблокировки. В случае же, если используется SRAM память, то аналогичные методы будут объявлены, однако тела будут пустыми, так как для SRAM не предусмотрена операция очистки.
Далее, в ходе реализации проекта, был создан уровень подсчета временных параметров.
Во время создания данного уровня были реализованы методы для подсчета временных параметров. Реализованные методы и выставленные временные параметры соответствуют документациям для выбранных устройств.
После этого был разработан уровень «bsp». Данный уровень нужен для того, чтобы была возможность протестировать один и тот же контроллер на разных отладочных платах. На этом уровне вызываются необходимые временные параметры и методы для их подсчета, в соответствии с работающей частотой контроллера.
В завершении, перед реализацией основного уровня «api» были созданы абстракции «version» и «soc». Они нужны для того, чтобы была возможность расширения драйвера с добавлением поддержки новых версий контроллера FLASH или SRAM и имплементации их в разных СНК соответственно.
Чтобы, начать тестирование, требуется основное API, которое позволит комфортно и эффективно работать со всеми уровнями драйвера. Методы на данном уровне абстракции работают над всеми другими, оперируя ими внутри себя и скрывая сложную логику. На рисунке 3 показан весь проект драйвера.
Рис. 3. Проект драйвера.
После создания работоспособного API, необходимо проверить его работу, а также работу контроллеров SRAM и FLASH согласно плану тестирования. При создании тестов были учтены реальные возможные сценарии работы с драйвером.
На рисунке 4 представлен один из разработанных сценариев.
Рис. 4. Сценарий работы контроллера в режиме мультиплексирования.
В процессе разработки устройства участвуют множество специалистов. Для отладки драйвера разрабатываемого контроллера требуется дорогостоящее оборудование, такое как осциллограф, отладочные платы, сервера и тому подобное. Если неправильно спроектировать драйвер для разрабатываемого контроллера, то может возникнуть ситуации, когда его дальнейшая эксплуатация невозможна.
Например, в разработанной структуре драйвера присутствует уровень, который отвечает за разные версии разрабатываемого контроллера. Он позволяет добавлять поддержку новых версий контроллера, оставляя при этом возможность работать и со старыми. Если не предусмотреть данную возможность, то возникнет ситуация, когда для нового устройства в контроллере была изменена логика работа с регистрами или внутренним буфером. И при этом старые устройство и контроллер все ещё актуальны. В таком случае, необходимо либо создавать полностью новый драйвер, где данная особенность уже будет учтена, либо создавать отдельный драйвер для новых устройств.
Однако, подход создания нового драйвера для каждого нового контроллера не желателен, так как на это тратиться больше времени, а сам проект увеличивается в объемах. Если проект увеличиться до слишком большого размера, то замедлиться его разработка и поддержка, а также будет под вопросом работоспособность всего драйвера в целом.
Развитием данной работы может служить добавление поддержку новых контроллеров, систем на кристалле, а также разработка плана тестирования.
Номер журнала Вестник науки №6 (63) том 3
Ссылка для цитирования:
Петрушинин М.П. ПРОЕКТИРОВАНИЕ ДРАЙВЕРА ДЛЯ РАЗРАБАТЫВАЕМЫХ КОНТРОЛЛЕРОВ // Вестник науки №6 (63) том 3. С. 893 - 902. 2023 г. ISSN 2712-8849 // Электронный ресурс: https://www.вестник-науки.рф/article/9090 (дата обращения: 17.05.2024 г.)
Вестник науки СМИ ЭЛ № ФС 77 - 84401 © 2023. 16+