Какие пару байт? Передёргиваете. Вы писали про размер кадра немного меньше размера FIFO. Его проверить надо (валидность всех полей, CRC, etc), прогнать полученный кадр по всем веткам протокола обмена надо (а он может быть многоуровневый) и только после этого можно будет формировать ответ (который тоже нужно сформировать (CRC и т.п.)).
А представьте теперь, что как раз в это время когда Вы это всё будете делать, по другому UART пришло ещё пару байт. А если ещё в этот момент и по 3-му и по 4-му UARTам ...?
Вероятность всё меньше и меньше, но это только говорит о том, что такие ситуации будут происходить редко, и будет Ваша система работать-работать, но иногда глючить
(терять байты, нарушаться связь при идеальной линии и т.п.).

И вот не надо рассказывать про 160МГц, здесь вроде не маркетологи сидят, а кое-кто даже даташиты на МК почитывает
У Вас ПО из ОЗУ работает? Или всё-таки из флешь? А скорость флешь с ростом частоты CPU не повышается, как была около 20МГц, так и осталась даже на STM32F4.
Так что - работало-работало Ваше ПО в фоне, горя не знало, заполнило кеш строками из фоновой задачи, тут вдруг пришло прерывание от UART и полезло оно вытаскивать команды из флешь, медленно и печально на 20МГц-ах...
А ему надо успеть за 2-3 символа кучу работы обмолотить. Опа...
Хоть техасцы в Tiva сделали шину к флешь в 2 раза пошире - там быстрее должно вытаскивать команды из флешь....

CRC считается по таблице - это недолго, определить ИД и длину еще быстрее, и флеш не такой уж медленный, как кажется, во первых 64 или 128 битный доступ, плюс конвеер, скорость почти не ограничивает, если не делать умопомрачительных ветвлений.
И протокол не настолько "тупой", много чего делается до начала передачи (ответы подтверждения, запроса идентификации вновь подключенных устройств и т.д.)

CRC - это для примера. Может быть, что угодно для проверки валидности кадра.
64-битный доступ к флешь увеличивает скорость флешь всего в 2 раза (даже на линейном коде без ветвлений в случае последовательности 4-байтовых инструкций) с 20 до 40МГц (эквивалентных).
Для 160МГц без тормозов на линейном 4-байтовом коде, нужна шина 256бит к флешь-памяти. Как сделано в Tiva.

PS: Впрочем - тред уже совсем ушёл в сторону. Вас не переубедить похоже, да и нафик

А еще любое прерывание - это сброс всех конвейеров...

Для справки, в стм флеш шина 128бит и частота 30МГц. Подружитесь с математикой и посчитайте, сколько времени выполняется одна инструкция при этих частотах, и сопоставте со временем между приемом символов...
ЗЫ Для обработки моего "неудачного" протокола требуется от 25 до 40 машинных инструкций, вот и прикинте, если интересно, а переубеждать меня не надо, я не зеленый студент, и проектов дофига сделал, причем все работают как надо

Сообщение отредактировал mantech - Apr 17 2015, 17:17

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

А позвольте некропостнуть и вступить в полемику по поводу высокоуровневых либ а-ля Cube.
Я сейчас много об этом думаю, а тут на тему наткнулся, прочитал 5 страниц.
Насколько я понял, большинство не переносит Cube по причине сложности (читай - простоты использования и универсальности). Ее верхний уровень куда выше верхнего уровня той же stdlib и уж подавно opencm3, поэтому напрямую их сравнивать как бы не совсем корректно.
Я не претендую на правоту, скорее хочу взвесить все за и против.

Вот, к примеру, надо мне передать 100 байт по UART. Раньше пользовался stdlib, в прерывании вызывал функцию, которая хранит пойнтер на массив, индексирует его и отдает очередной байт. Позже появилось желание не писать это в каждом проекте, а создать либу верхнего уровня для UART. Потом был SPI и так далее. В cube сделано то же самое, только универсально (и я хочу верить, ее проверяли, во всяком случае, версии новые выходят): есть готовый обработчик прерываний, досылающий массив, и вызывающий калбек поле полной отправки.
Да, код из-за этого большой. Конечно, если я буду делать максимально маленькое или максимально быстрое приложение, ни о каком cube речи не идет. Возможно, иногда даже поллингом получится передать быстрее, чем через прерывания или DMA.
Объясните, чем он так плох? И чем хорошо использовать opencm3, который не намного удобней работы с регистрами для человека, хорошо знакомого с камнем?

Вкратце: CUBE — признак идиота. Это как ардуйня. Только даже хуже.

А Вы попробуйте не вкратце, если не сложно.
Где граница между признаком идиота и библиотекой? Графические библиотеки тоже под запретом? А готовые ОС?
Если что, я не о программе Cube, а о библиотеке, что она использует. STM позиционирует ее как замену stdperiph_lib.

Сообщение отредактировал drozel - Oct 6 2015, 05:47

Да ни чем не плох, просто всегда удивляюсь, когда кто-нибудь решает, что можно ничего не зная о камне, как правило, не читая доков, просто взять какой-нить визард, типа куба и пр... и "написать" на нем прогу любой сложности, за день или меньше... Так-то фиг с ним, пускай пишет, только потом она, почему-то не работает!!! Вот почему, блин?!

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



Скажем так, если "программист" считает, что на кубе можно все "написать" от и до, то да - признак идиота, а если его использовать, как вспомогательный инструмент к голове - то полезная вещь.
ЗЫ. А на счет ардуины - не стоит так категорично, иногда нужно сделать просто и быстро - почему и нет?? Сам себе сделал что-то подобное на МХ6 с графикой, типа виндовой - для есложных приложений с гуем - самое оно

Сообщение отредактировал mantech - Oct 6 2015, 06:31

Вот вам на пальцах:

Ну берем SPI, настраиваем по кубовски на ДМА слейв прием, все там подключаем, запускаем, вроде как работает.

Идем дальше, хотим сделать так, буфер 1024 байта, заполняется по ДМА, время от времени проверяем его и если в нем уже есть полное сообщение (определяется по размеру сообщения в заголовке и по тому сколько байт приняло ДМА), забираем сообщение и перенастриваем ДМА на прием нового сообщения. Казалось бы все функции есть, и тут на тебе!

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

Ну дальше мы добавляем кучу ошибок ввиде переменных у которых забили valotile и следовательно при оптимизации отличной от none половина задержек виснет насмерть. Дальше добавляем задержки через while которые убивают RTOS если вдруг до нее дойдет.

К этому так же надо добавить наличие просто ошибок, коих немало в кубе, то есть не оглядываясь его использовать во взрослом проекте нельзя. А если мне надо его весь прочитать и перелопатить, то почему бы мне не сделать свою нормальную библиотеку? Которая за пару тройку боевых проектов будет иметь все необходимое под проц, но написанное по моей архитектуре и в моем стиле, и с моим контролем ошибок?

Вот и получается что если какая-то игрушка то куб очень ничего для домохозяек пойдет. А если что-то взрослое да за деньги, то труда с кубом в разы больше, он не дает никакого бонуса, и потому вреден... И в целом аналогия верная, это как ардуйня...


Все естественно ИМХО.

Дак так и получается, если делать не один проект, то все-равно дорабатываешь либы под себя и убираешь ошибки. Но ИМХО, писать с нуля, например усб стеки - ну это для отпетых "гурманов"

Мне кажется пример для UART вы неудачный выбрали. ))
Дело в том, что написать универсальный обработчик UART, на мой взгляд, нецелесообразно.
С одной стороны сам USART позволяет слишком многое, а с другой стороны законченный драйвер должен обеспечивать хотя бы канальный уровень (ведущий/ведомый, контрольная сумма, контроль приёма сообщений) и сетевой (определение маршрута и логическая адресация). А это для разных протоколов существенно отличается. То есть универсальный или не получится или будет слишком громоздкий, избыточный.
Кроме того значительно чаще интересен не "универсальный драйвер для одного типа МК (например STM32F4)", а драйвер для целого семейства. И здесь начинают проявляться особенности периферии. Посмотрите мануалы для F0/F1/F3/F4 контроллеров STM. Вроде похожи, но ... Кое где предусмотрена обработка полудуплекса, а где-то нет. Где то есть аппаратная обработка логичесской адресации. Разная обработка LIN протоколов. Ещё всякие особенности ...
Причём сама работа с железом у вас составит максимум 1% от библиотеки. Думаю меньше на самом деле. И она проста до безобразия. Вам просто надо почитать описание самих регистров.
Вот и получается ...
С одной стороны - прочитать описание регистров контроллера и написать универсальную (по возможности) библиотеку своего протокола.
С другой стороны - прочитать описание библиотеки КУБ или другой, со всеми взаимоувязками (так как там одна написана через другую) и, опять же, написать библиотеку своего протокола.
...
Так ответьте мне. В чём выигрыш? Я вот просто не пойму.
У меня создаётся впечатление, что библиотеками пользуются те, кто сами вообще ничего не пишут. А берут готовый пример с просторов инета, и прикручивают что-то своё с косяками.
...
Некоторыми библиотеками я пользуюсь сам. Например Ethernet. Но думаю, там то же самое. Просто недостаток моих знаний и времени. Я уверен, что если переписать это всё под себя то работать будет комфортней намного.

Вот-вот. Мне нравится, когда отдельные куски можно выдрать без особых усилий и вставить в свою программу. Конечно, если при выдирании выясняется, что там всё со всем связано тысячью нитей, то становится грустно...


+1. Запустить UART - это вообще тривиально. А режимы там разные могут быть, как верное подмечено, то есть рассчитывать на то, что чудо-библиотека всё сделает сама, не стоит. Если UART пугает, то, может, и подходить к МК не нужно?


Я думаю, самому делать TCP - неблагодарное занятие. Читать все эти RFC (а их много), отлаживать алгоритмы в реальных условиях (а эти условия могут быть сильно разные) - куча работы. Если кто-то это уже проделал, глупо повторять этот же путь снова.

Прямо в точку!!