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 раз меньше.