Проводим нагрузочное тестирование скоростных USB-библиотек для STM32F103C8T6

Само собой, я еле дождался выходных, чтобы провести проверки. Давайте рассмотрим результаты испытаний. А чтобы было интересней, попутно рассмотрим технологию отображения переменных «на лету», без остановки процессорного ядра. Ну, и технологию визуальной отладки elf-файлов, собранных пакетными компиляторами.

Какое тестирование будем проводить

Суть тестирования была обсуждена в комментариях к предыдущей статье. Исходная программа для PC шлёт данные. Какие – не важно. Данные, и всё тут. Контроллер эти данные принимает и благополучно игнорирует. Потому что вопрос был в скорости передачи. Новые библиотеки теоретически могут либо пропустить часть данных, либо перепутать местами пару буферов. Поэтому поток должен стать меняющимся по времени. В таких случаях, шлют либо псевдослучайную последовательность, либо инкрементирующиеся данные.

Не имея желания тратить много времени на формирование псевдослучайной последовательности для источника и приёмника (алгоритм же должен совпадать), я ограничился инкрементирующимся 32-битным словом. Главный недостаток такого подхода – в соседних пакетах могут совпадать вплоть до трёх байтов из четырёх. Но один, причём самый первый – будет различаться. Так что для сегодняшнего теста мне это кажется допустимым.

Дело в том, что протокол USB – пакетный. И сам пакет ловится на аппаратном уровне. Внутри блока не должно быть ситуации, что байт искажён, а дальше – снова пошли полезные данные. По крайней мере, из-за тех проблем, которые мы в библиотеках сейчас хотим поймать, такого не возникнет. Если данные и будут искажены, то глобально. Если же произойдёт затирание старых данных новыми, то в первую очередь будет затёрт первый байт, а он в разных пакетах – разный.

В принципе, все желающие смогут переписать мой код на другой вариант тестовых данных… Сегодня же, я просто буду слать инкрементирующееся 32-битное слово, а при приёме – проверять, что инкремент идёт без нарушения последовательности.

Как мы будем отслеживать результат

Как мы будем выяснять, что всё работает? Одного светодиода будет мало. Ну, а чтобы добавлять UART, надо сильно корёжить чужой код. Можно внести свои ошибки. Давайте воспользуемся функциональностью, о которой я знаю давно, но всегда пользовался ею только в среде разработки Keil. Сегодня я покажу, как ею воспользоваться в Эклипсе. Из комментариев к прошлой статье, я понял, что об этой технологии знают не все.

Отладочный порт JTAG позволяет вести работу, только когда процессорное ядро остановлено. Это неприемлемо для USB. Там и при обычной-то работе остановки чреваты таймаутами, а в нашем случае – даже если мы не поймаем таймаут, то скорость может быть занижена. К счастью, отладочный порт SWD позволяет отслеживать память на лету. В далёком 2016-м я проверял при помощи осциллографа, позволяющего задавать синхронизацию по длительности импульса, доступ к памяти силами SWD практически не замедляет работу процессорного ядра. Но как мы им воспользуемся?

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

А второе – это то, что мы с ребятами недавно нашли. У нас в конторе этого не знал никто. Оказывается, если собрать проект пакетным компилятором, внедрив в него отладочную информацию Dwarf-2, то затем этот elf-файл можно открыть в Эклипсе на отладку и получить полную связь с его исходниками. При этом сами исходники к проекту подключать не требуется. Отладчик будет автоматически подтягивать пути к ним из отладочной информации. Теперь я всегда так делаю. Собран проект GCC или CLang, а я просто подключаю elf к Эклипсе и трассирую её, не тратя времени на присоединение к этой Эклипсе самого проекта. Мне иногда даже присылают elf-файлы, собранный тулчейнами, которых нет на моей машине. Даже собранные в Линуксе (а я работаю с Windows). Метод работает даже в этих случаях, лишь бы проект был прислан в полном комплекте: elf и его исходники. Сегодня нам это поможет не дорабатывать авторские проекты в плане их структуры. Я просто буду собирать всё на базе «родных» makefile, а затем – подключаться отладчиком к elf-файлу.

Тренируемся подключаться

Первое, что нам понадобится сделать в CubeIDE, проект для STM32F103. «Минуточку!», —воскликнет внимательный читатель… «Автор только что обещал, что не придётся ничего делать с оригинальным проектом!!!». Всё верно. Это бзик CubeIDE. Нам нужен проект для STM32F103. Любой. Главное, чтобы он был под STM32F103. Создаём его, собираем и забываем. Что в нём – не важно. Важен сам факт его существования в среде разработки.

Теперь в CubeIDE идём в настройки отладчика. Например, так:

Нам бы не пришлось извращаться с созданием левого проекта, если бы мы выбрали пункт GDB Hardware Debugging. Я всегда выбираю его в обычных Эклипсах. Пробовал я его выбрать и тут:

Увы. Левый проект будет не нужен, но зато про функциональность отображения переменных в реальном времени говорят, что она недоступна. Поэтому увы и ах. Выбираем STM32 Cortex-M C/C++ Application. У меня там уже есть две конфигурации. Сейчас, чтобы убедиться, что я вас не обманул, я создам третью. Для этого дважды щёлкаю сюда:

Назову конфигурацию Article:

Надо выбрать путь к elf-файлу:

Я выбрал такой путь (нигде в пути не должно быть русских букв):

И вот тут загорается ошибка. Вот она, красненькая:

Чтобы её убрать, я должен выбрать проект, привязанный к STM32F103. Вот тут-то и надо ткнуть в Browse:

И выбрать заранее созданный левый проект.

Красненькое (признак ошибки) ушло:

Ой! На этом рисунке видно, что у меня после выбора проекта спрыгнуло имя elf-файла. Прописался elf этого проекта. Пришлось выбрать нужный после указания проекта ещё раз. Не зря пробежался по всем пунктам.

Так как нам тут нечего собирать (мы всё собираем пакетно), надо поставить флажок так, чтобы система не пыталась заниматься бесполезной работой:

На этой вкладке – всё. Переходим на вкладку Debugger. Правда, тут менять ничего не надо. По крайней мере, если у вас всё настроено так же:

Собственно, больше нигде ничего менять не надо. Ну что, запускаем отладку?

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

Проверяем первую библиотеку

Итак, скачиваем проект stm32samples/F1-nolib/CDC_ACM at master · eddyem/stm32samples · GitHub за авторством EddyEm.

Не забываем в makefile добавить формирование отладочной информации dwarf-2:

То же самое текстом:

CFLAGS	+= -O2 -g -gdwarf-2 -D__thumb2__=1 -MD

Начинаем править код.

В функции main() есть бесконечный цикл. Я оставлю от него только рожки-да-ножки:

    while (1){
        IWDG->KR = IWDG_REFRESH; // refresh watchdog
        usb_proc();
        get_USB();
    }

Рабочую функцию get_USB() я сделаю такой:

uint32_t loop = 0;
uint32_t errors = 0;
uint32_t errState = 0;
int32_t lastData = 0;
int32_t show = 0;
int32_t pkt = 0;

#define USBBUF 63
char tmpbuf[USBBUF+1];
int32_t* pData = (int32_t*) tmpbuf;
// usb getline
char *get_USB()
{
    int x = USB_receive((uint8_t*)tmpbuf) / sizeof(uint32_t);
    int i;

    show += 1;

    if(!x) return NULL;

    pkt += 1;
    // Буфер начинается с нуля - это новый цикл замеров
    // Забыли про ошибки!
    if (pData [0] == 0)
    {
         lastData = 0;
         errState = 0;
         loop += 1;
    }
    // Предотвращаем снежный ком ошибок
    if (errState)
    {
         return NULL;
    }
    // проверяем факт искажений
    for (i=0;i

uint8_t USB_receive(uint8_t *buf){
    if(/*!usbON ||*/ !rxNE) return 0;
...

    QByteArray data;
    data.resize(totalSize);

    uint32_t* dwPtr = (uint32_t*) data.constData();
    for (uint32_t i = 0;i

void usart3_isr()
{
    NVIC_ClearPendingIRQ(USART3_IRQn);
    get_USB();
}

    NVIC_SetPriority(USART3_IRQn, 15);
    NVIC_EnableIRQ(USART3_IRQn);

#include "stm32f10x.h"
…
void usb_lp_can_rx0_isr(){
   LED_off(LED0);
    if(USB->ISTR & USB_ISTR_RESET){
…
    }
    if(USB->ISTR & USB_ISTR_CTR){
        // EP number
        uint8_t n = USB->ISTR & USB_ISTR_EPID;

        if (n == 1)
        {
             NVIC_SetPendingIRQ(USART3_IRQn);
        }
        // copy status register
        uint16_t epstatus = USB->EPnR[n];
        // copy received bytes amount
…

uint32_t loop = 0;
uint32_t errors = 0;
uint32_t errState = 0;
int32_t lastData = 0;
int32_t pkt = 0;

void data_out_callback(uint8_t epnum){
  int i;
uint8_t buf[ ENDP_DATA_SIZE ];
int32_t* pData = (int32_t*) buf;

  int len = usb_ep_read_double( ENDP_DATA_OUT, buf) / sizeof (uint32_t);
  if(len == 0)return;

    pkt += 1;
    // Буфер начинается с нуля - это новый цикл замеров
    // Забыли про ошибки!
    if (pData [0] == 0)
    {
         lastData = 0;
         errState = 0;
         loop += 1;
    }
    // Предотвращаем снежный ком ошибок
    if (errState)
    {
         return NULL;
    }
    // проверяем факт искажений
    for (i=0;i