libopencm3, Неплохая либа для кортексов... Опции

[demiurg_spb]

https://github.com/libopencm3/libopencm3

ИМХО хорошая альтернатива стандартной библиотеке от ST и не только.

[Golikov A.]

"не о чем" - было о другом...

конкретный пример SPI обмен:
опустить CS
послать запрос - 6 байт
дождаться ответа (ножки ОК, Есть данные, Ошибка) или таймаут
в случае наличия данных принять их - 4 байта
поднять CS

Хорошо звучит написать драйвер, без блокировок, без ожиданий циклами и так далее...
А на деле что?
Прерывания принят - отправлен байт по SPI - нет, единственный способ это проверять флаг что передатчик закончил. ДМА настраивать на обмен 6 байтами - глупо, а 2 ДМА для приема 4 еще глупее. Если нет FIFO как в STM все байты сразу не запихаешь. Растянуть цикл обмена на несколько миллисекунд - глупо.

Вот и получается что "надо драйвер написать чтобы все в прерывании делал и не тормозил" - не о чем...

[AlexandrY]

ДМА настраивать на обмен 6 байтами - глупо, а 2 ДМА для приема 4 еще глупее.

Да, если недальновидно выбран микроконтроллер.

Я например сразу планирую сколько скоростных последовательных каналов будет в системе и прикидываю сколько каналов DMA понадобится.

Чем больше каналов DMA тем лучше чип заточен под RTOS.

Лучше всего здесь дела обстоять у Kinetis (32 канала), похуже у STM32F4 (16 каналов), еще хуже у LPC17xx (8 каналов)

[Dr.Alex]

Лучше всего здесь дела обстоять у Kinetis (32 канала), похуже у STM32F4 (16 каналов), еще хуже у LPC17xx (8 каналов)

Тут дело даже не в "канальности".
У STM32F4 например к каждому каналу (точнее, стриму) привязано до 8 определённых источников/приёмников данных.
Поэтому если вы хотите использовать ДМА для 2-3-4 источников, привязанных к одному стриму, то вас может ждать облом.
Точнее, облом был бы неминуем, но один и тот же источних часто (но не всегда) привязан к двум стримам (а в целом они распределены хаотично), но всё же облом вероятен (я — уже). Нет и речи о том чтобы использовать хотя бы половину стримов.

А к примеру в "тупике эволюции" блэкфине каналы ДМА не привязаны к конкретной периферии.
При этом забавно, что там каналов чуть ли не больше чем источников данных :-)))

[jcxz]

Поэтому если вы хотите использовать ДМА для 2-3-4 источников, привязанных к одному стриму, то вас может ждать облом.
Точнее, облом был бы неминуем, но один и тот же источних часто (но не всегда) привязан к двум стримам (а в целом они распределены хаотично), но всё же облом вероятен (я — уже). Нет и речи о том чтобы использовать хотя бы половину стримов.

Это одна из главных причин из-за которой недавно, при выборе МК для новой железки, мы отказались от STM32F4. Очень убого реализована периферия в нём - ни буферизации (FIFO) ни достаточного числа DMA-каналов для решения проблемы без FIFO.

Опять же иногда ДМА настроить дольше чем перепихать данные... LPC кстати имеет фифо - что здорово облегчает иногда дело, но все равно проблемы имеются...

LPC, Tiva имеют нормальные FIFO (UARTы, SPI, etc). STM32 экономит на пуговицах непонятно зачем, значительно ухудшая характеристики МК.

[mantech]

Это одна из главных причин из-за которой недавно, при выборе МК для новой железки, мы отказались от STM32F4. Очень убого реализована периферия в нём - ни буферизации (FIFO) ни достаточного числа DMA-каналов для решения проблемы без FIFO.

Че-то не пойму, или все пытаются использовать стм для ЦОС, с несколькими стримами по 100 мегабайт\сек или используют сразу всю периферию, что каналов дма нехватает или что еще...
Вот никогда эти фифо не использовал, муторно с ними, работал с 5 уартами и 2 спи одновременно, по 100мег не передавал, конечно, ибо для таких задач существуют коммуникационные процы или плис. Никаких проблем не испытывал, либо, принимал по прерываниям, либо дма, для больших пакетов.

Тут, по моему, искусственно создают бурю в стакане воды...

[jcxz]

Че-то не пойму, или все пытаются использовать стм для ЦОС, с несколькими стримами по 100 мегабайт\сек или используют сразу всю периферию, что каналов дма нехватает или что еще...
Вот никогда эти фифо не использовал, муторно с ними, работал с 5 уартами и 2 спи одновременно, по 100мег не передавал, конечно, ибо для таких задач существуют коммуникационные процы или плис.

Не для ЦОС (хотя и она там возможно в каком-то количестве будет чуть позже), но в устройстве нужно 5-6 UART (одновременно работающих и при этом желательно - не перегружающих систему прерываниями в десятки кГц) + 2 одновременно работающих SPI (20-40МГц). Это как минимум то, что в STM32 придётся делать с DMA. В старых устройствах на LPC17x примерно то же самое работает занимая всего 4 DMA-канала (2 SPI), а UART-ы без DMA нормально работают, так как имеют FIFO. Да и SPI-каналы имеют FIFO, так что, как я понимаю, меньше занимают шину блочными пересылками.
А в новом устройстве планируется более интенсивный поток по SPI-каналам (к тому-же - реалтаймовый). По этой причине в основном и отказались от STM32.
Как тут уже написали - работать с FIFO - то же самое что и без, практически никакой разницы, только частота обслуживания может быть в 16 раз меньше.

[mantech]

Как тут уже написали - работать с FIFO - то же самое что и без, практически никакой разницы, только частота обслуживания может быть в 16 раз меньше.

Это только в "тепличных" условиях. В моем случае была поддержка протоколов с пакетами разной длины от 6 до 1000 байт, причем длина указывается в первых байтах, без таймаутов, там же и ИД-пакета, которые нужно парсить "на лету", тут все фифы только вредят, и работа уартов на 115200 не сильно замедляет систему, если конечно, не нагружать прерывания чем-то еще, кроме приема...

[jcxz]

Это только в "тепличных" условиях. В моем случае была поддержка протоколов с пакетами разной длины от 6 до 1000 байт, причем длина указывается в первых байтах, без таймаутов, там же и ИД-пакета, которые нужно парсить "на лету", тут все фифы только вредят, и работа уартов на 115200 не сильно замедляет систему, если конечно, не нагружать прерывания чем-то еще, кроме приема...

Ну да... 11520*6UART*2(TX/RX) итого частота прерываний ==138240Гц, т.е. - прерывания с периодом 7.2мкс конечно не нагружают никак систему
Про случай когда надо работать всего с одним UART-ом - тут нет вопросов.
А ведь бывают ещё и бОльшие скорости по UART.
У нас тоже по всем UART-каналам идёт обмен по протоколам с размером кадров переменной длины. FIFO не мешает этому никак.

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

Когда нужно всего пару байт - никто не мешает использовать обмен по прерываниям: записать в FIFO сразу все 1...8 слов, а потом получить 1..N прерываний и вычитать.
Можно комбинировать (я так делаю при малых размерах транзакции по SPI, полностью влезающей в размер FIFO): настраиваю DMA только на приёмный канал, записываю в TX.FIFO сразу все байты (программно), а потом по окончании приёма всего пакета получаю ОДНО прерывание завершения DMA (без ожидания таймаута по завершению).
Готовность AT45DB никак не надо обходить. Считывать регистр состояния согласно документации. Хоть программно, хоть с DMA.
Никто не мешает смешивать работу через DMA с программным обменом, хоть одновременно, хоть поочередно.
В зависимости от SCLK и её соотношения с частотой CPU, можно хоть программно записать в SPI необходимую команду чтения статуса и ждать поллингом завершения приёма
(допустимо при большой SCLK, когда такое ожидание приёма занимает мало тактов и выигрыш от освобождения процессора на время передачи невелик или нету его),
хоть записать программно, настроив DMA на приём ответа и генерацию прерывания по завершению (если SCLK много меньше частоты CPU и если ждать поллингом, то
надолго займёшь CPU впустую).
На МК без FIFO всё гораздо хуже, так как нельзя записать целиком посылку в FIFO, настроив только RX.DMA.

Мы много используем AT45DB. Передача данных в драйверах идёт через DMA, опрос состояния - как я описал (у нас SCLK=25...30МГц).
Под рукой сейчас нет исходника с AT45DB, но вот подобная операция с nRF24L01+ (чтение регистра nRF24L01+ - короткая SPI-транзакция):

CODE

static void ActSSP(int cmd, int len, int stepNew)
{
Pclr(PIN_NRF_CS); //CS=low
isrStep = stepNew;
volatile HwRegsSSP *ssp = &concatAB(SSP, nSSP_nrf);
HwRegsDMA::T_CH volatile *ch = &DMA.CH[DMA_CH_nrf_RX];
//DMA-канал DMA_CH_nrf_RX статически привязан к данному SPI (nSSP_nrf), так что адрес источника (ch->SRC) и ch->LLI устанавливаются в инит-коде и каждый раз их писать не надо.
//Всё программирование DMA для запуска транзакции занимает 3 строчки кода ниже, настройка регистров: ch->DST, ch->CTL и старт RX.DMA: ch->CFG.
ch->DST = &sh.regIO.status;
ch->CTL = len + sizeof(sh.regIO.status) | 1 << 12 | B27 | B31;
ch->CFG = B0 | (DMA_REQ_nrf_RX >> 4) << 1 | 2 << 11 | B14 | B15;
ssp->CR[1] = B1; //включаем SPI-канал
__DMB();
ssp->DR = cmd; //старт передачи (и приёма)
}

static uint RegRead(REG reg)
{
ActSSP((int)reg + CMD_R_REGISTER, 1, IS_GAP);
concatAB(SSP, nSSP_nrf).DR = 0; //запись хвоста (для приёма значения регистра)
NrfCtxSw(); //переключение контекста в фоновую задачу с ожиданием завершающего DMA-IRQ, который делает CS=high
return sh.regIO.val[0];
}

Код

#define concatAB_(a, b) a##b
#define concatAB(a, b) concatAB_(a, b)

Это код для LPC17xx.

[SasaVitebsk]

Готовность AT45DB никак не надо обходить. Считывать регистр состояния согласно документации. Хоть программно, хоть с DMA.

Подскажите а в чём преимущество, если я готовность буду через DMA получать?
Просто мозг закипает.
Кто-нибудь приведёт расчёт доказывающий эффективность такой работы?
Для меня совершенно очевидна потеря производительности процессора в данном случае. Плюс явное усложнение читаемости программы. Плюс существенное замедление процесса записи флэшки.
По-моему необходимо рассчитывать производительность системы в целом. Не всегда имеет смысл передавать управление другой задаче. Учитывая, что время переключения с задачи на задачу фиксированное и зависит от выбранной ОС и особенностей процессора, чем меньше будет тик ОСи тем больше потери будут на обслуживание работы ОСи. Но тем быстрее будет реакция системы. Поэтому необходим какой-то компромисс. Но в любом случае что вызов прерывания, что передача управления другой задаче это многие десятки тактов. Если анализ занимает меньшее время, или сопоставим, нет смысла этим заниматься.

[jcxz]

Подскажите а в чём преимущество, если я готовность буду через DMA получать?
...
Учитывая, что время переключения с задачи на задачу фиксированное и зависит от выбранной ОС и особенностей процессора, чем меньше будет тик ОСи тем больше потери будут на обслуживание работы ОСи. Но тем быстрее будет реакция системы. Поэтому необходим какой-то компромисс. Но в любом случае что вызов прерывания, что передача управления другой задаче это многие десятки тактов. Если анализ занимает меньшее время, или сопоставим, нет смысла этим заниматься.

Вы мой пост вообще читали или сразу отвечать начали?
Я вообще-то там и написал, что в зависимости от соотношения частот CPU и SCLK SPI (сколько тактов CPU займёт SPI-транзакция) и от размера транзакции и нужно определять, что эффективнее - через DMA, или по прерываниям или вообще поллингом (если SCLK - велика, а транзакция == 1-2 байта).

Кстати, если речь зашла о AT45DB, то насколько помню там есть возможность быстрого чтения статуса: при активном сигнале CS и отсутствии обмена по SPI, она на линии MISO держит статус занятости. И достаточно просто прочитать состояние пина.
Хотя - может путаю с другой ИС? Уже не помню, давно работал с ней....

Хорошо, объясню подругому... Принимаю пакет, фифо настроен на 16 байт, а пакет - 7, т.е. прерывания на прием я не дождусь, а придет оно только, когда приму еще 9 байт, или таймаут, но я должен сразу ответить устройству, что принял от него пакет, а я отвечу только через мсек, а устройство будет "думать", что пакет проглотился и начнет слать новый - не годится.

Что за протокол такой кривой, что 3-4 символа задержка для него обрушивает обмен? На помойку его!
Если таймаут ответа такой короткий, то получается и ответ надо формировать в ISR, а перед этим значит надо и распарсить принятый кадр (на который отвечаем), а значит и парсер входящих кадров
(и собственно вся обработка протокола) должен быть в ISR.
Вот собственно Вы сами и ответили на свой-же вопрос про 130кГц прерываний
Так построенная работа (обработка протокола в ISR) да ещё для нескольких каналов параллельно и завалит всю вашу систему
Пока Вы будете формировать ответ с таймаутом 3-4 символа в ISR, в это время по другому каналу (работающему без FIFO) произойдёт потеря байтов.

Только не надо выдумывать следующий умозрительный случай, с протоколом работающим на низкой бодовой скорости и короткими таймаутами на ответ в 1-2 символа

ЗЫ. Лично мое мнение - фифо использовать хоть как-то удобно только под небольшие пакеты кратной длины, остальное либо прерывания, либо дма.

Главный плюс FIFO: кратное снижение необходимой частоты обслуживания хоть процессором (снижение частоты прерываний) хоть DMA (пакетные пересылки по шине, меньше её занятость).

И 130кгц прерываний, для векторного nvic - это немного. Тут все зависит от "кривости" обработчика

Немного, когда CPU нечем больше заниматься...

[mantech]

Вот собственно Вы сами и ответили на свой-же вопрос про 130кГц прерываний
Так построенная работа (обработка протокола в ISR) да ещё для нескольких каналов параллельно и завалит всю вашу систему

Не буду впадать в тупой спор, просто скажу, что кроме уартов на интах, работает файловая система, сетевой стек, парсер биткода виртуальной задачи, работа с кучей периферии, включая несколько каналов 1wire(кто в теме, тот знает, как этот протокол чувствителен к задержкам)и еще много чего... И самое главное - все работает и "не жужжит". Зависнуть все может только из-за кривости самого программиста.

Потом настраиваем прерывание на 1 символ, ставим ему не высокий приоритет и все.лекаться...

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

[jcxz]

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

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

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

[mantech]

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

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