USB FEED Project
USB FEED DRIVER ARMv7 / STM32 / Qt5 / C++
USB FEED DRIVER
ARMv7 Cortex™ M3 / STM32F103
15.05.15
Особенности драйвера и протокола
FEED PROTOCOL
2.1 FEED FRAME PROTOCOL
2.2 FEED ADDRESS PROTOCOL
Класс USB Feed порта (C++ / Qt5)
Тест-терминал
1. Ключевые особенности FEED драйвера и протокола
Устройство использующее FEED протокол представляется USB хосту как стандартный USB CDC ACM порт, поэтому для “установки” устройства нужен только inf файл (ОС Windows)
Устройство может использовать прерывание предусмотренное USB CDC классом
Высокая скорость передачи: 4,5 Mbit / s. И это не предел, так как размер буфера Bulk точки всего 62 байта (Full Speed - 12 Mbit / s), который может быть увеличен до максимальных 1024 допускаемых USB стандартом а устройство переведено в режим High Speed (480 Mbit / s).
Малый размер кода драйвера устройства ~1,5 kB ( ARMv7 Cortex™ M3 - STM32F103 / оптимизация -O2 ). Драйвер не использует стандартных библиотек (STM32F10x_StdPeriph_Lib_Vxxx / STM32_USB-FS-Device_Lib_Vxxx)
Высокое отношение размера полезной нагрузки к сервисной информации во фрейме. Так например из 255 байт допустимого размера фрейма, только 6 являются сервисными (2,35 %), при 31-битном адресе интерфейса и 3 (1,17 %) при 8-битном.
Малый трафик. Минимальный размер фрейма 3 байта (операция чтения с 8-битного адреса).
Большой диапазон адресов интерфейсов - 2 147 483 648 (31 битная адресация)
FEED драйвер освобождает разработчика устройства от необходимости изучения работы USB и представляет её просто как линию связи
FEED протокол с минимальными изменениями может быть расширен на любые другие линии связи
Целостность каждого фрейма защищена CRC8
2. FEED PROTOCOL
Протокол типа точка-точка. Состоит из двух логических уровней на каждом из которых передачу данных обслуживает протокол соответствующего уровня.
Уровни разделяются на:
Канальный
Транспортный
Работу на канальном уровне выполняет FEED FRAME PROTOCOL (фрейм протокол), а на транспортном FEED ADDRESS PROTOCOL (протокол логической адресации). Сетевой уровень на данном этапе разработки протокола пропущен так как в нём нет необходимости. Изначально протокол разрабатывался для осуществления двунаправленной передачи данных по USB шине, между ПК и устройством и вопрос объединения нескольких устройств в сеть не стоял.
FEED протокол работает поверх протоколов физического канала связи. Поэтому может выполнять свои функции на любой линии связи с устройством. В данном случае в роли физического канала связи выступает USB шина, но в будущем протокол будет расширен и на другие линии связи с доработкой и написанием соответствующих драйверов под конкретный фид-канал.
В представлении фид-канала, любое устройство подключённое к фиду представляется в виде устройства с неограниченным (теоретически) набором функций (интерфейсов), где фрейм-протокол (FEED FRAME PROTOCOL) обеспечивает целостность и доставку данных до устройства, а протокол логической адресации (FEED ADDRESS PROTOCOL) предоставляет возможность дальнейшей селекции и доставки принятых данных к интерфейсу устройства.
2.1 FEED FRAME PROTOCOL
Протокол нижнего канального уровня в двухуровневой модели связи фид-канала.
На его уровне реализуется:
Формирование кадров передаваемых/принимаемых данных. Передаваемые данные, если их длина превышает максимальный допустимый размер кадра, разбиваются на кадры (фреймы) на передающей стороне и собираются из кадров на приемной.
Контроль длины и целостности кадра. Длина кадра указывается в заголовке кадра и занимает 1 байт от общей длины кадра. Контрольная сумма кадра также занимает 1 байт и является последним байтом кадра.
Сброс приёмного буфера устройства.
В заголовке кадра при передаче записывается полная длина кадра (включая байт заголовка и байт контрольной суммы). При приёме, приёмный буфер заполняется приходящими данными пока в него не будет считано указанное в заголовке количество байт. После приёма заявленного в заголовке кадра количества байт, выполняется проверка контрольной суммы кадра.
Контрольная сумма кадра рассчитывается побайтно для заголовка и данных кадра и является их инвертированной суммой (по модулю 256), т.е. если на приёмной стороне провести подобную операцию вычисления контрольной суммы, включая сам байт контрольной суммы, результат при безошибочной передаче должен быть равен нулю.
Исключительной ситуацией является нулевая длина кадра. В таком случае выполняется сброс/очистка приёмного буфера фид-канала устройства с потерей всех принятых данных включая буфер приёма физического уровня (в данном случае PMA-буфер USB модуля микроконтроллера).
При не совпадении вычисленной контрольной суммы кадра с указанной, драйвер фид-канала выставляет флаг FRAME_CRC_ERROR в статусе канала чтобы пользовательское приложение могло обработать эту ситуацию.
Кроме того, из “не используемых” на канальном уровне размеров кадра (как нулевой) есть ещё длины 1 и 2 байта., которые могут быть использованы как ACK и NACK сигналы передающей стороне при без ошибочной либо не совпадающей контрольной сумме кадра соответственно. Это освободит пользовательское приложение от необходимости обрабатывать случаи приёма “битых” кадров.
2.2 FEED ADDRESS PROTOCOL
Протокол верхнего транспортного уровня в двухуровневой модели связи фид-канала. Определяет интерфейс-получатель фид фрейма. На его уровне выполняются задачи:
Определение разрядности адреса интерфейса устройства
Определение адреса интерфейса устройства
Определение запрошенной операции над интерфейсом (Чтение / Запись) устройства.
Протокол допускает два вида разрядности адреса интерфейса, 8 и 31 битный адреса. Разрядность адреса интерфейса определяется по длине данных фид фрейма. Возможны 5 вариантов результата определения адреса и последующих операций над интерфейсом устройства:
0 длинна данных фрейма - не обрабатывается
1 байт данных - операция чтения одного байта с указанного 8 битного адреса интерфейса
2 байта данных - операция записи одного байта по указанному 8 битному адресу интерфейса
3 байта данных - контроль протокола, зарезервировано, на данный момент не используется
4 и более байт - чтение/запись по указанному 31 битному адресу интерфейса
Адреса интерфейсов свободно определяются пользователем (разработчиком устройства). Но для большей информативности и возможности обращаться к адресам интерфейсов посредством символьных терминалов рекомендуется выбирать адреса имеющие хорошее (человеческое) символьное представление.
Примеры адресов интерфейсов и запросы к ним (dwsfeed.h):
/*** DWord Strings defines ***/
/* interfaces */
#define dwsDEV 0x3E564544 // DEV> DEVice [common] interface
#define dwsMCU 0x3E55434D // MCU> MicroController Unit [main in device] interface
#define dwsMCU0 0x3055434D
#define dwsMCU1 0x3155434D
#define dwsMCU2 0x3255434D
#define dwsMCU3 0x3355434D
#define dwsCPU 0x3E555043 // CPU> Central Processing Unit [main in device MCU's kernel]
#define dwsRAM 0x3E4D4152 // abstract RAM> [Random-Access Memory] interface of device
#define dwsROM 0x3E4D4F52 // abstract ROM> [Read-Only Memory] interface of device
#define dwsMEM 0x3E4D454D // abstract MEM> [memory] interface of device
#define dwsFILE 0x454C4946 // abstract FILE interface of device
#define dwsDATA 0x41544144 // abstract DATA interface of device
#define dwsLOOP 0x504F4F4C // LOOP-back received messages
/* requests */
#define dwsNAME 0x454D414E // NAME [any]
#define dwsINFO 0x4F464E49 // INFOrmation
#define dwsVERS 0x53524556 // VERSion
#define dwsMODL 0x4C444F4D // MODeL
#define dwsTXDY 0x59445854 // TX DelaY
#define dwsPROG 0x474F5250 // PROGramming
#define dwsBINX 0x584E4942 // BINX data header
#define dwsREPT 0x54504552 // REPeaT
#define dwsREG 0x3E474552 // REGister [mcu/device]
#define dwsPORT 0x54524F50 // PORT [mcu/device]
#define dwsADDR 0x52444441 // ADDRess [mcu/device]
#define dwsSTAT 0x54415453 // STATe / STATus [any]
#define dwsECHO 0x4F484345 // ECHO [for any interface present]
#define dwsALOC 0x434F4C41 // AlLOCate [memory]
#define dwsFREE 0x45455246 // FREE [memory]
#define dwsUSER 0x52455355 // USER name
#define dwsAUTH 0x48545541 // AUTHorization [means process phase]
#define dwsPSW 0x3E575350 // PSW> PaSsWord [input password]
#define dwsSESS 0x53534553 // SESSion [for current user]
#define dwsNIRQ 0x5152494E // InterRupt Query [query state irq pin]
#define dwsTEST 0x54534554 // TEST [any]
#define dwsBOOT 0x544F4F42 // BOOTing / re-BOOTingОперация (чтение / запись), которую требуется произвести с адресуемым интерфейсом, определяется старшим битом в 32 разрядном поле заголовка адресного протокола.
Процесс передачи данных от приложения хоста к интерфейсу устройства и обратно:
Устройство ядра USB модуля STM32F10x
Для тестирования FEED драйвера использовалась отладочная плата OLIMEXINO-STM32 <STM32F103RBT6>
4. Тест терминал
