Главная > Дополнительно > Mipsfpga и uart

Mipsfpga и uart

Содержание

1 Список литературы
2 Метод передачи и приёма
- 2.1 Скорость (, бод) и длительность бита (, секунд) связаны соотношением
3 Description
4 Description
5 Синхронизация и выборка
6 UART
7 Dialog Semiconductor
8 Кратко о BLE
9 Стек протоколов BLE
10 Инструменты разработки
11 Особые условия приемника
12 CDC — виртуальный COM порт
13 Чипы CH340g, FTDI FT232, ATMEGA 16U2 / 8U2
14 MSC — запоминающее устройство

Список литературы

Adam Osborne, An Introduction to Microcomputers Volume 1: Basic Concepts, Osborne-McGraw Hill Berkeley California USA, 1980 ISBN 0-931988-34-9 pp. 116-126
C. Gordon Bell, J. Craig Mudge, John E. McNamara, Computer Engineering: A DEC View of Hardware Systems Design, Digital Press, 12 May 2014, ISBN 1483221105, p.73
Allison, David. «Curator, Division of Information Technology and Society, National Museum of American History, Smithsonian Institution». Smithsonian Institution Oral and Video Histories. Retrieved 14 June 2015.
Oral History of Gordon Bell, 2005, accessed 2015-08-19
Products; FTDI.
Interfacing with a PDP-11/05: the UART, blinkenbone.com, accessed 2015-08-19
«Zilog Product specification Z8440/1/2/4, Z84C40/1/2/3/4. Serial input/output controller» (PDF). 090529 zilog.com
«FAQ: The 16550A UART & TurboCom drivers 1994». Retrieved January 16, 2016.
T’so, Theodore Y. (January 23, 1999). «Re: Serial communication with the 16650». The Mail Archive. Retrieved June 2, 2013.
bill.herrin.us — Hayes ESP 8-port Enhanced Serial Port Manual, 2004-03-02

Метод передачи и приёма

Передача данных в UART осуществляется по одному биту в равные промежутки времени. Этот временной промежуток определяется заданной скоростью UART
и для конкретного соединения указывается в бодах (что в данном случае соответствует битам в секунду).

Существует общепринятый ряд стандартных скоростей: 300; 600; 1200; 2400; 4800; 9600; 19200; 38400; 57600; 115200; 230400; 460800; 921600 бод.

Скорость (, бод) и длительность бита (, секунд) связаны соотношением

Скорость в бодах иногда называют
сленговым
словом битрейт
.

Помимо собственно информационного потока, UART автоматически вставляет в поток синхронизирующие метки, так называемые стартовый и стоповый биты
. При приёме эти лишние биты удаляются из потока. Обычно стартовый и стоповый биты обрамляют один байт информации (8 бит), однако встречаются реализации UART, которые позволяют передавать по 5, 6, 7, 8 или 9 бит.

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

Принято соглашение, что пассивным (в отсутствие потока данных) состоянием входа и выхода UART является логическая 1.

Стартовый бит всегда логический 0,
поэтому приёмник UART ждёт перепада из 1 в 0 и отсчитывает от него временной промежуток в половину длительности бита (середина передачи стартового бита). Если в этот момент на входе всё ещё 0, то запускается процесс приёма минимальной посылки. Для этого приёмник отсчитывает 9 битовых длительностей подряд (для 8-битных данных) и в каждый момент фиксирует состояние входа. Первые 8 значений являются принятыми данными, последнее значение проверочное (стоп-бит).

Значение стоп-бита всегда 1
, если реально принятое значение иное, UART фиксирует ошибку.

Для формирования временных интервалов передающий и приёмный UART имеют источник точного времени
(тактирования). Точность этого источника должна быть такой, чтобы сумма погрешностей (приёмника и передатчика) установки временного интервала от начала стартового импульса до середины стопового импульса не превышала половины (а лучше хотя бы четверти) битового интервала. Для 8-битной посылки 0,5/9,5 = 5 % (в реальности не более 3 %). Поскольку эта сумма ошибок приёмника и передатчика плюс возможные искажения сигнала в линии, то рекомендуемый допуск на точность тактирования UART — не более 1,5 %.

Поскольку синхронизирующие биты занимают часть битового потока, то результирующая пропускная способность
UART не равна скорости соединения. Например, для 8-битных посылок формата 8-N-1 синхронизирующие биты занимают 20 % потока, что для физической скорости 115 200 бод даёт битовую скорость данных 92 160 бит/с или 11 520 байт/с.

Description

Driver API for Universal Synchronous Asynchronous Receiver/Transmitter (Driver_USART.h)

The Universal Synchronous Asynchronous Receiver/Transmitter (USART) implements a synchronous and asynchronous serial bus for exchanging data. When only asynchronous mode is supported it is called Universal Asynchronous Receiver/Transmitter (UART). Almost all microcontrollers have a serial interface (UART/USART peripheral). A UART is a simple device to send data to a PC via a terminal emulation program (Hyperterm, TeraTerm) or to another microcontroller. A UART takes bytes of data and transmits the individual bits in a sequential mode. At the destination, a second UART reassembles the bits into complete bytes. Each UART contains a shift register for converting between serial and parallel transmission forms. Wikipedia offers more information about the Universal asynchronous receiver/transmitter.

USART API

The following header files define the Application Programming Interface (API) for the USART interface:

Driver_USART.h : Driver API for Universal Synchronous Asynchronous Receiver/Transmitter

The driver implementation is a typical part of the Device Family Pack (DFP) that supports the peripherals of the microcontroller family.

Driver Functions

The driver functions are published in the access struct as explained in

ARM_DRIVER_USART : access struct for USART driver functions

Example Code

The following example code shows the usage of the USART interface for asynchronous communication.

#include «Driver_USART.h»

#include «cmsis_os.h»

#include <stdio.h>
#include <string.h>

void myUART_Thread(void const *argument);
osThreadId tid_myUART_Thread;

extern Driver_USART3;

void myUSART_callback(uint32_t event)
{
uint32_t mask;

mask = |
|
|
;

if (event & mask) {

osSignalSet(tid_myUART_Thread, 0x01);
}

if (event & ) {
__breakpoint(0);

}

if (event & ( | )) {
__breakpoint(0);

}
}

void myUART_Thread(const void* args)
{
static * USARTdrv = &Driver_USART3;
version;
drv_capabilities;
char cmd;

#ifdef DEBUG

version = USARTdrv->();
if (version. < 0x200)

{

return;
}
drv_capabilities = USARTdrv->();
if (drv_capabilities. == 0)
{

return;
}
#endif

USARTdrv->(myUSART_callback);

USARTdrv->();

USARTdrv->( |
|
|
|
, 4800);

USARTdrv-> (, 1);
USARTdrv-> (, 1);

USARTdrv->(«\nPress Enter to receive a message», 34);
osSignalWait(0x01, osWaitForever);

while (1)
{
USARTdrv->(&cmd, 1);

osSignalWait(0x01, osWaitForever);
if (cmd == 13)

{
USARTdrv->(«\nHello World!», 12);
osSignalWait(0x01, osWaitForever);
}

}
}

Description

Беспроводная передача данных: типы, технология и устройства

Driver API for Universal Synchronous Asynchronous Receiver/Transmitter (Driver_USART.h)

USART API

The following header files define the Application Programming Interface (API) for the USART interface:

Driver_USART.h : Driver API for Universal Synchronous Asynchronous Receiver/Transmitter

The driver implementation is a typical part of the Device Family Pack (DFP) that supports the peripherals of the microcontroller family.

Driver Functions

The driver functions are published in the access struct as explained in

ARM_DRIVER_USART : access struct for USART driver functions

Example Code

The following example code shows the usage of the USART interface for asynchronous communication.

#include «Driver_USART.h»

#include «cmsis_os.h»

#include <stdio.h>
#include <string.h>

void myUART_Thread(void const *argument);
osThreadId tid_myUART_Thread;

extern Driver_USART3;

void myUSART_callback(uint32_t event)
{
uint32_t mask;

mask = |
|
|
;

if (event & mask) {

osSignalSet(tid_myUART_Thread, 0x01);
}

if (event & ) {
__breakpoint(0);

}

if (event & ( | )) {
__breakpoint(0);

}
}

void myUART_Thread(const void* args)
{
static * USARTdrv = &Driver_USART3;
version;
drv_capabilities;
char cmd;

#ifdef DEBUG

version = USARTdrv->();
if (version. < 0x200)

{

return;
}
drv_capabilities = USARTdrv->();
if (drv_capabilities. == 0)
{

return;
}
#endif

USARTdrv->(myUSART_callback);

USARTdrv->();

USARTdrv->( |
|
|
|
, 4800);

USARTdrv-> (, 1);
USARTdrv-> (, 1);

USARTdrv->(«\nPress Enter to receive a message», 34);
osSignalWait(0x01, osWaitForever);

while (1)
{
USARTdrv->(&cmd, 1);

osSignalWait(0x01, osWaitForever);
if (cmd == 13)

{
USARTdrv->(«\nHello World!», 12);
osSignalWait(0x01, osWaitForever);
}

}
}

Синхронизация и выборка

Плата arduino uno r3: схема, описание, подключение устройств

Стандартные цифровые данные бесполезны без какого-либо механизма синхронизации. На рисунке ниже показано почему:

Выборка двоичных данных при приеме через UART

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

Однако, как следует из названия «универсальный асинхронный приемник/передатчик», интерфейс UART не использует тактовый сигнал для синхронизации устройств Tx и Rx. Так как же приемник узнает, когда сделать выборку сигнала данных передатчика?

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

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

Момент прихода стартового бита в приемник UART

Чтобы гарантировать, что активный фронт тактового сигнала приемника будет приходиться примерно на середину битового периода, частота тактового сигнала битовой скорости, переданная в модуль приемника, значительно выше (в 8 или 16, или даже в 32 раза) реальной битовой скорости.

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

процесс приема запускается по границе спада стартового бита;
приемник ждет в течение 8 циклов тактового сигнала, чтобы установить момент выборки, который находится близко к середине периода бита;
приемник ждет в течение 16 циклов тактового сигнала, которые приводят его к середине периода первого бита данных;
первый бит данных оцифровывается и сохраняется в регистре приемника, а затем модуль снова ожидает 16 циклов тактового сигнала перед выборкой второго бита данных;
этот процесс повторяется до тех пор, пока все биты данных не будут выбраны и сохранены, а затем нарастающий фронт стопового бита возвращает интерфейс UART в режим ожидания.

Выборка данных при приеме через UART

UART

Universal Asynchronous Receiver/Transmitter или просто UART используется с ранних 1960-х и с тех пор претерпевал постоянные изменения. Несмотря на то, что постоянно производятся попытки уничтожить UART, последовательные протоколы этого типа всё ещё представляют важный способ общения между устройствами встраиваемых систем.

UART представляет собой периферийное устройство в процессоре, с помощью которого осуществляется общение между устройствами по последовательному протоколу на небольшие расстояния. Кстати, UART является основой стандарта RS-232 (тот самый D-образный разъем с 9-ю пинами). В языке «С» вывод printf часто может передаваться напрямую через UART. Вообще порты работающие по UART чаще всего называются просто последовательными портами. В самой простой форме UART представляет собой три провода: земля, передача, приём.

Первая проблема UART в том, что нет возможности определить какое устройство ведущее, а какое ведомое (master/slave), так что непонятно к чему цеплять transmit? Обычно, это определяют за нас. Например, кто-то, кто проектирует печатную плату может назвать этот провод как TX и определить, что устройство должно соединяться так, тогда система будет выглядеть следующим образом:

В итоге получается вариант, когда процессор и принимает, и передаёт данные. Другой способ конфигурации выглядит вот так:

Тогда получается вариант, где процессор всегда передаёт (TX) получателю (RX) и наоборот. Какой вариант правильный? Оказывается это решение принимает за нас производитель чипа и готовой платы/устройства. Я видел множество примеров использования обоих вариантов настолько часто, что без прочтения даташита невозможно было определить как именно следует производить конфигурацию устройств. Если бы я имел контроль над наименованием, то закрепил второй вариант, когда TX соединено с RX. На практике чаще всего TX, подсоединённый к TX, приводит к сгоранию чипов (тоже верно и для RX-RX), так что это хороший пример того, что надо читать документацию перед тем как соединять чипы по UART, так как существует несколько способов соединения.

Когда отправитель и получатель располагаются на одной плате, тогда уровень напряжения сигнала при передаче соответствует уровню напряжения питания процессора. К примеру, «1» будет передаваться с напряжением 3.3В, а «0», грубо говоря, с 0В. Это неочень полезно тогда, когда требуется передать сигнал более, чем на несколько дюймов (1 дюйм = 2.54 см), так как начинают появляться искажения сигнала и увеличивается падение напряжения. В итоге, чем дальше расстояние, тем количество ошибок передачи растет и в итоге становится невозможно передать сообщение, так как оно поступает до невозможности искаженным.

Для того, чтобы избежать подобной ситуации добавляют дополнительные чипы-буферы, усиливающие сигналы. После этого сигналы могут передаваться уже на метры без существенной потери информации. Однако, напряжения при передаче битов довольно странные: для передачи 1 используются -3В..-15В, а для передачи 0 — от +3В до +15В. Это те самые напряжения, которые используются в RS-232. Кстати, буферы в RS-232 также являются ограничителями тока, так что контакты разъёма можно замыкать между собой и он не выгорит.

Dialog Semiconductor

самые маленькие BLE чипыDA14583Cortex-M00 dBmBluetooth 4.1.

Кратко о BLE

здесьController«Vol.6 Core System Package »Host«vol.3 Core System Package »(Кликнуть для увеличения)AdvertisingManufacturer Specific DataScanRequestScanResponceBLEWi-Fi

Стек протоколов BLE

BLEHostControllerHostControllerHCIHost Controller InterfaceHostControllerBluetoothHCIUSBHCIHostGATTGAP, L2CA, SMP, HCIGAP APICentral, Peripheral, Observer, BroadcasterGATT API(Кликнуть для увеличения)(Кликнуть для увеличения)(Кликнуть для увеличения)(Кликнуть для увеличения)

Инструменты разработки

Средства разработки с предлагаемые сайтом Bluetooth Special Interest Group (Bluetooth SIG) — https://www.bluetooth.com/develop-with-bluetooth/developer-resources-toolsBluetooth SIG

Особые условия приемника

Ошибка переполнения

«Ошибка переполнения» происходит, когда приемник не может обрабатывать символ, который только что пришел так как предыдущий еще не обработан. Различные устройства имеют разные объемы буферной памяти для хранения полученных символов. Процессор должен поддерживать УАПП, чтобы удалить символы из входного буфера. Если процессор не поддерживает УАПП буфер достаточно быстро становится полным, будет происходить ошибка, и входящие символы будут потеряны.

Ошибка опустошения

«Ошибка опустошения» возникает, когда передатчик УАПП завершил отправку данных и буфер передачи пуст. В асинхронном режиме это трактуется как признак того, что не осталось никаких данных, подлежащих передаче, но дополнительные стоповые биты могут быть добавлены. Это сообщение об ошибке обычно возникает в УМПВВ (Universal Synchronous Asynchronous Receiver Transmitter — USART), так как опустошение является более серьезным в синхронных системах.

Ошибка кадрирования

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

Ошибка четности

«Ошибка четности» возникает, когда соотношение числа первых битов не сходится с битом четности. Использование бита четности не является обязательным, так что эта ошибка будет происходить только тогда, когда была включена четность проверки.

CDC — виртуальный COM порт

переехал на STM32 CubeCube для контроллеров серии STM32F1графического конфигуратора CubeMXusb in a nutshellна русском

bDeviceClass, bDeviceSubClass и bDeviceProtocol — описывают хосту что же это у нас за устройство такое, что оно умеет и какие драйвера нужно грузить. В данном случае тут сказано, что устройство у нас реализует Communication Device Class, а значит хосту нужно сделать виртуальный COM порт и связать его с этим устройством.
PID (Product ID) и VID (Vendor ID) — по этим полям хост различает разные устройства, подключенные к системе. Устройства при этом реализовывать одинаковый класс

Говорят для устройств продаваемых на рынке очень важно иметь уникальные VID/PID, но я не узнавал кто и где выдает эти ID-шники. Для домашнего устройства в единственном экземпляре достаточно значений по умолчанию.

wTotalLength — размер всего пакета дескрипторов для этой конфигурации — чтобы хост знал где заканчивается эта конфигурация и начинается следующая. Нам его нужно будет поправить, когда мы будем делать композитное устройство. Напомню, что все интерфейсы для этой конфигурации должны располагаться сплошным блоком, а значение wTotalLength определяет длину этого блока.
bNumInterfaces: класс Communication Device реализуется с помощью двух интерфейсов. Один для управления, другой для собственно пересылаемых данных.
bmAttributes и MaxPower указывает, что наше устройство имеет собственный источник питания, но при этом хочет потреблять до 100 мА от USB порта. С этими параметрами явно придется поиграться в будущем.

Class Driver (в случае CDC это файлы usbd_cdc и usbd_cdc_if): реализуют логику конкретного класса устройств — CDC для виртуального COM порта, MSC для устройств хранения данных, HID для клавиатур/мышек и всяких специфических устройств с пользовательским интерфейсом.
USB Core (usbd_core.c, usbd_ctlreq.c, usbd_ioreq.c): реализует общую логику работы всех классов USB устройств, умеет отдавать хосту запрашиваемые дескрипторы, обрабатывает запросы от хоста и настраивает USB устройство в целом. Также перенаправляет потоки данных из уровня драйвера класса в нижележащие уровни и наоборот.
USB HW Driver (usbd_conf.c): Вышележащие слои платформенно независимые и работают одинаковым образом для нескольких серий микроконтроллеров. В коде нет низкоуровневых вызовов функций конкретного микроконтроллера. Файл usbd_conf.c реализует прослойку между USB Core и HAL — библиотеке низкоуровневых драйверов для выбранного микроконтроллера. В основном тут живут простые врапперы, которые перенаправляют вызовы сверху вниз и коллбеки снизу вверх.
HAL (stm32f1xx_hal_pcd.c, stm32f1xx_ll_usb.c): занимаются общением с железом микроконтроллера, оперирует регистрами и отвечает на прерывания.

тут Virtual COM Port драйвер от STM

Чипы CH340g, FTDI FT232, ATMEGA 16U2 / 8U2

Обычно с чипами USB преобразователей и поиском драйверов сталкиваются в тот момент, когда возникает проблема подключения платы к компьютеру. Скорее всего, вы тоже нашли эту статью, пытаясь заставить Arduino IDE взаимодействовать с китайской ардуинкой. Давайте разберемся, какую роль во взаимодействии с компьютером играет чип преобразователя и зачем устанавливать какие-то драйверы, чтобы все заработало.

Зачем нужен USB / UART TTL преобразователь

Когда вы подключаете Ардуино к компьютеру или любому другому устройству по USB, вы связываете между собой сразу два мира: микропроцессорный, сосредоточенный на плате Arduino и мир внешних устройств. Подходы к организации взаимодействия между элементами в этих мирах сильно отличаются. Для работы внутри платы используется особый протокол со своими правилами взаимодействия – UART. И для того, чтобы “внутреннюю” линию соединить с “внешней” нужен определенный преобразователь-посредник, который будет хорошо понимать физические сигналы, используемые как для USB, так и для платы контроллера. Вот этим посредником и являются чипы USB- UART (иногда их еще обозначают называют USB-TTL, хотя это не совсем корректно) преобразователей, самыми популярными из которых являются микросхемы FTDI, CH340G, ATMEGA U16.

USB преобразователи в Ардуино

Мы должны использовать внешние чипы, потому что контроллер ATMEGA328, являющийся сердцем большинства современных плат Arduino, не содержит в своих кристаллических внутренностях встроенного преобразователя. Если вы посмотрите на плату ардуино, то увидите корпус чипа, на нем можно разобрать и его тип.

Исторически наиболее популярным вариантом чипов USB/UART конвертера была линейка микросхем от шотландского производителя FTDI. Главным ее недостатком была стоимость и весьма странная политика в области контроля контрафакта, зачастую приводящая к тому, что легальные купленные устройства блокировались драйверами компании. Сегодня существенную конкуренцию FTDI составляют микросхемы семейства CH340, массово производимые многочисленными китайскими производителями. Они гораздо дешевле и достаточно надежны и это постепенно привело к тому, что в большинстве недорогих контроллеров Arduino и адаптеров установлены именно чипы CH340 (CH340g).

Наверное, единственной, но очень важной проблемой при использовании CH340g взамен FTDI является необходимость в некоторых случаях установки USB драйвера. “Респектабельная” FTDI давно уже тесно интегрирована в Windows и при подключении устройства с FTDI-преобразователем никаких драйвером устанавливать не нужно – они уже есть в системе

Для подключения CH340g иногда нужно скачать драйвер и установить его – только после этого система увидит наше устройство.

Процедура установки драйвера для CH340g на самом деле очень проста и почти всегда проходит без ошибок на самых популярных операционных системах Windows7, Windows10. Именно поэтому никаких проблем с использованием недорогих ардуино плат, несущих на себе чип CH340, почти никогда не возникает.

Остается только вопрос – а зачем вообще нужен какой-то USB драйвер для подключения ардуино к компьютеру? Давайте разберемся.

USB драйвер для ардуино

Мы не будем уходить в теоретические дебри, разбирая многочисленные коммуникационные протоколы, поддерживаемые современными компьютерными системами. Главное, что нужно понимать: когда мы присоединяем какое-то устройство к компьютеру, оно может передавать или получать данные только если его “поймут” с другой стороны. На стороне компьютера таким переводчиком является специальная программа, называемая драйвером. Драйвер USB работает в режиме эмуляции последовательного, COM-порта. Это означает, что при подключении операционная система создает виртуальные, программные COM-порты, с которыми и работает драйвер. В Windows их можно посмотреть в диспетчере устройств.

Если мы подключаем Ардуино к компьютеру, то чип с помощью драйвера попросит систему открыть порт и начнет взаимодействие . И для чипов разных производителей потребуются разные драйвера. Проблемы возникают, когда драйвера нет. Система пытается найти его для подключенного устройства, не находит и мы никогда не увидим его в списке устройств. Для решения проблемы надо найти и скачать соответствующие драйвера, а затем установить их на компьютер. Ниже мы рассмотрим, как это делается на примере USB драйвера CH340.

MSC — запоминающее устройство

SdFat

Пользователю предоставляется класс File, через который можно создавать/открывать файлы, читать и писать данные. Клиентский код не парится взаимодействием с носителем информации и тонкостями файловой системы.
Класс Volume занимается всей кухней по обслуживанию файловой системы, каталога, кластеров, FAT и такого прочего. Общение с носителем данных делегируется в нижележащие уровни.
Драйвер SD карты — этот компонент знает как общаться с картой, какие ей слать команды и какие слушать ответы. Библиотека предоставляет несколько видов драйверов для карт подключенных по SPI и SDIO. Теоретически можно подставить свой драйвер, например, для RAM диска.
Вышележащие слои кроссплатформенные, они ничего не знают о том как именно данные будут писаться на карту или читаться с нее. Это позволяет собирать библиотеку под разные платформу (как Ардуино, так и другие). Для конкретной платформы или микроконтроллера можно написать драйвер, который будет реализовывать передачу данных через необходимый интерфейс. По умолчанию библиотека предоставляет несколько драйверов, в т.ч. для ардуиновского SPI, но я заморочился и написал свой драйвер ~~с преферансом и поэтессами~~ передачей через DMA на основе HAL.
Наконец, HAL обеспечивает работу с регистрами конкретного микроконтроллера

спецификации вот линка

Оцените статью: