Много текста.
читать дальшеВиртуальный COM-порт -- очень простой и удобный интерфейс (с точки зрения компьютера) для работы с внешними устройствами.
Чтобы с микроконтроллера такое организовать, мы ставим на платы дополнительные микросхемы. Обычно это CP2102. Но на последней плате нам электронщики поставили FTDI.
С одной стороны в FTDI включается UART микроконтроллера, а с другой втыкается USB-кабель, который идёт в компьютер. Но драйвер позволяет обращаться к USB-устройству как к COM-порту.
А проблема была у меня в том, что приём данных из микроконтроллера был очень медленным. Мне надо было успевать передать из микроконтроллера все данные, что у меня на руках, быстрее, чем за секунду. А передача занимала около трёх секунд.
Шаг 1. Профилирование кода на компьютере.
Показал: 4 килобайта данных передаются нормально, потом возникает пауза в 40 мс, когда ничего не приходит. При этом программа не зависает, а постоянно пырит буфер COM-порта -- там лежат несколько байт, которые не формируют полный пакет. Ждём. Потом ещё 4 килобайта принимаются нормально и опять пауза. И т.д. По-видимому, дело не в компьютере?
Шаг 2. Профилирование кода на микроконтроллере.
Показал: между пакетами никакой паузы нету. Однако отправка каждого пакета занимает 2-3 миллисекунды вместо 1-2. Пакеты по 256 байт, число пакетов около 700. Общее время передачи 2.6 секунды.
Шаг 3. Более подробное профилирование кода на МК.
Показал: подготовка данных для пакета (копирование, подсчёт контрольных сумм и т.п.) занимает меньше 1 мс на пакет. Всё время между пакетами тратится на отсылку по UART+копирование при помощи DMA-блока.
Шаг 4. Что там с тактовыми генераторами блоков DMA и UART?
Показал: DMA работает с общесистемной частотой. UART работает на частоте в два раза меньше (100 Мгц), но это максимум, что можно выставить (такие правила у 32-битных PIC MZ).
Шаг 5. А что там с baud rate?
Показал: baud rate можно поменять. Уменьшение приводит к дальнейшему замедлению.
Вывод: первопричина тормозов в baud rate.
Шаг 6. А если посчитать, какая же скорость мне нужна?
Показал: в общем, у меня стояла скорость 921600 бод (такую рыбу мне дали программисты из соседней организации). Мне же для того, чтобы всё успевать, нужно было примерно 1400000 -- и это без учёта заголовков пакетов, контрольных сумм и стоповых битов. То есть скорость по-умолчанию была тупо недостаточной.
Шаг 7. Увеличим скорость! До 1843200.
Показал: передача данных перестала работать.
Шаг 8. Поиграем со скоростями.
Показал: скорости до 1500000 включительно работают хорошо. А 1600000 уже не работает. Но 1500000 мне не хватает (передача всех данных занимает 1100 мс).
Шаг 9. Почитаем документацию на FTDI.
Показал: это неочевидно, но скорость выставляется по формуле 3 МГц/делитель. Я задаю скорость в бодах, а микросхема подбирает подходящий делитель. Делитель может быть дробным с шагом 0.125. Казалось бы, в чём проблема? 3 МГц/1600000=1,875. Ан нет. Дробная часть допустима только для делителей от 2 и выше. Значение делителя 0 соответствует 3 МГц, а 1 -- 2 МГц. Дробная часть для 0 и 1 не принимается. Эти два значения -- исключение. На практике это значит, что после 1.5 МБод следующее допустимое значение -- 2 МБод, а затем -- 3 МБод.
Я поставил скорость 2000000 и всё заработало.
@темы:
Программирование,
Борьба с техникой
29.08.2018 в 00:49
Кто в здравом уме каждый раз пишет тэги ручками, вместо того, чтобы использовать список уже имеющихся? Ну кто-кто…
Ты упрт, скажи честно?
29.08.2018 в 04:12
29.08.2018 в 05:23
29.08.2018 в 05:43