ПРОЕКТИРОВАНИЕ ДРАЙВЕРА ДЛЯ РАЗРАБАТЫВАЕМЫХ КОНТРОЛЛЕРОВ Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 627.7

Петрушинин М.П.

студент магистратуры кафедры математического обеспечения и стандартизации информационных технологий Российский технологический университет МИРЭА (г. Москва, Россия)

ПРОЕКТИРОВАНИЕ ДРАЙВЕРА ДЛЯ РАЗРАБАТЫВАЕМЫХ КОНТРОЛЛЕРОВ

Аннотация: цель работы - спроектировать драйвер для разрабатываемых контроллеров NOR-памяти типа FLASH и SRAM. В качестве устройств были взяты CY62167EV30 и S29GL для SRAM и FLASH памяти соответственно. Особенность контроллера для этих типов устройств в том, что существует множество вариаций работы. Необходимое условие для работы драйвера - это возможность работы без операционной системы, так называемый Bare Metal.

Ключевые слова: драйвер, SRAM, FLASH, импортозамещение, проектирование, Bare

Metal.

Введение

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

Основным требованием для разработки контроллера NOR-FLASH/SRAM - это предусмотреть возможность расширения функционала контроллера на любом этапе его проектирования. Таким образом, драйвер становится способным работать с разными режимами, устройствами и так далее.

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

Проектирование

Поддержка разных типов памяти

Драйвер для контроллера должен уметь работать как с памятью типа FLASH, так и SRAM.

Для FLASH памяти будет использована архитектура NOR. Данная архитектура использует логическую операцию «ИЛИ НЕ» для преобразований входные напряжений в выходные.

С точки зрения программирования FLASH память является более сложной. Так, чтобы осуществить какую-либо операцию необходимо заблаговременно осуществить несколько циклов команд. Они представляют из себя запись определенных параметров в заранее известные адреса.

Например, операция записи может выглядеть так:

- первый цикл - запись данных 0x00AA по адресу OxAAA;

- второй цикл - запись данных 0x0055 по адресу 0x555;

- третий цикл - запись данных 0x0025 по адресу 0xAAA.

И только после этого в контроллер необходимо записывать буфер. И, когда все данные будут подготовлены, записать 0x0029 по адресу сектора, что даст контроллеру команду о начале записи.

SRAM в этом плане выглядит проще. Для записи требуется только адрес, куда идет запись и сами данные.

Поддержка разных режимов работы

У разных устройств могут быть предусмотрены дополнительные режимы работы контроллера, такие как:

- режим работы burst. В этом режиме данные записываются не по одной единице за раз, а сразу несколько;

- режим работы page read. В этом режиме данные, аналогично режиму burst, данные считываются целой страницей;

- режим работы с преамбулами. Данный режим работы с FLASH автоматически выполняет необходимые циклы команд перед операцией;

- режимы работы с шинами данных в 8 бит и 16 бит;

- режим работы мультиплексирования. При работе с шиной данных в 16 бит в этом режиме часть адреса используется как данные.

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

Поддержка разных версий разрабатываемого контроллера

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

Имплементация в разных системах на кристалле

В разных системах на кристалле может быть поддержаны только определенные версии контроллеров. Драйвер должен иметь возможность использовать конкретную версию контроллера. При необходимости заменить в системе на кристалле одну версию на другую или добавить новую.

API уровень для обращения к функциям драйвера

Данный уровень абстракции должен быть самым высоким. Функции, реализованные здесь, не должны знать о том, как работает устройство и были ли внесены какие-либо изменения.

Таким образом, получившийся драйвер должен быть разделен на уровни, показанные на рисунке 1.

А nor/sram write() read()

config bsp work mode burst page read preambule

) xS /il6 multiplex

Version set_ver5ion() get_version()

SoC setupQ

Рис. 1. Общая архитектура драйвера.

Из рисунка 1 видно, что драйвер разделен на следующие уровни абстракции:

- уровень разных типов памяти. Предоставляет общие методы для чтения и записи данных. Возможно, архитектура памяти устроена таким образом, что операции чтения и записи осуществляются в обратном порядке. На данном уровне также предусматривается этот вариант;

- уровень разных устройств. На этом уровне обозначаются особенности конкретного устройства, такие как временные параметры, или, если это FLASH, необходимые циклы команд;

- уровень разных режимов работ. Предполагается, что если в каком-то контроллере отсутствует режим работы, то этот этап будет игнорироваться;

- уровень разных версий контроллера;

- уровень разных СНК. На этом уровне будут определяться какие

версии контроллера надо задействовать;

- общий уровень API для взаимодействия с драйвером.

В результате проектирования драйвера получилась структура, благодаря которой возможно легко добавлять новые устройства. Этому факту свидетельствует то, что в реализованном драйвере уже присутствуют несколько версий и СНК. По грубым расчетам, для поддержки нового контроллера, необходимо будет потратить одну рабочую неделю в самом не благоприятном случае.

Описание реализации

При реализации использовалась архитектура, представленная на рисунке 1.9. В проекте были реализованы следующие уровни:

- общий уровень API - «api»;

- уровень настройки драйвера для работы с конкретной отладочной платой - «bsp»;

- уровень реализации методов взаимодействий устройства - «driver»;

- уровень имплементации в разных СНК - «soc»;

- уровень реализации тестов согласно плану тестирования - «tests»;

- уровень подсчета временных параметров - «timing»;

- уровень использования нужной версии контроллера - «version».

Реализация API

Разработка драйвера началась с уровня «driver». Здесь были реализованы методы обращения с устройством.

На рисунке 2 показан код реализации команды очистки для FLASH памяти.

ф ф В el«ar_chip.c

1 ^include "driver.hfl

2

J void dr*v_flashl6_clear_chip (dr*v_mem_device_t* dev) { uint32_t base - dev-^iiase; if(de\i-^drv_mem_commands) {

HALF_REG(base + Cdev-> drv_mem_conimands->erase_chip. cm£i_cycZe[6] . addr & 6xfffe)) = de4->drv_mem_commands->erase_chip. cmd_cycle[Q] . data

HALF_REGCbase + Cdev-sdrv_mem_comiiiands->erase_chip. c/?!£i_cvcle[l].addr & Bxfffe)) - de4->drv_mein_coiiiiiiands->erase_chip. cmd_cycle[l]. data

HALF_REG[base + (dev-> drv_mem_coinmands->erase_chip. cffltf_c/cle[2] . addr £ Bxfffe)) - dev->drv_mem_commands->erase_chip. сл?£/_сус1е[2]. data

HALF_REGCbase + (dev->drv_mein_coipinarids->erase_chip.cmd_cycle[Z].addr £ Bxfffe)) = de4->drv_mem_coii]iiiands->erase_chip. cmd_cycle[Z]. data

HALF_REG(base + (.6e4->drv_mem_commands->erase_chip. cmd_cycle[tt]. addr & Bxfffe)) = dev->drv_mem_coinmands->erase_chip. cmd_cycle[6]. data

HALF_REG(base + Cdev-> drv_meir}_commands->erase_chip. cmd_cycle[5]. addr & Bxfffe)) = de4->drv_mein_cominand5->era5e_ctiip. cmd_cycle[5] .data 12 > else {

HALF_REG(base 4- 0ХААА) = 0X66AA;

HALF.REGCbase + 0x554) = 0x6655;

HALF_REG(base + SxAAA) = 0x6680;

HALF.REGCbase + 0ХААА) = OxGBAA;

HALF_REG[base + 0x554) = 0x6655;

HALF REGCbase + 0ХААА) = 0x6610;

19 J

22 void drv_flash8_cl.ear_chip (drv_men_device_t* dev) ■{

uint32_t base = dev-^j&ase; ifidev^drv_meni_cominands) {

BYTE_REG(base + Cdev-> drv_mem_conimands->erase_chip. cm£i_cycZe[6] . addr)) = de4->drv_meni_comiiiands->erase_ch2p. cmd_cycle[Q] . data

BYTE_REGCbase + Cdev->drv_msm_connnands->srase_chip. cffltf_cycle[l].addr)) = de4->drv_mein_coinuiands->erase_chip.cn!d_cycle[l] .data

BYTE_REG[base + {6e4->drv_mem_coinmands->erase_chip. caid_cycle[2] .addr)) = dev->drv_mem_commands->erase_chip. cmd_cycle[2] . data

BYTE_REG[base + Cdev->drv_men}_coii}inands-> erase_chip.c/?iii_cycle[3] .addr)) dev >drv_rnem_commands >erase_chip. ~i7>d_cycle[Z] .data

BYTE_REG(base + (.6e4->drv_mem_commands->erase_chip. ctnd_cycle[tt] . addr)) = Ae4->drv_mem_cominands->erase_chip. cfl?£/_cycle[4] . data

BYTE_REG(base + drv_meir}_commands->erase_chip. c/?iii_cycle[5] .addr)) dev->drv_insw_coimrands->erase_chip. cmd_cycle[5] .data 31 } else <

BYTE_REG(base 4- 0ХААА) = 0xAA;

BYTE.REGtbase + 0x555) - 0x55;

BYTE_REG(base + 0ХААА) = 0x86;

BYTE.REGCbase + 0ХААА) = OxAA;

J6 BYTE_REG(base + 0x555) = 0x55;

BYTE REGCbase * 0ХААА) = 0x16;

JC J

• 2.4k g)~/»/C/ flash/cleap_chip.с 1:18 Top 21 CO 166» 4 LF C/*l

Рис. 2. Реализация методов очистки для FLASH памяти.

Можно наблюдать, что для реализации были использованы операции разблокировки. В случае же, если используется SRAM память, то аналогичные методы будут объявлены, однако тела будут пустыми, так как для SRAM не предусмотрена операция очистки.

Далее, в ходе реализации проекта, был создан уровень подсчета временных параметров.

Во время создания данного уровня были реализованы методы для подсчета временных параметров. Реализованные методы и выставленные временные параметры соответствуют документациям для выбранных устройств.

После этого был разработан уровень «bsp». Данный уровень нужен для того, чтобы была возможность протестировать один и тот же контроллер на разных отладочных платах. На этом уровне вызываются необходимые временные параметры и методы для их подсчета, в соответствии с работающей частотой контроллера.

В завершении, перед реализацией основного уровня «api» были созданы абстракции «version» и «soc». Они нужны для того, чтобы была возможность расширения драйвера с добавлением поддержки новых версий контроллера FLASH или SRAM и имплементации их в разных СНК соответственно.

Чтобы, начать тестирование, требуется основное API, которое позволит комфортно и эффективно работать со всеми уровнями драйвера. Методы на данном уровне абстракции работают над всеми другими, оперируя ими внутри себя и скрывая сложную логику. На рисунке 3 показан весь проект драйвера.

г- • • • n or-f 1 as h - sram -driver -ч

/Users/misha/wrksp/C/nor- flash-sram-driver :

total used in directory 0 available 208.4 GiB

drwxr xr X s misha staff 160 May 21 23:31 api

drwxr xr X S misha staff 160 May 21 23:23 bsp

drwxr xr X 6 misha staff 192 May 21 23:23 driver

drwxr xr X S misha staff 160 May 21 22:42 soc

drwxr xr X 7 misha staff 224 May 21 23:36 tests

drwxr xr X 7 misha staff 224 May 21 22:42 timing

drwxr 1 xr X S misha staff 160 May 21 22:42 version

• № ià - nor-f"lash-sram- driver 10:0 All. QO 100%% LF Dired by name i

Рис. 3. Проект драйвера.

Реализация тестов

После создания работоспособного API, необходимо проверить его работу, а также работу контроллеров SRAM и FLASH согласно плану тестирования. При создании тестов были учтены реальные возможные сценарии работы с драйвером.

На рисунке 4 представлен один из разработанных сценариев.

Гф 9 $ В multiplex.с

1 ftinclude "nsc-api.hfl

3 extern nsc_device_t nsc_dev;

Л void test_nsc_preambu"leCnsc_device_t* device, uint32_t bank);

5 void test_nsc_preambu"le_reset_chipCnsc_device_t *device, uint32_t bank);

7 int mainO

8 <

9 boot all_test_run_skipped = 1;

10 TEST ITERATIONCuint32 t, dev num, NSC TEST DEVICE)

и {

12 nsc_wrapper *desc - &nsc_descs[*dev_num];

13

и /* NEW NSC DEVICE */

15 nsc_reset_device(&nsc_dev);

16 nsc_controller_t *ctr = nsc_dev.controller = (nsc_controller_t *) desc->nsc.base;

17 nsc_dev.mem_base = desc->nsc.memory_base;

18 nsc_dev.Icru = desc->lcru;

19 nsc_dev.pads = desc->patfs;

2в nsc_dev. irq - desc->ir<7;

21

22 /* INIT NSC DEVICE AND CHECK DEFAULTS REG VALUES */

23 nsc_init_device(Snsc.dev);

24 /* CONFIG BANKS */

25 TEST ITERATION(size t, banks, NSC TEST BANK CHECK)

26 {

27 size_t idx = «banks;

28

29 if <.tiesc->nsc.bank[iax].mode == NSC_MODE_BANK_DIS) {

Зв ctr->bank[idx],config3.reg = 0;

31 > else {

32 nsc config bankC&nsc dev, idx, Sdesc->nsc.6an/i[idx]);

33 >

ЗА y

1 • 2.5k © ~/w/C/n/tests/multiplex.c 1:19 Top ■f LF C/*l

^End of buffer

Рис. 4. Сценарий работы контроллера в режиме мультиплексирования.

Заключение

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

Например, в разработанной структуре драйвера присутствует уровень, который отвечает за разные версии разрабатываемого контроллера. Он позволяет добавлять поддержку новых версий контроллера, оставляя при этом возможность работать и со старыми. Если не предусмотреть данную возможность, то возникнет ситуация, когда для нового устройства в контроллере была изменена логика работа с регистрами или внутренним буфером. И при этом старые устройство и контроллер все ещё актуальны. В таком случае, необходимо

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

Однако, подход создания нового драйвера для каждого нового контроллера не желателен, так как на это тратиться больше времени, а сам проект увеличивается в объемах. Если проект увеличиться до слишком большого размера, то замедлиться его разработка и поддержка, а также будет под вопросом работоспособность всего драйвера в целом.

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

СПИСОК ЛИТЕРАТУРЫ:

1. CY62167EV30 MoBL®, 16-Mbit (1M х 16/2M х 8) Static RAM [Электронный ресурс]. URL: https://www.infineon.com/dgdl/Infineon-CY62167EV30_MoBL_16-Mbit_(1M_x_16_2M_x_8)_Static_RAM-DataSheet-

v18_00-EN.pdf?fileId=8ac78c8c7d0d8da4017d0ebe4ea831c9 (Дата обращения 05.05.2023);

2. Брайант, Р. Э. Компьютерные системы. Архитектура и программирование // 3-е изд., 2022. 994 с.

3. Харрис, Д. М. Цифровая схемотехника и архитектура компьютера RISC-V // 2022. 810 с.

4. Авдеев, В. А. Организация ЭВМ и периферия с демонстрацией имитационных моделей: учебное пособие // 2014. 708 C.

5. Керниган, Б. В. Язык программирования C: учебник / Б. В. Керниган, Д. М. Ричи. — 2-е изд. — Москва: ИНТУИТ, 2016. — 313 C.

6. Ким А. К., Перекатов В. И., Ермаков С. Г. Микропроцессоры и вычислительные комплексы семейства "Эльбрус". // 2013. 272 C.

7. Селиванова, И. А. Построение и анализ алгоритмов обработки данных: учебно-методическое пособие // 2015. 108 C.

8. Кольцов, Д. М. Эффективный Си на примерах. 100 готовых решений:

учебное пособие // 2022. 272 C.

9. Кетков, Ю. Л. Введение в языки программирования C и C++: учебное пособие // 2016. 291 C.

10. Пош, М. Программирование встроенных систем на С++ 17: учебное пособие // 2020. 394 C.

Petrushinin M.P.

Master's degree student of the Department of Mathematical Support and Standardization of Information Technologies of the Russian Technological University MIREA (Moscow, Russia)

DESIGNING A DRIVER FOR THE CONTROLLERS BEING DEVELOPED

Abstract: the purpose of the work is to design a driver for the developed NOR memory controllers such as FLASH and SRAM. CY62167EV30 and S29GL were taken as devices for SRAM and FLASH memory, respectively. The peculiarity of the controller for these types of devices is that there are many variations of operation. A necessary condition for the driver to work is the ability to work without an operating system, the so-called Bare Metal.

Keywords: driver, SRAM, FLASH, import substitution, design, Bare Metal.